PalForge: An Open-Weight AI Interviewer I Built for a Friend

What I Built

One of my friend is preparing for software engineering placements, and while helping him I noticed one common problem.

There are already lot of interview questions available online. DSA questions, aptitude, DBMS, OS, web development, everything is there.

But most of them are very generic.

They don't know what projects are actually written on your resume, what technologies you used, or what kind of role you're applying for.

So I thought, instead of giving another list of 100 interview questions, why not make something which actually interviews you based on your own resume?

That's how PalForge started.

PalForge takes your resume, target role and job description, and creates a personalized technical interview using Gemma.

For example, instead of asking:

What is MongoDB?

it can ask:

You used MongoDB in your project. Why did you choose it instead of PostgreSQL?

And if the answer is not complete, it can ask another question based on that answer.

That was the main thing I wanted from this project.

Not just questions.

Actual follow-up.

Demo

Live Web app:

https://palforge.onrender.com/

palforge.onrender.com

GitHub:

https://github.com/dev-yashpawar/PalForge

dev-yashpawar / PalForge

PalForge

Open-source AI interview practice, forged for a friend.

One friend. One target role. One interview built around what they actually know.

PalForge turns a candidate’s resume and target job into a technical interview, with answer evaluation, bounded adaptive follow-ups, a weakness profile, and a next practice session. Its paper, forest, and coral interface takes its cues from developer festivals and printed posters.

The problem

A friend preparing for software engineering placements needed to explain the projects and decisions on his own resume. Generic question banks covered plenty of material, but missed the context: what he built, why he chose his stack, and what the next company expected.

What I built

• A resume-grounded interview with 5, 7, or 10 questions.
• Warm-up, Standard, and Pressure styles.
• Technical answer evaluation with strengths, missing points, and specific feedback.
• Up to two deeper follow-ups per main question in Pressure Mode.
• Results calculated from actual…

View on GitHub

How It Works

The basic flow is:

Resume
+
Target Role
+
Job Description
↓
Gemma
↓
Personalized Questions
↓
Candidate Answers
↓
Technical Evaluation
↓
Follow-up Questions
↓
Weak Areas
↓
Next Practice Session

PalForge currently has 3 interview modes:

• Warm-up
• Standard
• Pressure Mode

Warm-up is more simple and direct.

Standard is closer to a normal technical interview.

Pressure Mode is where I tried to make it little more interesting.

If the candidate gives an incomplete answer, PalForge can ask deeper questions instead of just moving to the next one.

For example, if someone says:

MongoDB is better because it is faster.

PalForge can ask:

Under what workload would that statement stop being true?

This is actually the part I liked most while building it, because real interviews are also like this. Interviewers normally don't just ask one question and move on. They keep asking "why?", "what if?", "why not this?"

At the end, PalForge calculates topic-wise performance, finds weak areas and gives suggestions for what to practice next.

The next interview can also focus more on those weak topics.

Tech Stack

I used:

• React
• Vite
• Node.js
• Express.js
• MongoDB Atlas
• Mongoose
• Zod
• Gemma
• Google AI Studio
• Ollama
• Render
• GitHub

Gemma is used for the main AI part:

• generating interview questions
• evaluating answers
• generating follow-up questions
• finding weak topics
• giving final practice suggestions

MongoDB Atlas stores the interview sessions and results.

Render is used for hosting the application.

What Testing Taught Me

This project looked simple in beginning.

Input resume → send to AI → generate questions.

But while building it, I realised the difficult part is not calling the model. The difficult part is handling everything around the model.

Local AI worked... until I deployed it

Initially I was running Gemma locally using Ollama.

Everything was working fine on my laptop.

Then I deployed the project on Render and suddenly the AI stopped working.

The reason was this:

http://127.0.0.1:11434

On my laptop, this was pointing to Ollama.

But on Render, 127.0.0.1 means the Render server itself, not my laptop.

So obviously Render could not access the Ollama running on my machine.

After that I changed the setup.

Now PalForge can use:

• Ollama locally
• Google hosted Gemma for the public version

This way I can still use local inference while development, but anyone can test the public app without installing anything.

AI output is not always clean

Another problem was JSON output.

I wanted the AI to return proper structured data for questions and evaluation, but model output is not always perfect.

Sometimes formatting can break.

So I added validation using Zod and handling for malformed responses.

This taught me one simple thing:

AI should not control the full application.

The AI gives the intelligence, but the app should still control the flow.

Follow-up questions also need limits

At first, follow-up questioning sounded like a great idea.

But if you don't control it, the model can keep asking questions again and again.

So I added a limit to how many follow-up questions can happen for one main question.

Small thing, but important.

Why Open Innovation Matters

I wanted to use an open-weight model for this project because I didn't want the whole application to depend on only one closed API.

With Gemma, I can run the same idea locally using Ollama.

That is useful for a project like this because resumes and interview answers can contain personal information.

If someone wants, they can run everything locally and keep the data on their own system.

Also, using open-weight models gives much more flexibility.

I can change the model.

I can try a smaller model.

I can try a bigger model.

I can run it locally.

I can use hosted inference.

I can change how the interviewer behaves.

I'm not completely stuck with one provider.

For the public demo I'm using hosted Gemma because its easier for judges to test.

For local use, Ollama is still supported.

There is definitely a trade-off.

Local inference gives better privacy and control, but hosted inference is much easier to make publicly available.

For this project I wanted both options.

Keeping It Small

Initially I was thinking to make this much bigger.

Maybe job listings, authentication, recruiter dashboard, resume builder, application tracking and other things.

But then it would basically become another job portal.

And that was not the actual problem I wanted to solve.

So I kept the idea simple:

Help one friend practice explaining the things already written on their resume.

That's it.

The whole flow is basically:

Resume
→ Interview
→ Answer
→ Follow-up
→ Feedback
→ Improve

And for this challenge, I think that was enough.

What I Want to Add Next

There are still many things I want to try later:

• voice based interviews
• PDF resume upload
• better progress tracking
• better role-specific evaluation
• comparison between previous interviews
• running better models on lower-end laptops
• more detailed weak-topic analytics

But I didn't want to keep adding features just for the sake of adding features.

The main goal was to make one complete interview flow actually work.

Prize Categories

I'm submitting PalForge for:

Best Use of Gemma

Gemma is used for question generation, answer evaluation, follow-ups and final analysis.

Best Use of Render

The live PalForge application and backend are hosted on Render.

Best Use of MongoDB Atlas

MongoDB Atlas stores interview sessions, answers and results.

And of course, the overall Hacktoberfest Weekend Challenge: Build for a Friend.

PalForge basically started from one question:

What if interview preparation actually knew what you built?

This project is my small attempt to answer that.