This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
A close friend of mine had just finished another tech interview and sat there trying to explain to me how it went. She remembered the questions, she remembered her answers, but she couldnt figure out which part actually went wrong. No feedback, no reply, just silence. She was giving interview after interview and getting more demoralized every time.
Getting rejected in tech interviews sucks but getting ghosted and never knowing why is worse.
So I built Duster for her. It is an interview post-mortem app designed for one person to dump an interview the exact way she remembers it. The app automatically tags her weak spots like rambling or missing metrics, counts which mistakes keep showing up across multiple interviews, and generates targeted practice drills to help her fix them.
It has three parts:
- Debrief: saves the company, role, outcome, and her raw Q-and-A text dump, then tags each answer
- Patterns: totals those tags across interviews with trend arrows and streak counters
- Drill: asks five practice questions, scores her responses, and rewrites a stronger version of what she actually said
Demo

Live url : https://duster-tkgi.onrender.com/
Video demo : https://youtu.be/IFJ16sfahB8
Code
Github Repo :
AarishMansur
/
Duster
Duster is a post-interview coach for one person. She leaves an interview, gets rejected or ghosted, and never hears why. so now she knows
Duster
An interview post-mortem coach for one person.
She does the interview, gets rejected or ghosted, and never learns why. Rejections never come with feedback. Duster turns the interview the way she remembers it β a messy Q: / A: dump, or a voice note β into the weakness that keeps showing up, then gives her a drill aimed at that weakness.
Open-source models only. Nothing in this repo calls OpenAI or Anthropic. Every model call goes through Ollama on her machine, Backboard's open-weight models, or a Tinker fine-tune. With no keys set, the heuristic analyzer still tags answers.
What it does
-
Debrief. Company, role, outcome, and a dump of what they asked and what she said. Optional
.m4a/.mp3voice note, transcribed locally with faster-whisper and deleted. The audio never leaves the machine. -
Patterns. Weakness tags counted across interviews (
no_metrics β 7x in 4 sessions), withβ¦
How I Built It
Duster is built around open weight models with flexible inference backends chosen by an ANALYZER setting in .env:
Debrief (POST /debrief) ββ> Split Q/A ββ> analyze() ββ> SQLite (weakness_tag)
β
Patterns (GET /patterns) <ββ Count tags & Read Backboard βββββ€
βΌ
Drill (POST /drill/start) ββ> 5 Questions ββ> Score & Rewrite ββ> Backboard Thread
Local Inference with Ollama: By setting ANALYZER=ollama, it runs qwen2.5:7b completely locally on her laptop. Every model response is strictly parsed into JSON and checked with Pydantic. If an LLM returns bad JSON or hits a network error, it cleanly falls back to a rules based heuristic tagger so the app never crashes.
Local Audio Transcription: If she records a voice memo right after an interview, she can upload .m4a or .mp3 files. The server transcribes them locally using faster-whisper, drops the text directly into the debrief textarea, and deletes the audio file immediately.
Backboard Dual Integration: Backboard does two separate jobs using open weight models via OpenRouter provider. First, when ANALYZER=backboard, BackboardAnalyzer tags answers with memory=off and json_output=true without writing to a thread. Second, on every scored drill (even when using the heuristic tagger), it appends the question, score, and top tags onto a single persistent Backboard assistant thread with memory=Auto. The Patterns page reads that thread back so her practice history persists across sessions.
Fine Tuning with Tinker: I used Tinker to LoRA fine-tune Qwen3-8B on her labeled interview answers (data/train.jsonl). I used Qwen3-8B here because Tinker does not serve Qwen2.5-7B, the model I run locally with Ollama. When ANALYZER=tinker, the app samples that saved checkpoint. On a held out test set of [N] answers, the fine tuned model achieved 0.50 precision compared to 0.35 for the baseline heuristic rules, with [X] recall vs [Y] for the baseline. The dataset is small ([N] labeled answers) so treat these numbers as a promising start, not a benchmark.
Why Does Open Innovation Matter?
Open innovation was super important here for three big reasons:
Data Privacy You Can Actually Control: Post-interview debriefs contain sensitive details about private company questions, salary talk, and personal mistakes. In local mode (Ollama + local Whisper), her raw debrief text and audio never leave her laptop and are never sent to closed API providers for training. If she opts into Backboard, only the question, score, and top tags are stored on the remote thread, never the full raw debrief. Because the models are open weight, she gets to choose where that line sits.
Targeted Domain Fine Tuning: Generic closed APIs often miss subtle conversational flaws in behavioral answers. Fine tuning open weights (Qwen3-8B) via Tinker allowed us to directly boost precision on her specific weakness categories like rambling, no_metrics, weak_closing, and no_structure.
No Vendor Lock in & Free to Run Locally: The default analyzer is a heuristic engine, meaning the app works out of the box with zero API keys. When running locally with Ollama, she gets unlimited practice drills and post mortems for $0 in subscriptions or tokens. Backboard and Tinker are optional upgrades, not requirements.
Prize Categories
Main Challenge: Build for a Friend
Best Use of Backboard
Best Use of Tinker
Top comments (0)