2013–2026 SpaceX Full-Time OA / Interviews: 45 Experiences (Part 1 :)

Coverage: Part 1 covers the overall patterns, algorithm questions, implementation and take-home work, computer-science fundamentals, system design, and OOD/LLD evidence from 45 full-time SpaceX reports dated from 2013 through September 2026.

The short version

SpaceX does not use one fixed interview loop. The strongest repeat is a deep review of the candidate's own work, followed by fundamentals for the exact role.

1. Know every important line on the résumé. At least 21 of 45 reports explicitly mention a résumé review, work-history discussion, or project deep dive.
2. Prepare a technical presentation. Eleven reports mention one. Some lasted 10–15 minutes. Others lasted about an hour with panel questions.
3. Software questions are practical. Reported tasks use satellite beams, telemetry, pressure lookup tables, CSV files, DNA sequences, button events, and timestamped streams.
4. System design is not only about web apps. Ten reports mention design discussions involving satellites, real-time data, hardware tests, safety controls, fulfillment, and isolated script execution.
5. Clear thinking matters when the prompt is unclear. Several candidates received incomplete or contradictory requirements. Strong answers start with focused questions and stated assumptions.
6. The process can be long and uneven. Reports range from one short screen to 13 interview events across two application cycles.

How frequency is counted

3× means the same question family appeared in three independent candidate experiences in this 45-report set. A cross-post or follow-up from the same application counts once.

A few exact question records do not contain enough process detail to become complete Experience posts. They are marked as limited-context records instead of being mixed into the 45-report count.

These numbers show what candidates reported. They do not predict the next interview.

Main process patterns

Algorithm and data-structure questions

Algorithm 01: Starlink Beam Planner — 3× full experiences

This is the clearest repeated SpaceX coding task in the full Experience set. It appeared twice as a four-hour assessment and once in a technical phone interview.

Users and satellites are represented as three-dimensional vectors around a spherical Earth centered at (0, 0, 0). The solution assigns users to satellites and gives every selected beam one of four colors.

Reported rules:

1. A satellite must be within 45 degrees of the user's outward vertical direction.
2. One satellite can serve at most 32 users.
3. Same-color beams from one satellite must be at least 10 degrees apart.
4. Each case requires a minimum number of served users.
5. Coverage, runtime, and code quality can matter.

Practice: Starlink Beam Planner

Algorithm 02: Speed and pressure lookup family — 2×

Two reports used a hard-coded speed-to-pressure table, but the required behavior was different.

1. Linear interpolation — 1×. One report gave points including 0.0 m/s → 120.0 bar and 100.0 m/s → 300.0 bar. Pressure between known points had to be estimated with linear interpolation. Sudden pressure changes had to be avoided.
2. Lower-bound lookup — 1×. Another report asked for the pressure attached to the lower boundary of the matching speed interval. The candidate first overbuilt the solution, then simplified it to direct conditional checks after interviewer hints.

Practice: Pressure Chamber Linear Interpolation and Speed to Pressure Lookup

Algorithm 03: Monster Registry — 1× full experience, 2 verified sightings

The assessment used a CSV monster database. Given one monster name, the program had to print:

1. The monster's ID.
2. Monsters it is strong against.
3. Monsters it is weak against.
4. Every valid evolution path in depth-first order.

The detailed question evidence also preserves flexible CSV-column order, case-insensitive lookup, sorted results, and exact output sections. One additional independent report confirms the same task but does not have enough context for a full Experience post.

Practice: Monster Registry

Algorithm 04: Timestamped Telemetry Stream Differences — 1×

Subtract two ordered timestamped telemetry streams.

Important clarifications:

1. A timestamp may exist in only one stream.
2. Timestamps are in non-decreasing order.
3. Missing values must be handled correctly.
4. A follow-up introduced late events in production.
5. Downstream users needed a way to tell an initial result from a corrected result.

Practice: Timestamped Telemetry Stream Differences

Algorithm 05: Simplified Time-Based Key-Value Store — 1×

The task was a simpler timestamped key-value store. The report says the custom statement had contradictory logic and incorrect example outputs. The candidate had to clarify and correct parts of the task before coding.

Practice: Simplified Time-Based Key-Value Store

Algorithm 06: Button Combination Detector — 1×

Implement a function that detects a target combination of button presses. The report did not preserve whether order, repetition, timing, or reset behavior mattered. Those are the questions a candidate should ask before coding.

Practice: Button Combination Detector

Algorithm 07: DNA Sequence Match — 1×

Read a text file, find a matching DNA sequence, and produce the requested output. The report did not preserve the file format, match definition, overlap rules, output format, size limits, or examples.

The same six-hour assessment included another task asking for a short proposal and a coding implementation, but its subject was not disclosed.

Practice: DNA Sequence Match

