Interview guides · Rivian

Rivian Software Engineer Interview Guide

Rivian software engineer prep on operations: decide what you would need to see to know a release is going wrong.

The 60-second brief

A Software Engineer at Rivian works at the intersection of modern distributed systems, embedded hardware, and real-time vehicle operations. Software is central to the vehicle experience at Rivian, powering everything from low-level electronic control units (ECUs) and autonomous driving stacks (Perception, Planning, Middleware) to cloud-connected vehicle telemetry, mobile application backends, and factory-floor manufacturing execution systems in Normal, Illinois.

For a design discussion, a catalogue of architectures is worth less than the ability to turn a vague requirement into a data model and an API contract. A box diagram with no schema under it collapses at the first follow-up question.

Focus areas

Reconcile a movement ledger against derived positions
Make every external side effect safe to retry
Reserve inventory without overselling under concurrent allocation

Overview

Engineering teams across Rivian—including Connected Systems, Edge AI, Infotainment, Autonomy, and Enterprise Software—focus on build execution, reliability, and low-latency performance. Unlike pure web-application development, writing software at Rivian requires an understanding of how your code interacts with physical systems, resource-constrained automotive hardware, high-voltage battery management systems, wireless communication protocols, and safety-critical functional frameworks.

Engineers at Rivian design and implement production features, establish diagnostic and logging telemetry across vehicle fleets, optimize embedded execution pipelines, and scale cloud infrastructure. Candidates evaluate complex trade-offs between performance, memory footprints, system safety, and developer velocity.

The Rivian interview process

Rivian candidates report 5 rounds · ≈ 4-6 weeks. The stages below are what candidates describe, not a published process.

Introductory Call

Because the format is not fixed, the first job in the room is classification. Listen to the opening question and decide what it is: a probe into work you have already described, a fresh problem to solve now, or a conversation about how you operate. Each wants a different register, and the common failure is forcing a rehearsed structure onto a question that did not ask for it. Running a full design ritual on a ten-minute debugging question reads as not listening. When you cannot tell which it is, ask how long they want to spend and answer at that depth.

What to demonstrate

Whether the shape of your answer matches the question, so a yes-or-no gets answered before it is justified and an open prompt gets a direction before a detour
Whether you check how much depth is wanted instead of deciding for them, and whether you stop when the answer is complete rather than continuing until someone interrupts
Whether you can be redirected in the middle of an answer without restarting it from the beginning
Whether a question outside your experience gets an honest boundary followed by reasoning from what you do know, instead of a confident answer with nothing behind it

How to prepare

Rehearse one project at three lengths, roughly thirty seconds, three minutes, and a full walkthrough at the depth of a design review, and practise switching between them when someone interrupts mid-telling
Have someone ask you five questions of deliberately mixed type in one sitting without telling you the types, and score only whether you identified each one correctly before you started answering
Draft the sentence you will use to check depth, along the lines of asking whether the short version is useful here or they want the detail, and use it in a real conversation this week so the day of the round is not its first outing

Technical Screening

Input bounds are the part of the prompt most often skimmed, and they usually contain the answer. They tell you which complexity class is admissible, which narrows the search before you have thought about the problem itself. As a rough planning figure, a compiled language does on the order of 10^8 simple operations per second and an interpreted one roughly an order of magnitude less. So n up to about twenty admits enumerating subsets, a few thousand admits a quadratic pass, and a million admits neither: you need near-linear, or linear with a log factor. If the bounds are missing, ask for them.

What to demonstrate

Whether the approach is justified by the stated input size rather than by whichever pattern you recognised first
Whether you ask about the properties that change the algorithm: whether the input arrives sorted, whether duplicates occur, whether values are bounded integers, whether it all fits in memory
Whether you can name the bottleneck in your own solution and what would remove it, even when you deliberately leave it in place
Whether a claimed speedup is real, since memoising a recursion only helps when subproblems genuinely overlap and the state can be keyed cheaply

How to prepare

For each algorithm you rely on, write down the largest n it handles in roughly a second, then check two of those figures by timing them in the language you will actually type in
For two weeks, write one line naming your target complexity and the bound that justifies it before you write any code, then compare that line with what you ended up submitting
Practise the conversion backwards: given a required O(n log n), list the mechanisms that get you there (sorting, a heap, an ordered map, divide and conquer) and choose by what the problem needs to query, not by what you used last

Final Loop

Coding rounds mostly set a floor. They decide whether you clear the bar, not where you land on the ladder. Level tends to come out of the design discussion and the ownership stories, so the question worth auditing beforehand is whether the scope you describe matches the scope of the job. Work that stops at your own service, or a story whose hard part was writing the code rather than getting several people to agree on an interface, reads a level below where you think you are interviewing, and that gap is usually resolved downwards.

What to demonstrate

