HireSense-AI: The Mock Interview Room That Syncs Code, Video, and Judgment in Real Time

A deep dive into a full-stack collaboration app that wires together Socket.io, PeerJS, Judge0, and Gemini to turn interview prep into a live, shared workflow.

7 to 8 min read • View on GitHub • More from UI-VAIBHAV

A wide editorial scene of a mock interview room split into two linked spaces. On one side, a candidate works in a shared code editor while a timer hangs above the desk. On the other side, an interviewer watches a mirrored console with structured feedback, and a thin network thread connects video, editor state, and AI judgment. — HireSense-AI is less a chatbot than a shared interview room. The app treats code, media, and evaluation as synchronized parts of one live session.

Key Takeaways

HireSense-AI treats interviewing as a live coordination problem, not a chatbot problem.
Its real differentiator is the split-path architecture, where media, text state, code execution, and AI feedback each take the transport that fits them best.
The most interesting implementation detail is the double sync of code content and language selection, which keeps both sides of the room aligned in real time.
The project reads like an ambitious prototype that proves a single developer can assemble a credible end-to-end interview workflow from open components.

Most AI hiring tools start with a prompt box. HireSense-AI starts with a room. That difference matters, because the repo is not just trying to generate interview questions or score a resume. It is trying to hold a live session together while the candidate types, the interviewer watches, the editor changes, and the feedback loop keeps up.

That is why the most interesting thing in the code is not the model choice. It is the choreography. The app splits responsibilities across Socket.io, PeerJS, Judge0, and Gemini, then stitches them back into one shared experience. The result feels closer to Google Docs for interviews than to a traditional recruitment assistant.

The interview room, not the chatbot

The repo’s own documentation describes HireSense-AI as a comprehensive hiring assistant that aims to streamline the hiring pipeline. The code tells a narrower, more distinctive story: this is a mock interview cockpit. It is built around a synchronized room where live coding, video, and AI feedback all happen inside the same session.

HireSense AI is a comprehensive, AI-powered hiring assistant that revolutionizes talent acquisition through intelligent automation, bias detection, and real-time insights.

UI-VAIBHAV/HireSense-AI GitHub Readme, Project Documentation · UI-VAIBHAV/HireSense-AI: Agentic AI Hiring Assistant

That broader hiring framing is useful, but the implementation is more concrete. The backend is a Node and Express service. The frontend is a React app built with Vite. Real-time state flows through Socket.io. Video runs over PeerJS. Remote code execution is pushed out to Judge0. AI evaluation comes back from Gemini in a structured form that the UI can display without much ceremony.

What makes HireSense-AI different

The most revealing pattern is the double sync. The room does not only sync code text. It also syncs the selected language and version. That means the interviewer can change the environment in real time, and the candidate’s editor updates instantly. It is a small detail, but it exposes the project’s philosophy. The interview is treated like a shared live system, not a static test.

A close-up editorial illustration of two synchronized control dials linked by a hidden mechanism. One dial controls code and language, while the other controls feedback and evaluation. Turning one dial moves the other instantly, showing how the app keeps the interview room coherent. — The best implementation detail is also the easiest to miss. Code state and language state move together, which keeps the room aligned when the interviewer changes direction.

The architecture is split by data type. Text and room state go through the server, media goes peer to peer, code goes to Judge0, and evaluation comes back from Gemini as structured output.

If you want the shortest mental model for the app, it is this: choose the right transport for the right job. Socket.io carries room state. PeerJS carries media. Judge0 executes untrusted code elsewhere. Gemini returns feedback as data, not as a conversational blob.

How the real-time room is stitched together

The core coordination hub is the frontend DataProvider. It sets up shared session state and listens for changes that need to move across the room. When a participant types in the editor or changes the language, the app emits Socket.io events to the server, which relays them to the rest of the room. The result is a lightweight broadcast model that keeps the session in sync without overcomplicating the backend.

That separation matters. The server is not carrying video payloads. It is relaying room events. Media flows through a PeerJS WebRTC connection, which keeps the heavy audio and video path off the main application server. This is the right split for a live interview room, because it prevents the system from treating everything like chat traffic.