Algorithm 08: Find the Duplicate Number — 1×

Given an array of length n containing positive integers from 1 through n - 1, find a duplicate pair.

The report did not clarify whether one or several values may repeat, or whether “pair” means a repeated value, two equal values, or two indices.

Practice: Find the Duplicate Number

Algorithm 09: Number of Islands — 1 limited-context record

Count connected groups of land in a grid with DFS, BFS, or union-find. The exact problem is known, but the record does not contain enough candidate context for a full Experience post.

Practice: Number of Islands

Algorithm 10: Number of Islands II — 1 limited-context record

Land positions are added over time. Return the number of islands after every addition.

Practice: Number of Islands II

Implementation, debugging, and take-home tasks

1. Restricted C++ — 2×. One task required a map-like container with no C++11 and no STL containers. Another used C or C++ with the standard library limited mainly to input/output and strings, followed by a live code review.
2. Debugging plus two small array tasks — 1×. Exact prompts were not preserved.
3. Ten bug-finding and chart questions — 1×. This was a multiple-choice take-home.
4. Ten-question C++ quiz — 1×. Exact items were not preserved.
5. Live coding with an undisclosed prompt — 2×. One session mixed live coding with system design and behavioral questions. One onsite used several coding rounds of different difficulty.
6. Debug Python multiprocessing output — 1 limited-context record. An existing program uses a process pool and asynchronous work, but output.txt stays empty. The record points toward correct pool shutdown and retrieving asynchronous results.

Computer-science fundamentals

One Full-Stack phone screen preserved nine rapid verbal questions. Each appeared in one report:

1. What is a hash table?
2. How are hash-table collisions handled?
3. How is a hash table resized?
4. What does a hash table look like in memory?
5. What is Big-O notation?
6. What is the runtime of inserting at the end of a dynamic array?
7. What is the runtime of inserting in the middle of a dynamic array?
8. What is the runtime of inserting into the correct place in a sorted linked list?
9. What is the worst-case runtime of quicksort?

Three other reports mention data structures, operating systems, C++ fundamentals, or basic programming questions without preserving the exact wording.

System-design questions

Design 01: Starlink network, satellites, and ground stations — 2×

Two experiences point to the same broad design family:

1. Design a system related to satellite management and communication between satellites and ground stations.
2. Design part of Starlink's network architecture.

The reports do not preserve the exact boundary, scale, APIs, routing model, failure behavior, or consistency needs.

Practice: Design a Satellite Fleet Management and Ground-Station Communications Platform

Design 02: Distributed real-time data processing — 1× full experience

Explain how to design a distributed system for real-time data processing. The report does not preserve throughput, latency, delivery guarantees, state, storage, replay, APIs, or failure cases.

Practice: Design a Distributed Real-Time Data Processing Platform

Design 03: Dragon component testing — 1×

Design a system for testing components used by Dragon. The report does not say whether the components are hardware, software, or both. It also does not preserve test plans, equipment limits, evidence, retries, or pass/fail rules.

Practice: Design a Hardware Component Test Orchestration Platform

Design 04: High-demand commerce and fulfillment — 1×

Design a Starlink purchasing and fulfillment service that can handle a sudden demand spike after a high-profile public post.

Practice: Design High-Demand Commerce and Fulfillment

Design 05: Managed user-script execution — 1×

Design an end-to-end system that stores, manages, and automatically runs user scripts. The report does not specify languages, triggers, isolation, security, quotas, retries, logs, or scale.

Practice: Design a Managed User-Script Execution Platform

Design 06: Fail-safe railroad crossing — 1×

Sensors detect an approaching train. Several computers participate in the control system. The gates must go down before the train arrives and rise only after it has safely passed.

Practice: Design a Fail-Safe Railroad Crossing Control System

Design 07: Browser-to-backend request lifecycle — 1 limited-context record

Explain what happens after a user enters an HTTPS URL and how the request moves through the network and backend before the page is rendered.

Practice: Design a Browser-to-Backend Request Lifecycle

Design 08: Other one-off design discussions — 4× total

Each item appeared in one experience:

1. A verbal operations-related design problem that grew from a planned ten-minute discussion to about 30 minutes. The exact prompt was not preserved.
2. A general system-design discussion inside an Application Software live-coding round. The requirements were not preserved.
3. A traditional onsite system-design round whose prompt was not preserved.
4. Code quality and integration testing for mutually dependent microservices, followed by a redesign of a previous project without cloud services and questions about Kafka, databases, and required components.

OOD / LLD

No OOD or LLD prompt qualified as a full-time question in the current 45-experience set. Two public SpaceX object-design exercises came from an internship report, so they are not counted as full-time frequency.

Continue to Part 2: mechanical and hardware questions, project and behavioral questions, all 45 experience summaries, and preparation by role.