A technical interview measures two things at once: whether you can solve the problem, and whether anyone can follow how you solved it. Most preparation covers the first and ignores the second. This guide covers both, for coding rounds, system design rounds and the questions about work you have already done.

Knowing which format you are walking into, and what the person on the other side is writing down, removes a large part of the anxiety before you have solved anything.

The formats you are likely to meet

The coding round. One to three problems in forty five to sixty minutes, usually in a shared editor with no autocomplete and no way to run the code, sometimes as a timed automated assessment before a human sees you. Assessed: your approach, your choice of data structure, your handling of edge cases, your reasoning about time and space cost, and whether you narrate any of it.

The system design round. An open-ended brief in roughly the same time: design a service that does this, for this many people. Common from mid-level upwards, and there is no correct answer. The interviewer is watching how you handle ambiguity, what you ask before you draw, and whether you can name the trade-off you just made.

The take-home. A small project, usually scoped at a few hours. Tests and a short README normally count for more than an extra feature, and something small and clean beats something ambitious and half wired together.

Pair programming. You work on the problem with the interviewer rather than in front of them, so the assessment is mostly about collaboration: whether you take a suggestion, and whether you can be interrupted without losing the thread.

Questions about your own work. Describe a bug that took you days. Tell me about a technical decision you would make differently now. These are technical interviews too, and they are the ones candidates most often walk into unprepared, because the answers cannot be revised the night before. They come out of your own history, so the preparation is recalling it in enough detail to be specific.

The coding round

What you need to know without thinking about it

The surface area is smaller than it looks. Arrays and strings, linked lists, stacks and queues, hash maps, trees (binary, binary search, n-ary), heaps, graphs and tries. On the algorithm side: sorting, binary search, depth-first and breadth-first traversal, recursion and backtracking, dynamic programming, greedy approaches, two pointers and sliding window, and enough graph work to do a shortest path and a topological sort.

Alongside that, be able to say out loud why a loop inside a loop over the same input is quadratic, why a sort makes the whole thing linearithmic, and why the hash map you reached for spends memory to save time. You do not need to recite complexity classes, you need to justify the cost of what you just wrote.

A sequence that works

Under pressure, the failure mode is jumping to code. A fixed sequence protects you from it:

Restate the problem in your own words and confirm you have it right. Twenty seconds, and it catches misreadings that would otherwise cost you the round.
Work an example by hand, then a second one that is awkward: empty input, one element, duplicates, negatives.
Choose the data structure and say why, including what you considered and rejected.
Describe the algorithm before writing it, with its cost, and pause. If the interviewer is going to redirect you, this is the cheapest moment for it.
Then write it, still talking, with names a stranger could read.
Trace your own code against the example you worked at the start. Finding your own bug is a good outcome, not an embarrassing one.

What to say while you do it

Silence is the most common avoidable mistake. Interviewers cannot give credit for reasoning they did not hear, and they cannot offer a hint if they do not know where you are. A few sentences carry most of the load:

Let me make sure I have this right. [Restatement.] Is that accurate?

I am leaning towards a hash map here, because I need constant time lookups and I can afford the extra memory. Does that seem reasonable to you?

Each of those ends somewhere the interviewer can intervene cheaply. That is the point of thinking aloud: it turns a test into a conversation, and a conversation is easier to pass.

Patterns worth recognising

Most interview problems are variations on a few shapes. Recognising the shape is most of the work, so practise the recognition rather than memorising solutions.

Two pointers. A sorted array and a target: start one index at each end and move the one that brings you closer. Turns a quadratic pair search into a linear walk.

Sliding window. Anything asking for the longest or shortest contiguous run that satisfies a condition. Extend the right edge, and pull the left edge in when the condition breaks.

Fast and slow pointers. Linked list questions about cycles or middles. One pointer moves one step, the other moves two, and their meeting tells you what you need.

Backtracking. Permutations, combinations, board puzzles. Choose, recurse, undo the choice. The undo is the part people forget under pressure.

Dynamic programming. A problem where the answer for n is built from smaller answers you have already computed. Say the recurrence out loud before you write anything: if you cannot state it in a sentence, the code will not save you.

When you are stuck

Being stuck is expected and is not itself a failure. Handling it badly is.

Say the brute force version. A working slow solution is worth far more than an unfinished clever one, and it usually contains the insight that leads to the fast one.
Draw it. Boxes and arrows on the shared whiteboard, or on paper if you are in the room. Patterns show up visually that do not show up in your head.
Shrink the problem. Solve it for two elements. Solve it assuming all the numbers are positive. Then add the constraints back one at a time.
Ask. "I can see two approaches and I am weighing them, do you have a preference?" reads as collaboration, not defeat. Most interviewers want to help, and they are scoring you against their colleagues, not against a perfect candidate.