Whether the largest thing you describe owning ran end to end — the decision, the migration path, the rollout, and what you did when it went wrong — or stopped at the change you merged
Whether design answers include what you would not build, what you would defer, and what you would measure before committing, rather than only what the boxes are
Whether a disagreement in a story was settled with something checkable — a benchmark, a prototype, a written proposal — instead of by seniority or by waiting it out
Whether you can say which calls you made alone and which you escalated, and why the line sat where it did

How to prepare

Write your largest piece of owned work as a timeline of decisions — who decided what, when, and what you did when the plan broke — then delete every sentence whose subject is "we" and see how much survives
Take one system you know well and drill the migration answer: how old and new paths run side by side under live traffic, how you compare their outputs, what the rollback is once writes are going to both, and which step you would not automate
Map each line of the ladder in the job posting to a specific thing you have done, find the line you cannot support, and prepare the closest evidence you have plus an honest account of the gap

Project Presentation

You cannot drill a format you do not know, so put the preparation into material that travels. Three pieces of your own work, each rehearsed until you can take a follow-up you did not anticipate, will carry a conversation or a code walkthrough equally well. Specificity is what separates that from filler. A number needs its definition before it means anything: a p99 is over some window and measured at some hop, and a server-side figure excludes the queueing and network time a client would see. The number you cannot qualify is the one to leave out.

What to demonstrate

Whether your examples carry detail only someone who did the work would hold, such as what the binding constraint actually was, which alternative you rejected and why it was worse, and what you measured on each side of the change
Whether a number survives one follow-up, meaning you can say what it was measured over and whether it moved because of your change or merely alongside it
Whether a failure is described with the specific change that followed it, rather than a lesson stated in general terms
Whether your part in a team effort is stated accurately, including what other people did

How to prepare

Write a page on each of three projects covering the constraint, the option you rejected, the measurement before and after, and what went wrong. Cut any line you cannot take a follow-up on, since you are writing the parts you will be pressed on rather than a summary.
Recover the real figures while you still have access: request volume, data size, latency with its percentile and window, team size, timeline. Note where each came from, whether a dashboard, a design document or memory, and mark the estimates so you can say which they are out loud.
Take your weakest project story to someone who works in a different area and have them ask why four times in succession. The point where you run out of answer is the part to go and re-read before the round.

Technical Deep Dives

The same problem is scored by two different mechanisms depending on the format, and preparing for one does not cover the other. With a person watching, partial progress is visible and a hint is a correction you can absorb; silence is the expensive failure, because nobody can read a half-written function. With an automated grader there is no partial credit for what you were about to do, nobody to ask, and the worked examples in the prompt are the entire specification. Read them as a contract, down to whether an empty result should be an empty list or no output at all.

What to demonstrate

In a live session, whether your commentary tracks what your hands are doing, and whether a hint redirects you or gets defended against
In an automated one, whether you cover the cases the examples do not show, since the hidden cases are where the score moves
Whether you manage the clock on purpose: abandoning an approach that is not converging while there is still time to write something simpler that finishes

How to prepare

Have someone hand you a problem and feed you one deliberately wrong hint. Practise testing it against a concrete case instead of accepting or rejecting it on authority.
Do one timed run a week in a plain browser editor with autocomplete, linting and your own snippets switched off, which is closer to what these environments give you
For the automated format, write the harness before the solution: a main that feeds the worked examples plus an empty and a single-element case and prints expected against actual, so a wrong submission is caught by you first

Where candidates lose points

Ordering events by arrival rather than by event time

Offline handhelds, batch partner feeds and store-and-forward gateways deliver observations out of order as a matter of course, so a pipeline that folds whatever arrived last will flap a delivered shipment back to in transit and recompute on-time performance from the wrong facts. Message-broker ordering guarantees do not rescue this: per-partition ordering only holds within a partition, so unless the producer keys by the entity being tracked, two events for one leg can land on different partitions and be processed concurrently. The defence has two halves that are often confused - deduplicate on a stable key, then fold with a monotonic status lattice ordered by occurred_at - and both are needed, because deduplication alone still lets a stale event win. Note also that occurred_at is device-reported and therefore sometimes wrong, which is why storing received_at and a measured clock offset beside it is what makes event-time logic auditable instead of merely plausible.

Judging delivery windows and cut-offs in UTC

A delivery appointment, a receiving cut-off and a same-day promise are all statements about local wall-clock time at a specific stop, so evaluating them in UTC misclassifies on-time performance for any leg that crosses a zone, and misses cut-offs by an hour on the two days a year a region changes offset. The subtlety that catches experienced engineers is that converting a future local time to a UTC instant at write time bakes in the offset rules as they were known then: when a jurisdiction changes its rules, an appointment stored that way silently moves, which is why a future window is better stored as local wall time plus an IANA zone identifier and resolved at read time, while a past event is correctly stored as an instant. Duration arithmetic needs the same care, because a transit that spans a DST boundary is genuinely 23 or 25 hours long in local terms even though the elapsed instant count is unchanged. Storing only a date with no zone - common on partner feeds - is the version of this that cannot be fixed downstream, so the zone has to be captured at ingestion.

Check-then-act on shared state

