Interview

Records an online interview, transcribes it locally and reviews it. The audio never leaves the user's machine: only the transcript text reaches the model. Every review feeds a question bank shared by all applications, which /interview prep uses to predict and rehearse the questions of the next interview.

Talk to the user in their own language. Write review.md, the question bank and prep sheets in the user's language; quotes from the transcript stay in the interview's language.

Golden rule (same as cv-tailor): never invent data. Improved answers use only facts from the profile (workspace/profile/) or from the transcript.

Tools

The engine lives in tools/interview-recorder/ (see its README.md). Both scripts are self-contained uv scripts: uv run installs Python 3.12 and the dependencies on first use. Run them from that folder.

• record.py --out <dir> [--mic <name>]: records me.flac (microphone) and them.flac (system audio via WASAPI loopback). Windows only. The microphone is the Windows default input unless --mic picks another by part of its name. While running it keeps <dir>/recording.lock; it stops when <dir>/STOP appears, on Ctrl+C, or after --seconds N.
• record.py --list [--mic <name>]: shows which microphone and output device would be used, and lists every microphone.
• transcribe.py <dir> [--lang <code>] [--delete-audio]: writes <dir>/transcript.md with lines like [00:03:12] THEM: ... / [00:03:20] ME: .... Without --lang it detects one language from both tracks and prints it (Detected language: ...). Uses the NVIDIA GPU if available, otherwise the CPU. The first run downloads several GB (CUDA libraries and the model).

If uv is missing, tell the user to install it (winget install astral-sh.uv) and stop.

Where things go

Each interview gets its own folder inside the application's folder:

workspace/output/<company>-<role>/interviews/<YYYY-MM-DD>-<stage>/
├── me.flac, them.flac   (deleted after transcribing, unless the user wants to keep them)
├── transcript.md
└── review.md

<stage> is a short slug for the round (recruiter, technical, manager, case, final…). If the application has no folder yet, create workspace/output/<company>-<role>/ with the same slug rules as cv-tailor. Prep sheets go in the application folder as prep-<YYYY-MM-DD>-<stage>.md.

The question bank lives in workspace/interview-bank/ (index.md, experience.md, technical.md); its format is in question-bank.md. Read that file before creating or updating the bank. Everything stays inside workspace/ (git-ignored).

/interview start [application] [stage]

1. Find the application. Match what the user said against the folders in workspace/output/ and the rows of workspace/applications.md. If it is ambiguous or missing, ask (one short question). Ask for the stage only if it is not obvious.
2. Check nothing is already recording: look for workspace/output/*/interviews/*/recording.lock. If one exists, tell the user and ask whether to stop it first.
3. Check the devices: run uv run record.py --list and show the two device names plus the list of microphones. Ask in one line which microphone the call app (Teams, Meet, Zoom) is using, since it is often not the Windows default (e.g. headset mic in the call, webcam mic as default). If it differs, pass it with --mic <part of its name>. Bluetooth headsets appear only while connected. If the microphone looks like a built-in laptop mic and the output like laptop speakers, warn in one line: without headphones, the interviewers' voices leak into the ME track; use headphones.

4. Start the recording detached from this session, so it survives if the editor or the session restarts. From PowerShell (add '--mic', '"<name>"' to the list when needed):

   Start-Process -FilePath uv -ArgumentList @('run', '"<abs path>\tools\interview-recorder\record.py"', '--out', '"<abs path to the interview folder>"') -WindowStyle Minimized

   Then wait until recording.lock appears in the folder (up to ~60 s on the first run, while uv installs dependencies). If it does not appear, report the error.

5. Tell the user, briefly:
   • recording to <folder>; a minimized console window is the recorder;
   • ask the interviewers for consent at the start (e.g. "Do you mind if I record this for my notes?"). Recording rules differ by country; some require everyone's consent;
   • when finished: /interview stop (or press Ctrl+C in the recorder window if the session is gone).