The things that genuinely hurt are narrower than people fear: coding in total silence, ignoring a hint you were plainly given, arguing with the interviewer, never testing what you wrote, and giving no thought at all to cost or edge cases.

The system design round

Open-ended by design. Without a structure you will wander, so bring one.

Clarify before you draw

Spend the first five to ten minutes on requirements and resist the pull to start sketching. Ask what the core features are and who the users are. Then ask the questions that shape the architecture: expected scale, latency target, availability target, read heavy or write heavy, and whether strong consistency is required or eventual consistency is acceptable. A candidate who asks about the read to write ratio before drawing anything has already signalled experience.

Estimate roughly, out loud

Back of the envelope numbers exist to justify design decisions, not to be correct. If the interviewer tells you to assume half a billion writes a day, divide by the seconds in a day and you have a write rate of a few thousand per second. Assume reads outnumber writes heavily and the read path becomes the thing that needs a cache. Multiply by an average record size for storage per day and per year. Two minutes of arithmetic tells you which component is the hard one, and everything you say afterwards can point back to it.

Sketch the whole thing before any part of it

Clients, load balancer, application servers, cache, databases, object storage, and a queue if work can happen after the response. Get the boxes down, describe the request path through them, then go deep. Starting on a detailed sharding scheme before there is a diagram is the most common way to run out of time.

Expect the deep dive

The interviewer will pick one component and push. Be ready on the storage choice and why, sharding and what it makes hard (cross shard queries, rebalancing), replication and what it costs in consistency, what you cache and how it gets invalidated, where the single points of failure are, and what you would put on a dashboard to know the system is sick before your users tell you.

Name your trade-offs before you are asked

Every decision here gives something up. Consistency against availability when the network partitions, latency against throughput, storage cost against query speed, precomputing a feed at write time against assembling it at read time. Saying "this is the compromise I am making, and here is why it fits the requirements we agreed" is the difference between a design and a drawing.

The prompts recur

The briefs come from a short list: a social feed with follows and timelines, a link shortener, a chat service with delivery guarantees, a video upload and delivery service, a file sync service, a notification system, a rate limiter, a web crawler, a payment flow. Prepare three or four thoroughly rather than twenty superficially. The components repeat, so depth in one transfers.

Preparing

A focused month works for most people; two to three months is comfortable if your fundamentals are rusty. Early on, rebuild those fundamentals on easy problems until the syntax stops being the obstacle. In the middle stretch, move to medium difficulty and group problems by pattern rather than by topic, because the pattern is what transfers, and add system design reading if the role calls for it. In the final stretch, do full length mock interviews under time pressure, out loud, and spend as long reviewing what went wrong as you spent doing them.

Two things reliably make practice more efficient. Anders Ericsson's work on deliberate practice is the first: repetition alone does not improve performance, repetition aimed at a specific weakness with feedback does. Which means the problem type you avoid is the one to schedule. The second is the spacing effect: revisiting a problem a week after you solved it, when the solution has half faded, teaches you more than solving three new ones the same afternoon.

Beyond that, practise out loud and time yourself. The gap between understanding a solution and explaining it while typing is wide, and the only way to close it is to rehearse the explanation. Record yourself once and you will hear exactly where you go quiet. For system design, Martin Kleppmann's Designing Data-Intensive Applications covers more of the ground than any interview specific material.

For the spoken parts of a technical interview, the design discussion and the questions about your own past work, you can practise with Beacon. You paste your CV and the actual job advert, and it works out what that role and seniority attract, then generates questions for it. Each answer is marked out of ten against criteria it shows you rather than hides, and beside your answer it writes two model answers, one acceptable and one excellent, so you can see what the gap consists of. You can type or speak; spoken answers are transcribed and marked the same way, and behavioural answers are assessed against STAR. Sessions are kept, so you can answer the same question a week later and compare the marks. It is free during the beta, with no card and no limits.

On the day

If it is remote, test the camera, microphone and connection in advance, know how the shared editor works before the clock starts, and have a phone ready in case the connection drops. If it is in person, arrive early, bring paper, and know the names and roles of the people you are meeting. Either way, do not cram: reviewing a familiar concept the hour before helps, meeting a new one costs you the composure you will need in the first ten minutes.

During the round, keep to the sequence: clarify, approach, code, test, then cost and what you would improve. If you make a mistake, say so plainly and fix it, because catching your own error and correcting it calmly is a positive signal. If the time is nearly gone, stop coding and describe the rest. "The remaining steps are these, and here is how I would handle the edge case we discussed" salvages most of the credit.

Afterwards

The same day, write down every question you were asked and where you struggled, while the memory is still accurate. That record is worth more than anything else you take away, because it tells you what to practise next, whatever the outcome of this one. Then go and solve the problem you could not solve, properly, until you could teach it.

Interviewers are not trying to catch you out. They are trying to work out how you think, how you explain yourself, and what you would be like to sit next to. Almost everything in this guide follows from taking that literally.