Baseline Diagnostic — Day One

A timed 3-hour battery. You take this before any plan exists. Its only job is to replace assumptions about your level with measurements, so the six-month plan is built on what is actually weak rather than on what is conventionally assumed to be weak.

Do not read ANSWER-KEY.md or any solution.py before you finish. A contaminated baseline is worse than no baseline — it produces a plan optimized for a person who does not exist.

Table of Contents

• Why a Diagnostic at All
• Setup
• The Protocol
• Part 1: Coding (45 minutes)
• Part 2: System Design (45 minutes)
• Part 3: Python Internals Quiz (30 minutes)
• Part 4: Behavioral, Written (40 minutes)
• Scoring
• Recording Your Scores
• Monthly Re-Tests
• Rules I Will Hold You To
• References

Why a Diagnostic at All

The candidate-context assumptions this program started from — strong on search, retrieval, ranking and distributed systems reading; weak on timed coding speed, Python runtime depth, GPU/inference design, and staff-altitude behavioral narrative — are plausible and unverified. They came from a self-assessment.

Self-assessments are systematically wrong in a specific direction: people underrate skills they use daily (because familiarity feels like ease, not competence) and overrate skills they have read about but not performed under time pressure. If those assumptions are wrong in either direction, six months of study gets allocated to the wrong track, and you will not find out until the loop.

So: measure first. The battery deliberately spans all four onsite round types plus the internals layer, so the plan can be rebalanced against evidence rather than against a hunch.

This battery re-runs monthly. Its second job is producing a trend line — the single most motivating artifact in a six-month program, and the only honest evidence that the work is working.

Setup

cd swe-interview-prep/diagnostics
python3 --version          # 3.11+ required; 3.12 or 3.13 preferred

No third-party dependencies. pytest is optional — the test files run standalone.

You need, physically present before you start:

• A timer you can see. Not a phone you will unlock.
• A drawing surface for Part 2 — Excalidraw is reported to be the actual design-round tool, so use it. Diagramming under time pressure is a motor skill.
• A voice recorder. Part 1 is narrated out loud, and you will score the narration.
• Somewhere to write Part 4 that is not this repo (you will paste it in afterwards).

Close everything else. No AI assistant, no search, no documentation, no autocomplete beyond what your editor does natively. The point is to measure the floor, and the floor is what you have without tools.

The Protocol

Three hours, in one sitting, in this order. The ordering is deliberate: the reported screen is two 60-minute rounds back to back, so fatigue is part of what is being measured.

Hard stop means hard stop. When the timer ends, you stop typing mid-word. An interview does not grant extra minutes, and the entire diagnostic value of a timed instrument comes from honoring the timer. If you run over and score well, you have learned nothing.

Part 1: Coding (45 minutes)

Problem: d1-coding/problem.md — a resumable iterator with serializable state, presented in four progressive gates exactly as the reported onsite format works.

Why this problem. A resumable iterator with state serialization is one of the most-reported OpenAI screen problems (../research/findings.md), and it sits precisely at the intersection of the three reported Coding-2 themes — state management, memory efficiency, and the iterator protocol. It also produces diagnostic signal for Track B at the same time, which is why it is worth 45 of your 185 minutes.

The reported screen problem — the versioned key-value store — is deliberately not used here. It is the highest-value practice problem in Track A and burning it on a diagnostic would cost more than it measures.

How to run it

cd d1-coding
cp starter.py attempt.py          # work in attempt.py
# ... 45 minutes ...
python3 test_diagnostic.py attempt.py

The test runner reports per gate, so a partial result is a real result. It also prints which gate you reached and when — record the wall-clock time at which each gate first passed, because time-to-first-passing-gate is the single most predictive metric in this whole battery (see inference I3 in ../research/findings.md).

The rules that make it diagnostic

1. Narrate out loud the entire time, recorded. Restate the problem, state your approach, state complexity, name the invariant you are protecting. If narrating slows your coding noticeably, that is a finding — write it down. It is one of the most common causes of a passed-on-paper, failed-in-room outcome.
2. Open gates in order. Do not read gate 3 before gate 1 passes. The format's whole difficulty is that you cannot design for requirements you have not seen, and reading ahead destroys the measurement.
3. Record the clock time when each gate first passes. Write it in the log at the bottom of problem.md.
4. If you finish all four before 45 minutes, write down the elapsed time and stop. Do not polish. Speed is the variable being measured.

