Phase 11 — Mock Interview Mastery

Target level: All (mock difficulty scales from beginner through staff/principal/competitive) Expected duration: 4–8 weeks (depending on your overall track; mocks are continuous) Weekly cadence: 2 mocks minimum, 3+ if interviews are within 4 weeks

Why This Phase Exists

Phases 0–10 trained you to solve problems. This phase trains you to interview. Those are different skills. You can know every algorithm, pass every Phase 1–9 lab, write proofs from Phase 10 — and still fail a real interview because:

• You panic and forget the obvious under real-time pressure.
• You waste 8 minutes on clarifying questions a senior would resolve in 60 seconds.
• You code correctly but communicate nothing — the interviewer can’t tell if you’re thinking or stuck.
• You optimize prematurely before understanding the problem.
• You miss the follow-ups that separate “competent” from “hireable at level.”
• You finish in 25 minutes and have nothing to say when asked the extension question.
• You write buggy code, then spend the remaining time debugging instead of explaining.

A mock interview is the nearest equivalent to the real event without the stakes. Your job: complete at least 12 mocks (one per level), identify your failure mode per level, drill it until it stops happening.

The candidates who pass the hard rounds are not the ones who know the most algorithms. They are the ones who have rehearsed the performance enough times that the algorithm is almost a side effect of a clean interview.

How to Run a Mock

Alone (self-timed)

1. Read the problem statement only. Do not peek at hints, examples, follow-ups.
2. Set a timer to the mock’s exact allocated time.
3. Open a blank document (Google Doc, plain text, paper). No IDE, no autocomplete, no syntax highlighting. The real interview is in a shared Google Doc or CoderPad with minimal tooling.
4. Narrate aloud or write notes continuously. If you go silent for >30 seconds, stop, write down what you’re thinking, then proceed.
5. Write pseudocode first. If you have >20 minutes left after pseudocode, translate to real code. If less, stay in pseudocode and be very clear about logic.
6. When time expires, STOP. This is a time-management test, not a coding-speed test.
7. Self-evaluate against the 14-dimension rubric below. Score honestly. If your “Optimization” claim was O(N log N) but you wrote O(N²), that’s a 1, not a 4.
8. Do not look at the official solution until after a second self-mock at the same level. One failure teaches a fact; two failures teach the pattern.

With a partner (realistic)

• Find a peer, ideally one level above you.
• They read the problem statement to you. You ask clarifying questions; they answer in character.
• They watch silently as you solve. They give hints only if you explicitly request one (with a score penalty) or after 10+ minutes of being stuck.
• After the timer expires, they rate you on the 14 dimensions, then you debrief.
• Swap roles next session.

Best of both worlds

• Pramp, interviewing.io, Hello Interview (and similar) match you with strangers. Higher pressure, more realistic.
• Record yourself (audio + screen). Replay 24h later. You will be shocked at what you actually said vs what you remember.

The 14-Dimension Scoring Rubric

Every mock is scored 1–5 on each dimension. Total /70. Passing thresholds vary by mock level (see each mock file).

1. Problem Understanding

• 1: Misread the problem; solved the wrong thing.
• 2: Understood the surface; missed a subtle constraint.
• 3: Understood correctly, restated to interviewer.
• 4: Restated, identified the underlying category (graph, DP, greedy) within first 2 minutes.
• 5: Restated, identified category, and explicitly verified your interpretation with one well-chosen example.

2. Clarifying Questions

• 1: None asked; assumed everything.
• 2: One generic question (“can the input be empty?”).
• 3: 2–3 questions covering input bounds and edge cases.
• 4: 3–5 questions covering bounds, edge cases, output format, ambiguity resolution.
• 5: Surgical questions that probe the exact ambiguities of this problem (e.g., for LRU: “does put-on-existing count as a use?”).

3. Brute Force

• 1: No brute force articulated; jumped to optimization.
• 2: Mentioned brute force in passing.
• 3: Stated brute force with complexity; moved on.
• 4: Stated brute force, complexity, and why it fails the constraint.
• 5: Wrote brute force pseudocode briefly to confirm correctness before optimizing — gives you a verifier.

4. Optimization

• 1: No improvement on brute force.
• 2: Improved by a constant factor.
• 3: Optimal-class solution (e.g., O(N log N) when O(N log N) is optimal).
• 4: Optimal-class solution with the right pattern recognized within first 5 minutes.
• 5: Optimal solution + articulated why the optimization works (the key insight) + considered alternative optimizations and rejected them with reasoning.

5. Correctness

• 1: Solution wrong; doesn’t handle the given examples.
• 2: Handles examples but fails an obvious edge case.
• 3: Handles all standard edge cases.
• 4: Handles edge cases plus 1 non-obvious one (overflow, empty input, all-duplicates).
• 5: Walks through correctness argument using invariant or induction.

6. Complexity Analysis

• 1: Wrong or absent.
• 2: Correct but only stated at the end.
• 3: Correct, articulated during/after coding.
• 4: Correct, plus space complexity, plus identified the bottleneck.
• 5: All of the above + considered amortized analysis or worst-case input that triggers worst-case complexity.

