Here's something most people learn the hard way: you can solve 300 LeetCode problems and still fail a coding interview.
The reason is that an interview isn't a test of whether you can reach the answer. It's a test of how you reach it. Interviewers at Google, Meta, Amazon and the rest score you on roughly four things:
| Signal | What they're looking for |
|---|---|
| Communication | Can I follow your thinking? Would you be easy to work with? |
| Problem solving | Do you break the problem down, or flail? |
| Coding | Is the code clean, correct and readable? |
| Verification | Do you test your own work, or wait for someone else to find the bugs? |
A strong candidate doesn't hope to hit these. They follow a process that hits all four on purpose, whatever the question.
Here's that process.
Don't touch the keyboard yet. Restate the problem in your own words, then ask:
n ≤ 10⁵, you probably need O(n log n) or better, so an O(n²) solution won't pass.Then walk through the given example by hand. This one habit catches misunderstandings before they cost you 20 minutes.
💡 Interviewers often hold back details on purpose. Asking clarifying questions is part of the test, not a sign of weakness.
Even if it's obviously slow, say it out loud:
"The naive approach is to check every pair, which is O(n²) time and O(1) space."
This does three things: it proves you understand the problem, it gives you something to optimize from, and it's your fallback if time runs out.
Now find the bottleneck. Ask yourself, out loud:
(Not sure you can spot these patterns under pressure? Drill them one at a time in topic mode.)
Once you have an approach, state the time and space complexity, then check in before coding:
"I'm thinking a sliding window with a hash map, O(n) time. Does that sound reasonable to implement?"
If the interviewer nudges you toward something better, you've just saved yourself from coding the wrong solution. If they say "go ahead", you've got buy-in.
left, seen, max_len beat i2, x, tmp.is_valid(window) as a stub and fill it in later. It keeps the main flow readable.def length_of_longest_substring(s: str) -> int:
last_seen = {} # char -> most recent index
left = 0
max_len = 0
for right, ch in enumerate(s):
# If ch is inside the current window, shrink past its last position
if ch in last_seen and last_seen[ch] >= left:
left = last_seen[ch] + 1
last_seen[ch] = right
max_len = max(max_len, right - left + 1)
return max_len
Notice how readable that is. The interviewer can follow it without you explaining every line.
Never say "I think it works." Prove it.
>=, not >."Catching your own bug is a positive signal. It shows the interviewer exactly what you'd be like in a real code review. Many companies also run coding rounds with code execution turned off, so tracing by hand isn't optional.
Restate the final time and space complexity. Mention a tradeoff or improvement:
"If memory were tight, we could use a fixed-size array instead of the hash map, since the alphabet is bounded."
Then get ready, because there's usually a follow-up.
| Phase | 45-min round (1 problem) | Fast-paced round (2 problems) |
|---|---|---|
| Clarify | 3 min | 2 min |
| Approach | 7 min | 4 min |
| Code | 20 min | 12 min |
| Verify | 5 min | 3 min |
| Buffer / follow-up | 10 min | ~0 min |
Some companies, Meta especially, expect two problems in about 40 minutes. Practice the compressed version too.
Silence is the worst thing that can happen in an interview. When you're stuck, work through this list in order:
Some companies have started adding coding rounds where you're allowed to use an AI assistant. The framework still applies, with different emphasis: spend more time reading the existing code and tests first, give the AI small, well-defined tasks, and review every line it writes, out loud. Running the tests after each change becomes your Step 5. You're still accountable for every line.
You've just read it. It makes sense. You'll probably still forget half of it the first time you're under pressure.
That's normal. This framework is a habit, not a fact. Under pressure your brain falls back on whatever you've practised, not what you've read. Most candidates practise by solving problems silently on LeetCode, so in the real interview they stay silent, skip clarifying questions, and declare "I think it works" without tracing.
The only way to make this automatic is to practise in conditions that feel like the real thing: out loud, on a timer, with someone watching.
That's exactly why we built the letsinterview.me DSA mock interview.
It's a voice-based interview with an AI interviewer that behaves like a real FAANG interviewer, and it watches for the same things this framework is built around:
At the end of every session you get a breakdown with separate scores for communication and problem solving, so you can see exactly which step of the loop is breaking down.
Pick how you want to train:
Do one mock. Read your feedback. Fix the weakest step. Repeat. After a handful of sessions, the framework stops being something you remember and becomes something you just do.