study Simulation — Solo Mock Protocol¶

“You do not rise to the occasion. You fall to the level of your practice. Practice for the actual conditions.”

Solving problems in a quiet room without a timer is a different skill than solving them under an study partner’s gaze, narrating your thought process, on a whiteboard-ish text editor with no autocomplete. This file is the drill regimen that closes that gap.

The setup (one-time, ~30 min)¶

Editor. A plain text file in VS Code with autocomplete disabled. Or, better, use the LeetCode online editor — it has no local intellisense. View: Toggle Suggest.
Compiler. g++ -std=c++20 -Wall -Wextra -Wpedantic -O2 sol.cpp && ./a.out. That is your one command.
Timer. Any phone stopwatch. Set alarms at the milestones below.
Voice recording. Your phone’s Voice Memos app. Start recording, put the phone screen-down. You will listen back to two mocks per week.
Environment. No music, no browser tabs, no phone visible. study conditions.

Do this setup once, then every mock reuses it. Friction is the enemy of repetition.

Timing budget by problem type¶

Problem type	Time cap	If unsolved at cap	If unsolved after +15 min
Easy	12 min	Look up hint	Look up full solution
Medium	25 min	Look up hint (approach only)	Look up full solution
Hard	45 min	Look up hint	Look up full solution

Hard cap: 30 minutes on any Medium before allowing a lookup. Grinding a single problem for two hours is anti-learning — you burn cognitive fuel, hate the language, and quit the plan. Look up, understand, retry from scratch tomorrow.

The 6-phase study clock (25-min Medium)¶

Internalize these phase boundaries. Say them out loud as you cross them; this signals to a human study partner (and to future-you re-watching the recording) that you know where you are.

Phase	Time	What you do
1. Read & restate	0:00 – 1:30	Read the problem twice. Restate it in your words. Repeat the goal.
2. Clarify	1:30 – 3:30	“What are the constraints on n?” “Are duplicates allowed?” “Signed or unsigned?” “Empty input?” 3 questions minimum.
3. Approach	3:30 – 8:00	Talk out loud: brute-force first, then optimize. Name the pattern. Sketch complexity. Get study partner buy-in before coding.
4. Code	8:00 – 20:00	Type. Narrate what you are doing. Announce variable names, invariants, and loop conditions.
5. Test	20:00 – 23:00	Walk through with a small example. Then an edge case: empty, single element, all duplicates, negative numbers.
6. Complexity	23:00 – 25:00	State time and space. Explain the tradeoff. Suggest one alternative you did not pick and why.

Set three alarms: at 3:30 (clarify done), 8:00 (start coding), and 20:00 (start testing). Missing a phase boundary is failing the mock; you re-do it.

Speak out loud — always¶

Record every mock. The purpose is not to review the code (git shows the code). The purpose is to hear yourself think. You will discover:

You mumble the crucial insight and then forget you said it.
You use filler (“um,” “like,” “basically”) when uncertain.
You do not verbalize edge cases until prompted.
You skip complexity analysis when time-pressured.

Listen back at 1.5x. Two mocks per week. Twenty minutes total. Highest-leverage habit in this phase.

Weekly mock log template¶

Maintain in a single markdown file, appending each week. Add to your public NeetCode-150 repo README (Project P2.1).

### Week N mock log

| # | Date | Problem | Difficulty | Solved on first try? | Time to first correct | Notes / what I got stuck on |
|---|------|---------|------------|----------------------|----------------------|------------------------------|
| 1 | 2026-07-15 | LC 200 Islands | Medium | Yes | 14 min | Forgot to check visited before push; fixed. |
| 2 | ... |

**Voice-memo review notes (2 mocks reviewed this week):**
- Kept saying "basically" every 30s. Stop.
- Did not restate the problem at the top on mock #2 — skip a phase.
- Complexity analysis was correct but hedged ("I think it's O(n)?"). Say it flat.

Post the log publicly (repo README). Public accountability compounds. It also gives study partners something to talk about — candidates who keep a rigorous log tend to signal well.

Drill cadence (W11 onward)¶

Daily: 1 problem, timed, under 6-phase clock, no recording. Purpose: pattern reinforcement.
Twice weekly: 1 full mock, recorded, reviewed same day. Purpose: signal quality.
Weekly re-solve: 3 previously-solved problems from earlier categories, in half their original time. Purpose: retention.
Bi-weekly: 1 external mock (peer or platform, see below). Purpose: calibration.

Total weekly time on mocks: ~4 hours of your 10–15-hour budget. Non-negotiable in W11–W20.

External mocks — the 2026 landscape¶

Research this week confirms the following (things shift year to year in this space):

Platform	2026 status	Cost	Best for
studying.io	Alive, active. Now ~$225+/session with real Google/Meta engineers. Free anonymous peer mocks still exist but harder to schedule.	Paid tier premium; free tier limited	3–5 sessions before your actual FAANG loop.
Pramp / Exponent	Pramp acquired by Exponent; peer mocks remain free with sign-up.	Free peer, paid coach	Weekly peer reps at zero cost.
LeetCode Mock studies	Built-in, timed, but no human on the other side.	Free with LC subscription	Timing-only reps; not conversational.
AI mock platforms (Edesy, MockIF, PracHub)	Rapidly proliferating in 2026. Voice-based, 24/7. Quality varies widely.	Freemium	Behavioral rehearsal, not coding — the AI cannot evaluate C++ correctness deeply yet.

Recommendation for Raghul: Free Pramp/Exponent peer weekly starting W12. Add 2–3 paid studying.io sessions in W18–W20 as calibration before the actual loops in Phase 7. Do not spend on AI platforms for coding — they are not there yet for C++.

What a good mock feels like¶

A mock succeeded if all of the following are true:

You hit every phase boundary within 2 minutes of the target.
You verbalized at least one edge case before writing test code.
You stated complexity without hedging.
Your code compiled on the first g++ run (typos are fine; logic errors are not).
Your first submission passed at least the sample tests.
On voice-memo playback, you can follow your own reasoning without pausing.

A mock failed if any of these are true:

You went straight to coding without discussing the approach.
You never named the pattern (“This is BFS,” “This is 1D DP”).
You spent > 5 min silent while thinking. (Silence is a red flag in real studies — always narrate.)
Your complexity was wrong.
You could not explain a design choice when reviewing the recording.

Failed mocks are the point. Log what went wrong; re-mock the same problem class next session.

What most people get wrong¶

They do mocks in silence. They “do LeetCode” but never simulate the conversation. Then they walk into their first onsite and discover that solving is 40% of the study and the other 60% is how you solve it: the narration, the clarification, the complexity, the calm.

The fix is embarrassing but works: talk to yourself, out loud, in your own room, while typing. If you cannot bring yourself to talk to an empty room, you will freeze when someone is watching. Do the awkward thing now to make it automatic later.

And — the second failure mode — they never listen to the recordings. The recordings are the entire point. If you record but do not review, you are just performing. Review two per week, at 1.5x, taking two notes each. Twenty minutes. That is the drill.

Nav: ← Patterns & templates · Phase 2 projects →