Hotseat

Turn a résumé and job description into role-specific interview intelligence
See the evidence, gaps, risks, and hiring bar before entering the room.
A focused 3:30 interview that adapts to the candidate’s real answers.
Understand exactly where signal was gained or lost.
Rewrite the résumé without rewriting the truth.

Inspiration

Interview preparation is fragmented. Candidates use one tool to rewrite their résumé, another to research the company, and generic question lists to practise interviewing. None of those tools preserve a continuous chain between what the role requires, what the candidate can prove, how they perform under questioning, and what they should improve next.

We built Hotseat to connect that entire journey.

The core idea is simple:

Do not rehearse generic answers. Read the room, understand the evidence, and take the hot seat before it counts.

What it does

Hotseat transforms a real résumé and job description into a complete, role-specific preparation experience.

1. Intelligent intake

Candidates can upload or drag-and-drop their résumé as a PDF or text file, paste it manually, and provide the job description as either a file or text.

Hotseat extracts and normalizes both documents before treating them as separate sources of truth: the résumé describes what the candidate has actually done, while the job description defines the hiring bar.

2. Company and role research

The platform performs bounded research on the company, role, likely interview process, and evaluation criteria.

Instead of presenting an unexplained AI summary, Hotseat displays readable company intelligence with clickable sources and relevance notes.

3. Evidence-based match analysis

Hotseat produces separate diagnostics for:

overall role fit;
ATS readiness;
supported strengths;
missing or weak skills;
keyword coverage;
experience and credibility risks;
actionable improvements.

A missing requirement is not automatically converted into a candidate weakness. The system distinguishes between missing ability and missing evidence.

4. Adaptive interview briefing

Before entering the interview, candidates receive:

a role-specific interviewer persona;
likely pressure points;
candidate-specific weak spots;
a planned question bank;
company and hiring-bar intelligence.

The questions are generated from the actual gap between the résumé and the role rather than from a generic interview-question library.

5. Realistic timed interview

Hotseat runs a focused 3 minute 30 second interview in either live voice or typed mode.

The live experience uses the OpenAI Realtime API over WebRTC. The interviewer adapts to each answer, asks focused follow-ups, changes interview intensity, records evidence events, and automatically concludes when time expires.

The interviewer is rigorous but supportive. It gives fair credit to concise, complete answers, asks for only the most important missing proof point, and does not penalize nervousness, accents, or non-native phrasing.

6. Optional presentation feedback

Candidates can explicitly opt into camera sampling.

Hotseat captures a small rolling set of frames across the interview and uses them only for narrow, observable presentation feedback such as posture, gaze direction, gesture consistency, and composure.

It does not attempt to identify the candidate, infer protected traits, diagnose emotions, or pretend that camera evidence exists when permission was not granted.

7. Evidence-backed panel verdict

After the interview, Hotseat produces a transparent panel report containing:

a 0–100 panel estimate;
competency-level scores;
evidence from the candidate’s answers;
delivery analytics;
the moment where the candidate lost the most signal;
answer-by-answer autopsies;
stronger rewritten answers;
multiple panel perspectives;
a concrete next practice rep.

The number is deliberately labelled a Panel estimate, not a statistically calibrated hiring probability.

8. Résumé Signal Studio

Hotseat can then create a role-tailored résumé without inventing experience.

Candidates receive:

editable Markdown;
a live résumé preview;
a change ledger explaining every major revision;
strengthened keywords;
downloadable LaTeX;
print and PDF export;
six visually distinct ATS-safe templates.

The six document systems—Research Compact, Modern Classic, Minimal ATS, Cascade, Sterling, and Folio—target different professional contexts while preserving the same factual content.

How we built it

Hotseat uses a React 19 and TypeScript frontend powered by Vite, with a Node.js and Express backend in the same repository.

The frontend and API are served from one origin in production, simplifying uploads, security headers, API communication, and Cloud Run deployment.

OpenAI model responsibilities are separated by task:

a fast model handles bounded company research;
a structured reasoning model builds the match analysis and briefing;
a stronger reasoning model handles interview turns, verdicts, and résumé rewriting;
the Realtime API powers low-latency voice interaction.

The browser never receives the standing OpenAI API key. It requests a short-lived Realtime client secret from the backend before establishing a WebRTC session.

API inputs and AI outputs are validated through typed contracts and Zod schemas. The system limits uploaded files, transcript size, event count, image payloads, and generated content.

Data quality and evaluation integrity

The quality of Hotseat depends on maintaining a traceable evidence chain.

The application combines:

