Explaining a System From the Ground Up in an Interview

When an interviewer asks you to design or explain a system, the diagram is rarely what they are watching. They are watching where you start. A candidate who opens by drawing boxes for a web server, a database and a model has committed to an architecture before knowing what it has to do. A candidate who starts with the data, the users and the limits usually reaches a better diagram, and the interviewer can follow the reasoning at each step.

Start with the questions

Before drawing anything, ask the questions that change the design. Who uses the system, and how often? What counts as a correct answer, and what happens when the system is wrong? What data exists, how fresh does it need to be, and who is allowed to see it? What are the latency and cost limits, roughly? Keep the questions short and group them. Three or four well-chosen questions show that you know which details matter. Ten questions in a row can look like stalling.

If the interviewer does not know an answer, say what you would assume and why. Stating an assumption is a strength. It makes the design checkable, and it shows that you can work without complete information, which is most of the work.

State the constraints out loud

Constraints are the part of an explanation most candidates rush. Name them in a sentence each. The data arrives in daily batches, so a streaming design would add cost without benefit. Responses must come back quickly for most users, so the model call has to be small or cached. Personal data cannot leave a particular region. Each constraint removes options, and saying so tells the interviewer that your later choices follow from something real.

A useful pattern is to write the constraints on the side of the board or in your notes, then refer back to them when you make each decision. Saying given the daily batch, I would not add a queue here is clearer than a general remark about scale.

Build the system in layers

Describe the system from the outside in. Start with the user's request and the response. Then add the stages that transform the input: retrieval of relevant records, a model call, validation of the output, and whatever action follows. Then the storage, the logging and the monitoring. For an AI system, add the evaluation path as well: how you would know, after launch, that quality has dropped. Interviewers often comment on this last layer, because many candidates leave it out entirely.

Keep each layer to what it does and what it depends on. A sentence on the failure mode for each stage is usually enough: what happens if retrieval returns nothing, if the model returns malformed output, or if a downstream service is slow. That habit is what separates a diagram from an explanation.

Take a question-answering assistant over internal policy documents as an example. The layers are the user's question, the retrieval of the relevant policy sections, the prompt that includes those sections, the answer with its citations, a check that the cited sections actually support the answer, and a log of which sections were used. Each layer is small on its own. Together they show the interviewer where an answer could go wrong and how you would notice.

Go one layer deeper when asked

Interviewers will often ask you to go deeper on one part, and this is the moment the explanation is tested. Pick the stage they point to and explain the mechanism, not only the name of a technique. If the question is about retrieval, say how documents are split and indexed, what the similarity measure is actually comparing, and what it misses, such as exact identifiers or negations. If the question is about the model call, say how the input is limited, what happens when it is too long, and how you would detect a bad answer.

If you do not know a detail, say so, and reason from what you do know. I have not used this particular index, but the trade-off I would check is recall against latency is a much better answer than a confident guess. Interviewers are checking whether your reasoning holds up when it leaves familiar ground.

Silence is allowed. If you need thirty seconds to think, say that you are thinking and what you are weighing. Interviewers usually prefer a short pause to a fluent answer that wanders.

What the interviewer is checking

Most interviewers are not checking whether you name the right product. They are checking whether you can reason about an unfamiliar system in an orderly way, state your assumptions, accept a constraint that changes your plan, and notice a failure before someone else does. They also watch how you handle being wrong. A candidate who notices a flaw in their own design and repairs it openly often scores better than one whose first design looked flawless only because it was never tested.

To practice, choose a system you use every day. Explain it from the data up in five minutes, drawing only in the last two. Then have someone ask you to go one layer deeper on each stage. Note the questions you could not answer, research them, and try the explanation again a few days later. The second attempt will show you which parts of the reasoning have settled and which still depend on luck.