mock-interview

Mock Interview Questions

Overview

Generate interviewer-side mock-interview question sets from a candidate's resume, with drill-down chains that probe each main question level by level down the same thread.

This is the Socratic method applied to interviewing. Each follow-up digs one level deeper into the candidate's previous answer — same thread, never a sibling branch — and the chain keeps going until the candidate either reaches solid ground (genuine first-hand depth) or their reasoning collapses and they hit the edge of what they actually understand. That terminus — solid ground vs. collapse, and how deep it took to reach — is the signal the interview exists to produce.

Core principle: Each follow-up question must be a natural next question to the candidate's previous answer. Same thread, one level deeper — not a different branch. Stop only when the thread itself terminates (see Chain Depth Decision).

This is a collaborative co-design process with the interviewer, NOT a one-shot generator. The two rules below are mandatory and define how this skill works.

Rule 1 — Co-Design + Council, Not One-Shot (Mandatory)

Default LLM behavior is to silently produce a finished question set in one shot, then stop. That is the #1 failure this skill prevents. Two disciplines, neither opt-in:

1a. Per-question ping-pong with the interviewer

Do not dump a finished set. Build it with the interviewer, question by question. For each question, surface your decision rationale — direction, expected answer keywords, and resume evidence (not hidden chain-of-thought) — and get the interviewer's input BEFORE finalizing:

• Direction: "이 질문 이런 방향(키워드 X)으로 가려는데 어때?"
• Follow-up candidates: "이 답변 다음 꼬리질문 후보가 (A) …, (B) … 인데 뭐가 더 좋아?"
• Happy-case keywords + evidence: "이 질문엔 이런 키워드로 답이 나와야 할 것 같고, 이력서 근거는 X야(또는 이력서엔 없고 후보 이해도를 떠보는 질문이야) — 동의해?"

Incorporate the interviewer's answer, then move on. You may batch the stages of ONE chain (one area) into a single checkpoint message, but never batch multiple areas or the full set, and never ask for a blanket rubber-stamp — each stage's direction / keywords / evidence must be individually visible and individually confirmable, and you wait for per-stage feedback before the next area. The process and its granularity ARE the product — the interviewer's domain judgment is what makes the keywords and evidence correct.

1b. Council validation to unanimous APPROVE

Send the interviewer-agreed draft through a multi-model council on the 10 review axes (see references/council-iteration.md). Default path: iterate to unanimous APPROVE, bringing each round's conflicts back to the interviewer. Explicit opt-out path: run exactly one council round silently — auto-apply verified factual-error fixes and consensus fixes, no user arbitration — then ship. This is the DEFAULT final step, not a conditional gate.

The only opt-out

The interviewer explicitly says "빠르게 / 그냥 한 번에 / 알아서 다 만들어줘". The bare filler "그냥" alone (e.g., "그냥 질문 좀 뽑아줘") is a casual discourse marker, NOT an opt-out. Even on a real opt-out, run exactly one silent council round — auto-apply verified factual-error fixes and consensus fixes, no user arbitration, then ship; never zero. Factual errors are never waved through in fast mode. Absent an explicit signal, ping-pong and council are the default.

| Rationalization | Reality | |-----------------|---------| | "User asked casually, so just produce it in one shot" | Ping-pong is default. No explicit "빠르게" → ping-pong. | | "Council takes time, skip it" | Council is default. The only opt-out is an explicit user signal. | | "Asking per question is too much" | That granularity IS the deliverable. Skipping it produces keywords/evidence the interviewer never validated. | | "I'll show the whole draft, then they can edit" | One-shot-then-edit is not co-design. Surface direction/keywords/evidence per question, before finalizing. |

Rule 2 — Drill-down Chain ≠ Branching Tree

Default LLM behavior is to produce a branching tree when asked for "3-level follow-ups." That is wrong.

| Wrong (branching tree) | Right (drill-down chain) | |------------------------|--------------------------| | Q → Q-A / Q-B / Q-C (3 keyword branches) → each branches again | Q → natural next question from Q's answer → natural next question from that answer → … | | Interviewer jumps onto a different path based on answer keyword | Interviewer goes one level deeper on the same thread | | Spreads into sibling branches — each path stays shallow | One thread, each level deepening it to its natural terminus (see Chain Depth Decision) |

Test: If Q3 would still make sense without hearing the Q2 answer, it is a sibling branch, not a depth chain.

When to Use — Skill Selection Decision

Resume-related skills overlap on keywords. Use this flowchart to choose the right one.

