The technical interview — what actually differs from every other round
A technical interview isn't just "the hard round." It's testing a specific, narrower thing than the rest of the process — and prepping for it like a behavioral round is why strong engineers still stumble.
"Technical interview" gets used as a catch-all for "the part of the process that isn't small talk," which hides how different it actually is from everything else in a hiring process. A behavioral round is checking judgment and self-awareness. A technical round is checking something narrower and more falsifiable: can you actually reason through the kind of problem this job will hand you, out loud, in front of someone watching you do it.
What a technical interview is actually measuring
Not whether you know the answer — whether you can produce the reasoning that gets to an answer, live, including the parts where you're not sure. An engineer who says "I think it's this, and here's my reasoning, though I'd want to double check the edge case around X" is giving a stronger signal than one who states a confident answer with no visible reasoning behind it, even if the confident answer happens to be right. Interviewers are watching the process, not just scoring the destination.
This is also why technical interviews reward narrating your thinking, which feels unnatural to a lot of candidates who are used to working silently. Saying "I'm going to start with the brute-force approach, then see if there's an obvious way to cut the complexity" out loud, before you've fully solved anything, is doing real work — it lets the interviewer follow your reasoning instead of guessing at it from a block of code you produced in silence.
How technical rounds differ by company type
Product companies (particularly larger tech companies) tend to lean on data structures, algorithms, and system design — abstracted problems disconnected from any specific codebase, testing general problem-solving more than familiarity with a particular stack.
Service and consulting companies more often test fundamentals in depth — language basics, OOP concepts, database queries, sometimes straightforward coding exercises — because the actual work spans many different client codebases and stacks, so deep fundamentals transfer better than narrow expertise in one framework.
Smaller product teams and startups often skew toward practical, stack-specific questions closer to what you'd actually be doing day one, sometimes including a take-home project or a pairing session on a real (simplified) piece of the codebase.
Knowing which of these you're walking into changes what's worth spending your limited prep time on — cramming algorithm patterns for a company that's going to ask you to debug a slow API endpoint is time spent on the wrong thing.
The most common failure mode, and it's not lack of knowledge
Going silent. A candidate who freezes and says nothing while thinking gives the interviewer nothing to evaluate — no reasoning to follow, no partial credit for being on the right track, no chance to redirect a wrong turn before it wastes the rest of the round. The fix isn't "know more" — plenty of candidates who freeze know the material. It's practicing the specific, uncomfortable skill of narrating an unfinished thought out loud instead of waiting until it's fully formed.
The second most common one: not asking clarifying questions
Technical problems in interviews are often deliberately underspecified — not because the interviewer is being unhelpful, but because asking good clarifying questions is itself part of what's being evaluated. "Should this handle negative numbers?" or "what's the expected scale — hundreds of records or millions?" shows the same judgment a real engineer needs before writing code against ambiguous requirements. Diving straight into a solution without asking anything is a more common mistake than asking too much.
If you want to practice narrating your reasoning out loud, with role-specific questions and a real follow-up when an answer stays vague, try role-specific mock interviews — free to start.