Interview Prep · Topic 6 of 10

Mock Coding Interview

150 XP

Why mock interviews matter

Most candidates do not fail coding interviews because they lack algorithm knowledge.

They fail because interview conditions distort execution:

  • time pressure
  • speaking while thinking
  • ambiguity in prompts
  • stress-induced mistakes on easy steps

Mock interviews train the missing skill: performing with constraints.

What a coding interviewer is actually evaluating

A coding round is not just "did you get AC."

They evaluate:

  1. Problem framing (do you clarify requirements?)
  2. Algorithm choice (do you pick a reasonable approach quickly?)
  3. Correctness reasoning (can you justify it?)
  4. Code quality (readability, structure, edge-case handling)
  5. Debug process (when wrong, do you recover methodically?)
  6. Communication (can they trust you in real collaboration?)

Your mock process must measure all six, not just final output.

Mock format that actually works (60 minutes)

Phase 1: Problem intake (5 min)

  • restate prompt in your own words
  • ask clarifying questions
  • confirm constraints and return format

Phase 2: Approach discussion (8-10 min)

  • offer brute-force baseline
  • propose optimized approach
  • state time/space complexity before coding

Phase 3: Coding (25-30 min)

  • implement cleanly
  • narrate key decisions
  • handle edge cases explicitly

Phase 4: Test + debug (10-12 min)

  • run through examples manually
  • test boundary and adversarial cases
  • fix bugs out loud, not silently

Phase 5: Wrap-up (3-5 min)

  • summarize complexity and trade-offs
  • mention alternatives if time allows

If your mock skips any phase, it is weaker than a real interview.

Ground rules for serious mocks

  1. No hints for first 20 minutes.
  2. Use a timer.
  3. Speak continuously (as in real interview).
  4. No autocomplete-heavy IDE dependence.
  5. Record and review (audio/video if possible).

Without these constraints, you are practicing "coding alone," not "interviewing."

Scoring rubric (use after every mock)

Score each category 0-5:

| Category | 0-1 | 2-3 | 4-5 | |---|---|---|---| | Clarification | jumps into code blindly | asks some questions | sharp scope + constraints quickly | | Approach | wrong/unclear strategy | workable but shaky | strong strategy with trade-offs | | Correctness | cannot justify | partial reasoning | clear invariants and proof sketch | | Code quality | messy, fragile | mostly fine | clean, modular, readable | | Debugging | random edits | some structure | hypothesis-driven debugging | | Communication | silent or chaotic | understandable | concise, collaborative, confident |

Track trend, not one score.

Communication templates you should memorize

Clarification

"Before coding, I want to confirm input constraints, duplicate handling, and expected behavior for empty input."

Approach

"Baseline is O(n^2). I can improve to O(n) using a hashmap because we only need constant-time complement lookup."

Correctness

"Invariant: map contains elements from indices < i; if complement exists there, we have a valid pair."

Debug

"I suspect an off-by-one in boundary handling. Let me run the smallest failing case: n = 1."

Good communication reduces perceived risk even before final code is complete.

Common failure patterns (and fixes)

Failure 1: Coding too early

Symptom: rewrite solution multiple times.

Fix: spend 3-5 minutes on approach with complexity before first line.

Failure 2: Silent coding

Symptom: interviewer cannot evaluate reasoning.

Fix: narrate intent per block, not every keystroke.

Failure 3: No edge-case pass

Symptom: solution fails trivial boundaries.

Fix: always test:

  • empty input
  • single element
  • all duplicates
  • min/max constraints

Failure 4: Panic after bug

Symptom: random code edits.

Fix: use structured loop:

  1. reproduce bug
  2. form hypothesis
  3. test smallest counterexample
  4. patch minimal surface

Mock problem selection strategy

Use weighted mix, not random feed:

  • 40% medium core patterns
  • 30% medium-hard variants
  • 20% easy speed/confidence
  • 10% hard stretch

Category mix:

  • arrays/strings
  • trees/graphs
  • DP/greedy
  • design-style coding (classes/objects)

Do not do five similar two-pointer problems in a row.

Weekly mock plan (repeatable)

Week template

  • Mon: 1 timed medium (solo)
  • Wed: 1 paired mock (friend/mentor)
  • Fri: 1 medium-hard timed
  • Sat: review all mistakes and rebuild notes

After 4 weeks:

  • identify top 3 recurring failure modes
  • create targeted drills for each

Improvement comes from error analysis, not attempt count.

Post-mock review template

For each problem, capture:

  1. problem type/pattern
  2. first approach chosen
  3. first bug and root cause
  4. final complexity
  5. one sentence: "next time I will..."

Example:

"Missed duplicate handling in 3Sum due to skipping dedup after pointer movement. Next time I will run duplicate-specific dry run before coding."

Keep these notes in one running document.

Interview-day execution checklist

Before round:

  • quiet setup, stable network
  • coding language ready
  • pen/paper or scratchpad open

During round:

  • clarify first
  • complexity before coding
  • narrate key decisions
  • test before claiming done

End of round:

  • summarize solution and trade-offs
  • ask if interviewer wants optimization discussion

Consistency beats occasional brilliance.

Escalation strategy if stuck

If blocked for more than 3-4 minutes:

  1. restate what works and what fails
  2. propose fallback approach
  3. ask focused question ("Can I assume input is sorted?")

Staying collaborative under pressure is a positive signal.

Final takeaway

Mock coding is performance training:

  • technical depth
  • communication under stress
  • structured recovery from mistakes

Run disciplined mocks for 4-6 weeks and your coding rounds become predictable instead of random.