Read, decide, write is not safe under concurrency unless the decision and the write are one atomic step: a unique constraint with conflict handling, a compare-and-set, or a row lock held for the whole transaction. Two requests can both pass the existence check before either inserts, which shows up as duplicate rows under load and never in a single-threaded test.

Trusting input because it came from your own front end

Anything crossing a trust boundary is hostile: parameterise queries instead of building SQL by concatenation, validate against an allow-list rather than a deny-list, and bound the size of anything you allocate from a request. Raising this unprompted in an API or design question is a cheap and unusually strong signal.

Questions & practice

Given a clock face, calculate the angle between the hour hand and minute hand at a specific time.

Medium · data structures and algorithms

Approach

Name the brute-force solution and its complexity before improving on it.
Restate the input: its shape, its size, and what is guaranteed about it.
State the target complexity and say which constraint rules the naive version out.

Follow-up

What is the worst case, and how likely is it on real data?
How does this change if the input no longer fits in memory?

How do you leverage hash maps for efficient lookup in high-frequency data streaming tasks?

Medium · data structures and algorithms

Approach

Name the brute-force solution and its complexity before improving on it.
Walk one small example through your approach before writing the whole thing.
State the target complexity and say which constraint rules the naive version out.

Follow-up

What is the worst case, and how likely is it on real data?
Which test case would catch an off-by-one here?

Implement dynamic array or string manipulation logic (e.g., sliding window techniques).

Medium · data structures and algorithms

Approach

Walk one small example through your approach before writing the whole thing.
Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.

Follow-up

What is the worst case, and how likely is it on real data?
How does this change if the input no longer fits in memory?

Explain object-oriented programming concepts and syntax nuances in C++.

Medium · languages, concurrency and fundamentals

Approach

Identify the window where an invariant is briefly untrue.
Reach for the cheapest primitive that closes the race, not the broadest lock.
Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

What happens if two callers reach this at the same time?
Where could this allocate more than you expect?

What are the differences between low-side and high-side switching in embedded hardware control?

Medium · languages, concurrency and fundamentals

Approach

Identify the window where an invariant is briefly untrue.
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?

Find the busiest ten-minute window per reader after deduplication

Medium · sliding window · event time · deduplication

One day of observation_event from fixed readers: source_id (reader), subject_id (container), occurred_at, received_at, dedupe_key. 300 million rows, partner and device replays resend whole windows, and some events arrive six hours after they occurred. For each reader, return the 10-minute event-time window containing the most distinct containers, with the window's start. Target linear work per reader after sorting. State the window semantics you chose, and what the job does with an event that lands after its window was already reported.

Approach

Deduplicate before windowing, on dedupe_key, and keep the two concerns separate. A replayed batch is a no-op only if the duplicate is removed first; deduplicating inside the window logic counts a resend as traffic and reports a congestion peak that never happened. Dedupe is a hash set per reader-day or a sort-unique on the key — the same sort you need anyway.
Partition by source_id and sort each partition by occurred_at, never by received_at. Arrival order is an artefact of device connectivity and partner batch cadence; a reader that went offline for six hours would otherwise show its entire backlog as one impossible burst. Sorting dominates: O(p log p) per reader of size p, O(n log n) overall.
Two pointers over the sorted partition with a hash multiset container -> count and a separate distinct integer. Advance the right pointer, incrementing the count and bumping distinct only on a 0-to-1 transition; advance the left pointer while occurred_at[left] <= occurred_at[right] - 600s, decrementing and lowering distinct only on a 1-to-0 transition, and erasing the key from the map so the map's size and distinct never diverge. Each element enters and leaves once: O(p) amortised after the sort, O(window occupancy) space.
Justify the candidate set rather than scanning every possible start. With half-open windows [t, t+600), sliding a window right until its left edge coincides with an event can only add events and never removes one, so the maximum is attained at some event's occurred_at; checking the p windows anchored at events is sufficient and exhaustive. State the half-open convention explicitly — an event exactly at t+600 belongs to the next window, and flip-flopping on that produces off-by-one disagreements between this job and whatever reads its output.
Handle lateness by choosing a policy, not by hoping. Either run over a closed event-time batch with a stated lateness allowance — the day plus six hours, so the six-hour tail is inside the batch and the day-late tail is not — or emit under a watermark and restate the affected windows when a late event lands. Both are defensible; what is not defensible is silently dropping the late event, because that is how the busiest window quietly becomes the one with the best connectivity.

Worked solution (30 min)

Write the window semantics as one sentence — half-open [t, t+600), anchored at event timestamps — at the top of the function, and make the comparisons match it.
Implement dedupe, sort, then the two-pointer scan with the multiset and the explicit distinct counter.
Build a fixture for one reader: twelve events, one container seen three times inside a window, one duplicate dedupe_key, and one event at exactly t+600.
Hand-compute the expected maximum and window start, then run.
Re-run with the fixture shuffled and with the duplicate resent five more times, confirming the answer is unchanged.

