mock-interview

name

mock-interview

description

Run a real, spoken 20-minute mock interview against a specific company and role, then hand the recording to interview-analysis for scoring. Takes a CV and a JD, researches the company / department / team / hiring manager and the interview experiences reported for that company (falling back to the industry and role when the company has none), builds a timed question plan, then conducts the interview out loud: the questions are spoken through the computer's voice, the candidate answers into the microphone, and the recording is transcribed locally between turns so the interviewer can ask genuine follow-ups. Use this WHENEVER the user wants to PRACTISE or REHEARSE an interview — 模拟面试 / 练面试 / 面试练习 / mock interview / practice interview / "quiz me for my interview" / "interview me for this job" / "面试我" — even if they do not mention recording. This is the rehearsal skill: interview-prep writes a study report before, interview-analysis scores a real interview after, and this one is the practice run in between. Not for analysing an interview that already happened (use interview-analysis) or for producing a written prep report (use interview-prep).

Mock Interview (spoken, recorded, scored)

The candidate practises out loud against a real company and a real JD, and walks away with the same debrief report they would get from a real interview.

interview-prep  →  ✦ mock-interview ✦  →  interview-analysis
   study            rehearse out loud        get scored

The value is in the out loud part. A candidate who has silently read a prep report still stumbles the first time they have to say "why this company" to another voice, with a microphone running. This skill creates that first time, cheaply, before the interview that counts.

The one thing that makes this work

The questions are spoken by the computer and the candidate's answers go into the microphone. Between questions, the last answer is transcribed locally in a few seconds, so you — the interviewer — can hear what they actually said and probe the weak part of it, exactly like a real interviewer. Do not skip the hear step and fire pre-written questions; the follow-ups are most of the value.

Privacy — offline only

Everything is local: recording, speech, transcription, report. Never upload the CV, the JD, the audio, or the transcript to any external service. Web research in step 2 covers the company, never the candidate. Keep the candidate's phone, email and address out of every generated file.

---

Workflow

1. Preflight (do this first, it takes one command)

python3 skills/mock-interview/scripts/mock_session.py devices

This lists the microphones and confirms ffmpeg is present. Show the user the list and ask which input to use, then check three things with them:

• Headphones on. Otherwise the spoken questions leak from the speakers into the recording. The transcript builder detects and removes the leak, but clean audio scores better.
• Somewhere they can speak out loud for 20 minutes uninterrupted.
• A whisper backend. mock_session.py setup creates a venv and installs one (mlx-whisper on Apple Silicon, faster-whisper elsewhere). If the machine already has a whisper venv, reuse it instead — set MOCK_INTERVIEW_PYTHON to that interpreter or pass --whisper-python. Downloading a model takes a few minutes the first time; do it before the interview starts, never mid-session.

If there is no whisper backend at all, say so plainly and offer the fallback: run the interview anyway, ask the candidate to type a one-line gist after each answer so you can still follow up, and transcribe the full recording at the end. The recording itself is never at risk.

2. Gather inputs

• CV — required. Read it wherever it is; never copy it anywhere. Pull out projects with numbers, job history, tools, and the gaps.
• JD — required for this skill (a URL is fine). Without a target role there is nothing to rehearse against. If the user has no JD, offer to run against a generic role for their title and say the questions will be less pointed.
• An interview-prep report, if one exists — read it and reuse its research and question bank rather than redoing the work.

3. Research the company

Read references/research-brief.md. In short: company, then the department and the specific team, then the hiring manager, then the interview experiences reported for this company (Glassdoor / Seek / 一亩三分地 / 小红书 / Blind / levels.fyi). When the company has no reported interviews — normal for small NZ employers — fall back to the industry and role, and say so out loud in the plan rather than inventing company specifics.

Run the searches in parallel. Cite what you find. Never invent a fact about the company: the candidate may repeat it in the real interview.

4. Build and show the 20-minute plan

Read references/interview-plan.md for the time budget and how to derive questions from CV × JD × reported interviews. Show the user a short plan card (assets/plan-card.md) before starting — round type, interviewer persona, the question spine, and the two or three places you intend to press hard.

Ask three things, then start:

