Stage 1 · Code
Mock Interviews & Strategy
Post-Interview Reflection
The interview isn't over when you hang up — the post-mortem is where most of the learning happens. Structure your reflection to turn mistakes into a repeatable improvement system.
Why Post-Mortem Matters
Most candidates do the problem, get feedback (or not), and move to the next one. That's a wasted opportunity. Every interview — whether it goes well or poorly — contains signal about your preparation gaps. A structured post-mortem extracts that signal and converts it into a concrete study plan.
Memory of interview details fades fast. Immediately after the call, dump everything you remember: the exact problem, your approach, where you got stuck, the interviewer's reactions, time spent per phase.
Reflection Framework
Evaluate the interview across five dimensions. Score each 1–5 and note specific evidence for the score.
| Dimension | What to ask yourself | Poor (1–2) | Good (4–5) |
|---|---|---|---|
| Problem Understanding | Did I clarify constraints before coding? | Started coding immediately, missed edge cases | Asked clarifying questions, confirmed examples |
| Communication | Did I explain my thought process clearly? | Silent coding, had to be prompted | Narrated approach, discussed trade-offs aloud |
| Algorithm Design | Did I find the optimal solution? | Brute force only, couldn't optimise | Identified optimal pattern, discussed alternatives |
| Coding & Debugging | Did I write clean, correct code quickly? | Syntax errors, off-by-one, panic | Clean code, ran through example, fixed bugs calmly |
| Time Management | Did I allocate time well across phases? | Spent 30 min on brute force, no time for optimal | Quick brute → optimise → test, finished with time |
Common Pitfalls
| Pitfall | Why it happens | Fix |
|---|---|---|
| Jumping to code immediately | Nervousness, trying to look fast | Force yourself to write 3 examples and 1 brute-force outline before any real code |
| Going silent while thinking | Deep focus mode | Narrate your thinking: 'I'm considering a hash map here because…' Even wrong thoughts show process |
| Ignoring the brute force | Perfectionism / 'optimal or nothing' | Always state and implement brute force first — even if you know the optimal solution |
| Not verifying with examples | Overconfidence | After writing code, manually trace it on the example input before the interviewer asks |
| Freezing on bugs | Panic / lack of debugging strategy | Say 'let me add a print statement here' or 'let me trace the values step by step' — debugging is expected |
| Bad time allocation | No internal clock | Set mental milestones: 5 min clarify, 10 min brute, 15 min optimal, 10 min code, 5 min test |
Improvement Plan
After scoring yourself on the five dimensions, identify the lowest two scores and build a 1-week plan around them. Do not try to fix everything at once.
Week 1 target: Communication (score 2). Do 3 mock interviews focusing ONLY on narrating out loud. Record yourself. Week 2 target: Algorithm Design (score 2). Do 10 medium problems per week but categorise them by pattern before solving. Track which patterns you miss most.
- Score ≤ 2: Immediate attention — drill this dimension for 1 week with deliberate practice.
- Score 3: Adequate, can improve — maintain with weekly practice, don't over-invest.
- Score 4–5: Strength — maintain by teaching it to someone else or writing about it.
- Re-assess every 2 weeks — re-run the reflection framework on your next mock and see if scores improved.
- Track over time — keep a spreadsheet or note with scores per session. Look for trends, not single data points.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.