01
Purpose and users
Intrvuer is for candidates who want to rehearse for a specific role. It uses their résumé and the job they are targeting so practice questions and feedback relate to that role.
02
The problem
Reading a list of likely questions is different from answering one out loud. Candidates rarely get feedback on a specific answer unless someone sits with them.
- Context has to come from documents candidates already have.
- Feedback is only useful when it points at a specific answer.
- Speech and language services take time, so the session must show what is happening.
03
What I implemented
1 · Context setup
User’s task: add a résumé and the job being targeted.
What I built: the intake screens and the API that stores this context for the session.
2 · Spoken practice
User’s task: answer questions and follow-ups out loud.
What I built: the session interface, speech handling and the backend that sequences questions and follow-ups.
3 · Feedback report
User’s task: review what worked and what to change in each answer.
What I built: background processing with LLM integrations that produce per-answer feedback, and the report view.
- ContextRésumé, target job
- InterfaceNext.js session
- BackendFastAPI
- Background jobs
- Speech services
- LLM integrations
- ReportPer-answer feedback
Technical notes
- Each answer is one recording, uploaded for the question on screen with an idempotency key and a SHA-256 of the audio. The database allows one answer per question. A retry gets the original answer back without a second transcription; the same key with different audio is refused.
- An answer turn claims its question in a short transaction. Transcription and the follow-up decision then run with no transaction open, and the result is saved only if the attempt still holds the claim. The whole turn has a 90-second budget, under the app’s 120-second timeout; past that, the app gets a 503 it knows to retry. The interviewer’s reply is synthesised after the commit, so a synthesis failure costs the audio, not the answer.
- Feedback and résumé analysis run on Celery workers with Redis. Feedback is claimed under a lease and saved one answer at a time, so a retry pays only for the answers still missing. Scheduled sweeps pick up jobs that were never queued or whose worker died.
- Sessions, questions, answers and claims are stored in PostgreSQL. Answer audio is transcribed and discarded; the transcript is the answer.
04
Decisions and tradeoffs
Bring the role into the session first
- Decision
- Before the first question, an LLM reads the job description into requirements and the résumé into past roles. Questions are written from the top ten requirements and up to five roles, and the interviewer’s introduction names the company and position. After each answer, an LLM decides whether to ask a follow-up, with the conversation so far as context.
- Tradeoff
- Practice can’t start until the candidate has added both documents and the questions are generated, which the server allows up to 90 seconds. Follow-ups cost time on every answer too. I tried generating them in the background before they were needed, but when a candidate stopped halfway, the follow-ups already paid for were wasted. I dropped that in August 2026, so each answer now waits for one LLM call inside the turn’s budget.
Show listening, processing and recovery
- Decision
- The iOS app shows whether the interviewer is speaking or the candidate is recording. Each answer is written to disk as it is recorded and kept until the server accepts it; every retry reuses one idempotency key, so the server records the answer once. After five automatic attempts, not counting time offline, the answer waits in a saved-answers list with Retry and Discard. In a simulator test, an app killed mid-answer sent the answer on relaunch.
- Tradeoff
- There is no pause. A phone call ends the recording, and the app saves what was said and tells the candidate, instead of offering to resume. The server keeps only the transcript and the app deletes its copy once the server accepts it, so a bad transcript can’t be re-run from the audio. Keeping audio would have needed storage, a retention policy and a privacy position, and I declined it.
05
Outcomes
Evidence
A live product anyone can try, and a public sample report showing the feedback format.
Not yet measured
Usage and effect on interview results. No figures are claimed here.