1. Which round is this? — recruiter/HR screen, hiring manager, technical, or final/panel. Never assume. The same JD produces a completely different twenty minutes depending on the answer, and candidates usually know exactly which round they are facing.
2. Who is the interviewer? (optional — take "I don't know" for an answer.) A name, a title, or just "the founder" changes the persona more than anything else you can learn. A 12-person company where the founder screens you personally is not the same interview as an HR coordinator working from a form, even for the identical role. Check the JD first — small companies often name a contact in the ad, and that person is usually the interviewer. If they do give you a name, spend one search on it (see Layer 4 of references/research-brief.md) and say in the plan card how it shaped the persona.
3. Which language? — the interview language (usually English) and whether they want the debrief in Chinese.

Keep the questions themselves out of the chat before the interview. Surprise is the point.

5. Run the interview

Read references/interviewer-craft.md before the first question — it covers persona, when to probe, when to let a weak answer stand, and how to keep to time. Then loop:

S=~/mock-interviews/2026-08-07-acme-data-engineer     # session directory

# once, at the start
python3 scripts/mock_session.py start --dir "$S" --device 1 --locale en_NZ --minutes 20

# per question
python3 scripts/mock_session.py ask  --dir "$S" --kind question --text "Walk me through the pipeline you built at Trimble."
#   → the question is read aloud; tell the user in chat that it was asked,
#     show the text, and wait for them to say they have finished answering
python3 scripts/mock_session.py hear --dir "$S"
#   → returns what they actually said, how long they spoke, and their pace

# follow up on what they actually said — this is the whole point
python3 scripts/mock_session.py ask --dir "$S" --kind followup --text "You said it cut failures. From what to what?"
python3 scripts/mock_session.py hear --dir "$S"

# check the clock every few turns
python3 scripts/mock_session.py status --dir "$S"

# at the end
python3 scripts/mock_session.py stop --dir "$S"

While the interview is running, in chat:

• Post each question as text too. Speech alone is unfair if a word is misheard, and it gives the user something to scroll back to.
• Say only "→ answer out loud, then tell me when you're done." No hints, no coaching, no "good answer". You are the interviewer, not the coach — the coaching all happens in the report afterwards.
• Never reveal the plan or the next question.
• Watch the clock. At 15 minutes, move to reverse questions regardless of where you are. Landing at 20 ± 2 minutes matters more than finishing the spine.

If hear comes back with an answer that is empty or obviously garbled, the microphone may have dropped. Ask the user to confirm they can be heard rather than silently scoring a blank.

6. Build the transcript

python3 scripts/build_transcript.py --dir "$S" --language en \
  --initial-prompt "Acme Corp, Snowflake, dbt, Airflow, Trimble"

--initial-prompt is worth setting: feed it the company, product and tool names from the JD and CV so whisper spells them correctly. This produces, next to the audio:

file	what it is
interview.srt	full transcript, speaker-labelled, timestamped
interview.txt	the same as plain text
interview.candidate.srt	the candidate only — exact disfluency counts
interview.meta.json	per-question timing, answer length, speaking pace
interview.wav	the recording, for scrubbing alongside the report

Speaker separation here is exact, not guessed: the interviewer's lines are the question text we wrote, and the candidate's lines are whisper output with the interviewer's speaking windows removed.

7. Hand off to interview-analysis

Read references/handoff.md, then invoke the interview-analysis skill with the transcript, the audio, the CV and the JD. Tell it this was a mock interview and point it at interview.candidate.srt for filler counts and interview.meta.json for the timing data it cannot derive on its own.

Then, in chat, give the user three things and stop:

1. the single answer that would have cost them the job,
2. the single strongest thing they said, worth keeping verbatim,
3. what to drill before running this again.

The report carries the detail. Do not restate it in chat.

---

Files

• references/research-brief.md — what to research, in what order, and what to do when the company has no reported interviews. Read before step 3.
• references/interview-plan.md — the 20-minute time budget and how to turn CV × JD × reported interviews into a question spine. Read before step 4.
• references/interviewer-craft.md — how to actually behave as the interviewer: persona by round, probing rules, silence, time control. Read before step 5.
• references/runbook.md — setup, microphone permissions, and every failure mode with its fix. Read when something breaks.
• references/handoff.md — the contract with interview-analysis. Read before step 7.
• assets/plan-card.md — the plan card shown to the user before the interview.
• scripts/mock_session.py — recorder, text-to-speech, and per-turn transcription. devices | setup | start | ask | hear | note | status | stop.
• scripts/transcribe.py — local whisper wrapper, live and final tiers.
• scripts/build_transcript.py — merges the turn log with the full transcription into the files interview-analysis consumes.