Skip to content

A Preparation Framework for Technical Interviews

Most people prepare for technical interviews by grinding practice problems until the night before. It is not useless, but it addresses perhaps a quarter of what you are assessed on, and it is the quarter you can cram.

A better approach starts by being clear about what is being tested.

The four things being assessed

  1. Can you do the work? Technical ability, at the level the role needs.
  2. Can you explain your thinking? Whether someone can work alongside you.
  3. Do you make reasonable judgements? Whether you choose sensibly under constraints.
  4. Do you know what you do not know? Whether you flag uncertainty or bluff.

Candidates over-prepare for the first and neglect the rest. The fourth is the most common silent failure: a candidate who confidently asserts something wrong is far more worrying than one who says "I'm not certain — I'd check the docs, but I believe it works like this."

Preparing for the coding round

Practise problems, but practise them out loud. The skill being tested is not "solve this in silence"; it is "solve this while someone watches and asks questions". These are genuinely different, and only one of them is what you will be doing.

Work to a repeatable shape:

  • Restate the problem in your own words, and confirm you have it right.
  • Ask about constraints. Input size? Can it be empty? Duplicates? Does it need to be in place? This is assessed, not tolerated.
  • Say the naive approach out loud, with its complexity. It shows you can reach a working answer before optimising.
  • Improve it, explaining the trade-off you are making.
  • Write the code, narrating as you go.
  • Test it on a small example, deliberately, including an edge case.

A candidate who talks through a nearly-complete good solution usually beats one who silently produces a perfect one.

Preparing for system design

This is where senior candidates are separated, and where memorising architectures fails. Interviewers are watching whether you make reasoned choices and understand their consequences.

Start by establishing what you are building:

  • Requirements. What must it do? What is explicitly out of scope?
  • Scale. How many users, how much data, what read/write ratio?
  • What matters most? Latency? Consistency? Cost? Availability?

Only then draw anything. Begin simple — a single service and a database is a legitimate starting point — and add complexity only when you can say which specific problem it solves. Candidates who open with microservices, a message queue and three caches, before anyone has said how many users there are, are demonstrating pattern-matching, not judgement.

Say the trade-offs aloud. "I'd use a read replica here; that gives us read scale at the cost of some staleness, which is fine for this feature but wouldn't be for billing." That single sentence is worth more than another box on the diagram.

Preparing your stories

The behavioural round is not a formality; for senior roles it is often decisive. Prepare five or six real stories, each with enough detail to withstand follow-up questions:

  • Something you built that you are proud of
  • Something that went badly wrong, and what you changed afterwards
  • A technical disagreement, and how it resolved
  • A time you had to decide with incomplete information
  • Something you had to learn quickly
  • A piece of work you argued should not be done

Use the plain shape: the situation, what you specifically did, what happened, what you took from it. Say "I" when it was you and "we" when it was the team — interviewers notice candidates who claim a team's work.

The failure story matters most. Choose a real one with a genuine consequence, and be clear about your part in it. A polished non-failure ("I care too much about quality") reads as evasion.

Your questions are part of the assessment

Have a few that you actually want answered:

  • "What does the first ninety days look like?"
  • "What is the hardest part of this job that isn't obvious from the advert?"
  • "How does work get prioritised?"
  • "What happens when something breaks in production?"
  • "Why is this role open?"

The week before

Re-read your own CV and be ready to talk about every line. Check your setup if it is remote. Sleep. Cramming new material the night before mostly costs you the clarity you need for the three rounds that are not about recall.