Blog · 2026-02-06 · 14 min read

How to Prepare for a Technical Interview in 5 Days

A realistic five-day technical interview plan built on retrieval practice and self-testing - day by day, how to practise coding properly, what to memorise, logistics, behavioural stories, and an honest look at rejection.

Five days will not make you good at something you do not know. No plan will, and any plan that implies otherwise is selling something. Distributed systems, algorithms you have never seen, or a language you have not used in four years do not become interview-ready in five days of evening hours. Trying to compress that much new material into that little time is the single most common way people spend their preparation window and arrive no better off.

What five days can do is narrower and still worth a lot. It can make you reliable at what you already half-know, so that the good stuff does not evaporate under pressure. It can plug the specific gaps that would sink you, chosen by ranking rather than by whatever feels uncomfortable. And it can make sure you lose nothing in the parts of the interview that are not technical, which is where candidates are surprised by avoidable mistakes.

So the plan below spends five days on diagnosis, targeted repair, rehearsed output and logistics. It deliberately does not try to teach you a new field.

Day one: diagnose, do not study

Do not study on day one. Study feels productive and diagnosis is what everything else depends on.

Rank the gaps. Write down the topics you would be embarrassed to be asked about. Not the topics you find hard, the ones where being asked would make you look like you have been bluffing. Then rank them by how likely you are to actually meet them and how bad it would be to fail them. A second-tier algorithm you will be asked and cannot do costs more than a first-tier algorithm you know well, because it is far more probable.

Be honest in the ranking. People consistently rank by comfort rather than by risk, and then spend four days getting better at what they already knew.

Audit the CV line by line. This is the highest-value hour of the whole week. Every technology, every scale figure, every "led", "designed", "owned" on your resume is a claim that an interviewer may probe. Go through each line and sort it into three buckets: I could talk about this for ten minutes without bluffing; I have touched it but should not present it as expertise; I cannot defend this at all. For the second bucket, delete the claim or downgrade it to something you can support, such as "worked with" instead of "expert in". For the third bucket, delete it, unless you plan to spend one of your remaining days on it.

Weak claims are worse than no claims. A line you cannot defend does not get you credit for the knowledge, it gets you a follow-up you lose.

Note the format. Confirm how many rounds, how long each one is, and whether there is a system design round. Some rounds are whiteboard pseudocode, some are take-home, some are a shared editor with a real person pairing with you. Knowing this changes what you rehearse.

Day two: your two hardest topics, hands on

Take the top two from yesterday's ranking and go properly deep. Not a broad sweep, depth.

This day is about production, not recognition. You should be typing, running and breaking things, not reading about them.

• Solve the three or four canonical problems for each topic, by hand, in your editor, with a timer running.
• Get them wrong on purpose at least once. Asking what would make this fail teaches more than getting it right on the first attempt.
• Write down, in your own words, what the solution actually does. If you cannot compress it to a paragraph without reference, you do not have it yet.
• Then say it out loud. Explanation under time pressure is a separate skill from getting the code right, and the interview tests the second one.

If the topic is a language or framework rather than an algorithm, depth means building something small that exercises the part you are weak at, not reading its documentation start to finish.

Day three: breadth, plus the non-coding rounds

Split the day.

First half, breadth over the rest of the likely topics. Fast passes. For each area, aim to be able to give the definition, the reason it exists, one tradeoff, and one example. That four-part structure is the minimum that reads as competent, and having it ready across a wider surface protects you from the question you did not predict.

Second half, system design and behavioural.

If you are interviewing for a senior or mid-level role there is usually a design round. Do not try to memorise an architecture. Rehearse the shape of the conversation: requirements first, then estimation, then a high-level design, then one component in depth, and name a tradeoff at each step. The system design cheat sheet is written out as that framework, including the estimation arithmetic and a worked example you can walk through end to end.

For behavioural, do the afternoon exercise described below. Do not leave it to day four.

Day four: mocks, ideally with a human

This is the day that most people skip and it is the day that reveals the most.

A mock with another person is worth a lot more than another day alone, because you cannot see your own behaviour from inside it. If you can find someone who will do it, do it. If you can find someone who will ask you questions and be slightly impatient, that is even better.

If you cannot get a human, record yourself. Set up the camera, ask yourself the questions, answer them out loud in full, and then watch the recording rather than merely remembering what it felt like. People are reliably surprised by three things:

