Most engineers who fail a technical interview could have done the job. That gap, between being able to do the work and being able to demonstrate it in forty minutes under time pressure, is what this guide is about.
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.
A test you can run on yourself tonight
Pick any topic you would claim on your CV. Explain it out loud for sixty seconds. Then ask yourself "why" about the last sentence you said, and answer that. Then do it again. Most people hit a wall on the third layer. That wall is exactly where an interviewer will find you.
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.
Why do you use an index on that column?
Junior answer: Because it makes the query faster. Without an index the database has to scan the whole table.
Senior answer: That query filters on user_id and sorts by created_at, so it was doing a sequential scan plus a sort on about two million rows. A composite index on the two columns lets it seek and read in order, which took p95 from around 400ms to under 20ms. The cost is a slower write path and a few hundred megabytes, which was worth it here because the table is read far more than it is written.
Both answers are correct. Only one tells the interviewer that you have actually watched a query plan change.
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.
- Lead with the answer in one sentence. Do not narrate your way toward it.
- Say what is happening one level down, in the runtime, the database, the network, the browser.
- Name the condition where your answer stops being right.
- 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.
The interviewer is not deciding whether you know everything. They are deciding whether they would be comfortable handing you something unfamiliar on a Tuesday and walking away.
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
- 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.
- 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.
- 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.
- 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.
The one habit worth more than the rest
Answer out loud, to something that asks you a real follow-up, and then look at what you actually said. Silent reading feels like progress and is the least transferable form of practice there is.
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.
Common questions
How long should I prepare for a technical interview?
For most working engineers, two to four weeks at a few hours a week is enough, provided the time goes on speaking rather than reading. If you are switching stacks or levels, give it longer.
Do I need to grind algorithm problems?
Only if you are facing algorithm rounds, which is mostly large product companies and new-grad pipelines. For senior screens built around your own experience, that time is better spent on depth in the technologies you claim.
What if I go blank in the interview?
Say so, out loud, and start from something adjacent that you do know. Interviewers are far more tolerant of a visible recovery than of a long silence or a confident guess that unravels.
Is it bad to say I don't know?
No, as long as it is followed by reasoning rather than a full stop. The failure mode is not admitting a gap, it is having nothing to say about how you would close it.
The fastest way to find your walls is to be asked follow-ups on your own answers. Run a practice interview at your level and see where the second question lands. Try a practice interview
