Week 16: Mock Interview Marathon

Pattern family: Synthesis · Time budget: 18 hours · Prerequisites: Weeks 0 to 15 complete. · Cold-revisit obligation: all prior patterns, on demand.

Overview

This week is structurally different from every week before it. There is no new pattern, no canonical deep-dive, and no practice set. There is nothing left to teach you about arrays, graphs, or dynamic programming; across fifteen pattern weeks you have written the Pattern Cards, solved the canonical problems, and run the Friday cold revisits since Week 2. The fifteen patterns are in you. What this week does is convert that knowledge into interview performance.

The skill under test now is not “do I know sliding window”. It is recognition speed and calm execution under time. In a real interview you get one read of an unfamiliar statement, a clock, and a human watching. You do not get a quiet room and an open afternoon; you get forty-five minutes and a need to name the pattern in the first two, sketch the approach in the next five, and write correct Python while talking. That is a different muscle from the one the prior weeks built, and it only gets trained one way: under the conditions it is for. So this week you run four full mock interviews, drill recognition until it is reflexive, and write the retrospective that turns sixteen weeks into a plan for the next twelve.

flowchart LR
    A["Mon-Thu:<br/>four 60-min mocks<br/>one random problem each<br/>recorded and reviewed"] --> B["Fri:<br/>recognition speed drill<br/>20 statements x 3 min<br/>name, sketch, complexity"]
    B --> C["Sat/Sun:<br/>long-form retrospective<br/>RETROSPECTIVE.md<br/>+ 12-week plan"]
    C --> D["Course complete;<br/>graduate mode available"]

Notice: the four mocks come first because performance is built by performing, not by re-reading notes. The speed drill on Friday isolates the single sub-skill that the mocks expose as weakest: how fast you go from a cold statement to a named pattern. The retrospective is last because it can only be honest after the week has shown you where you actually stand.

Warm-Up: Retrieve Before You Begin

Answer from memory, no peeking, no notes open. This is a course-spanning recall sweep: if any of these is fuzzy, that pattern is a candidate for your weak-pattern list later this week. The first three items are cold problem statements with the pattern hidden, exactly like the speed drill and a real interview: for each, name the pattern and say why. The last two are cue-recall items, where the pattern is named and you supply its tell. Answer in your own words; check against the per-week specs only after you have answered.

  1. ⟲ Cold statement: “Given a string, find the length of the longest substring with no repeating characters.” Which pattern, and why? What distinguishes it from two pointers?
  2. ⟲ Cold statement: “Given n piles of bananas and h hours, find the smallest eating speed that lets you finish all the piles within h hours.” Which pattern, and why is it correct even though the input array is not sorted?
  3. ⟲ Cold statement: “Return all valid ways to place n queens on an n by n board so that none attack another.” Which pattern, and what is the three-line skeleton every solution of this shape shares?
  4. ⟲ What is the recognition cue for 1-D dynamic programming (Week 13), and what is the one sentence you must be able to write before any DP code?
  5. ⟲ What is the recognition cue for a heap (Week 8), and name the three heap shapes (top-k, merge, two-heaps) by the phrase that triggers each?
Check your recall 1. **Sliding window** (Week 3). The longest-substring-without-repeats statement is "find the longest / shortest / best contiguous subarray or substring satisfying condition X", anything about a contiguous range under a constraint. It differs from two pointers in that the window carries maintained state (a `Counter`, a `set`, a running sum, a deque) that updates as the right edge expands and the left edge shrinks; two pointers usually walks a sorted array from both ends toward the middle without that running state. Two pointers is the special case; sliding window is the general one. 2. **Binary search on the answer** (Week 5; this is Koko Eating Bananas). The answer space itself can be ordered even when the input is not. If you can write a `feasible(x)` predicate that is monotonic in `x` (true for all `x` past some threshold, false before it), you can binary search `x` directly. The tell is "minimum / maximum value such that a condition holds", here the smallest eating speed that finishes in time; you search the speed space, not the array, which is why the unsorted input does not matter. 3. **Backtracking** (Week 9; this is N-Queens). The cue is "generate all subsets / permutations / combinations", "find every solution that satisfies X", placement problems like this one. The skeleton: make a choice, recurse, undo the choice; with pruning to cut branches that cannot lead to a solution. The `path` plus `used` template carries the partial solution. 4. 1-D DP: overlapping subproblems where the decision at each position depends on prior decisions, surfaced by "number of ways", "longest / shortest ending at i", or "minimum cost to reach state X". The sentence you must write first: "`dp[i]` is the [answer] for [the subproblem indexed by i]." If you cannot write it, you do not yet understand the problem. 5. Heap: "top k", "kth largest / smallest", "find the median of a stream", "merge k of anything sorted", "always pop the best next thing". Three shapes: top-k uses a size-k heap; merging sorted streams pushes the heads and pops the smallest; the running median uses two heaps balanced against each other.

