SpaceX does not publish its interview process or question bank, so everything below comes from candidate reports and general interview practice, not from the company. The common picture (as of October 2026): a recruiter call, a screen with the hiring manager or an engineer, often an online coding or technical assessment for software roles, and then a long final round with several interviews and sometimes a presentation of your past work. What gets asked depends on the team. This article lists the kinds of questions to prepare for, with tested code for the software ones.
Check eligibility first
Many SpaceX job postings include an export-control notice: to comply with U.S. export regulations (ITAR), applicants must be U.S. citizens, lawful permanent residents, or in certain other protected categories (refugees and asylees), unless the company can get State Department authorization. Read the notice on the specific posting before you invest weeks of preparation. If you are unsure whether it applies to you, ask the recruiter. You can see current postings and their wording on SpaceX’s job board.
What the process usually looks like
- Recruiter call. Short, about your background and why SpaceX.
- Hiring manager or engineer screen. Resume deep-dive plus fundamentals for the role. Reports differ on the exact format.
- Technical assessment (common for software roles, not universal): a timed or take-home coding test.
- Final round. Several interviews with different engineers: coding, domain depth, design, behavioral. Some candidates report presenting a past project.
Timelines reported by candidates range from a few weeks to a couple of months. Don’t treat any list of stages as fixed; ask your recruiter what to expect and focus on the job description.
Software engineering questions
Teams that write flight, ground and vehicle software often work in C++ and Python, and reports describe emphasis on correctness, error handling and performance, not only on getting the algorithm right. Expect these areas:
- Data structures and algorithms: arrays, hash maps, linked lists, heaps, trees, graphs, sorting and searching, plus complexity analysis.
- Language fundamentals: stack vs heap memory, ownership and lifetimes in C++, object-oriented design, concurrency (threads, locks, race conditions).
- Reliability: how do you make software trustworthy when a bug is expensive? Think input validation, timeouts, retries, watchdogs, testing with simulated failures, and logging that lets you reconstruct what happened.
- System design: a telemetry ingestion pipeline, a fault-tolerant command service, or a tracker for many moving objects.
Example: track many objects with position and velocity
A representative prompt is “design a system to track the position and velocity of thousands of objects, with frequent updates”. The core is a hash map from id to state, which gives O(1) add, remove, lookup and update. Clarify before you code: Are ids unique? How often does each object update? Do queries need “all objects near X” (then you need a spatial index such as a grid or k-d tree), or only lookups by id?
class Tracker:
"""Objects keyed by id; each holds a position and a velocity."""
def __init__(self):
self._objs = {}
def add(self, oid, pos, vel):
if oid in self._objs:
raise KeyError(f"duplicate id {oid}")
self._objs[oid] = [tuple(pos), tuple(vel)]
def remove(self, oid):
del self._objs[oid]
def get(self, oid):
pos, vel = self._objs[oid]
return pos, vel
def update(self, oid, pos=None, vel=None):
o = self._objs[oid]
if pos is not None:
o[0] = tuple(pos)
if vel is not None:
o[1] = tuple(vel)
def step(self, dt):
for o in self._objs.values():
o[0] = tuple(p + v * dt for p, v in zip(o[0], o[1]))
t = Tracker()
t.add("sat-1", (0, 0, 0), (1, 2, 0))
t.add("deb-7", (10, 0, 0), (-1, 0, 0.5))
t.step(2)
print(t.get("sat-1")) # ((2, 4, 0), (1, 2, 0))
print(t.get("deb-7")) # ((8, 0, 1.0), (-1, 0, 0.5))
Then discuss the trade-offs. step is O(n) per tick, which is fine for thousands of objects and a reason to move to numpy arrays or C++ structures of arrays for millions. Real systems also need timestamps (data arrives late and out of order), units, and a decision about what happens when an update refers to an unknown id. If you want to practice the dictionary part, see the Hash Map lesson.
Example: rolling average of sensor readings
“Smooth a stream of readings with the average of the last k values” tests whether you update in O(1) instead of re-summing the window each time.
from collections import deque
class RollingAverage:
def __init__(self, k):
self.k, self.buf, self.total = k, deque(), 0.0
def add(self, x):
self.buf.append(x)
self.total += x
if len(self.buf) > self.k:
self.total -= self.buf.popleft()
return self.total / len(self.buf)
r = RollingAverage(3)
print([round(r.add(x), 2) for x in [10, 20, 30, 40, 50]])
# [10.0, 15.0, 20.0, 30.0, 40.0]
Mention floating-point drift: a long-running running sum accumulates rounding error, so a production version might recompute the sum periodically.
Example: closest approach of two objects
Two objects move in straight lines at constant velocity. When are they closest? With relative position dp and relative velocity dv, the distance is smallest at t = -(dp . dv) / (dv . dv), clamped to 0 if that time is in the past, and if dv is zero the distance never changes.
import math
def closest_approach(p1, v1, p2, v2):
dp = [a - b for a, b in zip(p1, p2)]
dv = [a - b for a, b in zip(v1, v2)]
vv = sum(x * x for x in dv)
if vv == 0:
return 0.0, math.sqrt(sum(x * x for x in dp))
t = max(-sum(a * b for a, b in zip(dp, dv)) / vv, 0.0)
d = math.sqrt(sum((a + b * t) ** 2 for a, b in zip(dp, dv)))
return t, d
print(closest_approach((0, 0), (1, 0), (10, 5), (-1, 0))) # (5.0, 5.0)
print(closest_approach((0, 0), (1, 0), (10, 5), (1, 0))) # (0.0, 11.18...)
For general coding practice with step-by-step explanations, you can work through the free problems on AlgoCademy, or use LeetCode or HackerRank; what matters is explaining your reasoning aloud while you solve medium-level problems. Our post on SpaceX technical interview prep goes deeper on the algorithm side.
Mechanical, aerospace and electrical engineering questions
For hardware roles, interviews go into fundamentals of your field and how you apply them. Examples of the kind of question to be ready for:
- Thrust-to-weight ratio. Thrust divided by weight (mass times local gravity). It must exceed 1 for liftoff. For example, 1,000,000 N of thrust on an 80,000 kg vehicle gives 1,000,000 / (80,000 x 9.80665), about 1.27; with 120,000 kg it is about 0.85, and the vehicle stays on the pad. These numbers are made up for practice.
- The rocket equation. Delta-v = Isp x g0 x ln(m0 / mf), where m0 is the initial mass and mf the final mass. Be able to say why a better Isp or a lower dry-mass fraction matters, and why staging helps. With Isp 300 s, going from 100,000 kg to 20,000 kg gives about 4,735 m/s, and to 50,000 kg about 2,039 m/s (practice numbers, not a real vehicle).
- Reusability trade-offs. What does recovering a booster cost in payload, what must survive reentry and landing, and how do you inspect and refurbish it?
- Thermal management, structures, materials, power systems, radiation-tolerant electronics, communications. Review the textbook material for your specialty and be ready to work a problem on a whiteboard, stating your assumptions.
Interviewers in these rounds are usually checking whether you can set up the problem, choose reasonable simplifications and check the result against a sanity limit, more than whether you recall a formula.
Open-ended and estimation questions
Questions like “how many satellites do you need for global coverage?” or “how would you cut launch cost by half?” have no single answer. A good structure: restate the goal, list the quantities that matter, make explicit assumptions, compute a rough number, then say what would change it. Saying “I would look up X; for now I assume Y” is better than silence.
Behavioral questions
Expect questions about pressure, failure, disagreement and ownership, for example:
- Tell me about a time you were responsible for something that went wrong. What did you change afterwards?
- Describe a technical decision you made with incomplete information.
- Tell me about a time you learned something new quickly to finish a project.
- Describe a time you disagreed with a teammate or manager and how it ended.
- What is the hardest project you worked on, and what was your own contribution to it?
Prepare four or five true stories using situation, action, result, and be precise about what you did rather than what the team did. Expect detailed follow-ups on your resume and projects, so don’t list anything you can’t discuss in depth.
Company knowledge
You are not expected to know everything, but you should be able to talk about why you want to work on launch vehicles, Starship, Starlink or whichever area the posting is for, and say something specific. Read the job posting and recent public material from the company, and avoid repeating headlines you can’t explain.
How to prepare, in order
- Read the exact job posting, including the eligibility notice, and list its required skills.
- Software: solve 30 to 50 medium problems in the language the posting names (often C++ or Python), and practice small design problems like the tracker above.
- Hardware: review your core courses and work through five or six typical problems end to end with units and sanity checks.
- Write down your stories, and rehearse your project presentation if one is requested.
- Ask the recruiter about format and tools so there are no surprises.