Expected result: The container seen three times contributes 1 to the distinct count; the resent duplicates contribute 0; the event at exactly t+600 falls in the next window; the reported start is an event timestamp, not a rounded clock boundary.

Verify it yourself

A brute-force O(p^2) scan over all event-anchored windows agrees on a 1,000-event fixture.
The distinct counter equals the multiset's key count at every step — assert it in the loop while testing.
Sorting by received_at instead of occurred_at changes the answer on a fixture with a backlogged device, which is the test that proves event time is doing work.

Follow-up

Two events for one container arrive from two readers a second apart. Is that congestion, a misread, or one container passing two portals?
You need this continuously rather than as a daily batch. What changes, and where does the memory go?
A device's clock is three hours fast. What does that do to this result, and how would you detect it from clock_offset_ms?

Add a required unit column and uniqueness to a live ledger

Hard · online migration · lock timeouts · unique constraints

inventory_movement holds 4.2 billion rows on PostgreSQL 15 and takes about 2,000 inserts per second around the clock. Two changes are required with no downtime: add uom_code TEXT NOT NULL, whose truthful value must come from the conversion factors in force at each row's occurred_at rather than from today's item master; and make idempotency_key UNIQUE, although duplicates predating the retry fix already exist. Give the ordered steps, the lock each one takes, its expected duration and its rollback.

Approach

ADD COLUMN with a non-volatile DEFAULT has been metadata-only since PostgreSQL 11, so no rewrite, but it still takes ACCESS EXCLUSIVE for an instant. That lock queues behind any long-running reader while blocking every statement behind it, so one 10-minute analytics scan turns a millisecond change into a 10-minute outage. Set lock_timeout to 2s and retry in a loop rather than waiting.
Reach NOT NULL without a scan under an exclusive lock: ADD CONSTRAINT ... CHECK (uom_code IS NOT NULL) NOT VALID, which is instant, then VALIDATE CONSTRAINT, which takes only SHARE UPDATE EXCLUSIVE and runs concurrently with inserts, then SET NOT NULL, which PostgreSQL 12 and later proves from the validated check and so skips its own scan. Drop the redundant check afterwards.
The truthful backfill is the long pole and must read the versioned conversion factor as of each row's occurred_at, not the current item master, or a supplier moving a case from 12 units to 10 retroactively reinterprets last quarter. Batch by primary-key range, a few thousand rows per transaction, with a sleep between batches and a resumable cursor in a control table. At 5,000 rows a second, 4.2 billion rows is roughly ten days of throttled work: that is a schedule, not a failure, and it must not block the deploy.
The UNIQUE index cannot be built until the duplicates are gone. CREATE UNIQUE INDEX CONCURRENTLY aborts on the first violation and leaves an INVALID index behind that is ignored by queries but still carries update overhead on every insert, and it can only be removed with DROP INDEX CONCURRENTLY. So: find the duplicates, resolve each one as a compensating reversal rather than a DELETE, since every duplicate key is a double-applied movement and deleting it fixes the constraint while leaving the position wrong.
Then CREATE UNIQUE INDEX CONCURRENTLY, which makes two passes over the table and waits out concurrent transactions, so budget hours here, and note it cannot run inside a transaction block: a migration framework that wraps every step in BEGIN will fail on this one. Promote it with ALTER TABLE ... ADD CONSTRAINT ... UNIQUE USING INDEX, which is a brief ACCESS EXCLUSIVE.
Question whether the constraint should cover all history. At roughly 40 bytes per key plus overhead, a btree over 4.2 billion rows is in the hundreds of gigabytes, while a retry never arrives a year later. A partial unique index bounded by a fixed occurred_at literal, rotated forward on a schedule, gives the same protection for a fraction of the size, and the predicate must be a literal because now() is not immutable.

Worked solution (45 min)

Write the migration as numbered steps with the lock mode, expected duration and rollback beside each, including the lock_timeout retry wrapper on every ACCESS EXCLUSIVE step.
On a copy at reduced scale, run ADD COLUMN while a long SELECT is open and observe writers queueing behind the lock request, then repeat with lock_timeout set and confirm the migration backs off instead.
Run the batched backfill against a versioned conversion table, kill it mid-run and restart it, confirming the control-table cursor resumes without redoing or skipping a batch.
Seed duplicate idempotency keys, attempt CREATE UNIQUE INDEX CONCURRENTLY, and confirm the INVALID index left behind, then drop it concurrently, resolve the duplicates as reversals and rebuild.
Compare the full unique index size against the partial one bounded by a fixed occurred_at literal.

Expected result: A step list where no statement holds ACCESS EXCLUSIVE for more than the lock_timeout, uom_code reaches NOT NULL without a table rewrite or a blocking scan, and idempotency_key carries a valid unique constraint with every pre-existing duplicate resolved by a compensating movement rather than a delete.

Verify it yourself

