InterviewBuddy — A Personalized AI Interview Coach Built for a Friend

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built InterviewBuddy, a personalized AI mock interview platform designed for Parshith Kumar S, who is preparing for software engineering interviews.

The problem I wanted to solve was simple: generic interview chatbots ask generic questions.

A real interview should be based on the candidate.

InterviewBuddy takes a candidate's resume, target role, optional job description, projects, skills, and previous interview performance and uses that information to conduct an adaptive technical interview.

Instead of simply generating another question, InterviewBuddy:

• Reads and structures the candidate's resume.
• Builds a candidate profile from their skills and projects.
• Uses an optional job description to understand role requirements.
• Generates personalized interview questions.
• Evaluates answers across technical accuracy, depth, and clarity.
• Identifies missing concepts and recurring weaknesses.
• Uses retrieval to ground questions in candidate-specific information.
• Adapts subsequent questions based on previous performance.
• Stores persistent weaknesses in PostgreSQL.
• Generates a final interview report.

For example, instead of asking a generic question like "What is REST?", InterviewBuddy can ask a candidate about how they designed REST APIs in their own project.

That makes the practice session much closer to a real interview.

Demo

Live application:
https://interview-buddy-1-quvm.onrender.com

Backend API / Swagger:
https://interview-buddy-v4c5.onrender.com/docs

The application is fully deployed and supports the complete interview flow from resume onboarding to final evaluation.

Code

GitHub Repository:
https://github.com/nagarjunm18/interview-buddy

How I Built It

The project uses:

• React + TypeScript — frontend
• FastAPI + Python — backend API
• PostgreSQL — candidate profiles, interview sessions, evaluations, and weaknesses
• RAG pipeline — candidate-specific retrieval
• TF-IDF + normalized vectors — lightweight semantic retrieval for the deployed free-tier environment
• Groq + openai/gpt-oss-20b — deployed LLM inference
• Ollama + qwen3:4b — local development and experimentation with an open-weight model
• Render — production deployment

One of the most interesting engineering decisions was adapting the retrieval layer for deployment constraints.

I initially used Sentence Transformers for embeddings. However, the dependency footprint was too large for the 512 MB free deployment environment.

Instead of abandoning retrieval, I replaced it with a lightweight TF-IDF vectorization approach with normalized vectors. The existing Retriever and similarity-threshold logic could then remain in place.

This gave me a much smaller deployment while preserving the retrieval pipeline.

I also designed the LLM layer so that the application could switch inference providers without rewriting the interview orchestration.

During development I experimented with Ollama and qwen3:4b locally. For the deployed application, I use openai/gpt-oss-20b through Groq.

This separation between the application logic and model provider means the interviewer can evolve without rebuilding the entire system.

Why Does Open Innovation Matter?

Open innovation was important to InterviewBuddy because I wanted the AI layer to remain replaceable rather than making the entire application dependent on one closed model.

During development, I was able to run an open-weight model locally with Ollama.

That gave me the ability to experiment with the model locally, understand the inference pipeline, and keep the LLM layer separate from the rest of the application.

The deployed version uses gpt-oss-20b, an open-weight model, through Groq for practical hosted inference.

This architecture means the core InterviewBuddy system isn't tightly coupled to one proprietary model.

The model can be changed while keeping the candidate profile, RAG pipeline, interview orchestration, evaluation logic, and persistent memory intact.

For an interview preparation tool that handles personal resumes and interview history, having control over the model and being able to move between local and hosted inference is particularly valuable.

What Makes InterviewBuddy Different?

The goal wasn't to build another chatbot.

The important part of InterviewBuddy is the interview loop:

A candidate's previous weaknesses can influence future practice sessions.

That makes the system increasingly personalized instead of treating every interview as an isolated conversation.

Prize Categories

Best Use of Render & GitHub

I am entering the Best Use of Render category.

InterviewBuddy uses Render for deploying the React frontend and FastAPI backend, with PostgreSQL for persistent application data. GitHub is used for source-code management, version control, and maintaining the project's development workflow. The GitHub repository is connected to Render for streamlined deployment whenever changes are pushed to the project.

My Agent Session

I used the InterviewBuddy application to conduct a complete interview session and verify the end-to-end flow from personalized question generation through answer evaluation and the final report.

Final Thoughts

I built InterviewBuddy around a problem that is personally meaningful to someone I know: preparing for software engineering interviews can become repetitive when every practice session starts from the same generic questions.

I wanted to build something that remembers the candidate, understands their projects, identifies their weaknesses, and changes the interview accordingly.

The result is a small but complete AI interview system that combines LLM inference, RAG, persistent memory, structured evaluation, adaptive questioning, and a production web application.