How to pass a software engineering technical interview

There is a specific kind of frustration in getting rejected from a role you know you could have done. You wrote the code they asked about last quarter. You have shipped the thing they are hiring for. And still the email arrives, three days later, saying they have decided to move forward with other candidates.

It usually isn't a knowledge problem. It's a demonstration problem. Interviews are a lossy channel, and the engineers who do well are the ones who have learned to push signal through it.

First, work out which round you are actually in

Candidates lose a surprising amount of ground by preparing for the wrong thing. A take-home rewards polish and tests. A live coding round rewards narration and recovery. A system design round barely cares whether your code compiles. And an AI screen, now the first filter at a growing number of companies, rewards something different again.

Before you prepare, get specific about the format. Ask the recruiter directly: how long, live or asynchronous, human or automated, coding or discussion, and what the interviewer will be looking at afterwards. Recruiters answer this question honestly almost every time, and almost nobody asks it.

• Recruiter screen. Not technical, but it sets your level. Say the level you want out loud, early.
• Automated or AI screen. A recorded or transcribed technical conversation, scored after the fact. See how AI technical screens actually work.
• Live coding. Someone watches you write code. Narration and recovery matter as much as the solution.
• Technical deep dive. A conversation about what you know and what you have built. This is where seniority gets decided.
• System design. Usually senior and above. Judged on how you reason about scale, failure and trade-offs.
• Behavioural or hiring manager. Ownership, conflict, judgement. Rarely the thing that sinks a strong technical candidate, but it can.

The second question decides the interview

Here is the pattern that shows up in almost every technical conversation. You are asked something reasonable. You answer it correctly. Then the interviewer asks a follow-up that goes one layer deeper into the exact thing you just said.

That follow-up is the interview. The first question is a doorway. The second one is the measurement, because it is generated from your own words, which means you cannot have rehearsed it and you cannot dodge it with a memorised paragraph.

So the useful preparation question is not "what will they ask me". It's "when I answer, what will they ask next, and can I go there". Read your own answers back and hunt for the words you used without being able to unpack them. Those are the words the follow-up will land on.

What a strong answer is actually made of

Strong answers are not longer. Very often they are shorter. What they contain that weaker answers don't is a second layer: the mechanism underneath the definition, the condition where it breaks, and the trade-off you accepted.

The senior version does four things: it names the specific situation, it says what was happening underneath, it quantifies the effect, and it volunteers the cost. You can build that shape into any answer you give.

1. Lead with the answer in one sentence. Do not narrate your way toward it.
2. Say what is happening one level down, in the runtime, the database, the network, the browser.
3. Name the condition where your answer stops being right.
4. Say what you would measure to know.

Four sentences. It fits inside a normal answer, it works for almost any technical question, and it moves you out of the group that recites definitions.

Talk about trade-offs without hedging

"It depends" is the correct answer to a lot of interview questions and the worst possible way to say it. Hedging reads as evasion, and it is the most common way experienced candidates get scored down.

The fix is to commit first and qualify second. Pick the option you would actually ship, say why, then name the condition that would change your mind. "I'd start with the boring relational option, because the access patterns are simple and I get transactions for free. If write volume went past what one primary can take, I'd revisit it, and the thing I'd watch is replication lag." That is the same nuance, delivered as a decision instead of a shrug.

When you genuinely don't know

Everyone gets asked something they cannot answer. The difference between candidates is almost entirely in what happens in the next thirty seconds.

Do not go quiet, and do not bluff. Bluffing is the fastest way to lose an interviewer, because the follow-up will find you and now they are also questioning everything you said before. Instead, say what you do know, reason out loud from it, and be explicit about where your certainty stops.

Something like: "I have not used that directly. From how the surrounding thing works, I would expect it to behave roughly like this, and I would check that by trying this. Where I'd be least confident is here." You are showing them how you handle unfamiliar territory, which is a large part of what they are trying to find out.

A preparation plan that fits around a job

Most published prep advice assumes you have unlimited evenings. Here is a version that assumes you have about four hours a week and an actual life.

If you have four weeks

1. Week one: inventory. Write down every technology on your CV and rate your honest confidence one to five. Anything you rated three that you would be asked about is your target list, not the fives and not the ones.
2. Week two: depth on the target list. For each item, work down three layers of "why" until you hit the wall, then read until the wall moves. Two items an evening is plenty.
3. Week three: out loud, under follow-ups. Reading does not transfer to speaking. Practise answering with someone or something that pushes back on what you actually said.
4. Week four: format rehearsal. Run the specific round you are facing, end to end, at full length, with no pausing to look things up.

If you have one week

Cut weeks one and two to a single evening of honest inventory, and spend everything else on speaking. The bottleneck for experienced engineers is almost never knowing, it's retrieving under pressure and shaping the answer, and that only improves by doing it out loud.

Practice that transfers, and practice that doesn't

Grinding algorithm puzzles transfers to interviews that are algorithm puzzles. If you are facing a senior deep dive about the systems you have built, five hundred puzzle problems will not help you, and a lot of engineers discover this the expensive way.

Match the practice to the round. If the round is a conversation, practise conversation. If it is a whiteboard design, draw and defend designs. If it is a live coding session, write code while narrating, because the narration is genuinely half the assessment and it is awkward the first three times you try it.

On the day

• Test your microphone on a recording, not in your head. Bad audio costs you points you will never see deducted.
• Have water, and use the pause it buys you.
• Take two seconds before answering. Silence feels much longer to you than to them.
• If you realise mid-answer that you were wrong, say so immediately and correct it. Self-correction reads as strength, right up until it arrives too late to look voluntary.
• Ask what they are worried about with your profile, near the end. The answer is useful, and the willingness to ask reads well.

The honest summary

You pass technical interviews by being able to go one layer deeper than the answer you just gave, on the topics you actually claim. Not by memorising questions, and not by knowing more things. Find your walls before an interviewer does, and move them.