In this article
Before you start
Follow-ups like this happen inside the rounds described in interview process and loops.
Why interviewers ask this
A correct first solution shows that you can code; the follow-up shows whether you can run what you wrote. Candidates describe a pattern in which a solved medium problem becomes the base for a talk about scale, caching and production. These are candidate reports from our question bank, not published rubrics.
The reported prompts include a dataset ten times larger than a take-home, many calls on the same Word Ladder input, an interval merge that must scale, an image pipeline redesigned for larger data, billions of users, making the write path safe for several threads, and asking how you would monitor the code once it is deployed. For the loop around such rounds, see the Anthropic interview process.
A weak answer jumps to a tool: "add a cache". A strong answer says which assumption broke and what it costs. A Staff-level answer also names the failure the fix creates. Where an assistant is allowed in the room, how an AI-assisted coding interview is graded covers that format.
The staff follow-up from first principles
- Staff follow-up
- A staff follow-up is a question added after a solved coding problem that changes one assumption of your solution, such as input size, repetition, concurrency or failure, and asks what you would change and why.
- Four golden signals
- The four golden signals are latency, traffic, errors and saturation, the four measurements Google's monitoring chapter says to focus on if you can only measure four things about a user-facing system.
In plain words
Picture a kitchen that cooks for four tables. The chef's method works. Now forty tables arrive. The method is not wrong, but some hidden assumptions fail: one stove, one cook, no spoiled stock. The follow-up asks which assumption fails first.
The analogy breaks in one place. A kitchen can add staff freely, while code must pay for each fix in memory, speed or complexity. Say the broken assumption, the cost and the smallest fix.
In code terms, the first solution is the method that worked for four tables. The follow-up is the crowd of forty. You are not asked to rewrite everything. You are asked to find the one hidden assumption that stopped being true, and to say how much the fix will cost.
Step 1: Name the assumption the follow-up breaks
Every first solution quietly assumes things: the data fits in memory, each input is new, one thread writes, nothing fails. Each reported follow-up attacks exactly one of these. Ten times more data attacks size. Many calls on the same input attack novelty. Making the write path safe for several threads attacks the single writer. Asking how you would monitor the code in production attacks the belief that nothing fails silently. Words being added or removed attack the belief that the data never changes.
Input: your working solution. Output: one sentence, "this breaks because I assumed X". A strong answer names the assumption the follow-up breaks, before any code. The Word Ladder problem, a breadth-first search (BFS) over words that differ by one letter, shows it well: the search assumes a fixed word list. You now have the target for the next step.
Step 2: Measure the cost with a number
Put a number on the broken assumption before you fix it. Ask how often the work runs, how its cost grows and how much memory it needs. An interval merge sorts first, so its cost grows like n log n. At 100,000 intervals that is about 1.66 million steps (n log₂ n); at ten times the data it is about 19.9 million, a growth of 12.0 times, not ten.1
Memory grows more simply. At 16 bytes per interval (illustrative), 100,000 intervals take 1.6 MB and a million take 16.0 MB.1 That fits in memory, so sorting stays; the cost to watch is time.
Input: the assumption from Step 1. Output: a time figure, a memory figure and a verdict on which one hurts. A figure from this step tells the interviewer you measure first.
Step 3: Repeated inputs need a bounded cache, if inputs repeat
A cache pays only when inputs repeat, and it needs a size limit. Least recently used (LRU) is an eviction rule that drops the entry unused for the longest time. An LRU cache is a store that keeps a fixed number of recent results and applies that rule when it is full. Its hit rate is the share of lookups answered from the store. The Python documentation says it works best when recent calls are good guides to upcoming calls.
In an illustrative run of 100,000 calls over 10,000 possible inputs, a 128-entry cache hit 42.2% of calls when a few inputs were popular and 1.3% when every input was equally likely.1 At 4,096 entries the two cases reached 85.2% and 40.0%.1
The lru_cache decorator keeps up to 128 calls by default (per the functools documentation) and needs hashable arguments. Its sibling functools.cache never evicts, so memory is unbounded.
Text description of the diagram
- A 128-entry cache hit 42.2% of calls with repeating inputs and 1.3% with uniform inputs.
- At 4,096 entries the two cases reached 85.2% and 40.0%.
Step 4: Bigger data means splitting it
When data outgrows one machine, split it along its natural key. Take a prompt reported by candidates about storing features for billions of users, grouped by country and then by business type. With 200 countries and 1,000 business types (illustrative), the lookup table has 200,000 keys; at 50 feature ids of 8 bytes each it is 80 MB, small enough to copy to every server.1
The large part is per-user data. One billion records of 100 bytes (illustrative) take 100 GB, or 300 GB with three copies.1 Shard that table by user id.
For a thread-safe write path, a common pattern is one lock per shard, so writers to different shards never wait for each other. Say what a lock costs: contention on a popular shard. Streaming and chunked reads are the same idea for the ten-times-larger take-home.
Step 5: In production, fail fast and watch four signals
Production questions ask what happens when a dependency is slow or down. A circuit breaker has three states, per the Azure Architecture Center: closed, where calls pass and failures are counted; open, where calls fail immediately; and half-open, where a limited number of trial calls pass. It opens when failures pass a threshold within a time period.
An illustrative run with five failures in 30 seconds and a 10-second time-out, over 600 calls to a dependency that is down for the whole minute, sent 10 calls downstream instead of 600.1 A breaker is the opposite of a retry: while open, it fails fast.
To monitor it, track the four golden signals: latency, traffic, errors and saturation. The same chapter advises tracking error latency separately, because a failed request can be fast.
Step-by-step description
- Say which assumption broke.
- Put a number on the cost.
- Cache only if inputs repeat.
- Shard or stream bigger data.
- Fail fast and track four signals.
- A strong answer names the assumption the follow-up breaks, before any code.
- A cache pays only when inputs repeat, and it needs a size limit.
- Fail fast and watch four signals in production.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
Your solution passes. Now the same input arrives many times a day. What changes?
First I check the premise: a cache only helps if inputs repeat, so I would measure the repeat rate on real traffic. If they repeat, I memoize the search (store each result by its input) in a least recently used cache with a fixed size, keyed on the immutable arguments, because an unbounded cache grows without limit. I expose hit rate and size so I can watch them. The trade-off is staleness: if words can be inserted or deleted, I clear the cached paths when the word list changes, since one insertion can change many shortest paths. If the repeat rate is low, I skip the cache and speed up the search itself.
What makes it Staff-level: it checks the premise before adding the fix, and it names the failure the fix creates. Say it in about a minute, then stop and let the interviewer pick the thread.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Premise | Adds a fix at once | Names what changed | Checks the assumption with data |
| Cost | No figures | States time or memory growth | Measures both and picks the one that hurts |
| Fix | One tool, no limits | Fix with a size or bound | Smallest fix, with its failure mode |
| Production | Nothing | Mentions logs | Names signals and a fail-fast path |
| Communication | Silent coding | Explains while coding | Frames, answers, then invites a follow-up |
Three variants of this question
What would you change if this ran in production?
Start with the failure you fear, then the signal that shows it: slow or failing dependencies call for a circuit breaker and the four golden signals (Step 5).
What if two threads write at once?
Say what a lost or doubled write costs, then protect the shared data: one lock per shard lets writers to different shards proceed together (Step 4). Name the price, which is contention on a popular shard.
What if the data changes while you read it?
Say what a stale answer costs. For a cache, clear or refresh the entries when the data changes; for a shared table, protect each shard with its own lock (Step 4).
Common mistakes
- "I'll add a cache." (wrong) It skips whether inputs repeat; in the run above a 128-entry cache hit 1.3% of uniform calls.1 (right) "I'd measure the repeat rate first."
- "I'll use
functools.cache, it's faster." (wrong) It never evicts. (right) "I'd use a boundedlru_cachewith an explicit size." - "The cache is threadsafe, so the function runs once per input." (wrong) The documentation notes a wrapped function can be called more than once if threads miss together. (right) "Concurrent misses can repeat work; I'd accept that or add a lock."
- "A circuit breaker retries until it works." (wrong) It does the opposite. (right) "While open, it fails fast and tries a trial call later."
- "I'd watch average latency." (wrong) Fast failures hide in the average. (right) "I'd track error latency separately."
Follow-up questions
What are the usual LRU cache follow-up questions in a coding interview?
Reported ones: what is the right size, what happens on a concurrent miss, how to invalidate when data changes and how to measure hit rate. The Python function exposes its hit and miss counts through cache_info().
How do you scale a coding interview solution when the interviewer asks?
Name the broken assumption, put a number on the cost and propose the smallest fix: cache, shard, stream or fail fast. Then say what the fix breaks.
How would you optimize your take-home code to handle a dataset ten times larger?
Measure where time and memory go before changing anything; sorting-based code grows slightly faster than the data does (12.0 times for ten times the intervals).1
Is a centralized store necessary for a multi-pod circuit breaker?
No, not usually. Per-pod breaker state is the common default: each pod trips on what it sees, with no extra network call. A shared store gives one fleet-wide view, but it adds latency and a dependency that can itself fail, so it is worth it mainly when pods are few or traffic per pod is too sparse to trip reliably.
Is the staff follow-up the same as a follow-up email after an interview?
No. A follow-up email is a note to a recruiter; the staff follow-up is a technical question inside the round. Related reading: the forward deployed and applied AI engineer rounds, the AI engineer question list and the OpenAI interview process.
- The staff follow-up changes one assumption of your solved problem; name it first.
- Put a number on the cost before choosing a fix.
- A cache pays only when inputs repeat, and it needs a size limit.
- Split big data by its natural key and say what each lock costs.
- In production, fail fast and watch latency, traffic, errors and saturation.
Sources
- Circuit Breaker pattern - Azure Architecture Center — Microsoft Learn, 26 Oct 2026
- Monitoring Distributed Systems, Site Reliability Engineering, chapter 6 — Google, 1 Jan 2016
- functools: higher-order functions and operations on callable objects — Python Software Foundation, 26 Oct 2026
