Technical Interview Tips for the Rounds That Are Not Really About the Answer
The interviewer already knows the solution. What they do not know is what you are like to work with when a problem does not immediately give way — and that is the entire thing being measured.
Four Formats, Four Different Tests
Technical interview is a label covering several quite different assessments. Preparing for the wrong one is a common and avoidable loss.
Forty-five minutes, one or two problems, usually shared editor. Tests whether you can decompose a problem, reason about complexity, and write something correct while a stranger watches.
Open-ended, whiteboard or diagram tool. Tests whether you can scope a vague requirement, make trade-offs explicitly, and defend them. There is no correct architecture, only defended ones.
They hand you unfamiliar broken code. Tests how you orient in someone else's work — which is what the job mostly is, and which pure algorithm practice does not prepare you for.
Unwatched, so correctness is assumed and everything turns on judgement: structure, tests, README, and knowing when to stop. Almost always followed by a discussion round about your choices.
Most technical scorecards have a line for communication, and it is weighted about as heavily as correctness. A candidate who reaches a working solution in silence and a candidate who narrates their reasoning to a nearly-working one do not score the same — and it is usually the silent one who loses.
Eight Things to Do Before the Round
Most of this is not more practice problems. It is removing the friction that makes competent people look flustered.
Coding, design, debugging, or a pairing session. Ask what language, whether you can use your own editor, and whether documentation is allowed. Every one of these is a normal question.
Solve problems out loud, alone, in full sentences. It feels ridiculous and it is the single highest-return preparation for a technical interview.
Standard library, string handling, the collection types, and how to sort with a custom comparator without looking it up. Fumbling syntax burns the clock and the interviewer's patience.
Input size, edge cases, whether input is sorted, what to do with empty or malformed input. Asking these before coding is scored, and skipping them is scored too.
Be able to say the time and space cost of your approach and why, before you write it. If they have to ask, you have already lost the point.
One system you built or worked in, and what you would change about it now. Design rounds routinely start from your own experience before moving to the hypothetical.
The shared editor, screen sharing, the whiteboard tool. Ten minutes with the platform beforehand prevents the worst possible opening five minutes.
Decide now what you will do when you stall: restate the problem, try the brute force, or work a small concrete example. Having a plan for being stuck is what stops being stuck becoming panic.
Eight Prompts and How to Open Them
Not solutions — openings. The first three minutes of each of these decides most of the score.
"Here is the problem. Take a look and let me know when you are ready."
Do not start typing. Restate the problem in your own words, ask about input size and edge cases, then say your intended approach and its complexity out loud before writing a line. Interviewers are scoring this opening explicitly.
"Can you do it faster than that?"
This means yes, there is a better approach, and it is usually a hint about which structure to reach for. Say what the current bottleneck is, then ask yourself out loud what would remove it. Do not silently rewrite.
"Design a system that does X for millions of users."
Scope before you draw. What are the read and write patterns, what scale exactly, what is allowed to be slow, what must never be lost. Candidates who start drawing boxes in the first minute reliably design the wrong system.
"Walk me through this code and tell me what is wrong with it."
Orient before diagnosing: what is it supposed to do, what are the inputs, where does it start. Then form one hypothesis at a time and say how you would test it. Scattergun guessing is the failure mode here.
"Why did you make this choice in your take-home?"
Have a reason, and be willing to say what you deliberately did not do. Naming the trade-off you accepted, and what you would add with another day, scores better than defending the submission as ideal.
"What would break first if traffic went up ten times?"
Pick one bottleneck and reason concretely through it rather than listing every scaling technique you know. Depth on one real failure mode beats breadth across ten rehearsed ones.
"How would you test this?"
Happy path, boundaries, empty and malformed input, then the thing that is hard to test and why. Mentioning the hard-to-test part unprompted is a strong signal and most candidates skip it.
"Do you have any questions for me?"
Ask about the actual engineering: what the deployment cycle looks like, how much of the week is maintenance, what the on-call load is. Concrete questions from the person who just watched you code carry weight.
What to Do While the Clock Is Running
Technical rounds are lost far more often to process than to knowledge.
Say the approach and its cost, get a nod, then write. Coding first and explaining after means any wrong turn is discovered at minute thirty instead of minute three.
Take a tiny input and trace it by hand. It exposes edge cases and, when you are stuck, it is the most reliable way to restart your thinking.
A working slow solution is worth far more than an elegant unfinished one, and it usually reveals the optimisation on its own.
Naming it and describing what you have ruled out invites a hint. Silent struggling reads as an inability to ask for help, which is a much worse signal than the stall.
When an interviewer asks about a case you have not handled, they are steering. Follow it. Candidates who politely push past two hints rarely pass.
Real names, small functions, no single-letter variables outside loop counters. Interviewers are imagining reviewing your pull requests.
Run through your own code on the example, out loud, including one edge case. Finding your own bug is a positive signal; having it found for you is neutral at best.
Saying you would normally add error handling but want to get the core working first is good judgement. Running out of time silently is not.
Four Questions Worth Asking
You have just been assessed on how you work. These check whether the work is what you want.
"What does a normal week look like — how much is new work versus maintenance?"
The most useful signal about the actual job, and the answer is rarely in the job description.
"How does code get reviewed and shipped here?"
Review culture and deployment friction shape daily life more than the tech stack does.
"What is the on-call expectation?"
A concrete, entirely fair question that is much harder to ask after an offer is on the table.
"What is the piece of the system everyone is quietly worried about?"
Engineers usually answer this honestly, and the answer tells you what you would actually be walking into.
"I have ruled out the sorted-input approach because the data comes in unordered, and the hash-map version solves the lookup but not the ordering requirement. I am weighing whether to sort first and accept the extra cost — does that seem like the right direction to you?"
Six Ways Technical Rounds Are Lost
Unspoken reasoning cannot be scored. Narrate the approach before writing and keep talking through the decisions.
Input size, edge cases, and constraints are part of the assessment. Jumping straight to code is read as not scoping.
An unfinished clever approach scores below a finished plain one. Get something working, then improve it out loud.
Interviewer questions mid-round are steering, not curiosity. Two ignored hints is usually the end of the round.
Judgement includes knowing when to stop. A focused submission with tests and a short README beats a sprawling one that missed the deadline.
Say you do not know, then say how you would find out. The person asking often built the thing you are guessing about.