Do nothing else while the interview runs. Never offer live help or answers during the interview.

/interview stop

1. Find the running recording (recording.lock, see above). If there is none but a folder has me.flac/them.flac and no transcript.md, go straight to step 3.
2. Create the STOP file in that folder and wait until recording.lock disappears (a few seconds). Report the duration if visible.
3. Pick the language. Pass --lang only if the user said which language the interview was in. Otherwise omit it and let transcribe.py detect it. Do not infer it from the CV or the posting: the user often doesn't know beforehand, and it often differs (e.g. a Spanish consultancy interviewing in Spanish for an English-speaking client). When the run finishes, tell the user the detected language. If it is wrong, or the interview switched languages, re-run with --lang set to the main language (keep the audio until the transcript looks right, then delete it).
4. Make sure no call is running. Transcribing is heavy (GPU, several CPU cores, a few GB of RAM for an hour of audio) and can make a video call stutter on a modest machine. Never transcribe while any recording.lock exists. Ask in one line whether the call is over and nothing else is about to start; if the user has another call soon, leave the audio in place and transcribe later (/interview stop again, or "transcribe the pending interview").

5. Transcribe in the background (it takes minutes for a long interview; the first run also downloads the model). It runs below normal priority, but heavy work may still feel slower meanwhile:

   uv run transcribe.py "<folder>" [--lang <code>] --delete-audio

   Drop --delete-audio if the user asked to keep the audio, or if the language was detected and the user may want a re-run; delete the FLAC files once the transcript is confirmed. Tell the user it is running; continue with the review when it finishes.

6. Run /interview review on the new transcript.

/interview review [transcript]