pg_stat_activity shows no statement blocked on this table for longer than lock_timeout during any step.
Row counts and SUM(delta_qty) per key are identical before and after the whole migration, except where a duplicate was reversed.
The failed-index rehearsal leaves an index marked invalid in pg_index, proving the cleanup step is needed rather than theoretical.
Every backfilled uom_code matches the factor in force at that row's occurred_at, verified on a sample spanning a known pack-size change.

Follow-up

Sequence the application deploy against these steps. When exactly may the code start writing uom_code, and when may it start requiring it?
The backfill is on day six and the conversion-factor table is itself corrected. What happens to the rows already written?
How do you roll back after SET NOT NULL is in place and half the traffic depends on the column?

Write the reconciliation query that finds ledger and position variance

Easy · aggregation · outer joins · reconciliation

inventory_movement(movement_id, item_id, node_id, lot_id, state, delta_qty) is the ledger; inventory_position(item_id, node_id, lot_id, state, qty, version, last_movement_id, reconciled_through_movement_id) is its running sum, written in the same transaction as each movement. Write one query that reports every key whose stored qty disagrees with the sum of its movements, including keys present in only one of the two tables, bounded by a watermark movement_id you pass in. State what the job does with each variance, and how you avoid re-summing four billion rows every night.

Approach

Aggregate once and join once: a CTE doing SELECT item_id, node_id, lot_id, state, SUM(delta_qty) AS ledger_qty FROM inventory_movement WHERE movement_id <= :w GROUP BY 1,2,3,4, then FULL OUTER JOIN inventory_position USING those four columns. One pass plus one hash aggregate, O(n) in movements scanned; a correlated subquery per position row instead costs one index scan per key and is orders of magnitude slower at 40 million keys.
Use FULL OUTER JOIN, not LEFT. A key with movements and no position row is the signature of a lost position update, and a position row with no movements is the signature of a write that bypassed the ledger. Both disappear under a LEFT JOIN from either side.
Compare with IS DISTINCT FROM and COALESCE the join keys out of both sides, so a missing row reads as a variance rather than as NULL = NULL evaluating to unknown and being filtered away.
Run both sides in one snapshot: either a single statement, or a REPEATABLE READ transaction. Reading positions in one transaction and movements in another manufactures variances for every key written in between.
Make it incremental with reconciled_through_movement_id: sum only movements in (reconciled_through, :w] and add that delta to the previously verified total. The catch is that sequence values are handed out before commit, so a movement whose id is below :w can become visible after the scan and would then never be re-summed. Set :w to a max(movement_id) observed a few minutes earlier, beyond the longest write transaction, and full-scan one partition per night on a rotation as a backstop.
A variance is reported, not repaired. Rewriting qty to match the ledger hides the double-applied retry that caused it; only a physical count may produce a cycle_count_adjust movement, and the location should be flagged unreliable to planning until it is counted.

Follow-up

The job finds 14 variances, all on one node, all negative. What do you look at first, and what would make you suspect the reconciliation job itself rather than the data?
How do you run this without the nightly scan competing with the ATP read path for buffer cache and I/O?
What does the query return for a key whose only movements are a receipt and its exact reversal, and is that row worth reporting?

Design a perception/sensor-fusion logging system for autonomous driving test vehicles.

Medium · system design and architecture

Approach

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.
Choose a partition key and say what query it makes expensive.

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?

Architect a real-time ingestion pipeline for processing millions of telemetry events from a connected vehicle fleet.

Medium · system design and architecture

Approach

Name the read and write paths separately; they rarely have the same bottleneck.
Fix the scope first: who calls this, how often, and what they do when it fails.
Choose a partition key and say what query it makes expensive.

Follow-up

What would you drop to keep the system up under load?
What breaks first when traffic grows ten times?

Describe the network stack and data flow for edge-to-cloud synchronization over unstable cellular connections.

Medium · system design and architecture

Approach

Name the read and write paths separately; they rarely have the same bottleneck.
Fix the scope first: who calls this, how often, and what they do when it fails.
Choose a partition key and say what query it makes expensive.

Follow-up

What would you drop to keep the system up under load?
What breaks first when traffic grows ten times?

How did you validate and test safety-critical code before releasing it to integration testing?

Medium

Approach

Say what you would check first and why it is the highest-information step.
Clarify what is being asked and what a complete answer contains.
State your assumptions explicitly before working the problem.

Follow-up

What assumption would you test first?
How would you know your answer was wrong?

Fold late, duplicated scan events into leg status

Medium · event time · partitioning · deduplication · late data

Observations arrive from handhelds, fixed readers and partner feeds: 9,000 per second average, 40,000 at peak. Partner feeds resend whole windows nightly and offline devices deliver six hours late. Each event carries dedupe_key, subject_id, observed_status, occurred_at and received_at. Design ingestion and the fold that maintains shipment_leg.status: the stream partition key, the deduplication mechanism, the ordering rule, and the handling of an event that is a week late or stamped in the future. Size observation_event's storage and partitioning.

Approach