Learning objectives

By the end of this week you can:

  • Recognize under time: read an unfamiliar statement cold and name the correct pattern in under thirty seconds, then sketch the approach in under five minutes.
  • Communicate: think aloud through a full solve, state the brute force and its cost first, state the complexity of your improved approach before coding, and drive a worked example by hand.
  • Diagnose: watch a recording of your own mock and identify, in writing, the exact moments you froze, the cues you missed, and the patterns that came back slow.
  • Produce the retrospective: deliver a RETROSPECTIVE.md that names your weak and strong patterns honestly and lays out a concrete twelve-week continuation plan.

The week’s schedule

The time budget is eighteen hours: roughly an hour per mock plus an hour reviewing each recording (eight hours), three to four hours on the speed drill, and the remainder on the retrospective.

Monday through Thursday: four full mock interviews. One 60-minute mock per day. One problem per mock, drawn at random from any prior week (Weeks 1 through 15, including the canonical problems and the practice sets). You do not choose the problem and you do not know its pattern going in; that is the point. Run each mock under interview conditions:

  • A live human is best: a study partner who will read you a problem and watch you work, a peer mock-interview platform that pairs you with a stranger, or a paid mock service if you have one. A human interrupts, asks “why”, and makes you talk, which is exactly the pressure you are training for.
  • If no human is available, the Muster tutor in graduate mode runs the mock for you (see the next section). It draws the problem at random, holds the clock, and debriefs you. It still refuses to solve.
  • Record the session if you possibly can (screen plus audio). Then watch the recording the same day and note, in writing, where you froze, where you went silent, where you reached for the wrong structure first, and how long it took you to name the pattern. The recording is more useful than the solve; almost nobody watches themselves interview, and the freezes are invisible from the inside.
  • One problem in 60 minutes is correct. A real screen is one or two problems in 45 minutes, so 60 minutes for one problem, including the talk and the review, is the right load. Do not cram four problems into a mock; that trains the wrong thing.

Friday: the recognition speed drill. Twenty problem statements pulled from across the prior weeks, three minutes each. For each statement you only name the pattern, sketch the algorithm in two or three lines of plain English, and state the time and space complexity. No coding. Details below.

Saturday or Sunday: the long-form retrospective. Two to three hours, written. This produces RETROSPECTIVE.md, specified at the bottom of this page. It is the capstone deliverable of the course.

How to run a mock with the tutor (graduate mode)

After you complete Week 16, the curriculum is finished but the tutor is not. It enters graduate mode: no more weekly content, just pattern-recognition drills and timed mock interviews on request. The contract is in tutor-reference.md (learner-facing) and the enforcement detail is in .tutor/tutor-core.md (the “Graduate mode” section). You ask for this mode explicitly; until you do, the tutor stays on the current week.

You can use graduate mode to run this week’s mocks. Ask it directly, for example: “Run a timed mock. Draw one problem at random from any prior week, hold the 25-minute floor, do not tell me the pattern, and debrief me at the end.” In graduate mode the tutor will:

  • Draw a problem at random from any prior week and give you one at a time.
  • Hold the clock and enforce the 25-minute struggle floor, exactly as it did all course.
  • Refuse to name the pattern (you recognize it cold) and refuse to write or grade solution code. The five principles still apply in graduate mode; the only thing that relaxed is that the tutor now runs mocks and drills on demand instead of marching you through a week. It coaches; it does not solve.
  • Debrief you with the five questions at the end, and point you at LeetCode’s judge as the oracle rather than grading by inspection.