Frontend editor change -> Socket.io emit -> backend relay -> other clients
Frontend language change -> Socket.io emit -> backend relay -> other clients
Audio/video stream -> PeerJS WebRTC -> direct peer-to-peer path
Code run request -> backend proxy -> Judge0 -> result back to UI
Resume or answer text -> Gemini -> structured feedback -> UI

The code editor also reveals a practical design choice: the app treats language selection as part of session state, not just local UI chrome. If the interviewer switches from JavaScript to Python, the candidate’s editor follows. That is exactly the kind of small system behavior that makes a live interview feel coherent instead of fragile.

AI is the evaluator, not the whole product

The AI layer is important, but it is not the center of gravity. The backend uses Gemini for question generation and answer evaluation. More importantly, the prompts are structured so the frontend can trust the shape of the response. That keeps the UI predictable and avoids turning the app into a free-form prompt playground.

This is a good example of using AI as a module inside a workflow. The model is there to produce interview questions, summarize answers, and generate structured feedback. The product still depends on the room, the editor, the media stream, and the execution service. AI is the judge inside the system, not the system itself.

Why Judge0 matters

Remote code execution is one of the most serious parts of the app, and Judge0 is the right kind of boundary. Running arbitrary interview code on the application server would be a security and maintenance headache. Proxying execution to a dedicated service gives the project isolation, portability, and a cleaner failure mode.

Approach	Safety	Operational burden	Scaling	Best use
Run code on the app server	Low. Untrusted code shares the same process boundary.	High. Each language runtime becomes your problem.	Poor. Every environment change adds friction.	Quick demos only.
Proxy code to Judge0	Much better. Code runs outside the main app.	Lower. The service handles execution complexity.	Better. The app stays focused on orchestration.	Live coding interviews and sandboxed testing.

That choice also keeps the frontend simpler. The editor only has to submit code and show results. The app does not need to pretend it is a full compiler runtime. It just needs a dependable bridge to one.

The resume-to-feedback pipeline

The resume flow completes the loop from pre-interview context to live interview output. A PDF lands in the backend, where it is parsed with pdf-parse. The text is truncated, then passed into Gemini for analysis. The code includes retry logic, which is a practical touch when the model call is the slowest or least predictable part of the chain.

This is where the repo becomes more than a live coding toy. It connects the candidate’s background to the interview session itself. That makes the app feel like a workflow, not a collection of features.

Pipeline snapshot

Upload a resume. Extract text. Trim the payload. Ask Gemini for analysis. Reuse that context to shape the interview. Then move into the room and evaluate answers in real time. The whole arc is tight enough to be useful, and simple enough that one developer can actually hold it in their head.

What this competes with

HireSense-AI sits between utility tooling and product platform. It is broader than a resume parser, because it includes a live interview room. It is thinner than a commercial ATS, because it does not try to own the whole recruiting stack. That in-between position is exactly what makes it interesting.

Project type	Scope	Real-time collaboration	AI role	Code execution	Target user	Maturity
Single-purpose resume parser	Narrow. Usually one upload flow.	No.	Scoring or matching.	No.	Job seekers or recruiters.	Usually polished in one lane.
Interview prep tool	Medium. Focused on practice.	Sometimes.	Question generation or review.	Sometimes.	Candidates.	Often isolated from the interview room.
HireSense-AI	Broad enough to cover a full mock interview loop.	Yes. Core to the design.	Evaluator and question generator.	Yes, through Judge0.	Candidates, interviewers, small teams.	Prototype stage with ambitious scope.
Enterprise ATS	Very broad. Hiring ops and pipeline management.	Sometimes, but not centered on the session.	Screening, ranking, workflow automation.	Rarely exposed directly.	Recruiting teams.	Mature and closed source.

The real editorial point is not that HireSense-AI outclasses enterprise tools. It is that it demonstrates how far a single developer can get by assembling strong open components and focusing on one coordinated workflow.

The prototype signal

This repo has the shape of a strong capstone: a clear product idea, a coherent stack, and enough moving parts to show judgment. It also has the rough edges you would expect from an early-stage solo build. The app is ambitious, but it is still a prototype, not a finished recruiting platform.

That is not a flaw in the article. It is the point. The project is valuable because it shows a credible architecture for a hard problem. It proves that the interview room can be treated as a synchronized system, and that AI becomes more useful when it is one part of that system instead of the whole story.