Separate the two defences, because each alone leaves a defect. Deduplicate on dedupe_key with a unique constraint or a keyed store, then fold with a monotonic status lattice. Deduplication alone still lets a stale picked_up overwrite delivered; monotonic folding alone still double-counts a resent window in any per-event aggregate such as dwell or scan productivity.
Partition the stream by subject_id, the leg, so every event for one leg lands in one partition and is handled by one consumer. Broker ordering is per-partition only, so keying by source or device puts two events for one leg on different partitions to be processed concurrently, and the lattice would then be applied by two writers racing. Keying by leg spreads well because a single leg's event rate is physically bounded by scanning; the residual risk is a partition carrying several thousand legs of one large load, which is a throughput problem to absorb, not an ordering one.
Write the fold as: order candidates by occurred_at, compare status_rank, take the maximum, never assign by arrival. Keep superseded events with processing_status superseded instead of discarding them, because the discarded event is usually the one that explains a dispute. Since occurred_at is device-reported and sometimes wrong, the rank lattice plus clock_offset_ms is what makes the rule safe - an event whose occurred_at is in the future beyond tolerance still folds on its rank but is flagged and not trusted for timing.
Set the lateness policy in hours, not seconds. Hold a per-partition watermark at received_at minus the allowance; events behind it are still applied to the leg, because the lattice makes that safe, but any aggregate already published from them - on-time performance, dwell, carrier scorecards - must be restated rather than silently mutated, so a restatement path is part of the design. Beyond the retention horizon the event is stored with processing_status rejected_late and folded into nothing.
Size the store from the average, not the peak: 9,000 per second is about 780 million rows per day, roughly 150 GB per day at 200 bytes. Daily range partitions on occurred_at give 30 partitions for a 30-day hot window rather than hundreds, which keeps planning time sane. A late event writes into an older partition, so partitions cannot be detached on age alone - they close only after the lateness allowance. Index (subject_id, occurred_at) for the fold and the trace; a block-range index on occurred_at degrades here because insert order stops correlating with event time.

Worked solution (35 min)

Write the dedupe key and the store that enforces it, and set its retention against the partner's replay window.
Write the status lattice as explicit ranks and the fold rule, then replay the same eight events in three different orders and confirm one identical final status.
Push three events through the rule - six hours late, a week late, and occurred_at two days in the future - and name the processing_status each ends in.
Compute rows per day, bytes per day, partition count at daily granularity, and state which query the chosen index actually serves.

Expected result: Deduplication on dedupe_key plus a fold taking the maximum status_rank ordered by occurred_at, keyed by leg so ordering holds within a partition; superseded events retained; a lateness allowance measured in hours with an explicit restatement path for published aggregates; and roughly 780 million rows and 150 GB per day into daily partitions on occurred_at that close only after the allowance, indexed on (subject_id, occurred_at).

Verify it yourself

Replaying any permutation of the same event set yields the same leg status.
Replaying an entire partner window changes no status and writes no duplicate row.
A late event can raise a status but can never lower one.
The partition key is justified against the ordering requirement, not merely against even spread.

Follow-up

A partner replays a 24-hour window every night. What does that cost in the dedupe store, and how long must a dedupe key be retained to stay correct?
On-time performance was published yesterday and a late pickup event arrives today. Restate it or leave it, and what does the consumer of that number need to know?
Where does the fold's state live, and what happens when a consumer restarts in the middle of a partition?

One partner's leg statuses freeze while every other feed advances

Easy · poison message · head-of-line blocking · event ingest

Since 06:40 UTC no leg fed by one partner has changed status; every other feed is current. Ingest is healthy and CPU is flat, and observation_event rows from that source are still landing with current received_at and processing_status 'pending'. Consumer lag is growing on exactly one stream partition, whose head row has over 900 attempts and a byte-identical last_error on each one. Give the ordered diagnosis and the change that stops one unapplicable observation from stalling a partition again.

Approach

Separate the partner not sending from us not applying, because both look identical to a customer. Rows landing with current received_at and processing_status 'pending' prove ingestion is fine and the fold is stuck; if received_at had gone stale instead, this would be a partner or transport incident and nothing in the consumer would be at fault.
Read the blocked partition at its head, ordered by offset, and classify the error rather than counting it. An identical error string across 900 attempts is deterministic and implicates the payload; a varying set of connection resets, timeouts and 5xx implicates the downstream store. Only the deterministic case is a poison message.
Reproduce outside the consumer by running the fold over that one event. The usual cause here is an observed_status the partner added that has no rank in the progress lattice, or a subject_id whose leg does not exist yet, so the fold throws before it can write.
Decide the exit against the ordering contract, which is per subject and not per partition. Many legs hash into one partition, so blocking on one of them is a bug and not a guarantee. Park the row as processing_status 'rejected_malformed' with its offset in a dead-letter view, advance the offset, and block only the affected subject if the event is well-formed but not yet applicable.
Make the retry policy classify instead of counting. Deserialisation failures, unknown enum values and constraint violations are terminal and must never be retried in place; IO errors and timeouts are retryable with bounded attempts and backoff. Alert on oldest-pending age per partition, which turns positive within seconds, rather than on lag, which drifts up slowly and looks like normal backlog.

