Interview

/interview — Interrogate the resume

/interview does not write answers to recite. It turns the important claims on the resume and in the JD into verifiable questions, and checks — through an interview contract, one question at a time, evidence scoring, and targeted retry — whether the user can explain real responsibilities, implementation, metric definitions, trade-offs, and failures.

resume / JD → claims + role-competency matrix → interview contract → question & scoring contract
           → one question at a time, dynamic follow-ups → session ledger → evidence review + retry

Inputs

1. The role's resume (<folder>/01-Resume.html) and career/facts.md — including its TODO: lines, which are exactly the numbers an interviewer will probe.
2. The JD (<folder>/03-Job-Description.md).
3. career/stories.md ([fact] vs [draft — confirm]).
4. Round, time available, feedback preference.

No JD → predict from the resume. No resume → ask for one project. Ask only for what materially changes the drill; otherwise use defaults. Unknowns are UNCONFIRMED; never fabricate experience, numbers, or technical detail. Save a review to disk only on request (default: the role's 04-Interview-Prep.md); never into a public file.

North American rounds

Modes

Predict — /interview predict

Extract Ownership / Metric / Technical / Architecture / Result claims; build competency — evidence — gap from the JD; rank by relevance × probability × wording risk × evidence gap; output high-probability, supplementary, and stress questions. Per core question: source, intent, facts the answer must cover, next follow-up. No long model answers.

Q: Why did you choose an event-sourced store instead of updating rows in place?
Source: resume — "designed the ingestion pipeline … replayable"
Intent: technical choice, decision authority, trade-off
Answer must cover: original problem, alternatives, why this one, your part, result evidence
Follow-up: what breaks first at 10× the event volume?

Grill — /interview grill

Build the contract (references/interview-contract-and-session.md); lock a scoring contract before each question (references/question-and-scoring-contract.md); one question per turn; dig / clarify / step down / switch / end based on evidence; feedback per policy (immediate = training, deferred = realistic); keep the ledger. Scenario or system design → references/scenario-interviews.md. Never give the answer before the user answers; hints only as agreed, never project facts.

Review — /interview review

From the ledger: verified / partial / unverified / contradictory claims with the answer evidence; what needs a fact, knowledge, or toned-down wording; the two follow-ups most likely to expose the user; prioritised actions. No total score. Template: references/review-and-retry.md.

Retry — /interview retry

Only partial / unverified / contradictory claims; variants and counterfactuals, not repeats; compare evidence with last time; passed claims leave the queue.

Claims and what to probe

• Ownership — personal scope, what you built by hand, decisions, team split. Project result ≠ personal result.
• Metric — baseline, denominator, period, data source, attribution.
• Technical — inputs/outputs in this project, why this technique, the trade-off. Definitions do not count.
• Architecture — components, data flow, boundaries, alternatives, failure handling, scaling limits.
• Result — shipped or not, who uses it, how measured, personal vs. team.

Chase first: vague verbs without object/evidence; numbers without a measurement definition; "led / architected" without a boundary; happy path only; term definitions without project role; contradictions with the resume or earlier answers.

sufficient → ≤ 1 alternative / counterfactual → close claim
partial    → probe only the critical missing piece
no idea    → step down to the smallest fact → still nothing → unverified, switch
two answers with no new evidence → stop the branch
budget reached → wrap up → Review

When the resume is stronger than the user can defend, offer exactly three paths: add a real fact, learn the missing knowledge, or tone the wording down. Changes to facts.md / stories.md only with confirmation.

Spoken register

Anything the user will say out loud — a pitch, a background walkthrough, a STAR answer, a model phrasing offered as a hint — is written for the ear, not the page. Polished parallel prose reads as machine-written the moment it is spoken.

• Short sentences, contractions, one idea per breath. Spoken connectors are expected: "so", "basically", "the thing I did was", "and then".
• Open like a person answering ("Sure. So, quick version —"), not with a thesis statement.
• No taglines, no parallel slogans, no closing summary line. End on a fact or a one-line "that's what got my attention", then stop.
• Plain verbs over résumé verbs: swapped / fixed / built / made sure, not replaced / eliminated / architected / ensured.
• Approximations and one small self-correction are allowed ("about 75%", "like, ten hours a week") — that is how real recall sounds.
• Facts and numbers are unchanged and still come only from career/facts.md.
• Test before handing it over: read it aloud. If it sounds like a LinkedIn About section, rewrite.
• Pair every script with a beat skeleton (per beat: where / what you did / number / why it matters to them) and have the user say it back in their own words. The skeleton is the deliverable; the script only shows how the beats connect.

Sequence

/job-match → /great-resume → /make-resume → /job-apply → /interview → /offer. The resume is written for the recruiter; the follow-ups are reserved for the facts.