Software Engineering · Chapter 7 of 31
The software engineering loop, round by round
Five rounds, each testing something specific. Knowing which lets you choose the right story.
| Round | What it is really testing | Prepare |
|---|---|---|
| Recruiter | Level, motivation, comp fit | A one-sentence answer to why this company |
| Coding | Progress under uncertainty, thinking aloud | Two problems a day, out loud, on a timer |
| System design | Trade-off reasoning with numbers | Five designs, each ending in a bottleneck you name |
| Deep dive on your work | Whether you actually did what your CV says | One project, three levels of why on every decision |
| Behavioural / values | Conflict, failure, and whether you are pleasant to work near | Five stories, one of them a failure that was yours |
The deep dive is the round people under-prepare
You will be asked about one thing on your CV in far more detail than you expect — why that database, why that framework, what you would do differently, what the alternative was and why you rejected it. Decisions made casually two years ago need reconstructing, and ‘that was the team standard’ is an acceptable answer only if you can say what the standard was for.
The five stories, and the one everybody skips
An outcome you owned. A conflict you resolved. Something you shipped that failed. A time you changed your mind given evidence. And something you are still not sure you got right.
The last one is the differentiator. Candidates present a resolved narrative for everything, and interviewers who have done the job know that is not what engineering feels like.
What each round is actually deciding
Rounds look like tests of separate skills. They are closer to separate people answering separate questions about you, and knowing which question a round is answering changes what you should emphasise in it.
| Round | The question it answers | What to lead with |
|---|---|---|
| Recruiter screen | Is this person plausibly in range, and will they accept? | Clarity about what you want and your timeline. This round is mostly logistics and it eliminates people who are vague |
| Coding | Can they write correct code while being watched? | Your approach, out loud, before typing. And your edge cases, unprompted |
| System design | Do they make decisions with stated costs? | Numbers before boxes. Then the failure mode |
| Behavioural / values | Do we want this person on a team at 3am? | Specific situations with your own actions in them. 'We' answers fail this round |
| Hiring manager | Do I want to manage this person, and will they stay? | Your questions. This is the round where what you ask matters more than what you answer |
| Bar raiser / cross-team | Is this a company-level yes, not just a team-level one? | Consistency. This person is explicitly calibrating against candidates outside this team |
The failure modes, by round
- Coding: silence while stuck; not testing; treating the interviewer as an examiner rather than a colleague. The round is designed to be collaborative and most candidates play it solo.
- System design: drawing before asking; designing for a scale nobody specified; no failure modes. And the subtle one — having exactly one answer, when the round is testing whether you know the alternatives you rejected.
- Behavioural: answering with 'we' throughout, so the interviewer cannot establish what you did. Also: choosing a story with no conflict in it, which leaves nothing to assess.
- Hiring manager: having no questions, or only questions answerable from the careers page. This round is substantially about whether you have thought about the job.
- All rounds: not knowing why you are leaving, or describing it in a way that makes the interviewer wonder what you would say about them next.
The questions to ask, and why they work
“What does the first ninety days look like for whoever takes this?” A team with a real plan answers instantly. Hesitation is genuine information.
“What is the last thing the team shipped that did not go well, and what changed afterwards?” Tests whether the organisation learns, and it is very hard to answer with a script.
“How much of the work is new build versus operating what exists?” A number, and a surprisingly common source of post-joining disappointment.
“Who decides what the team works on?” Answers range from ‘we do’ to a chain of four names. Both are workable; you should know which you are joining.
“What would make you regret hiring someone into this role?” The most useful question available, and the one that most often produces an honest, unrehearsed answer.
These work because they are hard to answer from a script and easy to answer honestly — which means the answer is informative either way.
Check yourself