Follow-up

The parked event turns out to be a real delivered scan. How do you replay it after the code fix without double-applying, and what makes that safe?
What should the customer-facing status show for legs that were queued behind it?
The partition key is currently the leg id. What breaks if you key by partner instead, and what if you key randomly?

Suggested practice checklist

For someone fluent in a dynamic language who has shipped real work but has never had to say what the runtime is doing underneath. The week is built on measuring and deliberately breaking things, because the questions that expose this background are the ones where the interviewer asks why a second time.

Day 1 — Measure before reasoning

Take a slow piece of your own code, write down in advance where you believe the time goes, then profile it and record how wrong the guess was. The cost is usually an allocation you did not notice or an accidental quadratic membership test.
Replace one list membership test inside a loop with a set and measure at a thousand, ten thousand and a hundred thousand elements, confirming the shape of the curve rather than only that it got faster.
Write down the three quantities you can now measure instead of assert: wall time, peak memory, and call count for the function you suspected.

Deliverable: A before-and-after profile of real code plus a written note on the size of the gap between the guess and the measurement.

Day 2 — References, copies, and the bugs they produce

Write the function with a mutable default argument, call it three times, and explain the accumulating result: the default is evaluated once when the function is defined, so every call shares one object.
Build a nested structure, take a shallow copy, mutate an inner element, and show that both views changed, because a shallow copy duplicates the container and not the elements. Then fix it with a deep copy and state the cost you just accepted.
Write two functions, one mutating its argument in place and one rebinding the local name, and predict the caller's view of each before running it. That single distinction produces most of the bugs that pass their tests.

Deliverable: Three small programs whose output you predicted correctly before running, each with a one-line statement of the rule underneath.

Day 3 — Types, once, in a language that checks them

Port one module you have already written, roughly a hundred lines, into a statically typed language, and record every place the compiler demanded an answer your original had left implicit: a value that can be absent, a numeric width, a case never handled.
Write the same signature in both languages and state what the static one guarantees before the program runs and what it does not, since it will not save you from a wrong algorithm or an index out of range.
Write the difference between an interface satisfied by declaration and one satisfied structurally, with one case each where the other approach would miss the mistake.

Deliverable: One module in two languages plus a list of the questions the type checker forced you to answer.

Day 4 — Concurrency, starting with what actually runs at the same time

Run the same CPU-bound function across four threads and four processes and measure both. Under the default CPython build the threaded version will not speed up, because only one thread executes bytecode at a time; the process version will. Check which build you are on first, since free-threaded builds remove that lock and change the result.
Then run a blocking I/O workload across four threads and measure it speeding up, because the interpreter releases that lock around blocking calls, which is why treating threads as useless is wrong as a general claim.
Build the lost update: two threads each incrementing a shared counter a hundred thousand times, and show a final value below the expected sum, because an increment is a load, an add and a store and the thread can be suspended between them. Fix it with a lock and then measure what the lock costs.

Deliverable: Three measurements, threads against processes on CPU work, threads on I/O work, and a demonstrated lost update, each with the mechanism written underneath.

Day 5 — Debugging as a procedure rather than an instinct

Work one real failure as a bisection: find a revision or an input size where it is good and one where it is bad, halve repeatedly, and state the two assumptions bisection needs, that the property changes exactly once across the range and that the test is reliable.
Minimise one failing input to the smallest version that still fails, and record how many rounds it took.
Keep a hypothesis log for one bug in three columns, what I believe, what would disprove it, what I observed, and stop yourself the first time you are about to change two things at once.

Deliverable: One bug worked to root cause with a written hypothesis log and a minimised reproducing input.

Day 6 — Tests that catch the bug you are about to write

Implement an LRU cache with a capacity bound, then write the three test cases that would catch an off-by-one in eviction: insert exactly capacity items and assert nothing was evicted, insert one more and assert the least recently used key is the one gone, and read an old key just before that insert so the eviction victim changes.
Add a property test comparing your implementation against a deliberately slow reference, an ordered list scanned linearly, over a few thousand random operation sequences, because a slow reference finds the cases you would not have thought to write.
Write one numeric test that fails under exact equality and passes with a tolerance, and state why the tolerance has to be relative rather than absolute once the magnitudes grow.

Deliverable: An LRU implementation with three boundary tests, one property test against a slow reference, and one tolerance-based numeric test.

Day 7 — Debug something broken, out loud

Have someone plant three defects in a two-hundred-line program, an off-by-one, a shared mutable state bug, and a wrong error-handling path, then find them while narrating, under a fixed rule: state the hypothesis before touching anything.
Time each one and record which tool found it, reading, a printed value, a debugger, or a test, because the question asked in interviews is how you would find it rather than what it was.
Write the sentence you will use when you do not yet know the cause, one that names the next measurement instead of offering a guess.