A human partner is still the better mock when you can get one, because a human reacts unpredictably and the tutor will not. Use graduate mode when no human is available, or to drill recognition between human mocks.

The recognition speed drill

The single most decided thing in an interview happens in the first two minutes: do you recognize the pattern or not. If you do, the rest is execution you have practiced fifteen weeks. If you do not, you flail. This drill isolates that moment and trains it.

How to run it:

  1. Assemble twenty problem statements from the prior weeks. Pull from the canonical problems and the practice sets across Weeks 1 through 15. Cover families broadly: do not stack ten DP problems. Seed the set with at least two or three greedy, bit-manipulation, or math problems (Week 15): those have no prior fixed cold-revisit at-bat and are the freshest material entering this week, so they are the highest-variance draws, and the ones most likely to catch you cold. If a study partner picks them for you so they are a surprise, better.
  2. Set a timer for three minutes per statement. Sixty minutes total for twenty, plus short breaks.
  3. For each statement, out loud or on paper, do only three things: (a) name the pattern (sliding window, binary search on the answer, monotonic stack, two-heaps, topological sort, 1-D DP, and so on); (b) sketch the algorithm in two or three lines of plain English (what is the state, what is the loop, what is the data structure); (c) state the time and space complexity in general form.
  4. Do not write code. The drill is recognition and planning, not implementation. Coding is the part you have already trained.
  5. Mark each statement: did you name the pattern in under thirty seconds? The goal is sub-30-second pattern identification on a clear majority of them. The ones that took longer, or that you got wrong, go straight onto your weak-pattern list.

Sub-30-second recognition is the bar because it is roughly what the first two minutes of an interview allow before you need to start talking through an approach. If recognition is slow, that is the highest-leverage thing to fix, and the drill tells you precisely which patterns are slow.

Communication under pressure

This is the interview meta-skill, and it is the one thing this week is allowed to teach you directly, because it is not a solution to any problem; it is how you carry yourself through any solve. An interviewer scores your thinking, not just your final code. A silent candidate who writes a correct answer often loses to one who talks through a slightly worse answer, because the interviewer is hiring someone they will pair with, and they cannot evaluate thinking they cannot hear.

Run every solve, in mocks and in the real thing, on this spine:

  1. Restate and clarify first. Say the problem back in one sentence. State the input and output shapes and confirm the constraints (the size of n, the value ranges, whether the input is sorted, whether there are duplicates). Constraints are cues; they often tell you the intended complexity before you have an idea.
  2. State the brute force and its cost out loud. Even the dumb O(n^2) scan. Naming it does two things: it shows the interviewer you can get to a correct answer immediately, and it gives you a baseline to improve from. Improving from a stated baseline reads as engineering; jumping straight to the clever answer (or freezing because you cannot find it) does not.
  3. Name the pattern and the better approach, with its complexity, before you code. Say “this is binary search on the answer, I will write a monotonic feasible(x) and search the speed space; that is O(n log(max)) time, O(1) space” and only then open the editor. Stating the target complexity before coding keeps you honest and lets the interviewer redirect you early if you are about to write the wrong thing.
  4. Think aloud while you code. Narrate the loop invariant, the reason for each data structure, the edge you are guarding. Silence reads as being stuck even when you are not.
  5. Test with a concrete example by hand. When the code is written, walk a small input through it out loud, then deliberately test the edges: empty input, a single element, all duplicates, the largest allowed n. Finding your own bug before the interviewer does is a strong signal; the judge in practice was your oracle, and in the room your worked example is.

None of this is new problem-solving. It is the wrapper around the problem-solving you already own, and the mocks are where you rehearse it until it is automatic.

Final deliverable: RETROSPECTIVE.md

