Coding interview questions — what changes once you stop treating it as a LeetCode problem
Most coding interview advice is about which algorithm to memorize. The actual differentiator is what you do in the five minutes before you write any code, and the sentence you say after you finish.
Search "coding interview questions" and every result is a list: two sum, reverse a linked list, valid parentheses, merge intervals. The list isn't wrong, but it answers the wrong question. Two candidates can solve the exact same problem, both get the right answer, and walk out with completely different scores — because the score was never really about the answer.
What's graded before you write a line of code
Clarifying the problem out loud. "Can the array contain duplicates?" "What should happen with an empty input?" "Are we optimizing for time or space?" Skipping this and diving straight into code is the single most common way a strong coder loses points — not because the code is wrong, but because it solved a version of the problem the interviewer didn't ask.
Stating a brute-force approach before optimizing. It feels slow to say "the naive way is nested loops, O(n²), and here's why that's not good enough" before writing the fast version — but that sentence is doing real work. It tells the interviewer you know why the optimization matters, not just that you memorized it.
What's graded while you're coding
Talking. Silent coding for eight minutes followed by "done" gives the interviewer almost nothing to grade except whether the final answer runs — and a wrong answer with no visible reasoning looks identical to someone who didn't understand the problem at all. Narrating the approach as you go ("I'm using a hash map here so this lookup is O(1) instead of scanning the array again") turns a binary pass/fail into a demonstration of how you think, which is the actual thing being evaluated.
What's graded after the code runs
Whether you test it yourself. Walking through your own solution with a small example, out loud, before the interviewer asks "does this handle X" is worth more than people expect. It's the difference between "I think this works" and "I checked that this works," and interviewers can tell which one they're watching.
Whether you can state the complexity. Not just naming Big-O, but explaining why — "this is O(n log n) because of the sort at the start, everything after that is linear." A correct answer with no complexity analysis reads as lucky; a correct answer paired with accurate complexity reasoning reads as understood.
How you react to a hint. Nobody solves every problem cleanly on the first try, and interviewers know that. What they're watching for when they nudge you toward an idea is whether you can actually use the hint — incorporate it and keep moving — versus getting stuck defending the approach you already committed to.
The part practice problems don't train
Solving two hundred problems on a coding platform builds pattern recognition, and that's genuinely useful — you'll recognize "this is a sliding window problem" faster. What it doesn't train is saying any of the above out loud, in real time, to a person who's judging the explanation as much as the code. That's a different skill from solving the problem alone at your desk, and it's usually the one that's never been rehearsed by the time the real interview starts.
Prepair asks scoped technical questions by role and level and scores the answer you give out loud — not a live coding judge or an algorithm-by-algorithm drill, but practice for narrating your reasoning under a bit of real pressure, which is the part silent LeetCode reps don't touch. Try a free interview — 3 a month, no card required.