Without an argument, use the most recent transcript.md without a review.md next to it. The user may also paste a transcript or point to one made elsewhere (e.g. Teams' own transcription).

1. Read the context: the transcript, the application folder (tailored CV, cover letter, any notes such as company research or earlier reviews), its row in workspace/applications.md, and workspace/profile/.
2. Read the transcript critically. Whisper misspells names, companies and technical terms (e.g. "chunking" may come out as "chunky"); fix obvious ones silently and mark doubtful ones with [?]. Ignore hallucinated filler on silences ("Thanks for watching"). ME is the user; THEM can be several interviewers on one track: tell them apart from context when possible.
3. Write review.md next to the transcript with these sections:
   • Summary: who was there (names and roles, if said), the stage, length, overall impression in 2-3 lines.
   • Questions and answers: for each substantive question, in order:
     • the question (timestamp + close paraphrase or quote);
     • what the user answered, in 1-3 lines;
     • assessment: did it answer what was asked; structure (STAR for behavioral questions); technical accuracy; concrete examples and metrics; length; missed opportunities;
     • a better answer when the original was weak or incomplete, built only from the profile and the transcript. If the best answer needs knowledge the user may not have (a technical concept), explain the concept briefly and say so.
   • What they told us: new facts about the role, team, stack, process, compensation, benefits, location or work mode, with timestamps.
   • Questions the user asked and what was answered; questions worth asking next time.
   • Next steps and preparation: what comes next in the process and what to prepare, most important first.

4. Update the question bank (format in question-bank.md). If workspace/interview-bank/ does not exist, create it; if earlier review.md files exist that are not in its Interviews included table, offer to merge them first, oldest first, so the history keeps its order. Then, for each substantive question of this interview (not salary or logistics):

   • find the group that tests the same ability, reading index.md first and opening only the files it points to;
   • if there is one: add the wording under How it was asked if it is new, add a History line with the rating (✅ / ⚠️ / ❌, the same judgment as the review), recompute Status and Asked, update the Best answer (the user's own answer when it was ✅), and add any new JD signals;
   • if there is none: create a group with the next ID, under an existing theme or a new one;
   • update the index rows and add the interview to Interviews included.

   Write it directly: it is derived from the review, not new facts about the user. Report it in step 5 as one line (e.g. "bank: 4 questions updated, 2 new; T-007 went from weak to good").

5. Propose updates in one message, one line each, and apply them once the user confirms:
   • workspace/applications.md: status (e.g. interview) and a short note about this round.
   • Profile: new facts the user stated about themselves (achievements, metrics, skills, anecdotes) go to the matching file with source: interview <company>-<role> (<YYYY-MM-DD>), following the rules in workspace/profile/README.md. A strong answer can become a reusable entry in stories.md.
   • Application notes: facts about the company or role go to a notes file in the application folder (an existing one if there is one, such as company-research.md).
   • If the agent keeps persistent memory about the user's job search, update it with the process stage and next steps.
6. Finish with the three or four most useful takeaways in the chat, and the path to review.md.

/interview prep [application] [stage]

Prepares the next interview of an application from the question bank. It reads the bank but never changes it: only real interviews (/interview review) do.

1. Read the context: the application folder (job description or posting, tailored CV, company research, interviewer profiles, earlier reviews of this application), its row in workspace/applications.md, workspace/profile/ and workspace/interview-bank/index.md. Ask for the stage only if it is not obvious (screening, technical, manager, executive…). If the posting text is missing, ask for it.

2. Estimate how likely each bank question is, from the index:

   • JD match: its JD signals appear in the posting (strong if they are core requirements, medium if secondary);
   • stage fit: its Type and Stages fit this round (a screening asks experience and motivation; a technical round asks concepts and design; an executive round asks impact, leadership and judgment);
   • frequency: asked many times across companies means likely anywhere.

   Rate each as high, medium or low. Experience questions that come up in almost every interview (introduction, key projects) are always high.

3. Predict new questions: core requirements of the posting that no bank question covers. Mark them as new, not asked yet, and draft their answers from the profile. If the profile has nothing to back a requirement (or it is in gaps.md), say so and draft an honest answer.
4. Prioritize by probability × weakness: first high-probability questions with status weak, regressed, fair or unrated and the new ones; then high-probability good; mastered questions only as a one-line reminder. Low-probability questions are left out unless the list is short.

5. Write prep-<YYYY-MM-DD>-<stage>.md in the application folder:

   • What to expect: stage, interviewers if known, the posting's three or four themes most likely to be probed.
   • Questions to rehearse, in priority order: the question and its ID, probability and why (which signal or frequency), status and the last time it was asked, best answer (~30 s), key points, honesty notes. Copy from the bank, adapted to this posting: point the answer at what this company needs.
   • New questions (not in the bank) with draft answers.
   • Questions to ask them, fit for the stage and the interviewer.
   • Reminders: recurring lessons from the bank's history (e.g. "structure first, then the example"; "don't answer with tools when asked for patterns").

   If the interview language is unknown, add the best answers of the high-probability questions in the other likely language too. If a prep sheet or a hand-made question list already exists in the folder, ask before replacing it.

6. Finish in the chat with the five questions to rehearse first and the path to the prep sheet.

Troubleshooting

• THEM track is silent: the call audio is playing on a device other than the Windows default output. Set the headphones as the default output device before starting, and do not switch devices mid-call.
• ME track faint, echoey or empty: the recorder used a different microphone than the call (it defaults to the Windows default input). A webcam or laptop mic in the same room still picks you up, just with lower quality. Next time pass --mic with the microphone the call uses.
• Transcript partly translated or garbled (e.g. Spanish speech written as English): wrong language. Re-run transcribe.py with the right --lang (needs the audio, so delete it only after checking).
• Echo or interviewers' voices in the ME track: no headphones. The review still works; mention it if it confuses who said what.
• CUDA unavailable … falling back to CPU: transcription still works, just slower. On CPU, --model medium or --model small is faster at some cost in accuracy.
• Recording left running (e.g. the session closed): /interview stop finds it through recording.lock. If the recorder process died, the FLAC files written so far are still valid; delete the stale recording.lock and transcribe.