According to the source notes, Software Engineers at SpaceX work across very different teams. Some write flight software for Falcon 9, Dragon or Starship. Some build networking protocols for Starlink. Others build enterprise tools that support the factory. The notes name Flight Software, Starlink, Starshield and Test Equipment as teams where the interview emphasis differs, so the same job title can lead to quite different loops.
The notes list day-to-day work such as real-time control loops, simulation environments that test flight software against virtual hardware, automated test suites, and support for launch or test operations: monitoring telemetry and debugging anomalies as they happen. Languages reported for the role are C++, C and Python, and some enterprise teams use .NET or Go. The notes describe regular collaboration with hardware, avionics, integration and test engineers, who supply the operating limits the software has to respect.
For preparation, this means the loop goes beyond an algorithms screen. The reported questions mix standard data-structure problems with low-level topics (asynchronous FIFOs, Gray code, timing analysis), engineering physics (stress and strain, fluid flow, gas behavior) and design problems framed around physical systems. Candidates report that the onsite also includes a presentation of a project they owned. The source notes say candidates for enterprise or web-tooling roles should expect more standard software architecture questions but still be ready to reason from first principles.
Recruiter Screen
reportedCandidates report that the first call covers your background, academic achievements and why you want to join. For early-career applicants this can include GPA and occasionally standardized test scores, so have the exact figures ready. Use the call to find out which team the loop is for and whether that team gives a take-home. The source notes say emphasis differs between teams such as Flight Software, Starlink, Starshield and Test Equipment, and both answers change what you should practise next.
What to demonstrate
- Your background as described on your resume
- Academic record, including GPA and sometimes standardized test scores for early-career candidates
- Motivation for joining SpaceX in particular rather than any technology company
How to prepare
- Write a short why-SpaceX answer that names a specific program (Falcon 9, Dragon, Starship or Starlink) and the kind of software you want to work on there
- Ask which team the loop is calibrated to, whether a take-home is part of it, and whether the onsite is in person or virtual
- Mark every resume line you could not explain down to the lowest level of detail, then either prepare it or remove it
Technical Phone Screens
reportedCandidates report one to three technical interviews with engineers or engineering managers. Reported formats include live coding (sometimes on a platform such as Codility), rapid-fire CS fundamentals, and deep dives into past projects. The source does not say which round asks which question. Still, the reported coding and fundamentals questions are a good warm-up for this format: single-transaction stock profit, stack versus queue and the cost of a queue insert, plus bank questions on hash-table collisions and on detecting an ordered button sequence in an event stream. Because fundamentals questions come quickly, practise short, exact answers: the definition, the complexity, and one case where the choice matters.
What to demonstrate
- Correct, readable live code for standard data-structure and algorithm problems
- Quick, precise recall of CS fundamentals, such as the cost of basic operations on common structures
- Technical depth when an interviewer drills into a project on your resume
How to prepare
- Solve the stock-profit problem in one pass, state O(n) time and O(1) space, and cover the edge cases: prices that only fall (profit zero), a single price, an empty array
- Practise two-sentence answers on stack versus queue access order, O(1) enqueue with a linked list or circular buffer, and collision handling by chaining versus open addressing
- Practise in a plain editor without autocomplete and run your own test cases before you say you are done
Take-Home Assessment
reportedSome teams give a take-home. The source notes call it intensive: candidates report anywhere from 2 to 12 hours, on realistic scenarios such as satellite orbit optimization or low-level C++ system control. A simple solution that works and is easy to test is easier to finish in that window and easier to defend afterwards than an elaborate one. Keep the core computation separate from file and console I/O so it can be tested on its own, and write down the physical and numeric assumptions the scenario forced you to make.
What to demonstrate
- Work on a realistic scenario, such as satellite orbit optimization
- Low-level C++ system control, where the scenario calls for it
How to prepare
- Before writing code, list the assumptions the scenario forces (units, coordinate frames, sampling rates, limits) and put them at the top of the README
- Keep the logic in functions that take plain inputs so you can unit test them, and use the bank's unit-testing question to practise explaining your test choices
- For embedded or flight-software teams, review C++ ownership and memory management: RAII, smart pointers, and avoiding allocation inside time-critical loops
Onsite Interview
reportedCandidates report an onsite, or a virtual full-day equivalent, built around the technical presentation and followed by four to six back-to-back one-on-one interviews on deep domain questions, system design and behavioral fit. Some candidates also get a facility tour where the guides keep asking technical questions, so treat the tour as part of the interview. The reported questions span CS and low-level fundamentals, engineering physics, practical design and behavioral prompts, and the balance depends on the team.
What to demonstrate
- Depth on the project you present when the panel interrupts with follow-ups
- How you reason through questions asked on the spot, including during a facility tour
- Coverage across domain fundamentals, design and behavioral fit
How to prepare
- Keep a one-page sheet for each area (low-level systems, engineering physics, design, behavioral) and review it the evening before
- Practise answering an unfamiliar physics or systems question by naming the governing law, stating your assumptions and giving the direction of the answer before any numbers
- Prepare questions about the team's hardware, test setup and telemetry so the conversations and the tour go both ways
Technical Presentation
reportedCandidates report presenting a project they personally owned to a panel of SpaceX engineers. The source notes describe frequent interruptions that drill into design choices, calculations and code structure. They advise against putting anything on a slide you do not understand down to the physics level. Expect to walk through the system architecture as a block diagram, the trade-offs behind your component and protocol choices (the notes give UDP versus TCP for telemetry as an example), and a failure you diagnosed during testing.
What to demonstrate
- Ownership: whether you did the work you are presenting
- Depth: whether you can defend calculations and design choices when interrupted
- Failure analysis: how you found a root cause and verified the fix
- Clear communication of complex technical material
How to prepare
- Choose a project where you made the key decisions, and mark on the slides which parts were other people's
- For every number on a slide, have the derivation ready and know what changes if its assumption is wrong
- Run a mock where the listener interrupts every slide with 'why this and not the alternative?', and cut any slide you cannot defend
Panel Interviews
reportedCandidates report four to six interviews covering deep technical questions, system design and behavioral fit. The source does not say which interview asks which question. Reported design prompts include an optimization algorithm for satellite configuration under signal beam and pointing-angle constraints, an algorithm for a pressure chamber system that uses velocity data from mission control during liftoff, and a first-principles system for drying clothes without a standard dryer architecture. The bank adds designing a Starlink network and a battery management system. Start from requirements and physical constraints: what is measured and how often, what can fail, what the safe state is, and what the software does when a sensor or link reports a wrong value.
What to demonstrate
- Design reasoning that accounts for physical limits such as memory, thermal boundaries and network latency
- Deep domain technical knowledge for the team you are interviewing with
- Behavioral answers about ownership, disagreement and ambiguity
How to prepare
- For each reported design prompt, write down the sensors and actuators, the failure modes, the safe state, and how you would test the design in simulation before it touches hardware
- Work through an example scenario the source notes give for low-level systems, a thread-safe circular buffer in C++ without standard-library synchronization primitives, and explain the ordering guarantees it relies on; it is an example scenario, not a reported question, and it is not tied to any round
- Prepare the behavioral stories listed in this guide, each with the decision you made and what you would change
6 candidate reports. Individual accounts describe a particular role and hiring cycle.
Spacex Software Engineer interview: one-hour onsite presentation
The process moved through several technical touchpoints quickly. I had three phone interviews with different people, then reached an onsite stage that became the center of the evaluation. There, I gave a one-hour presentation on my greatest achievement. It felt fast-moving and evaluative rather than conversational. After the presentation, I was sent home right away, so I never reached the longer…
Read full experienceSoftware Engineer interview at Spacex: interview experience
I got far enough to face technically intense screens that seemed built to test end-to-end understanding. Even when a question was posed as a hypothetical, it did not feel like a formula-memory exercise. It felt as though they wanted hands-on reasoning and confidence with fundamentals across the chain. The hardest part was a run of very pointed hypotheticals that seemed only loosely connected to m…
Read full experienceSpacex Software Engineer interview experience
The recruiter-to-technical flow was fairly standard, but it became a full evaluation cycle. It started with HR or cultural fit, followed by technical conversations with team members. In one technical discussion, I spoke directly about prior jobs while several people listened and occasionally joined in. Later rounds demanded deeper understanding and clearer communication. The hiring manager was in…
Read full experienceSpacex Software Engineer interview: a surprise half-day panel
I started with HR, then met a hiring manager and a technical team member before what was described as an onsite. By the time I reached the panel, the process had grown into a full half-day onsite interview. What caught me off guard was the framing. It had been sold as a simple, quick chat, but it was really a technical interview. After I answered, they pushed back with follow-up questions that se…
Read full experienceSpacex Software Engineer interview: project details and a medium coding problem
The first round began with a resume dive and moved directly into technical questions. The interviewer focused on one of my projects and pushed on the details instead of accepting the high-level story. I felt they wanted clarity on my decisions and implementation choices, and much of the discussion rested on solid C++ fundamentals. After that, the process shifted to a coding assessment after the e…
Read full experiencePracHub editorial advice for the preparation topics above.
Putting a number, component choice or calculation on a presentation slide that you cannot derive when the panel interrupts
The source notes describe the panel drilling into design choices, calculations and code structure during the presentation. Go through your deck slide by slide and, for each figure, write down where it came from, the assumption behind it, and what changes if that assumption fails. For each component or protocol, prepare the alternative you rejected and why. Cut anything you cannot defend down to the physics level.
Guessing a number on an engineering physics question instead of reasoning aloud from the governing law
The source tip is to say plainly what you do not know and then reason from base principles. For the corner-supported steel plate, start with a free-body diagram and ask how support stiffness changes the load path (compliant pucks versus rigid steel blocks). For doubling flow through a pipe, say whether you assume laminar flow (pressure drop roughly proportional to flow rate) or turbulent flow (roughly proportional to its square). For a sealed gas, remember that pressure scales with absolute temperature, not Celsius.
Presenting team work as your own on the resume or in the presentation, then being unable to go deeper
The source notes warn that anything on your resume can be probed to the lowest level of detail, and they advise making it clear when you only played a minor part. For each project, write out which decisions you made, which you inherited, and which others made. Say this before you are asked. A smaller scope you can explain in full holds up better than a larger one that falls apart on the second follow-up.
Writing code or a design that works on paper but ignores memory limits, thermal boundaries or link latency
The source notes say candidates get rejected for not explaining how their software interacts with physical constraints. In the pressure-chamber, satellite-configuration, Starlink or battery-management prompts, state early what hardware the code runs on, how much memory and time it has, and what happens when a sensor reads out of range or a link drops. When coding, name where allocation, blocking or unbounded recursion could break a real-time budget.
Overbuilding the take-home or a design answer with layers that do not help correctness or testing
Every extra layer is something you have to finish in the time limit and defend under follow-up questions. In the take-home, keep a thin I/O shell around pure logic and include the tests you ran. In design answers, start with the simplest system that meets the stated constraints, then add a component only when you can name the failure or requirement it handles.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Describe the difference between a Hardware Description Language (HDL) …
Describe the difference between a Hardware Description Language (HDL) like Verilog and a high-level software language like C++ or Python.
Approach
- Distinguish a value from a reference to it, and say which one you handed out.
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
Follow-up
- Where could this allocate more than you expect?
- How would you prove the race exists rather than suspect it?
Explain the concepts of Static Timing Analysis (STA) and how you would…
Explain the concepts of Static Timing Analysis (STA) and how you would go about speeding up a critical timing path.
Approach
- Distinguish a value from a reference to it, and say which one you handed out.
- Say what the runtime actually does before reasoning about the code.
- Identify the window where an invariant is briefly untrue.
Follow-up
- How would you prove the race exists rather than suspect it?
- What happens if two callers reach this at the same time?
How does a clock cell differ from a standard cell in ASIC design, and …
How does a clock cell differ from a standard cell in ASIC design, and what is clock latency?
Approach
- Distinguish a value from a reference to it, and say which one you handed out.
- Reach for the cheapest primitive that closes the race, not the broadest lock.
- Say what the runtime actually does before reasoning about the code.
Follow-up
- Where could this allocate more than you expect?
- What happens if two callers reach this at the same time?
Order a job dependency graph and find its critical path
A workspace defines up to 50,000 jobs with up to 200,000 dependency edges and an estimated duration_seconds per job. Given the edge list, reject the graph if it contains a cycle and name one cycle's nodes; otherwise return a valid execution order, the earliest possible completion time with unlimited workers, and the set of jobs whose slack is zero. Then say which single job to shorten in order to cut the completion time, and by exactly how much. State the complexity of each part.
Approach
- Kahn's algorithm for the order: compute indegrees, seed a queue with zero-indegree nodes, emit and decrement. O(V + E), which at 50,000 and 200,000 is milliseconds. If fewer than V nodes are emitted, the graph contains a cycle.
- Kahn detects a cycle but cannot name one. The nodes left with indegree above zero contain every cycle, so run one DFS restricted to that residual subgraph with three-colour marking and report the stack slice from the grey node the back edge points at. That is the difference between a usable error message and 'dependency cycle detected'.
- Earliest completion with unlimited workers is the longest path, which is NP-hard on a general graph and linear on a DAG. State the precondition, then relax in topological order:
earliest_finish[v] = duration[v] + max(earliest_finish[u] for u in preds(v)), taking the max over an empty predecessor set as zero. The makespan T is the maximum over all nodes. O(V + E). - Second pass in reverse topological order for
latest_finish, thenslack[v] = latest_finish[v] - earliest_finish[v]. Zero-slack nodes form the critical path, and there can be several disjoint critical paths, so return the set rather than one chain.slack[v] = 0is exactly the statement that some longest path runs through v; equivalently, the longest path through v has lengthT - slack[v]. - The speed-up bound is the point of the question, and the obvious form of it is wrong. Shortening a zero-slack job v by d, with 0 <= d <= duration[v], cuts the makespan by
min(d, T - L_avoid(v)), whereL_avoid(v)is the longest path in the graph with v deleted: the longest path that avoids v, not the second-longest path overall. The two coincide only when the runner-up path misses v. Counterexample: A of 10 s feeds both B of 5 s and C of 4 s, so T = 15 s and the second-longest path is 14 s, yet shortening A by 10 s leaves a makespan of 5 s. The realised gain is the full 10 s, because both paths ran through A and shrank together, whilemin(10, 15 - 14)predicts 1 s. The reason is structural: shortening v reduces every path through v by d and leaves every other path alone, so the new makespan ismax(T - d, L_avoid(v)). - Compute
L_avoid(v)the direct way: delete v and re-run the same forward relaxation, O(V + E) per candidate. The cheaper equivalent skips the deletion, sinceL_avoid(v)only ever matters through that max: setduration[v] := 0, recompute the makespan asT0(v) = max(T - duration[v], L_avoid(v)), and the gain ismin(d, T - T0(v)), which is identical for every d <= duration[v]. Only zero-slack jobs are candidates, because shortening a job with positive slack changes the completion time not at all. One relaxation is milliseconds at this size, so ranking a critical set in the hundreds costs O(k(V + E)) and is worth doing exactly; a critical set in the tens of thousands is not, and there you evaluate a shortlist, longest jobs first, and say that the answer is the best of that shortlist rather than the optimum.
Worked solution 30 min
- Build four fixtures. A: 12 jobs, two branches of 100 s and 95 s that share no job. B: fixture A plus one back edge. C: two disjoint paths tied at 100 s. D: the shared-prefix case, one job of 10 s feeding a 5 s job and a 4 s job, so the longest path is 15 s and the runner-up is 14 s.
- Run Kahn; on fixture B confirm it emits fewer than V nodes, then run the residual-subgraph DFS and print the actual cycle.
- Compute
earliest_finishforward andlatest_finishbackward, and list the zero-slack set for each fixture. - For each zero-slack job v, recompute the makespan with
duration[v] := 0to getT0(v), and record both the correct boundT - T0(v)and the wrong one,T - second_longest_path, side by side. - Apply the shortening for real (20 s off the critical branch of A, 10 s off the shared prefix of D) and diff the recomputed makespan against each prediction.
Follow-up
- Only m workers are available. What happens to your answer, and what can you still promise about the schedule you produce?
- Edges arrive incrementally as the customer edits the pipeline. How do you detect a cycle at insert time without re-running Kahn over 250,000 elements?
- Durations are estimates. How would you express completion time as a distribution, and what breaks about the critical path once you do?
Decide which facts an invoice line copies instead of joining
invoice_line_item already denormalises tenant_id, which is reachable through invoice_id, and stores amount_minor even though quantity times unit_price_micros would recompute it. A reviewer asks you to normalise both away, and separately asks whether the tenant's legal name and billing address should be copied onto the invoice header. Decide each case. For every field you keep denormalised, name the read pattern or the invariant that justifies it, the anomaly the copy can develop, and the mechanism that prevents that anomaly here.
Approach
- Split the question into two kinds of copy, because they fail differently. A copy of a currently mutable fact is a cache: it drifts and needs invalidation. A copy of a fact frozen at write time is not a cache at all, it is the record of what happened, and normalising it away destroys information the source no longer holds.
- Keep tenant_id on the line. It costs 8 bytes, it leads every index on the table so no read is ever accidentally cross-tenant, and it turns a wrong join into an empty result rather than another tenant's money. Prevent the drift structurally: a unique constraint on invoice (invoice_id, tenant_id) plus a composite foreign key from the line on (invoice_id, tenant_id) makes a mismatched pair impossible, so the database enforces agreement instead of a code review.
- Keep amount_minor. Rounding must happen exactly once, at a named site, with a stated mode (half-even here). If readers recompute from quantity and unit_price_micros, every reader owns a rounding decision, and half-up and half-even diverge systematically across thousands of lines rather than cancelling out. A check constraint can bound the stored value but deliberately cannot re-derive it.
- Copy the legal name and billing address onto the invoice header, written once and never updated. The statement must show what was true when it was sealed, and the tenant record will change afterwards. This is a snapshot for the same reason
source_rollup_watermarkis stored per line: without it, nobody can reconstruct what the customer was told. - Name the read pattern that pays for all of it. Rendering, dispute response and export are per-tenant, per-period reads over thousands of lines that would otherwise join back to slowly changing dimensions that no longer hold the historical value. The write side is a once-per-period batch, so the extra columns cost nothing that matters.
- Concede the case where the reviewer is right: a mutable operational attribute such as the tenant's current plan name has no business on a line. If a report wants it, join. If a statement needs the plan as of the period, that is another snapshot and it belongs on the header with the rest.
Follow-up
- Write the composite foreign key and the unique constraint it requires on the parent. What does it cost on every line insert, and what does it do to a bulk load?
- A tenant is renamed after being invoiced. Which rows change, and what does the customer see on last quarter's PDF?
- Where does currency live, and what breaks if a tenant's billing currency changes between two periods?
Enforce a concurrent-run quota that survives simultaneous requests
A plan allows at most 20 concurrently running rows in job_run per tenant. The table holds run_id, tenant_id, workspace_id, status (queued, leased, running, succeeded, failed, timed_out, cancelled, lost), lease_token, leased_until, started_at and finished_at. Today the service runs select count(*) from job_run where tenant_id = $1 and status = 'running', compares the result to 20, then inserts. Under load a tenant exceeds the cap by exactly the number of concurrent requests. Name the anomaly, say which isolation levels do and do not prevent it, and give a version that holds, as SQL.
Approach
- Name it: write skew. Each transaction reads a predicate (the count of running rows), neither modifies what the other read, and both then insert rows that jointly violate an invariant no single row expresses. Read committed permits it. So does repeatable read, because snapshot isolation's first-updater-wins check fires only on conflicting row updates, and these are inserts touching disjoint rows.
- Enumerate the fixes with their real costs. SERIALIZABLE works: PostgreSQL's SSI tracks the predicate read and aborts one transaction with SQLSTATE 40001, which obliges the caller to retry and makes the abort rate rise with contention on a hot tenant. Folding the predicate into the write as
insert ... select ... where (select count(*) ...) < 20narrows the race to the statement's snapshot but does not close it under read committed. - Give the version that holds at read committed: serialise on a row both transactions must touch.
update tenant_concurrency set running = running + 1 where tenant_id = $1 and running < 20 returning runningupdates zero rows when the cap is reached, and zero rows is the rejection. This works because at read committed a blocked UPDATE re-evaluates its WHERE clause against the newly committed row; at repeatable read the same statement raises a serialisation error instead, so the isolation level changes the calling contract. - State the cost you just bought. That row is now a per-tenant serialisation point, so admission throughput for the tenant is bounded by one divided by the lock hold time; at a 2 ms hold that is roughly 500 admissions/second. Keep the critical section to the single UPDATE, with no network call or scheduling decision inside the transaction, and decrement in the same transaction that writes the terminal status.
- Close the leak the status enum implies: a run can end as
lost, so a crashed worker otherwise consumes a slot forever. Reconcile on a schedule againststatus = 'running' and leased_until < now(), and treat the counter as a fast path overjob_run, which stays the system of record.
Worked solution 25 min
- Seed a tenant with 19 running rows, then fire 8 concurrent sessions each running the select-then-insert, and count the resulting running rows.
- Repeat at REPEATABLE READ and confirm the count still exceeds 20.
- Repeat at SERIALIZABLE, count the 40001 aborts, and note that without a retry loop those requests fail rather than queue.
- Implement the atomic counter UPDATE, re-run the 8-way test, and confirm exactly 20 running rows with zero over-admissions.
- Kill a worker mid-run, let the lease expire, and check whether the slot comes back without intervention.
Follow-up
- Write the retry loop for the SERIALIZABLE version. What does the caller see when it keeps aborting, and what bounds the retries?
- Two regions each keep a counter. What is the effective cap, and what does admission do when the counter store is unreachable?
- The cap changes mid-flight on a plan upgrade. Do running jobs get killed, and what does the counter row look like during the change?
Given an array representing stock prices over time, write a function t…
Given an array representing stock prices over time, write a function to find the maximum profit you can achieve from a single buy and sell transaction.
Approach
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
- Fix the scope first: who calls this, how often, and what they do when it fails.
Follow-up
- What would you drop to keep the system up under load?
- How does this behave when that dependency is down for an hour?
Describe how you would design a software system to dry clothes using f…
Describe how you would design a software system to dry clothes using first principles, assuming you cannot use standard commercial dryer architectures.
Approach
- Choose a partition key and say what query it makes expensive.
- Fix the scope first: who calls this, how often, and what they do when it fails.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- What would you drop to keep the system up under load?
How would you adapt a testbench to handle protocol changes, such as mi…
How would you adapt a testbench to handle protocol changes, such as migrating from an AXI to an AHB bus interface?
Approach
- State the consistency you need, and where you are willing to be stale.
- Choose a partition key and say what query it makes expensive.
- Name the read and write paths separately; they rarely have the same bottleneck.
Follow-up
- How does this behave when that dependency is down for an hour?
- What would you drop to keep the system up under load?
A flat steel plate is suspended by four hockey pucks in the corners. D…
A flat steel plate is suspended by four hockey pucks in the corners. Describe the stresses that develop in the plate. Where are they at a maximum, and where are they at a minimum? What happens if the hockey pucks are replaced with steel blocks?
Approach
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
- State your assumptions explicitly before working the problem.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Design a machine-readable error contract for the gateway
The edge gateway serves roughly 30k requests/second to SDKs and CI pipelines that retry automatically. Today every failure returns 500 with a prose message that clients string-match on. Design the error contract: the response body fields, and the status code for a malformed body, a revoked credential, a scope the credential lacks, a row belonging to another tenant, a reused idempotency key sent with a different body, an exceeded rate limit, and an unreachable dependency. For each, state whether the client may retry and on what schedule. Deliverable: the envelope schema plus the status-to-retry table.
Approach
- Split the envelope by audience: a stable
codestring for programs, amessagedocumented as human-only and free to change, arequest_idthat joins to gateway logs, and adetailsarray for per-field problems. The code list is an enum that only ever grows. - Assign status by who has to change something: 400/422 for the caller's bytes, 401 for a credential that no longer authenticates, 403 for a scope or entitlement, 404 rather than 403 for a row in another tenant because 403 confirms the identifier exists, 409 for an idempotency conflict, 429 for a limit, 503 for a dependency.
- Derive retryability from the method and the idempotency key rather than from the status: a 5xx or a timeout is an unknown outcome, not a failure, so GET/PUT/DELETE may be retried under HTTP semantics and POST only when it carries an idempotency key.
- Put the schedule in the response: Retry-After on 429 and 503 overrides the client's own backoff; otherwise capped exponential backoff with full jitter, sleeping uniformly in [0, min(cap, base * 2^attempt)], bounded by a total attempt budget so retries expire before the caller's deadline.
- Write the negative rules into the published contract: clients must never parse
message, must tolerate unknowncodevalues by falling back to the status class, and a code's meaning is never redefined once shipped.
Worked solution 20 min
- Write the envelope as a JSON schema with four top-level fields and say which are guaranteed present on every error.
- Fill a seven-row table: condition, status, code string, retryable yes/no, and the schedule or the reason retrying cannot help.
- For each non-retryable row, write the one thing the caller must change (bytes, credential, plan, key) so nothing is marked non-retryable without a remedy.
- Add the unknown-outcome row for timeouts and 5xx separately from the other rows, and give it an action other than 'treat as failed'.
- Write two sentences of client guidance: honour Retry-After when present, apply full jitter otherwise, and stop at the attempt budget.
Follow-up
- A customer reports they retried a 500 from POST /v1/runs and ended up with two sandboxes billed. Whose bug is it, and what in your contract permits their reading?
- You need to add a new error code next quarter without a version bump. What did the v1 contract have to say for that to be non-breaking?
Hourly rollups merge one hour and lose another
Reconciliation flags one tenant on one day. Summing usage_event.quantity by hour of occurred_at gives 24 non-empty hours, but usage_rollup_hourly holds 23 rows for that tenant, workspace and SKU, one of which carries roughly the sum of two adjacent hours. Other days reconcile exactly, and the affected date matches a civil-time transition. hour_start is documented as truncated to the hour in UTC. You have both tables, the rollup job source, and its runtime environment. Give an ordered checklist, the mechanism, and the correction path for a day that may already be sealed.
Approach
- Bisect by dimension until one cell explains the whole difference: tenant, then day, then SKU, then hour. A defect confined to a single transition date already rules out deduplication and late arrival, both of which are indifferent to which hour an event lands in.
- Read the truncation with its precondition stated: date_trunc on a timestamptz value is evaluated in the session TimeZone, not in UTC. If the job connects without pinning that setting, it inherits the server or container default.
- Follow that to the collision: in a zone that observes daylight saving, two distinct UTC hours map to the same local wall-clock label at the autumn transition, so both fold into one key under the unique constraint on (tenant_id, workspace_id, sku, hour_start) and their quantities sum into one row. At the spring transition a label never occurs and the row is simply absent.
- Confirm from data rather than from reading code: run the same aggregate twice, once with the session pinned to UTC and once with the job host zone, and check that the second reproduces the stored rollup exactly.
- Fix at the source by pinning the connection to UTC explicitly, or by truncating on occurred_at AT TIME ZONE 'UTC', rather than relying on a default that differs between a developer machine, CI and production.
- Correct according to status, not convenience: an open hour is recomputed with revision incremented, a sealed hour is frozen and the difference becomes an adjustment line on the next invoice with voided_by_line_id pointing at the line it reverses.
Follow-up
- The same job also emits a daily figure for a dashboard. Why can a correct hourly rollup still produce a wrong day, and what does the tenant's billing timezone have to do with it?
- How would you detect this class automatically rather than waiting for reconciliation, given that it only manifests twice a year per zone?
Roughly ninety minutes on weeknights with one longer weekend block. The plan cuts scope rather than compressing everything, on the assumption that one thing finished per night beats four half-started.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Fix the scope and take a cold baseline
- Read the role description and write the three things the loop will almost certainly test, then write an explicit not-doing list and keep it visible all week.
- Take one twenty-five-minute coding problem and one fifteen-minute design prompt cold, and write the single sentence naming what blocked each, because those two sentences decide where the remaining evenings go.
- Set the week's rule: one thing finished every night, including the night you only have forty minutes.
Deliverable: A one-page scope with a not-doing list and two cold attempts, each carrying one sentence on what blocked it.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02One pattern, written three times from blank
- Choose the single pattern most likely to appear in your loop and write it three times from an empty file rather than editing the previous attempt.
- On the third pass, write the invariant as a comment before the loop body and the complexity before the first line of code.
- Stop at ninety minutes even if the third version is imperfect, and write the one thing you would fix given another hour.
Deliverable: Three independent implementations of the same pattern plus a note on what changed between them.
Practice prompt ↗Practice prompt ↗03One design, only to the depth you can defend
- Take one system shape and go only as far as requirements, interface and data model, refusing to draw a box you could not survive a follow-up about.
- Attach one number to each non-functional requirement, deriving it rather than asserting it, and write the assumption the number rests on.
- Write the one tradeoff you are choosing against and the observation that would make you reverse it.
Deliverable: One design at interface-and-schema depth with derived numbers and one written reversible tradeoff.
Practice prompt ↗Practice prompt ↗04Only the fundamentals you will have to defend
- Write, in under two hundred words each, the answers to the two questions that follow almost any implementation: why this structure and not the obvious alternative, and what happens to this code at a hundred times the input.
- Write what an index actually costs: faster lookups on the indexed columns against a write that now maintains a second structure, plus the cases where the planner declines to use it anyway, low selectivity, or a predicate wrapping the column in a function.
- Delete any answer you cannot deliver aloud in under a minute, since an answer that needs reading is not an answer you have.
Deliverable: Three written answers, each under two hundred words and each timed aloud.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Your own work, timed
- Write a ninety-second and a four-minute version of your main project and time both aloud rather than reading them.
- Prepare the two follow-ups that always come: what you would do differently, and how you knew it worked.
- Put one number in the first sentence and be ready to say exactly where it came from and what it excludes.
Deliverable: Two timed narratives with one defensible number in the opening line.
Practice prompt ↗Practice prompt ↗06The one full rehearsal, in the weekend block
- Run a sixty-minute mock covering a coding round and a design round in one sitting with no break, because sustained attention is the thing evenings have not trained.
- Immediately afterwards, and before hearing any feedback, write the three moments you lost the thread.
- Spend the rest of the block only on those three moments, and on nothing you merely feel shaky about.
Deliverable: Mock notes naming three failure moments with a specific fix written under each.
Practice prompt ↗Practice prompt ↗07Taper
- Write the twenty-minute warm-up you will actually do on the morning: one problem you can already solve from a blank file, one design you can narrate, and nothing you have never seen.
- Re-read only your own notes from this week and open no new material.
- Write the logistics down: the editor or shared document you will be working in, whether execution and lookups are permitted, and the sentence you will use when you do not know something.
Deliverable: A one-page card holding the design structure, the project numbers, and the logistics.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The reported behavioral prompts focus on ownership, disagreement, ambiguity and motivation. For each story, name the decision you made yourself, the trade-off behind it, what went wrong, and what you would change. The source notes warn against claiming work you did not do, so say plainly where your part ended.
Why do you want to work for SpaceX over other technology companies, an…
Why do you want to work for SpaceX over other technology companies, and how do your personal goals align with our mission of reaching Mars?
Approach
- State the situation in two sentences and spend the rest on the reasoning.
- Name the disagreement and how you resolved it with evidence.
- Pick a story where you made the decision, not one where you watched it.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Give an example of a time you took extreme ownership of a failure. Wha…
Give an example of a time you took extreme ownership of a failure. What did you learn, and how did you rectify the situation?
Approach
- State the situation in two sentences and spend the rest on the reasoning.
- Name the disagreement and how you resolved it with evidence.
- Give the blast radius: what could have broken, and what you measured.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Estimate a tenant-leading index migration you have never run
Someone needs a date. usage_event carries an index on (occurred_at) and needs (tenant_id, occurred_at); the largest tenant holds roughly a hundred times the median tenant's rows, the table is partitioned daily with years of retention, and you have never run a migration on a table this large. Give an estimate you would defend: how you decompose the work, the two or three numbers you would go and measure first, the range and confidence you state, and what you commit to when the person asking needs a single date today.
Approach
- Refuse the bare number and then give one anyway, in the form that is actually useful: a range plus the measurement that collapses it. 'Four to eleven days; one afternoon building this index on a restored copy of the largest partition takes that to within a day' is an answer, while 'it depends' is not.
- Decompose by failure mode rather than into equal chunks, because that is where estimates go wrong. On a partitioned parent you create the index ON ONLY the parent, build each partition's index with CREATE INDEX CONCURRENTLY, then ALTER INDEX ... ATTACH PARTITION, at which point the parent index becomes valid. CONCURRENTLY does not block writes but scans each partition twice, waits out older transactions, cannot run inside a transaction block, and on failure leaves an invalid index you must drop concurrently and retry.
- Name the two unknowns that dominate and price them: build time on one restored partition of realistic size, and whether the planner actually chooses the new index for the skewed tenant, since selectivity for a tenant holding most of the rows is a different question from selectivity for the median tenant. Both are half-day measurements against a replica, and both are cheaper than being wrong by a week.
- State the assumptions the range is conditional on, because that is what makes a slip a re-estimate instead of a credibility event: no partition above a stated row count, one concurrent build at a time so it does not compete with ingest for I/O, and an ingest backlog that can absorb the added write amplification while both indexes exist.
- Budget the step nobody budgets: verification and the old index's removal. Dropping the old index is fast, but deciding it is safe to drop means confirming no plan still uses it, and that confirmation waits on real traffic across a full weekly cycle rather than on your patience.
- Answer the single-date request honestly. Commit to a date for the first checkpoint — the measured build number from the replica — and to re-estimating on that date, and say plainly what you are not committing to yet. A date with a scheduled re-estimate is worth more to the asker than a confident wrong one, and you should say why in those words.
Follow-up
- The concurrent build fails half way through the largest partition. What is the state of the database and what do you do next?
- Your estimate slips by sixty percent. Which assumption broke, and at what point would you have known?
- The person asking needs the date for a customer commitment. Does your answer change?
- 01
Tell me about the most difficult technical project you have owned from start to finish. What design trade-offs did you make, and what would you do differently?
- 02
Why do you want to work for SpaceX over other technology companies, and how do your personal goals connect to its work toward Mars?
- 03
Describe a time when you had a significant technical disagreement with a teammate or manager. How did you resolve it, and what was the outcome?
- 04
How do you handle operating in an environment with highly fluid requirements and extreme ambiguity?
- 05
Give an example of a time you took extreme ownership of a failure. What did you learn, and how did you rectify the situation?
- 06
Explain what you would change if you rebuilt one of your technical projects today.
Is this an official Spacex interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Spacex. Rounds and questions reflect what candidates have reported, not a process Spacex has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How is the SpaceX Software Engineer interview different from a typical software interview?
Candidates report standard algorithm questions alongside practical system design, low-level concepts and engineering physics, plus a technical presentation where the panel interrupts to drill into your choices. Prepare all four areas instead of only algorithm practice, and weight them by the team your loop is for.
PracHub interview research ↗How should I prepare for the technical presentation?
The source notes describe a panel that interrupts often and drills into design choices, calculations and code structure, with attention to whether you owned the project and how you handled failures. Pick a project where you made the key decisions, be ready to derive every number on your slides, prepare the alternatives you rejected, and have one failure story with its root cause and fix.
PracHub interview research ↗Do I need to know physics and mechanical engineering for a software role?
According to the source notes, yes for most hardware-adjacent roles such as Flight Software, Avionics and Test Equipment: review statics, mechanics of materials and fluid dynamics. For enterprise or web-tooling roles the notes say the focus shifts toward standard software architecture, but you should still be ready to reason from first principles.
PracHub interview research ↗How long is the take-home assessment?
Candidates report that some teams assign one and that it can take anywhere from 2 to 12 hours, on scenarios such as satellite orbit optimization or low-level C++ system control. Ask your recruiter whether your team uses one, keep the solution simple and testable, and document the assumptions the scenario forced you to make.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-24