Part 2: System Design (45 minutes)

Problem: d2-system-design.md — a fault-tolerant distributed job scheduler. This is the reported screen design question, verbatim in shape.

Deliverable: a written design document plus a diagram. Both are graded. Producing a written artifact under time pressure is itself the skill — it appears in the design rounds, in the take-home grading criteria, and in the deep dive.

Use the template in the problem file. Do not skip the "tradeoffs I explicitly rejected" section — reported sources name "name-dropping technologies without defending the tradeoff" as the leading design-round anti-pattern, and that section is where the antidote lives.

Time budget inside the 45: roughly 5 minutes requirements and scale, 5 minutes API and data model, 10 minutes high-level architecture and diagram, 15 minutes deep dive on the two hardest components, 10 minutes failure modes and tradeoffs.

Part 3: Python Internals Quiz (30 minutes)

Quiz: d3-python-internals.md — 20 questions, closed book.

Answer in prose, briefly. Several questions ask you to predict program output; write your prediction before running anything, and do not run anything until scoring. The gap between your prediction and reality is the actual measurement — a question you got right by running the code measures nothing.

Mark each answer with your confidence: certain / fairly sure / guessing. A confident wrong answer is a different and more dangerous defect than an admitted gap, and the rubric scores them differently.

Part 4: Behavioral, Written (40 minutes)

Prompts: d4-behavioral.md — three prompts, written answers.

Written rather than spoken, deliberately: writing exposes whether the content is there. Spoken delivery can paper over a story with no decision in it, and delivery is a separately trainable skill you will drill later. Right now we are measuring whether you have the raw material.

Roughly 12 minutes each, plus 4 minutes to re-read. Do not edit for polish — the rubric scores decision content, tradeoff articulation, and scope, not prose quality.

Scoring

Score yourself against RUBRIC.md after all four parts are complete, using ANSWER-KEY.md.

The rubric maps each part's score to a starting level per track, which is what determines the shape of PLAN.md:

Score honestly, and if in doubt score down. A generous rubric is the one thing that guarantees you fail the real loop. It costs nothing to be told you are L1 and discover in week 6 that you are L2. The reverse costs the offer.

Recording Your Scores

Write your results into scores/ using the template there, then tell me the numbers. Only then does PLAN.md get written.

The minimum I need to build the plan:

The two subjective fields matter as much as the numbers. Where you froze localizes the gap far more precisely than the aggregate score does.

Monthly Re-Tests

Re-run at roughly weeks 4, 9, 13, 17, 21, and 25. Variants live beside this file as they are generated (retest-01/, retest-02/, …) — same shape, different problems, so you are measuring skill rather than recall.

At each re-test:

1. Take the battery cold.
2. Score it.
3. Compare against the trend line in scores/.
4. Rebalance the plan. If a track has reached L3, its hours move to the weakest track. This is the mechanism that keeps a six-month plan from becoming a six-month ritual.
5. Re-run the coverage audit.
6. Re-run the Phase 0 search. If something newer and better-sourced than the source report appears, supersede it.

Rules I Will Hold You To

• No reading ahead. Gate N+1 stays closed until gate N passes.
• No tools. No AI, no search, no docs. This measures the floor.
• Hard stops. Timer ends, hands off.
• Predict before running. Part 3 measures your model of the runtime, not the runtime.
• Score down when unsure. See Scoring.
• Record the freeze points. Where you got stuck is worth more than what you scored.
• Completion is never "I read it." Nothing in this program is marked done on the basis of reading. Only a passed drill, a working artifact, or a scored mock counts.

References

• ../research/findings.md — why each part is shaped this way
• ../research/source-report.md — the 41-row fidelity checklist
• RUBRIC.md — scoring bands and level mapping
• ANSWER-KEY.md — reference answers, after you finish
• ../mocks/README.md — the weekly scored mock protocol this feeds into
• Excalidraw — https://excalidraw.com (reported design-round tool)