Software engineer interview questions — and the CV claims behind them
The behavioural and system-design questions software engineers actually get, what each one is really probing, and which line on your CV an interviewer will press hardest.
What this interview is actually testing
Whether you can reason about a system you did not design, and whether the work on your CV is work you actually did rather than work your team did.
The questions, and what each one is really asking
1.Walk me through the architecture of something you built.
What it probes: Whether you understand the system beyond your own service. Engineers who owned a piece can describe their piece; engineers who owned the design can explain why the boundaries are where they are, and what they would move.
2.Tell me about a bug that took you a long time to find.
What it probes: Debugging method, not intelligence. The good answer has a hypothesis, a way of testing it, and a moment where the obvious explanation turned out to be wrong. The weak answer is a story where the fix was luck.
3.How would you design a system to handle a hundred times the traffic?
What it probes: Whether you reach for a real bottleneck or a memorised list. Interviewers are listening for you to ask what the traffic looks like before answering.
4.Tell me about a technical decision you disagreed with.
What it probes: How you handle being overruled, and whether you can state the other side's case fairly. Engineers who can only describe the opposing argument as stupid are describing a team they were not really part of.
5.What would you do differently if you rebuilt that project today?
What it probes: Whether you have kept thinking about the work since you shipped it. A candidate with no answer either did not own it or has not looked back.
6.How do you decide when code is ready to ship?
What it probes: Your actual relationship with testing and risk, as opposed to the one on your CV. The answer that mentions a specific thing you refused to ship is worth ten that mention coverage percentages.
7.Explain something technical to me as if I were not an engineer.
What it probes: Whether you can operate with product and support people. Increasingly asked, and often the question that separates two otherwise identical candidates.
The CV claim they'll press hardest
A performance or scale number — "reduced latency by 40%", "scaled to 2M requests/day".
It is the most quoted line on an engineering CV and the easiest to be vague about, so interviewers have learned to open there. The follow-up is always some version of "how did you measure that?", and the answer needs a baseline, a method and a before-and-after you actually saw. If the number came from a dashboard someone else read out in a retro, say so — that is a fine answer, and it is much better than owning a number you cannot reconstruct.
Engineering interviews split into two halves that candidates prepare very unevenly. The coding exercise gets weeks. The conversation about your own work gets none — and it is usually the half that decides between two people who both passed the screen.
The reason is that the conversation is harder to practise generically. There is no LeetCode for “explain the system you spent two years in”, because the material is specific to you.
What the architecture question is really doing
“Walk me through the architecture of something you built” sounds like a prompt to describe a diagram. It is not. It is a test of scope.
Engineers who owned a service can describe their service accurately and then stop. Engineers who were in the design can keep going: why the boundary sits between those two components, what it cost to put it there, what they would move if they started again. Neither answer is wrong — but only one of them supports the word “architected” if that word is on your CV.
This is worth thinking about before the interview rather than during it, because the gap between the two answers is where a slightly inflated CV line becomes visible. Nobody accuses you of anything. The conversation just gets shallower, and you can feel it happening.
The numbers question, which is where CVs get tested
Performance and scale figures are the most quoted lines on engineering CVs, and interviewers know it. “Reduced p99 latency by 40%” invites exactly one follow-up: how did you measure that?
A good answer has a baseline, a method, and a before-and-after you personally saw. A shaky answer has the number and a shrug.
And the honest version — “that figure came off a dashboard our SRE quoted in the retro; my part was the query change that caused it” — is a better answer than a confident reconstruction. It is specific, it is checkable, and it tells the interviewer you know the difference between your contribution and your team’s. What does not survive is a number you cannot explain, which is precisely what an AI-written CV bullet will hand you if you let it.
Preparing from your own CV instead of a question bank
The efficient preparation is not more questions. It is three passes over the document you already sent them:
Find every number. For each, write down where it came from and how it was measured. Any you cannot source, soften before you send the CV rather than defend in the room.
Find every strong verb. “Led”, “owned”, “designed”, “architected”. For each, write the one sentence that justifies it — who else was involved, what you decided. If that sentence is uncomfortable to write, the verb is too strong.
Pick your three most probeable projects and prepare the architecture, the hardest bug, and the decision you would reverse.
That is most of the behavioural surface of an engineering interview, and all of it comes from your own material. Our free resume claim checker flags the lines an interviewer is most likely to open with, which is a quick way to find where to start; the STAR method guide covers the shape of the answers themselves.
Questions about the interview itself
- What questions should I expect in a software engineer interview?
- Beyond the coding exercise, expect an architecture walkthrough of something on your CV, a debugging story, a scaling or design discussion, and at least one question about disagreement or a decision you would change. The behavioural half is not filler — it is where teams decide between two candidates who both passed the technical screen.
- How do I prepare for a software engineer interview in a week?
- Pick the three projects on your CV you are most likely to be asked about and, for each, write down the architecture, the hardest bug, the decision you would reverse, and how any number you quoted was measured. That covers most of the behavioural surface. Spend whatever is left on the coding format the company actually uses rather than on general practice.
- Do software engineer interviews still ask about system design?
- For anything above entry level, usually yes, and often informally — an architecture question about your own work rather than a whiteboard prompt. That version is harder to prepare with generic material and easier to prepare from your own CV, because the interviewer is asking about a system you were genuinely in.