Deliverable: A recorded debugging session with time-to-find per defect and the method that found each.

Scope is read from what you decided

Team size, service count and tickets closed say very little. Seniority shows in the decision you owned: what you chose not to build, which constraint you traded away, whose objection you had to resolve before anything could move. A large project where you executed someone else's plan is a small story.

Tell me about a time a project failed or fell behind schedule. What did you learn, and how did you adjust?

Medium · behavioural and engineering judgement

Approach

Give the blast radius: what could have broken, and what you measured.
Close with what you would do differently, concretely.
Pick a story where you made the decision, not one where you watched it.

Follow-up

What did you decide not to do, and why?
What would you do differently if you ran that again?

Ship freight cost attribution with named, dated debt

Medium · technical debt · cost attribution · scope cutting

You have eight working days to get freight cost onto order margin. The correct model allocates each shipment_leg cost across the orders on that leg through a bridge, with a stated basis such as billable weight, and attaches accessorials to the stop that incurred them. The version that fits the window copies linehaul_cost_cents onto each line, split evenly. Describe a time you shipped known debt: exactly what you cut, the guard that made the shortcut visible rather than silent, who agreed to carry it, the date it was paid down, and what it cost while it stood.

Approach

State the accepted failure concretely rather than as a category: on a multi-stop load, an even split charges a two-pallet order the same freight as a twenty-pallet order, and a detention accessorial incurred waiting at one stop is smeared across orders that were not there. Margin on small orders is understated and on large ones overstated, in a way that is systematic rather than random, so it will not average out.
Make the shortcut loud. Emit a counter on legs with more than one order, tag every attributed row with the basis used so downstream consumers can filter, and report the share of cost that went through the even split. A shortcut that reports its own frequency converts an unknown into a number you can take to the paydown conversation.
Bound the exposure before shipping: count historical legs with more than one order and the weight dispersion within them. If ninety percent of legs are single-order parcel, the debt is small and quantified; if a third are multi-stop truckload, the plan does not survive contact and you learned that in a query rather than in a finance review.
Handle the arithmetic correctly even in the shortcut, because integer minor units do not divide evenly. Splitting 100,003 cents across three orders must assign the residue deterministically, to the largest order or to the first by id, and the sum of the parts must be asserted equal to the leg cost; rounding each share independently is how a reconciliation against the carrier invoice ends up off by cents nobody can explain.
Name the owner, the date and where both are written, then report what actually happened: how much cost flowed through the shortcut, whether the paydown date held, and if it slipped, by how long and what finally forced it.
Distinguish debt you can pay from debt that compounds. An attribution you can recompute from shipment_leg and the bridge later is recoverable; one that overwrites the leg cost or discards the stop detail destroys the inputs and cannot be unwound, and a strong answer says it would have refused that version at any deadline.

Follow-up

The paydown date arrives and the team has a new deadline. What is different about this conversation from the first one?
Finance has been reporting margin off this for six weeks. What do you tell them, and what do you restate?
Which version of this shortcut would you have refused outright, and why that one?

Resolve a review disagreement over clamping a position

Easy · code review · invariants · reconciliation · disagreement

A pull request changes the pick path from a plain decrement to qty = GREATEST(qty - :n, 0) on inventory_position, because the CHECK (qty >= 0) constraint has been failing a few times a day and paging the on-call. The author argues the page is noise and a negative on-hand is meaningless anyway. You disagree. Describe a code review disagreement you had: the argument you made, how you kept it about the system rather than the person, what you conceded, and how it ended. State what the clamp destroys and what you proposed be done with the failures instead.

Approach

Name the information the clamp destroys, in one sentence: the constraint failure is the only signal that the ledger and the shelf disagree, and GREATEST turns a detectable variance into a silent one that surfaces later as a picker standing at an empty location for an order the system promised.
Concede the real half of the author's case immediately, because it is real: paging a human on a data condition that a human cannot fix at 3am is bad design. The disagreement is not whether the page should stop but whether stopping the page should also stop the evidence.
Propose the version that satisfies both: catch the constraint violation at the application boundary, write a cycle_count_adjust movement with its own reason code and reference so the correction is a first-class row rather than an invisible edit, fail the pick task with a specific error the floor can act on, and move the alert from a page to a variance report per item-node pair.
Anchor the argument in the append-only model rather than in taste. Positions are derived from inventory_movement, so a clamp makes the position stop equalling the sum of its movements and the reconciliation job now reports a permanent, unexplainable variance on that key.
Say how you handled the disagreement mechanically: the comment thread, then a short synchronous conversation once it became clear the thread was circling, and a written decision so the next person reading the clamp knows why it is not there.
State the concession you actually made, including if you lost. Losing a review and writing the detector anyway is a legitimate and common outcome worth describing plainly.

Follow-up

The clamp has already been in production for a month. How do you find out how much stock it silently absorbed?
Where should the adjustment movement get its reference, given that no count sheet exists at pick time?
The author is more senior than you and unconvinced. What is your next move?