digraph skill_selection {
    rankdir=TB;
    node [shape=box, style=rounded];

    "Improve / fix / rewrite\nthe resume itself?" [shape=diamond];
    "Find / match jobs\nfor the candidate?" [shape=diamond];
    "Prepare interviewer-side\nquestions about the candidate?" [shape=diamond];

    "Improve / fix / rewrite\nthe resume itself?" -> "Use resume-forge\n(or review-resume)" [label="yes"];
    "Improve / fix / rewrite\nthe resume itself?" -> "Find / match jobs\nfor the candidate?" [label="no"];
    "Find / match jobs\nfor the candidate?" -> "Use resume-apply" [label="yes"];
    "Find / match jobs\nfor the candidate?" -> "Prepare interviewer-side\nquestions about the candidate?" [label="no"];
    "Prepare interviewer-side\nquestions about the candidate?" -> "Use THIS skill\n(mock-interview)" [label="yes"];
    "Prepare interviewer-side\nquestions about the candidate?" -> "None of the above —\nask user for clarification" [label="no"];
}

Triggers that map to THIS skill:

• User provides a resume (PDF/markdown) and asks for interview questions
• User mentions "꼬리질문 / follow-up questions / drill-down / 2단계 / 3단계 깊이"
• User wants to prepare to interview a candidate (NOT to be interviewed)

Workflow

1. Read the resume. If PDF/image, emit a markdown rendering as Part 1 of the deliverable. If already markdown, reference directly.
2. Extract project-by-project facts.
3. Identify 5–10 candidate high-signal areas (trade-off decision, design rationale, or operational depth).
   → PING-PONG: present the area list, ask "이 영역들 어때? 더 팔 곳 / 뺄 곳?" Incorporate before continuing.
4. For each agreed area, present the chain as ONE checkpoint (Rule 1a batching): show the Main question and each stage — direction / happy-case keywords / resume evidence individually visible — and wait for the interviewer's per-stage feedback before moving to the next area. Apply the Chain Depth Decision per stage; keep drilling the same thread until it terminates (the candidate reaches solid ground, or a natural next question no longer follows). Never rubber-stamp a whole chain; never batch multiple areas into one checkpoint.
5. Assemble the agreed draft per Required Deliverable Structure (incl. [Interviewer Guide] blocks, 1-page summary).
6. COUNCIL VALIDATION (default): load references/council-iteration.md via Read tool, run council on the 10 review axes, iterate to unanimous APPROVE, bring each round's conflicts back to the interviewer. (If the interviewer opted out: run exactly one silent council round — auto-apply verified factual-error fixes and consensus fixes, no user arbitration — then ship.)
7. Ship after unanimous APPROVE (or the interviewer explicitly stops).

Steps 3, 4, and 6 are interactive. Do NOT run 1→7 silently and present a finished artifact unless the interviewer explicitly opted out ("빠르게 / 그냥 한 번에 / 알아서 다 만들어줘" — bare "그냥" alone does NOT count).

Chain Depth Decision

Drill the same thread until it terminates. There is exactly ONE reason to stop: no natural next question follows from the prior answer. Use this at each potential next stage.

digraph chain_depth {
    rankdir=TB;
    node [shape=box, style=rounded];

    "Does a natural next question\nfollow from the prior answer?" [shape=diamond];

    "Just heard the prior stage's answer" -> "Does a natural next question\nfollow from the prior answer?";
    "Does a natural next question\nfollow from the prior answer?" -> "STOP — the thread terminated:\nsolid ground reached, or the candidate\nhit the edge of their knowledge.\nThat terminus IS the signal." [label="no"];
    "Does a natural next question\nfollow from the prior answer?" -> "Write the next stage and keep drilling —\neven past what the resume explicitly states." [label="yes"];
}

If the only way to "continue" is to jump to a different aspect, that is a sibling branch, not depth — stop this chain and open a new Main question (Rule 2).

Do NOT stop because the resume text "ran out." The resume records what the candidate claimed, not the limit of what is worth probing — and real understanding usually lies past the literal resume text. A natural next question on the same thread is fair game no matter how deep it goes.

Fairness guard: keep "I don't know" (모르겠습니다) cost-free. Deep drilling is fair only if admitting the edge of one's knowledge is cheap — then a collapse is honest signal, not a manufactured one. A candidate who invents an answer under pressure does so because the interviewer punishes "I don't know," not because the question is deep — so fix the reaction, not the depth. The Interviewer Guide should say "if they reach their limit and say so, that is a clean terminus — note the depth and move on," never "they should have known this."

Anatomy of a Good Stage

Use numeric main-question IDs (Q1, Q2, …). Never use letter suffixes (Q-A, Q-B, Q-C) — those signal sibling branching, which Rule 2 forbids.

### Q{n} → stage-{N} drill-down

