How to Explain Your Projects in English in an Interview

"Can you walk me through a project you're proud of?" This question shows up in almost every interview for technical, design, data, and freelance roles. It's where your real skills should shine. But the opposite often happens: candidates who know their projects inside out struggle to explain them in English.

Usually the problem isn't vocabulary. It's order. The candidate starts with technical details, jumps to the problem, goes back to the tools, and forgets to mention the result. The interviewer gets lost, even though the project is good.

The most common mistake: starting with the tech stack

Compare these two openings:

Weaker:

"I used React, Node.js, PostgreSQL, Redis, Docker, and AWS…"

Stronger:

"A small clinic was losing patients because booking was by phone only."

The first opening leaves the interviewer guessing what all that technology was for. The second gives context immediately: there was a real problem, and this project solved it. The tools still matter, but they belong later, in the solution.

A five-part frame

Part	Question	Example sentence
1. Problem	What was wrong or needed?	The client needed… / Users couldn't…
2. Role	What were you responsible for?	I was the only backend developer.
3. Solution	What did you build, and how?	I built… using…
4. Result	What changed?	Now the clinic gets bookings online.
5. Lesson	What did you learn?	I learned to…

This is close to the STAR method, but it fits projects better because it has room for the technical solution. If you already use STAR, the two work well together. See the STAR method for English interviews.

Example: a 30-second and a two-minute version

Prepare two versions of every project. The short one answers general questions or fits when time is tight. The long one is for when the interviewer says "Tell me more" or "Walk me through it."

30-second version

I built an online booking system for a small clinic. Before that, patients could only book by phone. I designed the database and built the backend. Now most patients book online. The staff spend less time on the phone.

Two-minute version

(Problem) A small clinic was taking all bookings by phone. The staff were busy, and patients often couldn't get through.

(Role) I worked with one frontend developer. I owned the backend and the database.

(Solution) I built a REST API with Node.js and PostgreSQL. The tricky part was double bookings. Two patients could pick the same slot at the same time. I solved it with a database lock on each time slot. I also added WhatsApp reminders one day before each visit.

(Result) After launch, most bookings moved online. The clinic told us missed appointments went down.

(Lesson) I learned to test edge cases early, like two people booking at once.

Notice "the tricky part." Interviewers love hearing about a specific technical challenge, because it shows you really did the work rather than just being on the team.

"I" vs. "we": be honest about your role

Almost every project is a team effort. That's normal. But the interviewer needs to know which parts you did.

Less clear	Clearer
We built the payment system.	I built the payment API. My teammate built the checkout page.
We improved performance.	I found the slow queries and added indexes.
We used microservices.	The team used microservices. I owned the notification service.

Don't claim other people's work as yours. Follow-up questions expose it fast. It's better to describe your actual role, even if it was small, and explain it in detail.

Explaining technical terms simply

Sometimes your interviewer isn't technical: a recruiter, a product manager, or a client. For them, translate technical terms into everyday impact.

• Instead of "I implemented caching with Redis," try: "I made the page load faster by saving common results."
• Instead of "I set up CI/CD," try: "I set up automatic tests and releases. Now we can ship safely every day."
• Instead of "I normalized the database," try: "I reorganized the data, so the reports became accurate."

If the interviewer is technical, go ahead and use the terms. If you're not sure, start simple and then ask:

Would you like more technical detail?

Follow-up questions to prepare for

After you explain a project, these questions are very likely:

Why did you choose that technology?

What was the hardest part?

What would you do differently now?

How did you test it?

How many users did it have?

Short sample answers:

We chose PostgreSQL because the data had many relations. And the team already knew it well.

If I did it again, I'd add monitoring from day one. We found some bugs too late.

If you're asked for a number you don't know exactly, don't guess:

I don't know the exact number. It was a few hundred users a day, I think. I can check if that's helpful.

When your project didn't use the technology they want

The job may ask for experience you don't have yet. Don't slip that technology into your project story. Use the honest pattern instead:

I haven't used AWS in a project yet. But I deployed this project on Google Cloud. The concepts are similar, like virtual machines and storage. I'm learning AWS now with a small test project.

This answer is honest, shows related experience, and gives a learning plan. That's much stronger than a claim that collapses at the next question.

Template and checklist

Project:   [short name]
Problem:   [the real problem, 1 sentence]
My role:   [your role, 1 sentence]
Solution:  [what you built + 1 technical challenge + how you solved it]
Result:    [what changed; numbers only if you're sure]
Lesson:    [1 lesson]
Short version (30s): ...

• I have two or three projects with this template filled in.
• Each project starts with the problem, not the tech stack.
• My role is described with "I" and separated from the team's.
• There's one technical challenge I can explain in depth.
• There's a plain-language version for non-technical interviewers.
• Every number I mention is accurate.

Summary

Explaining projects in English gets much easier when the order stays fixed: problem, role, solution, result, lesson. Prepare a 30-second and a two-minute version, separate your role from the team's, and get ready for follow-up questions. Your best project can also be the "proof" in your answers to tell me about yourself and why should we hire you.

Repartee can read your projects from your CV, LinkedIn PDF, GitHub, and the stories you type yourself. When you're asked about a project, the answer script is built only from that material, and its claims are checked before it's marked as verified.