7. Code Quality

• 1: Unreadable; magic numbers; one-letter variables everywhere.
• 2: Works but ugly; copy-paste blocks; unclear naming.
• 3: Readable; reasonable names; small functions.
• 4: Clean structure; helpful comments where non-obvious; good use of standard library.
• 5: Production-quality — clear names, no dead code, idiomatic for the language, would pass a code review.

8. Testing

• 1: Did not test.
• 2: Tested only the given example.
• 3: Tested 1–2 edge cases unprompted.
• 4: Systematic walkthrough of given examples + 2+ deliberately-chosen edges.
• 5: Found and fixed own bug through testing, or explicitly stated which test classes would expose risks.

9. Debugging

• 1: Hit a bug, panicked, never recovered.
• 2: Hit a bug, fixed by trial and error.
• 3: Hit a bug, debugged systematically with prints.
• 4: Hit a bug, hypothesized cause, verified with targeted assertion, fixed.
• 5: Hit a bug; narrated the debug protocol aloud; fixed in under 3 minutes.

10. Communication

• 1: Silent typing.
• 2: Occasional muttering; no clear narrative.
• 3: Explained brute force and optimization out loud.
• 4: Continuous narration of thought process; pauses only to think briefly.
• 5: Narrated, paused at decision points to consider tradeoffs, invited interviewer input at appropriate moments.

11. Handling Follow-ups

• 1: Could not answer follow-ups.
• 2: Answered partially.
• 3: Answered correctly with one prompt.
• 4: Answered correctly without prompt; proposed reasonable extensions.
• 5: Answered, anticipated the follow-up before it was asked, and proposed extensions.

12. Language/Runtime Knowledge

• 1: Made language errors (Python integer-divides where float was needed; Java auto-boxing trap).
• 2: No errors but no runtime awareness.
• 3: Used appropriate language features (Python Counter, Java Map.Entry).
• 4: Articulated runtime cost (Python list.insert(0, ...) is O(N); Java String += is O(N²) in a loop).
• 5: Discussed GC/memory model/concurrency implications when relevant.

13. Tradeoff Reasoning

• 1: Picked one approach with no comparison.
• 2: Mentioned one alternative.
• 3: Compared two alternatives with a stated reason.
• 4: Compared 2–3 alternatives across time/space/code complexity axes.
• 5: Articulated which alternative would be preferred under different constraints (small N vs large N, read-heavy vs write-heavy, latency vs throughput).

14. Production Awareness

• 1: None — solved as an algorithm puzzle.
• 2: Mentioned scaling in passing.
• 3: Articulated 1–2 production concerns (latency, persistence, concurrency).
• 4: Articulated multiple production concerns; explained how implementation would change.
• 5: Discussed monitoring, failure modes, backward compatibility, deployment strategy — staff-level signal.

Passing Thresholds by Mock Level

Notes:

• Production-aware dimensions (#13, #14) are weighted higher for mocks 07–10.
• Communication (#10) is the most common reason candidates fail; if your average for #10 is below 3.5, drill it specifically.
• Mock 12 (competitive) deprioritizes #11–#14 (no follow-ups; pure algorithm).

Common Failure Modes by Level

How to Schedule Mocks

12-Week Accelerated Track

• Weeks 1–4: Mocks 01–04 (one each)
• Weeks 5–8: Mocks 05–08 (one each)
• Weeks 9–12: Mocks 09–12 (one each) + repeats of the ones you failed

6-Month Serious Track

• Months 1–2: foundations; no mocks yet
• Month 3: Mocks 01–03 (2 per week)
• Month 4: Mocks 04–06 (2 per week)
• Month 5: Mocks 07–10 (3 per week)
• Month 6: Mocks 11–12 + heavy re-mock cycle (4 per week)

12-Month Elite Track

• Months 1–6: foundations + light mocks (mock 01–04, 1 per week)
• Months 7–9: Mocks 05–10, 2 per week
• Months 10–12: Mocks 11–12, ICPC contests, 3 mocks per week + 2 contests per week

How to Self-Evaluate Honestly

The single biggest failure mode is grade inflation. To counter:

1. Record the session. Listen back. You will hear all the silent gaps and the muttered “uh, let me think” filler.
2. Compare to the rubric word-for-word. “I tested edge cases” is not enough for a 4 unless you actually tested 3+ unprompted edge cases.
3. Find someone harsher than you to debrief with. Ideally an engineer one level above your target.
4. Track scores over time. A flat line means you’re not improving — change something (new problem domain, harder mock, partner).
5. The dimension where you score lowest is your training target. Drill it for two weeks, then re-mock.

Mock Index

What “Pass” Means

Passing a mock is necessary but not sufficient readiness. The full readiness checklist is in READINESS_CHECKLIST.md. The mocks here verify you can perform — not that you can do so consistently. Aim for 3 consecutive passes of any given mock before considering that level handled.