• The length of the preamble before getting to the point. Most answers open with three sentences of context the interviewer did not ask for.
• The filler. You will hear "so basically" and "kind of" at a frequency you would not have predicted, and each one is a place where a cleaner sentence could have gone.
• The collapse under follow-up. The first answer is fine. The follow-up is where you hedge, get vague, and stop committing.

Two mocks is enough. Three is a waste of a day you could have spent on something you can fix.

Day five: light review and logistics

Light review only. Re-read your notes and your CV. Revisit the two or three things you flagged as weakest. Do not learn anything new. Cramming on the last day converts a manageable amount of nervous uncertainty into a solid block of it, and it does not add knowledge at that point.

Prepare the practical things. This is the part people leave until the morning of and regret:

• Confirm the time, and the timezone if it is an overseas call.
• Write your questions to ask them now, so you are not deciding under pressure. See below.
• Re-read the job description once and have two specific things in mind you want to ask about the team.
• Dress for the company. Not formally, and not sloppily. Match the level of dress you saw in photographs or on their site.
• Lay out your documents: ID, any certificates you want to have ready, a copy of your resume if they asked for one.
• Silence notifications on the phone and on the computer, including the ones you habitually check. Do this the night before, not during the call.
• Test the audio with a recording. Play it back. Almost every bad interview that is technically a good one is a bad microphone.
• Test the call link on the actual platform at least a day before. Book platforms regularly generate meeting links that only appear shortly before the call, and some of them require a plugin you do not have.
• Have a fallback. A phone number that works, a second device, a hotspot. Know what you will do if the link dies in the first two minutes.

Sleep. Do not trade the last night's sleep for one more hour of review. Fatigue costs you working memory and steadiness, which is exactly what the interview needs, and the marginal hour of reading is worth less than neither.

How to practise coding properly

Reading solutions is close to useless. It feels like progress and it is not, because it produces familiarity rather than recall. Being able to follow someone else's solution is a different ability from producing one, and the interview tests production. Every study session should begin with you attempting, out loud or in code, before you look at anything.

You must type them. Reading code teaches you nothing about the thing that actually fails under pressure: generating the code while explaining it. Type every solution you intend to have available. Yes, typing is slow. That is the point, because slow now is fast in the room.

Practise timed. A problem you have seen before and take forty minutes to solve is not a problem you have solved. Run the clock, and require a working solution with the edge cases handled before time expires. Track your times per topic so you know where you are actually slow, and so day four's mock is not a surprise.

Review your own wrong answers. This is where the day is actually won. For every solution you got wrong, or got right only after twenty minutes, write the note you wish you had written before you started: which approach fails and on what input, what the invariant is that makes the correct approach work, what the off-by-one was. Keep one file. Two days before an interview, re-reading your own mistakes is worth more than a fresh topic.

Say your reasoning as you go. Narrate: here is what I am trying, here is why this is too slow, here is what I am about to change. Interviewers are grading the reasoning, and a silent correct solution gets less credit than a narrated one that makes two false starts.

Use blocks rather than one long session, because attention degrades and you will not notice:

# Four focused blocks with breaks, then a proper break away from the desk.
for i in 1 2 3 4; do
  echo "block $i - 25 minutes, phone in another room"
  sleep $((25 * 60))
  echo "break - 5 minutes, stand up and move"
  sleep $((5 * 60))
done
echo "done - 30 minutes away from the desk, no reviewing"

What to memorise and what to look up

Nobody expects you to remember the default port Redis listens on, the precise ordering guarantees of a specific database's isolation levels, or the current major version of a framework. Nobody has ever failed a round for that. What everybody expects is that you can explain a race condition, why a particular data structure fits an access pattern, what makes a design not scale, and what you would do about it.

So memorise the reasoning-shaped knowledge and look up the reference-shaped knowledge.

Genuinely memorise:

• The complexity of the common operations on the data structures you use, and why the complexity is what it is.
• How to detect and fix a race condition, including what a lock does and does not guarantee.
• Why normalisation stops you normalising, and when denormalisation is the right call.
• How an index works, and why a write gets slower when you add one.
• Where latency comes from in a typical request, and which of those you would attack first.
• Your own stories. Details you can recall without thinking are details you will not fumble.

Look it up without shame:

• Ports, environment variable names, CLI flags, default configuration values.
• Exact syntax of an API you have not used in months.
• Version numbers and changelogs.
• The precise wording of a design pattern's definition.

