This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
I built Friend Interview Buddy, a private AI-powered interview preparation assistant for a friend who is preparing for software engineering interviews.
The problem was simple: generic AI interview tools can ask questions, but they don't necessarily understand your own projects, experience, resume, and weak areas.
So I built a local AI coach that can learn from the user's own preparation material.
What it can do
- 📄 Upload a resume or preparation material
- 🔎 Search the uploaded documents using semantic search
- 🤖 Ask questions about the user's own experience and projects
- 💬 Provide personalized interview coaching
- 🎤 Run a mock software engineering interview
- 🧠 Evaluate interview answers
- 📊 Provide feedback, improvement suggestions, and follow-up questions
- 🔒 Keep personal documents and AI processing on the user's machine
The goal wasn't to build another generic chatbot.
The goal was to build something my friend could actually use before an interview — with their own information as the source of truth.
🎥 Demo Screenshot
The demo shows:
- Starting the local AI application
- Uploading a resume
- Building the local knowledge base
- Asking questions about the resume
- Starting a mock interview
- Answering an interview question
- Receiving AI-generated feedback
- Running the application without relying on a cloud AI API
Code
GitHub Repository
The project is structured as:
friend-interview-buddy/
│
├── backend/
│ ├── app/
│ │ ├── main.py
│ │ ├── config.py
│ │ ├── models.py
│ │ │
│ │ └── services/
│ │ ├── document_service.py
│ │ ├── ollama_service.py
│ │ └── rag_service.py
│ │
│ ├── data/
│ ├── .env.example
│ └── requirements.txt
│
├── frontend/
│ ├── src/
│ │ ├── App.jsx
│ │ ├── api.js
│ │ ├── main.jsx
│ │ └── styles.css
│ │
│ ├── package.json
│ └── vite.config.js
│
├── .gitignore
└── README.md
How I Built It
The project is built around open-weight AI running locally.
The core stack is:
- Qwen3 — open-weight language model
- Ollama — local model runtime
- nomic-embed-text — local embedding model
- FastAPI — Python backend
- React + Vite — frontend
- RAG — retrieval from the user's own documents
The basic architecture looks like this:
User
│
▼
┌───────────────┐
│ React + Vite │
└───────┬───────┘
│
▼
┌───────────────┐
│ FastAPI │
└───────┬───────┘
│
┌───────┴────────┐
│ │
▼ ▼
Document/RAG Interview Logic
│ │
▼ │
nomic-embed-text │
│ │
└───────┬────────┘
▼
Qwen3 via
Ollama
│
▼
Personalized Response
1. Document ingestion
The user can upload files such as:
PDF
DOCX
TXT
Markdown
The backend extracts their text and divides it into smaller chunks.
Resume
↓
Text extraction
↓
Chunking
↓
Embeddings
↓
Local knowledge index
2. Semantic retrieval
When the user asks a question, the question is converted into an embedding using nomic-embed-text.
The system compares that embedding with the stored document embeddings and retrieves the most relevant chunks.
User Question
↓
Embedding
↓
Similarity Search
↓
Relevant Resume Sections
3. Qwen3 generation
The retrieved context is then passed to Qwen3 through Ollama.
Instead of simply asking:
"Answer this question."
the application effectively gives the model:
Relevant information from the user's documents
+
User's question
+
Interview-coach instructions
Qwen3 then generates the response.
4. Interview mode
The application also has a dedicated interview mode.
Instead of acting like a general chatbot, the model is instructed to behave like a software engineering interviewer.
It can:
- Ask one question at a time
- Base questions on the candidate's projects
- Increase difficulty
- Challenge vague answers
- Evaluate responses
- Suggest improvements
- Ask follow-up questions
This makes the open-weight model part of the actual application logic rather than simply being an optional chatbot feature.
Why Does Open Innovation Matter?
This is probably the most important part of the project for me.
Interview preparation involves personal information.
A resume can contain:
- Employment history
- Projects
- Education
- Contact information
- Personal achievements
- Technical experience
I didn't want the core experience to require sending all of that information to a third-party AI API.
That's why I chose local inference.
🔒 Privacy
The documents can remain on the user's computer.
The architecture is:
User's Computer
Resume
↓
Local RAG
↓
Local Embeddings
↓
Local Qwen3
↓
Response
There doesn't need to be a cloud AI provider in the middle.
🌐 Offline capability
After the required models have been downloaded, the core application can run locally without an internet connection.
That means the user can disconnect from the internet and still use the fundamental interview-coaching workflow.
🔧 Model freedom
The application isn't permanently tied to one proprietary API.
The model is configured through an environment variable:
OLLAMA_MODEL=qwen3:4b
That means I can experiment with different locally available models without redesigning the entire application.
💰 No per-request AI API cost
Because inference happens locally, there isn't a per-request charge from a hosted AI provider.
The trade-off is that the user's computer needs enough resources to run the selected model.
🧩 Control over the AI behavior
The prompts, retrieval process, interview logic, document processing, and model selection are all under my control.
That makes experimentation much easier.
I can change:
Interview difficulty
↓
Prompt
↓
RAG strategy
↓
Model
↓
Evaluation criteria
without depending on a proprietary API's behavior.
Open innovation made the project more personal
A closed API could certainly have helped me build an interview chatbot quickly.
But the open approach allowed me to make privacy and ownership part of the product itself.
The AI isn't something my application sends information to.
The AI is part of the application.
What I Learned
The biggest lesson was that building with an open model isn't simply about replacing one API call with another.
The interesting engineering work happens around the model:
Documents
↓
Chunking
↓
Embeddings
↓
Retrieval
↓
Prompt construction
↓
Model inference
↓
Evaluation
↓
User experience
The model is one component of the system.
The real product comes from everything around it.
I also learned how powerful a relatively small local model can become when it receives the right context instead of being asked to answer everything from its general knowledge.
What I'd Build Next
This is currently an MVP, but there are several directions I'd like to take it:
- 🎙️ Voice-based mock interviews
- 📈 Interview performance tracking
- 🧠 Long-term local conversation memory
- 🎯 Job-description vs. resume gap analysis
- 🥊 "Devil's Advocate" interview mode
- 📚 Personalized daily interview preparation
- 🧪 Better RAG with a dedicated vector database
- 🐳 Dockerized one-command setup
- 📦 Support for additional local models
The long-term idea is to turn it into a personal, private interview preparation environment rather than just another AI chat interface.
Final Thoughts
I started with a simple question:
"Can I build something useful for someone I know, instead of building another generic AI demo?"
That led me to Friend Interview Buddy.
The project is small, but the idea behind it is important to me: AI becomes much more useful when it can work with someone's personal context without requiring that context to leave their control.
That's what open AI made possible for this project.
Top comments (0)