The capstone of the course. It lives in your own work repo (not in this curriculum repo), at the repo root or in a retrospective/ folder, committed like everything else. Write it from honesty, not aspiration: it is for you, six weeks from now, deciding what to drill before a real screen. Spec:

  1. Weak-pattern list. The patterns that came back slow in the mocks, took over thirty seconds in the speed drill, or that you got wrong. Name each pattern, the specific symptom (for example “froze on state definition”, “reached for the wrong data structure first”, “could not recall the loop order”), and the one problem you will re-solve to attack it.
  2. Strongest patterns. The three or four patterns you recognized instantly and executed cleanly. Name them and, in one line each, why they are solid (so you can stop spending time there).
  3. Three problems you expect in real interviews, with a playbook for each. Pick three problems (or problem shapes) you think a real screen at your target companies is likely to ask. For each, write a short playbook: the recognition cue that identifies it, the approach in two or three lines, the target time and space complexity, and the one edge case you will not forget. This is your pre-interview cheat sheet, written by you, defensible from memory.
  4. A 12-week post-course continuation plan. Concrete, week-numbered, and realistic for your hours. Reasonable ingredients: spaced re-solves of the problems on your weak list (the cold-revisit habit does not stop at graduation); company-tagged problem sets for your target employers; one or two mocks per week with a human or in graduate mode; and a deliberate next step beyond pure algorithms, for example beginning system design, since most full interview loops include it. State what you will do each week and how you will know you did it.

A suggested outline to fill in:

# Muster Retrospective

## Where I stand (one honest paragraph)

## Weak patterns
- Pattern: <name> | Symptom: <what went wrong> | Re-solve: <problem>
- ...

## Strongest patterns
- <name>: <why it is solid, one line>
- ...

## Three problems I expect, with playbooks
### 1. <problem or shape>
- Recognition cue:
- Approach (2-3 lines):
- Time / space:
- Edge I will not forget:
### 2. ...
### 3. ...

## 12-week continuation plan
| Week | Focus | Concrete activity | Done when |
| ---- | ----- | ----------------- | --------- |
| 1    |       |                   |           |
| ...  |       |                   |           |

The tutor will not write this for you. In graduate mode it will probe it Socratically if you ask (“your playbook for Two Sum says ‘use a hash map’; what is the key and the value, and why one pass?”), the same way it probed your Pattern Cards all course.

Reflect

This week’s reflection is course-spanning. Twenty minutes, in writing, after the retrospective is drafted:

  • Explain it back: in five sentences, describe to a peer about to start Week 1 what actually transferred from sixteen weeks of this course. Not the list of patterns; the reflex. What can you do now in a cold room that you could not do before?
  • Connect: look at the “How the patterns build” dependency graph in the curriculum overview. Trace one chain end to end (for example arrays to trees to heaps to graphs) and say in your own words how each pattern leaned on the one before it. Where did a late week expose a gap in an early one?
  • Monitor: of the fifteen patterns, which one would you least want to draw cold in a real interview tomorrow, and what is the single problem you will re-solve first to fix that?

How to know you are done with this week (and the course)

  • The four mock interviews are done, each recorded if possible, and each recording reviewed with written notes on where you froze.
  • The recognition speed drill is done: twenty statements, named-sketched-costed, with the slow and wrong ones captured.
  • RETROSPECTIVE.md is written and committed in your own work repo, with all four sections: weak patterns, strongest patterns, three problems with playbooks, and the twelve-week continuation plan.
  • .tutor/revisit-log.md reflects this week’s mock problems and the speed-drill misses, with dates.
  • .tutor/progress.md updated to “Course complete; graduate mode available.”

If any of the above is missing, the week is not done, and the course is not done. There is no Week 17; “Course complete; graduate mode available” is the terminal state. After it, the tutor stays available in graduate mode for as long as you keep drilling.

Resources

Free, no account required where possible:

  • A peer-to-peer mock-interview platform, where you alternate interviewing a stranger and being interviewed. The reciprocity is the value: interviewing someone else trains you to read a solve from the other chair.
  • A study partner or a local or online study group: trade problem statements for the speed drill and run mocks for each other. A human who reacts unpredictably is the closest free analog to a real interviewer.
  • The Muster tutor in graduate mode, when no human is available, for timed mocks and recognition drills (see tutor-reference.md).
  • [Docs] Python standard library reference, for keeping heapq, collections, and bisect cold in the room: https://docs.python.org/3/library/index.html