How to Prepare for a Technical Interview

2026-08-14 · 9 min read

Most engineers prepare for a technical loop by grinding algorithm problems, because it is the part with a scoreboard. It is also, for mid and senior roles, rarely the reason people are rejected. Here is where the time actually pays.

What a loop is really made of

A typical loop is four to six rounds: one or two coding, one system design, one or two behavioural, and often a hiring-manager conversation. For a senior role the design and behavioural rounds carry more weight than the coding one — you can be adequate at coding and get an offer; you cannot be vague about trade-offs and get one.

So the allocation that matches reality is roughly: 40% coding, 35% design, 25% behavioural for mid-level, and closer to 25 / 45 / 30 for senior. Almost everyone does 90 / 5 / 5.

Coding: patterns, not volume

Three hundred problems is the wrong target. There are roughly fifteen patterns that cover the overwhelming majority of interview questions — two pointers, sliding window, binary search on answer, BFS/DFS, topological sort, heap, intervals, prefix sums, backtracking, dynamic programming on sequences, union-find, monotonic stack, tries, bit manipulation, and graph shortest paths.

Solve five or six problems per pattern and write down, in one sentence, the signal that tells you it is that pattern. “Sorted array plus a target sum” → two pointers. “Shortest path in an unweighted graph” → BFS. Recognition is the skill being tested; the coding is mechanical once the pattern is picked.

Talk while you code. The most common cause of a failed coding round is not a wrong answer, it is silence. The interviewer is grading your reasoning and cannot grade what they cannot hear. Say what you are considering and why you are rejecting it, before you commit.

System design: get a repeatable path

The failure mode here is not ignorance, it is disorder — forty-five minutes disappearing into one corner while breadth never gets shown. Run the same sequence every time: clarify requirements and scale, sketch the API, sketch the data model, draw the high-level components, then go deep on the one or two parts the interviewer pushes on, and name the trade-offs out loud.

We wrote a longer version of this in the system design framework. The key point: structure scores higher than knowledge, because structure is what transfers to the job.

Behavioural: the round engineers under-prepare

Engineers treat this round as small talk and it is not — it is often where the level is decided. “Senior” is demonstrated by stories about ambiguity, disagreement and things you deliberately did not do, not by another algorithm.

Prepare six stories in STAR form and make sure at least two involve a decision you would defend and one involves a genuine failure. Say “I” rather than “we” — a story about your team earns your team the credit.

Know the system you will be judged in

Read the job description for the stack and the domain, and look up how the company runs its loop — most publish it. Fifteen minutes here changes which of your six stories you tell and which language you write in.

What to skip

  • Memorising language trivia. Nobody senior is asked what the default capacity of a slice is.
  • Obscure algorithms. If it needs a named theorem, it is not being asked in a 45-minute round.
  • Rehearsing answers word for word. Prepared sentences collapse at the first interruption; prepared structure does not.

On the day

Preparation gets you the material; the interview still happens in real time, under pressure, often at 9am. Interview Copilot listens to the interviewer and shows an answer as they finish speaking — grounded in your own CV so the examples are yours, and able to read a coding task straight off your screen. It stays invisible during screen share on Zoom, Meet and Teams.

Read next