# I Built My Friend an AI Interviewer That Remembers Where He Struggles > Source: > Published: 2026-10-04 22:32:06+00:00 *This is a submission for the [Hacktoberfest Weekend Challenge: Build for a Friend](https://dev.to/challenges/hacktoberfest-weekend-2026-10-01).* Most interview preparation platforms remember your score. **InterviewMirror remembers something more important:** I built InterviewMirror for my friend **Tharun**, who was preparing for technical interviews. He was already studying, solving coding problems, and practicing interview questions. But we noticed a recurring problem: answering the first question wasn't always the difficult part. The difficult part was what came next. **"Why?"** **"How does it work internally?"** **"What happens if we change this?"** **"Can you explain it another way?"** Those follow-up questions often exposed gaps that a simple question bank couldn't identify. There was another problem. If Tharun struggled with a particular concept during one practice session, the next session didn't necessarily know about it. So I asked: **What if an interviewer could remember where you struggled and use that information to make your next interview better?** That became **InterviewMirror**. InterviewMirror is an **adaptive AI technical interviewer** that analyzes a candidate's answers, identifies weaknesses, remembers them, and uses that memory to influence future interviews. The core idea is simple: **Your previous interview changes your next interview.** A traditional interview practice loop looks like: text Question ↓ Answer ↓ Next Question InterviewMirror turns it into: Question ↓ Answer ↓ Analyze ↓ Remember ↓ Adapt ↓ Improve A Simple Example Suppose Tharun is asked: Explain how HashMap works internally in Java. His answer is partially correct, but he struggles when the interviewer asks about collision handling. InterviewMirror identifies: Weakness detected: HashMap collision handling That weakness becomes part of his interview memory. During a future interview, InterviewMirror doesn't simply ask the same question again. It can approach the same underlying concept from a different scenario: You're designing a cache where many keys may map to the same bucket. How could that affect performance, and how would Java handle heavy collisions? Same concept. Different challenge. That is the behavior I wanted to build. I didn't want to give Tharun another question bank. I wanted to give him an interviewer that remembers. Demo Live Demo: [https://interviewmirror-xlks.onrender.com/](https://interviewmirror-xlks.onrender.com/) GitHub: [https://github.com/Harini-7228/interviewmirror](https://github.com/Harini-7228/interviewmirror) The most important part of InterviewMirror isn't the first question. It's what happens after the interview. The Adaptive Interview Loop The core loop looks like this: INTERVIEW #1 ↓ Weakness detected ↓ MongoDB Atlas ↓ Weakness remembered ↓ INTERVIEW #2 ↓ Different question ↓ Same underlying concept tested The objective isn't to make candidates memorize previous questions. It is to help them improve the concepts they repeatedly struggle with. Code The complete source code is available on GitHub: [https://github.com/Harini-7228/interviewmirror](https://github.com/Harini-7228/interviewmirror) The project is structured around several core components: Gemma: The Intelligence Layer Gemma is the core AI layer of InterviewMirror. It is used for: This makes Gemma part of the core product behavior, rather than an optional AI feature. MongoDB Atlas: The Memory Layer MongoDB Atlas provides the persistent memory behind InterviewMirror. The application stores relevant information such as: ElevenLabs: Giving the Interviewer a Voice Interviews are conversations, not just text fields. InterviewMirror integrates ElevenLabs to provide spoken interviewer questions. The interaction becomes: Gemma ↓ Interview Question ↓ ElevenLabs ↓ Spoken Interviewer ↓ Candidate This makes the experience feel closer to an actual interview. Render: Making It Real InterviewMirror is deployed on Render and is publicly accessible. Live application: [https://interviewmirror-xlks.onrender.com/](https://interviewmirror-xlks.onrender.com/) Instead of keeping the project as a local prototype, I wanted people to be able to actually interact with the system. Why Does Open Innovation Matter? The interesting part of InterviewMirror isn't simply that it uses AI. It's how AI is used. I could have built a basic interface that sends a prompt to an AI model and displays the response. That would have produced another AI wrapper. Instead, InterviewMirror uses Gemma as part of an adaptive learning loop: Generate ↓ Evaluate ↓ Detect ↓ Remember ↓ Adapt ↓ Generate Again The model's output influences what the candidate experiences next. That makes the AI a core component of the application rather than a decorative feature. Using an open-weight model also creates room for experimentation around the model layer without making the entire application dependent on one proprietary AI provider. The interview engine, memory system, scoring system, and user experience can evolve independently. For me, that's what open innovation means in this project: Not simply using an open model. But using it to build something that can continue to evolve around the model. **Prize Categories** InterviewMirror uses the following technologies as meaningful parts of the final implementation. **Gemma** Gemma powers the core AI interview experience, including question generation, answer evaluation, weakness detection, contextual follow-ups, and interview analysis. **MongoDB Atlas** MongoDB Atlas provides persistent interview memory and stores information that can influence future interviews. **ElevenLabs** ElevenLabs provides the voice layer for the AI interviewer. **Render** Render hosts the publicly accessible application. Each technology has a specific role in the product rather than simply being included as a technology showcase. What I Learned: Building InterviewMirror changed the way I think about AI applications. Initially, the idea sounded simple: "Build an AI interviewer." But there are already many tools that can ask interview questions. The more interesting question became: What should the interviewer remember? A question is temporary. A score is only a snapshot. But a recurring weakness is valuable information. That changed the architecture of the entire project. Gemma analyzes the candidate's response. MongoDB Atlas preserves meaningful interview history. The next interview uses that history. The candidate receives feedback and another opportunity to improve. This created a much more meaningful AI loop: Past Performance ↓ Understand Weakness ↓ Remember ↓ Adapt Future Interview ↓ Practice Again ↓ Improve Building for a Friend Changed My Approach Instead of starting with a technology and asking: "What can I build with this?" I started with a person and asked: "What problem does my friend actually have?" That led to a much more focused product. I wasn't trying to build another AI interview platform. I was trying to solve one specific problem: How can I help my friend practice the things he repeatedly struggles with? That's what InterviewMirror became. **What's Next** InterviewMirror is still evolving. The next areas I want to explore include: **Final Thought** When I started InterviewMirror, I thought I was building an AI interviewer for my friend. But the project made me realize something: The most useful interviewer isn't necessarily the one that asks the hardest questions. It's the one that notices: "You struggled here last time." And then says: "Let's try again — but differently." That's InterviewMirror. **Your previous interview changes your next interview.** Please, Like, Share, Comment down your thoughts on this post!!