Tidewater Freight system design interview

The interviewers engaged with your system-design choices and your Copperleaf example; Arjun’s follow-ups exposed gaps in estimation and in explaining how the live-update path works. Sofia said the team would be in touch through Priya by Thursday, September 10; prepare to defend your traffic calculations, store assumptions and update flow.

Study roadmap

1. Make estimates accurate and auditable. State the formula, calculate it, then check the result before moving on; drill with rates, per-region loads and totals. At 03:59 you said 120 writes/second, then corrected it to 1,200 after Arjun asked you to check.
2. Explain the full data path, not just the components. Practise describing how updates reach each regional subscription, how snapshots meet live changes, and what the cache does. Arjun asked “Subscribes how?” at 07:40 after your initial architecture named a cache without its role.
3. Support capacity claims with assumptions and limits. Say what workload a store or gateway must handle, what evidence supports the capacity claim, and what you would measure or test. At 04:28 you called 1,200 writes/second small for Redis and proposed one or two nodes without a supporting figure.
4. Make latency choices traceable to the requirement. Explain the freshness budget and the cost of batching, including what happens when updates are delayed. At 05:55 you justified one-second batches by frontend redraw cost and the fifteen-second expectation, but did not break down the remaining latency budget.
5. Prepare measurable outcomes for every experience claim. Keep the quantified Copperleaf contract-test result ready, and add evidence to claims such as “rendering too much” made the reports page slow. You gave no load or outcome measure for that reports-page example at 05:55.

Where they dug longest

• Traffic and capacity — Arjun: He asked for writes per second at 03:53, asked you to check your arithmetic at 04:09, and then asked whether 1,200 was a lot for the store at 04:23. You corrected the calculation yourself after the prompt.
• Per-dispatcher update rate and batching — Arjun: He asked for the read-side load at 04:41 and challenged why updates should be batched once per second at 05:50. You justified batching with frontend redraw cost and the fifteen-second freshness target.
• Gateway subscriptions and initial load — Arjun: He asked “Subscribes how?” at 07:40 and how the map behaves on first open at 07:55. You explained regional pub/sub and a snapshot followed by changes.
• Expect these same points in the next round.

Strengths and weaknesses

Strengths

• You clarified scale, update frequency, dispatcher count, freshness and history before designing at 01:00–01:55.
• You connected one-second batching to frontend redraw cost and cited your reports-page experience at 05:55.
• You gave a complete disagreement story: API changes broke pages about twice a month; contract tests caught changes before release; there were zero breakages for three months, and the lead adopted the tests for two other teams (08:48).
• You identified stale GPS data as distinct from a stopped truck and proposed showing it greyed out after a minute (06:24–06:29).

Weaknesses

• Your first traffic estimate was wrong by a factor of ten: you said 120 instead of 1,200 writes per second, then corrected it after Arjun asked you to recalculate (03:59–04:13). State the division and verify the result before presenting it.
• “A lot of traffic” did not answer the request for a number (03:47). Start with the calculated rate and distinguish writes from reads.
• “Redis is small” and “a single instance does way more” were unsupported capacity claims (04:28). Give a measured capacity, or label the assumption and propose a load test.
• Your reports-page example supported the reason for batching but not the result: “rendering too much … made it slow” had no number or outcome (05:55). Prepare a concrete before-and-after measure if you have one.
• You named a cache at 02:00 without explaining what it caches or how it reduces traffic. Describe its purpose and the requests it serves before adding it to the design.

Your weakest answer, rewritten

Question: “How much traffic?”
Your answer: “A lot? I’m not sure. It’s a lot of trucks.”
Could have sounded like: “The ingestion rate is 1,200 writes per second: 12,000 trucks sending every ten seconds. If those trucks are evenly split across 30 regions, that is about 400 trucks per region, or about 40 updates per second for a dispatcher watching one region; I’d batch changes once a second to limit frontend redraws while staying within the fifteen-second freshness target.”
Borrows from: Your corrected write-rate calculation at 04:13 and regional-load and batching answers at 04:44–05:55.

The interview by time

Strongest segment: the disagreement story, because you gave the problem, your action and measurable results, including zero breakages for three months.

Your questions

• You asked whether the live map needs the last hour of history (09:47). Arjun said dispatchers need it constantly, currently use a second tool, and it is on the roadmap.
• You asked what the first three months look like (10:09). Sofia said the live map is being rewritten and you would work on it from week one; the current map polls every thirty seconds, prompting dispatcher calls.
• Worth asking next: “For the last-hour view, what must the rewrite preserve or change about the second tool?” This follows from Arjun’s account of frequent use and the roadmap.
• Worth asking next: “What is driving the move away from thirty-second polling, and what freshness target will define success?” This follows from Sofia’s description of the current map and dispatcher calls.

Follow-up email

Draft — check before sending

Hi Sofia and Arjun,
Thanks for discussing the live-map design; I was especially interested in the last-hour history dispatchers currently get from a second tool.
For the traffic estimate, 12,000 trucks sending every ten seconds means 1,200 writes per second; my Copperleaf contract tests helped prevent breakages for three months.
Thanks again, Maya.