How MiPrep works

What happens between the interviewer finishing a question and an answer appearing on your screen.

Worth understanding once, because most of the settings only make sense against it — and because when something goes wrong, knowing which stage broke is most of the fix.

The path a question takes

  1. One audio channel is captured on your machine: the system audio your computer is playing — the interviewer's voice coming out of your speakers. Sys on the toolbar is that channel. Your microphone is never opened.
  2. Speech becomes text continuously, not in batches. Partial words appear in the transcript before the sentence finishes.
  3. A question is recognised in that running transcript. You do not press anything. If the interviewer phrases something as a statement and MiPrep does not react, the Answer button asks anyway.
  4. Your material is retrieved. Your resume, role notes and prepared cards are searched for what is relevant to this question — this is what Answer source controls. If a prepared card matches closely enough, that card is used instead of a generated answer.
  5. The answer streams back and renders as it arrives. What is on screen is what is ready; the rest follows. This is why an answer appears to start before the question has finished — because it has.

How the listening actually works

One capture, at the system level. The audio your computer is playing — the interviewer's voice arriving through your speakers — is captured and transcribed. Your microphone is never opened, so nothing you say is recorded, transcribed or sent anywhere.

This is also why macOS asks for Screen Recording. There is no way on macOS to capture another application's audio without it, and without it MiPrep hears you and nothing else — see Permissions.

Transcription is continuous, not chunked. There is no "recording, then processing" cycle. Words arrive as they are spoken, including partial ones: a half-finished sentence appears in the transcript and is rewritten as the speaker completes it. That is why the transcript sometimes visibly corrects itself — it is showing you its current best guess rather than waiting to be sure.

Nothing is triggered by hand. No press-to-listen, no wake word. A question is recognised in the running transcript and answered. If a question is phrased as a statement and MiPrep does not react, the Answer button asks anyway.

Silence is what ends a session, not a timer. Any speech at all — including an interim, half-recognised word — counts as activity. Five minutes with none of it and the session stops on its own, with the last thirty seconds counting down inside the Stop button. A long thinking pause will not cut you off; an empty room will.

Why it starts answering before the question ends

MiPrep does not wait for a full stop. Transcription is continuous and the answer begins forming while the interviewer is still talking. When the phrasing turns out different from what was anticipated, the answer is replaced rather than finished.

The practical consequence: the first words on screen are sometimes replaced a moment later. That is the system correcting itself, not a glitch.

What runs where

WhereWhat
On your MacAudio capture and mixing. The overlay itself, and its exclusion from screen capture. Your settings. Session history.
Off your machineSpeech-to-text and the answer generation, while a session is running. Your uploaded material, stored against your account and encrypted at rest.

No recording of the call is kept. See What leaves your machine for the specifics, including the one optional setting that uses your webcam.

The two ways a question arrives

Spoken — the path above.

On screen — a coding exercise nobody reads aloud. MiPrep watches one window you pick, notices when its content actually changes, and answers what is written there. Covered in On-screen questions.

They are independent. A live session transcribes audio whether or not you have picked a window, and window-watching works whether or not anyone is talking.

Where it fits in a prep routine

The overlay is the live half. The other half — your resume, the role description, and the prepared answer cards it draws on — lives in the web app, and is worth doing before the interview rather than during it. An answer can only be grounded in material that exists.