The distinction is: memorise the explanation, look up the notation.

Behavioural prep that fits in an afternoon

Build a small set of stories that you can tell well, and reuse them at different angles rather than inventing new ones under pressure.

Pick six. Two technical wins, one failure you owned, one conflict or disagreement, one influence without authority or mentoring, and one time you handled ambiguity or incomplete information. Six is enough to cover the common question set without becoming a fixed script.

Give them all one structure. Situation in two sentences, Task in one, Action for the bulk, Result with a number. Same structure for every story, so you never spend interview time deciding how to organise the answer. Write each one to about two hundred words, which is roughly a two-minute answer.

Then say them out loud. All six, timed. Twice is enough. Out loud is the important part, because a story you have only read aloud in your head will not come out in the right order under pressure, and the detail you will forget is usually the number in the result.

Know the follow-ups. For each story, list the two or three questions it invites and answer them. If you cannot answer them, that story is not finished. This is where most prepared candidates lose an interview: the story was good and the third follow-up had no answer.

The non-technical side of Indian hiring, including the HR round that follows the technical one, is covered separately in the HR round guide.

Questions to ask, and questions not to ask

Ask at the end, and ask real ones. Skipping this reads as not being interested, and asking only about process signals the opposite.

Worth asking:

• What is the hardest problem the team owns right now, and what happens to whoever owns it?
• How does the team decide what to build, which tells you whether your opinion is wanted?
• What did the last incident look like, and what changed as a result?
• What does on-call involve here, and how often does it page?
• Why is this role open, and what happened to the last person?
• What is expected in the first ninety days, in concrete terms?

Not worth asking:

• Anything you could look up on their site or in the job description, which signals you did not read either.
• Questions you would not care about the answer to. Interviewers can tell.
• "Do I get a laptop", "is there a free lunch", and anything with the same energy. It is not illegal to care about these, but they are not what the interview is for.
• Compensation, in the technical round. Ask in the HR round, where it belongs.

Have three or four ready and ask them whatever they look like. You do not need a full agenda.

The hour before

Close the laptop. Re-read your resume once, because it is what they will read while you are talking and it should not contain anything you are uneasy defending. Read your story summaries, not full notes. Have your questions in front of you. Test the link and the audio one more time. Then stop working.

Do not attempt to learn anything, do not read long technical material, and do not review your weaknesses, because that is a reliable way to spend the hour thinking about the things you are worst at. Set your own expectations: you are going to have some questions you cannot answer, that is normal, and the plan is to be honest and move on rather than to bluff.

Eat something. If you are prone to nerves, do not use caffeine to fix it.

After the interview

Send a short follow-up the same day or the next morning. Two to four sentences: thank them, restate one specific thing you enjoyed from the conversation, and add one thought you had afterwards. Not a summary of your strengths, not a paragraph. A short, specific note is remembered; a long one is skimmed.

Then write down, while it is fresh, what you were asked and how you handled it. Not because anyone will read it, but because the next interview is the one where this is useful.

Apply, and keep applying. One process taking three weeks tells you almost nothing about the market.

On rejection

Most rejection is not about you, and being told so is not consolation, it is a fact about the mechanics. There are many rounds and few slots. There is a level bar and a budget. There is a candidate who scored higher. There is sometimes a reorganisation that happened after your interview. Treating a rejection as a verdict on your ability produces the wrong response, which is to stop.

Here is what is actually in your control:

• Whether your claims on paper are true. The audit on day one is the most useful hour on this list, because a claim you cannot defend turns into a question you fail rather than a gap you would have been asked about anyway.
• Whether you can explain your own work under questioning. This is the most common genuine technical failure, and it is a rehearsable skill rather than a talent.
• Whether you recover quickly. Apply again the next day. The process that rejects you teaches you what the next one will ask.
• How you treat people in the room. Small companies talk to each other. Large ones do too, slower. It matters more than people admit and less than people fear.

What is not in your control: the level you were interviewing against on that particular requisition, who else applied, the internal budget, whether the interviewer was having a good day, and whether the offer gets approved. Spend your worry budget on the first list, because worrying about the second list accomplishes nothing at all.

Related reading: the system design cheat sheet covers the design round, and the HR round guide covers what happens after the technical rounds clear.

Want the full set?

• 360 questions, every one with a model answer
• JS + browser cheat sheet
• STAR + concept answer frameworks
• 5-day prep plan