-
"Interview Room's start screen — candidates can upload their resume before the session begins, purely rely on technical questions or both. "
-
"Resume PDF parsing — questions are grounded in the candidate's real projects and experience, not generic prompts."
-
"A live interview in progress — voice-based Q&A powered by the Web Speech API, no typing required."
-
"The adaptive difficulty engine adjusts question complexity in real time based on how the candidate is performing."
-
"The final report card — a full performance summary generated at the end of the session."
Inspiration
Placement season at NIT Delhi turns every hallway conversation into "have you started prepping for interviews yet?" — and most of that prep still happens the old way: reading generic question lists off the internet, or roping in a friend for a rushed, unscripted mock round. I wanted something closer to the real thing — a system that actually listens to how you answer, adapts the difficulty the way a real interviewer would when you're struggling or coasting, and gives you a report card instead of a vague "you did fine." The goal wasn't just a personal practice tool — I built Interview Room as a flagship portfolio project meant for real use by other NIT Delhi students going through the same grind.
What it does
Interview Room is a voice-based, adaptive mock interview simulator. You talk to it — real voice input and output, not typing into a chat box — and it runs you through a five-phase interview structure, adjusting question difficulty on the fly based on how you're performing. At the end, it generates a report card summarizing your performance.
How we built it
- Backend: Node.js + Express, with MongoDB for persistence and Google's Gemini for the LLM-driven interview logic (question generation, follow-ups, evaluation).
- Voice I/O: Built on the Web Speech API for both listening to answers and speaking questions back — no typing required.
- Adaptive difficulty engine: Tracks performance through the session and shifts question difficulty accordingly, rather than running a fixed script.
- Resume-aware: Parses an uploaded resume PDF so questions are grounded in the candidate's actual projects and experience.
- Five-phase structure: Mirrors how real interviews are structured, rather than one flat block of questions.
- Quality tooling: A CI pipeline alongside an LLM evaluation harness to validate interview logic quality rather than relying on manual spot-checks.
Challenges we ran into
- Making voice feel natural, not clunky: Getting turn-taking, latency, and recognition accuracy to a point where the conversation feels natural took real tuning.
- Adaptive difficulty without whiplash: Tuning the engine so it responds to performance smoothly, instead of swinging wildly after one good or bad answer.
- Evaluating an LLM-driven system: "Does this even work well?" isn't a simple pass/fail when the interview logic itself runs on an LLM — building an evaluation harness to actually measure quality was necessary but non-trivial.
- Going from "working" to "usable": Getting to functionally complete was one milestone; deployment, concurrent users, login/session history, and moving to streaming STT/TTS are the challenges still ahead.
What we learned
- How to design an adaptive system where "difficulty" responds to live signal from the user instead of being a hardcoded ladder.
- Practical experience wiring voice I/O into a web app end-to-end, and the gap between "the API works in a demo" and "this feels natural to use."
- The value of building an evaluation harness before shipping — testing an LLM-driven feature by hand doesn't scale.
- What it takes to move a project from "works on my machine" to something meant for real users.
What's next for Interview Room
Public deployment (Render or Railway), real user acquisition among NIT Delhi students, streaming STT/TTS, login/session history, and rate limiting.
Log in or sign up for Devpost to join the conversation.