Running my interview prep on Claude

Early in April I sat down with Claude to work through a set of dynamic programming problems. Its first response to the first problem was a complete explanation with the solution. I stopped it and asked to be guided with questions instead. Its next move was to ask, “what should dp[i][j] mean?” That question was itself a hint: it told me the state was two-dimensional, which was the one thing I was supposed to work out on my own. I flagged it, and the rule we wrote down was to ask “what does your state look like?” and nothing more specific.

That exchange captures the central problem with using a large language model as an interview coach. By default it is built to be helpful, and in interview preparation the most helpful-looking response (the answer, the structure, the reassurance) is usually the one that destroys the practice.

This post describes the system I built around that problem across more than 500 conversations: a project of source-of-truth documents, written standing instructions for the coach, separate protocols for teaching, drilling, testing and mock interviews, and a handoff discipline that let preparation survive across sessions. It is part 5 of the 35 companies, 8 offers series, and the system served every loop in it, with most of the depth going into the Google loop.

What the system produced:

• Conversations: more than 500 over five months, February to August 2026
• Coding practice: 102 questions over 18 days, each run by the same planner and interviewer protocol
• Coach verdicts that turned out wrong: at least five, in both directions (detailed below)
• Google loop: Strong Hire on the ML domain and Googleyness rounds, Hire on both coding rounds

Background: three ways AI tutoring fails#

Generic AI tutoring fails in three predictable ways, and each one is worse in interview preparation than in ordinary learning.

It gives answers. Reading a solution feels like learning and mostly is not. The generation effect, documented by Slamecka and Graf (1978), shows that information you produce yourself is remembered better than information you read. An interview tests whether you can produce the answer, so a coach that hands it over removes the exact skill being tested.

It flatters. Language models trained on human feedback tend to agree with the user. Sharma et al. (2023) found sycophancy across five leading AI assistants and traced it partly to human preference data that rewards agreeable answers over accurate ones. A coach that tells you a shaky answer was “great” is worse than no coach.

It forgets. Every new conversation starts from zero, and very long conversations degrade. My weak spots, my resume numbers, my recurring mistakes and the rules I had already set all had to survive across hundreds of sessions.

The fix for all three is the same: write things down. The coach’s behavior, my state and my material all lived in documents that every session loaded, rather than in any single conversation.

The architecture#

The system had three layers: a set of documents in a Claude project that every conversation could see, a small number of session types with their own protocols, and a feedback path from every session back into the documents.

graph LR
    A[("Standing<br/>instructions")] --> E["Session"]
    B[("Profile and<br/>habit table")] --> E
    C[("Source-of-truth<br/>docs")] --> E
    D[("Question banks")] --> E
    E --> F["Teach"]
    E --> G["Drill"]
    E --> H["Test"]
    E --> I["Silent mock"]
    F --> J["Handoff doc"]
    G --> J
    H --> J
    I --> J
    J -->|"patches"| C
    J -->|"patches"| B

    class A,B,C,D blue
    class E amber
    class F,G,H,I violet
    class J green

Standing instructions governed how the coach behaved in every session. The profile recorded how I learn, my confirmed strengths and the habit table from my interview debriefs. Source-of-truth documents held the material: ML implementation from scratch, theory, system design, LLM internals, pipelines and experimentation, a metric bank and a behavioral story bank. Question banks held coding and ML questions, numbered so a schedule could refer to them.

Documents as memory#

The documents were the coach’s memory, and they needed the same maintenance as any codebase.

Numbered and capped. Each document had a number and a scope, and I set a ceiling on how many could exist at once. When a new topic came up, it went into an existing document unless it clearly needed its own. Without the cap, every session wanted to produce a new document, and within weeks nobody (including the coach) knew which one was current.

Handoffs at the end of every session. Each session ended with a short handoff: what was covered, what was solid, what failed and exactly how, and what to do next. When daily handoffs piled up, I had Claude consolidate them into one master handoff that described the current state of every topic rather than a history of sessions. A topic that broke and was fixed became one line flagging it for a later cold check, with only the faulty snippet kept.

Repairs, not rewrites. Documents rotted: interview dates went stale as the schedule moved, cross-references pointed at documents that had been merged or renumbered. I ran periodic repair passes with a strict brief to fix only the listed categories of rot and change nothing else. A model asked to “improve” a document will rewrite it; a model asked to repair three named problems will mostly do that.

Standing instructions for the coach#

The most valuable document in the project was not about interviews at all. It was a set of standing instructions that told the coach how to answer anything. A few of the rules, paraphrased:

• When a request is vague, restate it as a concrete one-line spec before answering, and work against the spec.
• Recompute every number by a different method before stating it.
• Label every recalled claim that has not been verified in this session.
• Ask at most one clarifying question, and only when a wrong guess costs more than the question.
• Put the answer in the first three sentences, then the reasoning, then the risks.

The core of it was a list of ten “fake competence” patterns, each with a tell and a counter. Invented identifiers: a plausible function name or flag the coach cannot say where it read. Smooth arithmetic: a number that first appeared while writing the sentence. False balance: an answer where swapping the conclusion for its opposite would change almost nothing else. Template answers: advice that would still fit if you swapped my specifics for someone else’s. Premise adoption: building on a claim in my question without checking it. Every answer had to pass a final gate against these before being sent.

The profile document added coaching rules specific to me. The ones that mattered most:

1. Never coach technical content unless my direction was fundamentally wrong.
2. Never open a session by listing what needs fixing; start with the task.
3. Never ask “do you want to try this?”; assign it.
4. Never accept “as far as I remember” about my own production metrics.
5. Never reveal a pattern, algorithm name or problem structure before I attempt a problem.

The fifth rule came from that April dynamic programming session, and it is the one most coaching setups get wrong.

