onsite

Onsite turns your resume and job description into a realistic three-round AI mock interview, then delivers evidence-based feedback and a personalized 7-day practice plan.

Comment

Inspiration

Technical interview practice is usually fragmented. You might rehearse behavioral answers in one place, solve coding problems somewhere else, and study system design from a checklist. That does not feel like a real onsite interview.

I built Onsite to simulate the complete experience in one continuous session. When I scoped it out, I was not sure it was buildable in a week: three separate voice interviewers, live code and canvas context, real test execution, and reliable round handoffs on one interview clock. The goal was to turn a candidate's own resume and job description into a realistic practice environment, not another generic chatbot.

What it does

Onsite creates a realistic three-round AI mock interview from a candidate's resume and target job description:

  1. Priya, HR probes real projects, experience, and role fit with behavioral follow-up questions.
  2. Mateo, Coding presents a problem in a live editor, asks for the candidate's reasoning, reads their current code and canvas, and runs real tests against the submitted solution.
  3. Dana, System Design reads the architecture drawn on a shared canvas and asks about the candidate's actual components, tradeoffs, scaling decisions, and failure modes.

The experience runs as one continuous session with a server-owned clock and real interviewer handoffs. At the end, Onsite generates an evidence-based readiness report with per-dimension scores, supporting interview evidence, strengths, concerns, better-answer guidance, and a personalized 7-day practice plan.

How I built it

Onsite is a Bun and Turborepo application built with:

  • Next.js, TypeScript, Tailwind, shadcn/ui, Monaco Editor, and Excalidraw for the candidate experience
  • Express, Prisma, and PostgreSQL for persisted interview state, round orchestration, reports, and server-owned timing
  • LiveKit and OpenAI Realtime for low-latency voice conversation
  • GPT-5.6 round agents with isolated HR, coding, and system-design instructions
  • Native tool calling for loading coding problems, reading the current workspace, running code, and ending rounds with structured reports

Each interviewer has its own instructions, objectives, scoring dimensions, and conversation memory. The backend remains the authority for the interview state machine, timing, round transitions, and persistence.

I used Codex as an implementation partner across the monorepo. It helped me build and refine the multi-agent orchestration, LiveKit worker, browser-to-worker workspace synchronization, interviewer instructions, report flow, UI polish, debugging, and TypeScript verification. GPT-5.6 powers the server-side agents, native tool calls, structured round reports, and final practice plan.

Challenges I faced

The hardest problem was making a voice interviewer behave like a credible interviewer instead of a generic conversational assistant.

I had to prevent voice echo from interrupting the interviewer, eliminate empty speech turns, and ensure the server could advance a round even if an agent delayed its handoff. The solution was to use server-side voice turn detection while keeping the backend in control of the clock and transitions.

Another difficult problem was keeping Mateo aware of the candidate's current work. The coding agent needs both the live code editor and the design canvas in the same response. I introduced atomic workspace snapshots so the browser sends the latest code and canvas context together, allowing Mateo to ask questions about the actual implementation and diagram instead of a scripted prompt.

Making the coding round credible also required real execution. Mateo can load a structured problem, inspect the candidate's solution, run a real test harness, and discuss the concrete stdout, errors, and failing cases.

What I learned

A strong interview simulator needs more than a capable conversational model. It needs reliable orchestration, isolated round context, real tools, durable state, and explicit rules for when to advance.

I also learned that useful feedback must be grounded in evidence. The best practice plan is not generic advice generated after the fact. It is built from what the candidate actually said in HR, wrote in the editor, and designed on the canvas.

What's next

I plan to add richer report visualizations, more role-specific interview rubrics, replayable feedback moments, broader language support for coding rounds, and deeper company-specific interview research.

Built With

Share this project:

Updates