> [Natural next question from the prior stage's expected answer]

**Why this question is natural**: [1-2 sentence rationale referencing the prior answer thread]

**Happy-case answer keywords**
- [Concrete senior-discriminating points]
- [Operational signals — not buzzwords]
- *(Bonus, if mentioned spontaneously)* [Vendor / framework nuance — extra credit only; absence is not a scoring penalty]

**Resume evidence**: [Direct quote from resume that anchors this stage — OR, when the stage probes past the literal resume, say so plainly (e.g. "beyond the resume: does the GET_LOCK claim rest on real understanding of its lack of TTL?"). This line tells the interviewer how to read a failure here: a contradicted claim, or just the edge of the candidate's knowledge.]

Happy-case Keyword Rules

Keywords must be senior-discriminating, not surface vocabulary:

• ✅ "queue capacity = arrival rate × allowable wait (Little's Law)" — dimensional reasoning
• ❌ "ThreadPoolExecutor", "queue", "backpressure" — buzzword soup

Three layers per stage:

• Primary — average expected answer
• Strong senior signal — vendor nuance, dimensional analysis, anti-pattern recognition
• (Bonus, if mentioned spontaneously) — extra credit; absence is not a scoring penalty

Anti-pattern trap handling: When candidates commonly pick a wrong option (e.g., CallerRunsPolicy breaks HTTP-pool isolation), keep that option visible in the keyword list AND attach a separate [Interviewer Guardrail] probe to verify the candidate recognizes the trap.

Question Framing — Real Facts, Not Hypotheticals

When asking about something the candidate may not have done, the tempting escape is the hypothetical — "If X had been the case, then …". Avoid it:

• Hypotheticals collapse to zero signal when the candidate says "that didn't apply to me" — nowhere to go next.
• The candidate reasons on top of an invented premise, weakening discrimination.

Pattern: ask a factual question, then let the chain naturally terminate or deepen based on the answer.

> Did the external site's webhook retry policy depend on your response code?

[Interviewer Guide — follow-up]
- "No, they didn't retry on response code" → chain naturally terminates (normal). Move to next area.
- "Yes, they retried based on response code" → enter the deepening question:
  "How did you respond on 0 affected rows to avoid retry storms?"

One answer signals termination, the other deepening. Both are valid signals. Hypothetical framing forces both onto the same path and loses the signal.

Visual Separation for Multi-Question Stages

When a stage naturally contains 2+ questions, do not put them in a single quote block — the interviewer reads them aloud in one breath.

**[Interviewer Guide — first utterance]**
> [Question 1]

[Happy-case keywords for Q1]

**[Interviewer Guide — second utterance (only if Q1 answer is sufficient)]**
> [Question 2 — natural deepening from Q1 answer]

[Happy-case keywords for Q2]

Conditional deepening uses a yes/no gate:

**[Interviewer Guide — yes/no gate]**
> [Yes/no question]

**[Interviewer Guide — follow-up handling]**
- "No" → chain naturally terminates (normal)
- "Yes" → proceed to the next utterance

Fact-Check High-Risk Areas

Common LLM factual errors. Verify before including in happy-case keywords:

| Area | Common error | Accurate fact | |------|-------------|---------------| | MySQL GET_LOCK() | "No auto-release" | Connection-scoped auto-release on session termination. Real issue: no lease/TTL, so the lock can stay held when the owning session hangs or its connection leaks without closing | | jmap | "Deprecated" | Per Oracle JDK docs, classified as experimental/unsupported (not deprecated). jcmd preferred | | MySQL composite index + range | "Only first column in key_len" | key_len includes the equality prefix plus the first range column. The second range column is a post-filter (ICP / Using where) | | Queue capacity sizing | "Processing time × wait time" (dimensional error: time²) | Arrival rate × allowable wait (Little's Law, L = λW) | | CallerRunsPolicy | "Normal backpressure choice" | When the isolated pool is reached from an HTTP/Tomcat thread, this defeats the isolation — anti-pattern | | LLM zero-retry | "Zero-retry for all errors" | Major LLM vendors (OpenAI, Anthropic, etc.) officially recommend exponential backoff for 429 Rate Limit — this is the exception |

This table is meant to grow. Add new factual pitfalls as you discover them.

Domain Mapping — Optional, Opt-In Only

Default: do not generate domain-mapping questions. A company name in the resume/prompt is not a license to auto-generate domain-specific probes.

Opt-in triggers: "Map to company X context" / "Include domain-fit questions" / "Add [domain] mapping".

Bad mapping is worse than no mapping. Example: mapping medical-reservation concurrency to an exchange's matching engine is the wrong analogy — matching engines are single-threaded in-memory while reservation systems use distributed locks. The correct analog is balance-hold / withdrawal-limit. Verify entity and pattern correctness for every mapping.

Required Deliverable Structure

1. Part 1 — Resume body extracted as markdown: For PDF/image resumes, render the resume content at the top (personal info, experience, projects, activities). Interviewers cross-check facts without reopening the PDF.
2. Part 2 — Areas (5–10): Main → drill-down stages, each a natural next question down the same thread, continuing until the thread terminates (solid ground or the edge of the candidate's knowledge). Each stage's Resume-evidence line says whether it is anchored in the resume or probes past it.
3. Interviewer Usage Guide: Progression principles, area priority, time allocation for 60/90-minute modes.
4. 1-page Compressed Summary (table): area name, main one-liner, drill-down stages, time — scannable at a glance.
5. Red / Green Flag Checklist: signals for evaluating responses.

Council Validation (Default Final Step)

This is the corrected design. Earlier versions made council an opt-in "quality gate" — that was wrong. Council is the DEFAULT final step.

Send the interviewer-agreed draft through a multi-model council on the 10 review axes (chain naturalness, evidence-line honesty, happy-case senior discrimination, factual accuracy, depth appropriateness, utterance separation, difficulty calibration, question fairness, domain-mapping accuracy, area coverage — full definitions in references/council-iteration.md).

Do not expect one round. Typically 3–7 rounds. "round-2-pass + minor polish" ≠ ship-ready.

The only opt-out: interviewer explicitly says "빠르게 / 그냥 한 번에 / 알아서 다 만들어줘" (bare "그냥" alone does NOT count). Even then, run exactly one silent council round — auto-apply verified factual-error fixes and consensus fixes, no user arbitration — then ship. Opt-out reduces ping-pong and iteration depth; it never skips the first factual round.

REQUIRED: load references/council-iteration.md via the Read tool. Do not run council from memory — the strict prompt format, the 10 review axes, feedback triage, conflict→user-interview, and stop conditions all live there.

Common Rationalizations (Stop Signals)

| Excuse | Reality | |--------|---------| | "User asked casually — produce it in one shot" | Ping-pong is default. No explicit "빠르게" → ping-pong per question. | | "Council takes time — skip it" | Council is the default final step. Opt-out requires an explicit user signal. | | "A tree structure is richer" | The user specified a chain. Richness comes from depth, not sibling branches. | | "Listing keywords is enough" | Keyword lists become buzzword soup. Operational signals, dimensional reasoning, vendor nuance discriminate seniors. | | "Company name appeared — auto-add domain mapping" | Domain mapping is opt-in. Auto-adding produces bad analogies and gets rejected. | | "This fact is common knowledge" | See the fact-check table. LLMs get these wrong often. | | "The interviewer will know to break it up" | A single visual block gets read aloud as one block. Use [Interviewer Guide] separators. | | "All stages must reach depth 3" | Depth is set by the thread, not a quota. A chain stops when no natural next question follows — that may be depth 2 or depth 5. Don't pad to a number. | | "The resume doesn't back this depth, so stop" | The resume is what they claimed, not the limit of what's worth probing. If a natural next question follows on the same thread, drill it — real understanding usually ends past the literal resume text. | | "They couldn't answer the deep one — mark them down" | Reaching the edge of one's knowledge is a clean terminus, not a deduction. Only a collapse on claimed territory (contradicting their own resume) is a negative signal. Keep "I don't know" cost-free. |

Red Flags — Stop and Restart

If any of these appear, stop and correct:

• Presenting a finished question set in one shot without per-question ping-pong (and the user did NOT opt out)
• Shipping without council validation — the default path requires council to unanimous APPROVE; opt-out fast mode requires exactly one silent round. Zero council rounds is ALWAYS a red flag.
• Finalizing direction / keywords / evidence without asking the interviewer "이거 어때?"
• Sibling-branch notation (Q-A, Q-B, Q-C used as follow-ups)
• Two or more questions packed into a single quote block
• Domain-mapping area present when the user did not request one
• Happy-case lists that are buzzword soup
• A chain stopped at the resume boundary while a natural next question on the same thread still existed (the collapse point was never reached)
• All chains padded to the same depth regardless of where each thread naturally terminates

Bottom Line

This skill is a collaborative co-design loop, not a generator. Build the question set with the interviewer one question at a time (Rule 1a), keep every follow-up a true depth chain drilled to where the candidate's understanding actually ends (Rule 2), then validate to unanimous council APPROVE (Rule 1b). The process and its granularity are the product — a finished artifact dumped in one shot, however polished, is the failure mode this skill exists to prevent.