Tech interviews are hard. I’ve gone through dozens as a candidate and watched hundreds more on the hiring side at companies like Skype, Skyscanner, and startups where I was the one deciding who gets an offer. Most candidates prepare for the wrong things.
The advice hasn’t changed much in 10 years: grind LeetCode, memorize system design frameworks, prep your STAR stories. That’s all still relevant. But it’s not where most people actually lose offers. They lose offers because of how they communicate under pressure, not because they can’t solve the problem.
What actually matters in the coding round
Interviewers don’t care whether you get the optimal solution on the first pass. I mean this. At Skyscanner, the debrief criteria explicitly said solution optimality is one of the lower-weighted signals. What they’re watching is your process.
Specifically, they’re watching whether you:
- Clarify the problem before writing code (asking about edge cases, input size, constraints)
- Think out loud rather than going silent for 4 minutes
- Identify a brute-force approach and explain why you’re moving past it
- Catch your own bugs when asked to test the code
The candidate who writes a clean O(n log n) solution in silence and then freezes on follow-up questions will score lower than the candidate who writes an O(n²) solution while explaining every decision. I’ve seen this happen more times than I can count.
The Stack Overflow 2024 Developer Survey found that communication skills ranked higher than any specific language proficiency in what engineering managers value when hiring. That’s not surprising, but most interview prep ignores it entirely.
System design: the part most candidates blow
System design interviews filter for senior and staff engineers mostly. But a lot of engineers at the mid-level also get them and almost no one prepares the right way.
The wrong way to prepare: memorize “design Twitter” solutions from YouTube. The right way: understand the trade-offs in 5 or 6 core architectural decisions well enough to reason about a new problem you’ve never seen.
Those decisions are things like: SQL vs NoSQL and when the line actually matters. Sync vs async processing and what latency requirements change the answer. Caching layer placement and what cache invalidation problems come with each choice. You don’t need a script. You need to be able to reason from first principles and explain your trade-offs out loud.
Interviewers at Google, Stripe, and most well-run companies are explicitly looking for candidates who can hold two competing design options in their head and articulate the cost of each. The candidate who says “I’d use PostgreSQL because it’s familiar” without talking about the scale constraints will get a weak hire at best.
Behavioral questions are harder than they look
I’d argue behavioral rounds are where more offers are lost than in coding rounds, at least at the senior level. And they’re almost entirely about preparation, not innate ability.
The typical failure mode isn’t lying or giving bad answers. It’s giving answers that are too vague to be credible. “I communicated clearly and resolved the conflict” is a non-answer. What did you actually say to the other person? What did they say back? What did you decide and why?
Prepare 5 or 6 stories, not 3 and not 12. Fewer than 5 and you’ll find yourself recycling them in ways that feel repetitive to interviewers. More than 12 and you’ll lose track of which one you told in which round, especially across multi-round onsites where 4 different people ask variations of “tell me about a conflict.”
Each story needs a concrete outcome with a number or a measurable result. “Reduced deployment time from 3 hours to 47 minutes” beats “improved our deployment pipeline” every single time.
Where AI tools fit into this
There’s a version of using AI for interview prep that works and a version that doesn’t. The version that works: using something like Claude or GPT to run mock behavioral interviews, get feedback on your STAR stories, and identify weak spots in your system design reasoning. You’re using it to practice, not to get answers.
The version that backfires: relying on a real-time AI overlay to generate answers word-for-word during a live interview. If you can’t think through a system design problem without a prompt, you won’t make it through the follow-up questions where interviewers probe your reasoning. The gap becomes obvious fast.
Real-time copilots like Craqly are most useful as a quick memory jog, surfacing a framework or a bullet point you already know but can’t access cleanly under pressure. That’s meaningfully different from having the tool think for you. If you’ve done the prep work, having a nudge in the right direction doesn’t undermine your performance. It supports it.
Small things that actually matter
These are the things nobody writes about because they seem obvious, but they consistently separate candidates who get offers from candidates who don’t.
Ask at least two genuine questions at the end of every round. Not “what’s the team culture like.” Something you actually want to know that shows you’ve thought about the role. “What does the on-call rotation look like for this team and how has it changed over the last year” is infinitely better than the questions every candidate asks.
Follow up with a brief thank-you note to the recruiter after each round. Not a generic email. One sentence specific to something you discussed. Recruiters notice when nobody does this, which is most of the time.
Don’t ask about compensation until the recruiter brings it up. I know this seems counterintuitive but the first person to name a number has less use in negotiation.
What doesn’t matter as much as you think
Blind 75 completion. I know this is a hot take. The Blind 75 is a fine collection of problems for practicing common patterns, but finishing all of them doesn’t mean much if you can’t explain your reasoning out loud. I’ve interviewed candidates with 500+ LeetCode problems solved who couldn’t talk through a medium string problem coherently. The problems aren’t the preparation. The out-loud thinking is the preparation.
Also: which company’s template you use for system design. The FAANG template, the Grokking template, the “How to Ace System Design” YouTube playlist. They’re all fine. They all teach the same 5 concepts. Pick one and actually internalize the reasoning, then throw the template away.