the original résumé;
the target job description;
sourced company research;
role-labelled transcript turns;
structured interview events;
optional consented camera frames.

Each source has a limited purpose. Company research can influence interview emphasis but cannot create candidate facts. Camera frames can influence presentation feedback but not technical competence. The résumé remains the factual authority for generated résumé content.

Realtime model events can occasionally arrive late or be omitted. Hotseat therefore reconciles them against the transcript using deterministic evidence repair. This prevents completed answers from disappearing or producing a zero-score verdict.

Delivery metrics are calculated from transcript text and timestamps instead of being invented by the model. Voice-only measurements are marked unavailable in typed mode.

The résumé generator also runs a hard-fact comparison that rejects unsupported dates, percentages, currency figures, email addresses, and other measurable claims.

The hardest challenges

Preventing false candidate answers

During early voice testing, interviewer playback and startup fragments such as “Hello” and “Certainly” could be transcribed as candidate answers.

We solved this by disabling the outbound microphone track while interviewer audio is playing, reopening it after a guard window, and correlating speech-start, speech-stop, and transcription events by their realtime item IDs.

Repairing missing scores

Some interviews contained valid transcript answers but displayed zero scored answers because model tool events had not arrived before verdict generation.

Instead of masking the number in the UI, we created a transcript-derived evidence layer that repairs missing events, suppresses duplicates, and preserves higher-quality model-generated evidence when it is available.

Reliable camera sampling

Camera capture could occasionally run before the video element had decoded its first frame, particularly when moving between the setup screen and interview room.

We added live-track readiness checks, capture retries, remount and tab-resume capture, rolling sampling, and an awaited final frame before verdict submission.

Balancing interview realism

The first strict-interviewer prompt became too adversarial because instructions such as “challenge every claim” were repeated across multiple prompt layers.

We redesigned the prompt contract around a rigorous but supportive interviewer, neutral acknowledgements, one focused follow-up per evidence gap, proportional scoring, and a controlled intensity ceiling.

Producing attractive and ATS-safe résumés

Generating arbitrary LaTeX directly from a model produced inconsistent hierarchy and could merge headings, dates, and wrapped bullets.

We separated content generation from document design. The model returns structured factual content, while deterministic code renders six verified LaTeX systems.

How GPT-5.6 Ultra and Codex accelerated development

All of the engineering workflow was completed through Codex using GPT-5.6 at Ultra reasoning effort.

GPT-5.6 Sol Ultra provided the reasoning layer used to compare architectures, hold multiple debugging hypotheses, analyse screenshots, and plan long implementation sequences. Codex provided the execution environment that inspected the repository, edited code, ran tests, controlled browser QA, compiled LaTeX, prepared deployment infrastructure, and operated the approved GCP and GitHub workflows.

Codex accelerated:

specification synthesis;
product and technical research;
frontend and backend implementation;
prompt engineering;
realtime WebRTC debugging;
evidence and scoring design;
visual and responsive QA;
LaTeX compilation and PDF inspection;
containerization;
Cloud Run deployment;
security and secret auditing;
technical documentation.

The product owner remained responsible for product direction, visual feedback, evaluating interview realism, supplying reference materials, controlling credentials, and approving deployment.

The development loop was not “generate code and hope.” It repeatedly followed:

Observation → competing hypotheses → discriminating test → root-cause fix → regression test

Accomplishments

Built a connected résumé-to-interview-to-verdict workflow.
Implemented both typed and realtime voice interviewing.
Prevented interviewer playback from being scored as candidate speech.
Added transcript-based evidence repair and duplicate suppression.
Created reliable consent-based camera sampling.
Built six distinct, compilable, ATS-safe LaTeX résumé systems.
Added deterministic local fallbacks for every AI workflow.
Passed 26 automated tests, strict TypeScript validation, and the production build.
Deployed a non-root container to Google Cloud Run.
Stored the OpenAI credential securely in Google Secret Manager.
Published the complete project and documentation on GitHub.

What we learned

The most important lesson was that reliable AI products need more than strong prompts.

Realtime AI behaves like a distributed system: audio, transcripts, model responses, and tool events can arrive independently and out of order. The application needs deterministic contracts and reconciliation logic around the model.

We also learned that generative content and deterministic presentation should be separated whenever factual integrity matters. The model is excellent at reframing evidence, while conventional code is better at enforcing document hierarchy, validation, reproducibility, and safety boundaries.

Finally, visual polish is not separate from engineering quality. Loading states, unavailable-data states, responsive layouts, evidence explanations, and privacy language all affect whether users can correctly understand and trust an AI result.