You want to show range, so your design is ambitious. There is a streaming queue in front, a feature store in the middle, a fine-tuned language model doing the scoring, a vector database beside it and a container platform under everything. The interviewer asks small, flat questions: "why a feature store here?", "what would the simplest version look like?", "how many rows a day did we say?" Your answers get shorter. The feedback says "over-engineered", "buzzwords", or "could not size the problem", and it stings because you named tools that real companies genuinely use.
Any ML system design or case round, and it is at its worst on small-scale prompts where the real answer is unglamorous. It is common in candidates who prepared from public system design material written for large consumer platforms, since that material is honest about its own scale and students carry the diagrams across to problems a thousand times smaller. It also appears in project defence rounds, where a capstone with four services and a message broker attracts the same question. The trigger is almost always a fear that a simple answer will look like a small skill set. Linked module: 6.5 (ML system design / case round).
Every component in a design is a bill, and the interviewer is checking whether you know that.
A streaming queue is a service somebody runs, monitors, upgrades and gets paged for. A feature store is a second source of truth that can now disagree with the first one. A fine-tuned model is a training pipeline, a versioned artefact and a re-training decision every time the underlying content changes. None of those is wrong in itself; each is wrong when nothing in the problem pays for it.
The arithmetic usually settles it, and the candidate never does the arithmetic. Nine hundred listings a day is one every ninety-six seconds. Four thousand loan applications a day, over ten busy hours, is about one every nine seconds. Numbers like that do not need a distributed queue, and saying so out loud — "this is a tiny load, so one small service is enough" — scores better than any component name, because it proves you sized the problem before you solved it.
The second half of the diagnosis is the missing baseline. When a design opens at its most complex version, there is no way to tell whether the complexity bought anything. A gradient-boosted ranker that beats a bureau score by a wide margin is a result. The same ranker with no bureau-score baseline beside it is a claim. The interviewer asks "what would the simplest version look like?" precisely because the answer to that question is the measuring stick for everything above it.
The reason capable students do this is that complexity feels like competence and simplicity feels like a thin answer. In this round the reverse holds. Naming five tools shows you have read; removing four of them with a reason shows you have chosen. Only one of those is a hiring signal.
Design upward from the dumbest thing that could work, and make every added component pay a stated bill.
The three-rung ladder, always in this order.
The trigger is the part that turns an ambitious answer into a professional one. "I would use X" is a preference. "I would move to X when Y happens, and it costs me Z" is a decision.
Do the arithmetic before you draw. Convert items per day into requests per second, out loud, every time. Items per day divided by the number of busy hours, divided by 3,600. If the answer is under ten, say the load is small and design accordingly. This single habit prevents most of this entry.
Justify each box in one sentence, or delete it. Walk your own diagram and say what each component buys. If a component's sentence is "it is what people use", remove it and say why you removed it: "a feature store solves training-serving skew across many teams, and here there is one model and one team, so I would keep features in the service and revisit if a second consumer appears."
Rules are a legitimate answer. When labels are scarce or the definition is unsettled, say the first version is rules, and say what the rules produce: a review queue whose decision log becomes the label set that makes version two possible. That is not a smaller answer than a model. It is the answer that gets built.
Practise on deliberately small prompts — a three-person trust team, a single branch, one district's crop advisory — because small numbers are where this habit is exposed and corrected. Make the requests-per-second calculation a fixed step in your rubric, and refuse yourself the serving marks when it is missing. For every tool you plan to name in an interview, write one sentence on what it costs to run and one on what problem makes it worth that cost; if you cannot write both, do not name it. Grade your own capstone the same way by walking its diagram and deleting every box whose sentence is weak, since defending a lean design is far easier than defending an impressive one. Keep one line ready for the round: "the simplest thing that could work here is ..." — candidates who can finish that sentence quickly rarely get the over-engineering note.
Q: "We get about a thousand support tickets a day and want them routed to the right team. How would you build it?" Strong answer: do the arithmetic (about one a minute, so no scale problem), propose keyword rules plus the existing category field as the baseline, then a small text classifier as V1 with the accuracy bar it must clear, then name the trigger for anything larger — and say plainly that a queue, a feature store and a fine-tuned model are not paid for at this volume. Weak answer: a streaming pipeline and a fine-tuned model. The tell is whether the candidate ever converts the volume into a rate; those who do almost never over-build, and those who do not almost always do.