Session protocols#

Different kinds of practice need different behavior from the coach. I ended up with a handful of session types, each with its own written protocol, and I kept them in separate conversations so that one mode never leaked into another.

Teach sessions were Socratic and incremental: one concept at a time, a question before any explanation, confirmation before moving on. When a teaching session did not land (two of them, on context compression and agent frameworks, did not stick), I rebuilt them in a stricter format: one question at a time, theory and context first, and I drove the pace by saying “next.”

Coaching and test chats were kept apart. Coaching chats, which I prefixed with “c:”, allowed hints and explanation. Test chats were cold: the problem, my attempt, and a debrief only at the end. Mixing the two in one conversation meant that by the time I reached the test, I had already been coached.

Coding sessions split the coach into two roles. A planner read the day’s schedule from the plan and listed the problems. An interviewer then ran each problem the way a real coding round runs.

graph TD
    A["Planner: today's<br/>schedule"] --> B["Interviewer:<br/>present problem"]
    B --> C["Clarifying<br/>questions"]
    C --> D["Brute force<br/>and complexity"]
    D --> E["Convince before<br/>coding"]
    E --> F["Code: bugs hinted<br/>via trace requests"]
    F --> G["Complexity, dry run,<br/>edge cases"]
    G --> H["Debrief and<br/>teaching"]
    H --> I[("Master handoff")]

    class A gray
    class B,C,D,E,F,G amber
    class H violet
    class I blue

The interviewer never named the pattern, never taught mid-problem, and pointed at bugs by asking me to trace specific inputs rather than by correcting the line. If I deflected or got complexity wrong after one hint, it logged the miss and moved on.

Silent mock interviews were clean-room. For mocks, Claude saw only my resume, not the project’s coaching history, so it could not quietly steer toward weaknesses it already knew about. Follow-ups were proportional to the question, it pushed back the way an interviewer would rather than a coach, and after the mock every answer went into one of four buckets: pass, pass with a small correction, revision needed, or coaching and retest. The coaching that followed had a fixed shape: what I said, the ideal answer, and the theory that connects them.

I practiced aloud. I answered many mock questions by speech-to-text, which forced spoken phrasing rather than polished writing. The protocol told the coach to ignore transcription artifacts, of which there were many (“Dixtras” was Dijkstra).

Model and mode matched the session. Late in June I asked Claude to review my heaviest sessions and recommend a configuration for each. The rule that came out of it was simple: extended reasoning for audits, document rebuilds and cross-document consistency checks, where there is real ambiguity to resolve; no extended reasoning for mocks, drills and teaching, where the model applies a known framework and added latency hurts the pacing of the session. For generating long question banks, small batches with a running list of covered topics produced better questions than one huge prompt.

Where the coach was wrong#

The system worked, and the coach was still wrong in instructive ways. The table below compares its verdicts after a round with what actually happened.

The pattern is clear: the coach’s post-round verdicts were noisy, and mostly too harsh, with one important miss in the other direction. It was good at finding specific weaknesses and poor at predicting outcomes. I stopped asking it to predict and used debriefs only to find the next fix.

The other errors were about behavior, and each produced a rule.

It leaked structure. The dp[i][j] question was the first of several. The rule became: no hints about shape, pattern or structure before an attempt.

It steered to one expected answer. In an ML debugging mock it kept nudging me toward the answer it had in mind when my different answer was also correct. The rule became: accept any correct angle and grade the reasoning, not the match.

It flagged a non-error. After my Googleyness round it marked a job title I used as a verbal slip. The title matched the resume I had submitted exactly. The coach was working from a different version of my history than the interviewer was.

It leaked solutions at the worst time. In the final days before the onsite coding rounds, in a session meant to be nudges only, it gave away a full optimized solution, and kept doing it after I restated the rule. Under time pressure in a long session, written rules erode, and the only fix was to restate them in the session itself.

It explained when I needed to practice. Two long teaching sessions on agent topics produced fluent explanations that I could not reproduce a day later. The rebuild that worked had me answer before every explanation.

Results#

The system carried the whole search and was most visible in the Google loop: Strong Hire on the ML domain round, Strong Hire on Googleyness and Leadership, and Hire on both coding rounds. The coding sprint ran 102 questions in 18 days through the same planner and interviewer protocol, with every miss logged in one master handoff.

The less visible result was continuity. By July a fresh conversation could load the project, read the latest handoff and pick up exactly where the previous day’s session had stopped, including which problems had failed and why. That is what made five months of preparation compound instead of restarting every morning.

What I’d do differently#

Write the standing instructions on day one. I wrote them after weeks of correcting the same behaviors in conversation. Every rule in that document was a correction I had already made by hand several times.

Separate coaching and testing from the start. The “c:” convention came late. Before it, many of my tests were contaminated by coaching earlier in the same conversation.

Never ask the coach to predict an outcome. Its verdicts were wrong often enough to be useless for planning and harmful for morale. Ask it what to fix, not how you did.

Keep fewer documents. The cap helped, but I still spent real time maintaining documents. A smaller, stricter set would have needed fewer repair passes.

Use clean-room mocks earlier. Mocks where the coach knew my weaknesses felt harder than they were, because it went straight for them. Real interviewers do not know your weak spots, and the clean-room mocks were a better simulation.

Conclusion#

An AI coach is only as good as the constraints around it. Left to its defaults, it gives answers, agrees with you and forgets everything by the next conversation, which is the opposite of what interview practice needs. Written rules, separate session types and documents that carry state across sessions turn it into something closer to a disciplined sparring partner.

The most useful thing I learned is that the coach’s judgment of my performance was the least reliable part of the system, and its ability to run a strict protocol was the most reliable. Use it to drill, not to grade.

Part 5 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.