Interviewly

Companies get more candidates than their recruiters can meet. A first-round technical interview run by a voice agent saves those hours, but only if the recruiter trusts what comes back, the candidate gets a fair hearing, and the tool never becomes the one deciding who is hired.

• Real spoken interviews over WebRTC: LiveKit carries the audio, Deepgram Nova-3 transcribes it, Cartesia Sonic-3 speaks, and a Groq model reached through a LangGraph graph writes every line. LiveKit's own reply generation is never used.
• Two models, and neither scores. One asks the questions live; a separate pass after the interview writes what was and was not said. The live model has no path to score or review data at all, because under NYC Local Law 144 a tool that scores candidates is an automated employment decision tool, and one that writes notes for a human is not.
• Plain code runs the interview. Topic coverage, the minimum number of questions, the follow-up cap and the time limit are decided in Python: the model can propose a follow-up, and the controller decides whether it may ask it.
• An invite link carries a random token, never a candidate id, and the browser trades it once for a short-lived credential.

• Live: the web app on Vercel, the API, voice worker, Redis and the Judge0 code runner on AWS, the database on Supabase. A merge to main deploys both.
• Proctoring counts strikes on the server: fullscreen exits, window switches, gaze and a verified screen share, with the evidence kept.
• A hiring decision is refused until the recruiter has scored every answer by hand.
• A candidate whose connection drops rejoins at the question they were on, instead of starting over.

• Put the legal line in the architecture, not in a prompt.
• Let code decide the flow, and let the model only word it.
• Remove an attack surface rather than defend it: the closing line is scripted, and candidates have no channel to question the model.