How to Explain Your Project in an Interview (With a Real Walkthrough)

Explain a project in four parts — the problem, your approach, your part and what’s next — in about two minutes. Then stop, and let the interviewer choose where to go deeper. Everything else in an interview about a project is follow-up questions, and you can prepare for most of them.

What the interviewer is listening for

When an interviewer says “tell me about a project”, they are rarely checking the feature list. They want to know:

Whether you understood the problem, not just the task you were given.
What you decided, and why — the choices, and what you gave up.
What you did yourself, especially in a team.
Whether you are honest about limits: what doesn’t work yet, what you would change.
Whether you can explain technical work clearly to someone who hasn’t seen it.

The four parts

This is the structure of every case study on this site. It works for a college project as well as for production software.

Part	What to say	Rough time
1. The problem	Who had the problem, and why it mattered	20–30 seconds
2. The approach	The shape of the solution and the one or two decisions that mattered most	30–40 seconds
3. Your part	Exactly what you built or decided, in “I” sentences	40–50 seconds
4. What’s next	The current status, a limitation, and what you would do with more time	15–20 seconds

The times are a starting point, not a rule. The point is that the problem and your part get most of the time, and the technology list gets almost none — it comes out naturally in parts 2 and 3.

A worked example: BioGraph

Here is how I would explain BioGraph, environmental audit software I work on, in about two minutes. It uses only what the public case study says, which is also a good rule for employer projects.

The problem. In India, industries that operate with pollution-control consent file an annual environmental statement, called Form V, with their State Pollution Control Board. Preparing it by hand meant re-entering the same water, air, waste and energy figures across sections and then formatting them into documents. Reviews were slow, and the documents came out differently from one submission to the next.

The approach. BioGraph turns that into one workflow: a company is configured by its pollution category, audit data is entered once, section by section, and the system generates the submission documents from it. The decision that shaped everything was to make the exports deterministic first — every document is generated from a template and validated data, so the same data always produces the same document.

My part. I worked mostly on the backend. I built the company configuration by pollution category — Red, Orange, Green and White — and the data models for the audit sections. I built authentication, authorization and audit logs, because a compliance record has to show who changed what. And I built the export system that produces PDF, Word, Excel and CSV documents from templates, plus Redis caching and indexed, paginated queries for the larger datasets.

What’s next. It’s in production. The next step is pre-filling audit sections from plant data, which only makes sense now that the exports are predictable.

Notice what the example doesn’t do: it doesn’t open with “I used React, Express, PostgreSQL and Redis”. The stack comes up once, where it explains a decision.

Prepare for the follow-up questions

Most follow-up questions are predictable. Prepare a two- or three-sentence answer to each:

“Why did you choose X?” — the database, the framework, the architecture. Have one real reason, and one alternative you considered.
“What was the hardest part?” — a specific problem, how you found it and how you fixed it.
“How do you know it works?” — your tests, and how you checked the output. (BioGraph has unit, integration and end-to-end tests.)
“What would you change?” — an honest answer is stronger than “nothing”.
“What happens at ten times the data or users?” — where it would break first, and what you would do.
“Walk me through the architecture.” — see the next section.

Draw the architecture in thirty seconds

You may be asked to sketch the system. Practise drawing it with no more than five boxes: the client, the API, the database, anything else that stores or moves data (a cache or a queue), and the outside world (devices, users, other systems). Then trace one request through it out loud.

A five-box sketch: a React web client sends requests to an Express API, which handles authentication, authorization, audit logs and rate limits. The API uses PostgreSQL for companies and audit data, Redis for cached reads and rate limiting, and an export service that produces PDF, DOCX, Excel and CSV files. — BioGraph in five boxes. Trace one request out loud: a user saves an audit section, the API checks their permissions, writes to PostgreSQL and records an audit log entry.

If it was a team project

Say “we” for what the team did and “I” for what you did, and be precise about the difference. “We built a placement portal; I designed the database schema and wrote the authentication API” is far stronger than “we built everything together”. Presenting your work covers what to include for each project.

If the code is private

Employer code usually is. You can still explain the problem, the architecture and your decisions without sharing anything confidential. Say clearly that the code is private and offer a walkthrough instead — that is what the case studies on this site do. Don’t describe customers, data or internal details you haven’t been allowed to share.

Mistakes to avoid

Starting with the technology list. Start with the problem.
Saying “we” for everything. The interviewer is hiring you, not the team.
Claiming more than you did. Follow-up questions find it quickly.
No numbers at all. If you have them — rows, users, response times, time saved — use one or two. If you don’t, don’t invent them.
Talking for five minutes. Stop after two, and let them ask.

A template to fill in

The problem:   ______ had a problem: ______. It mattered because ______.
The approach:  I/we built ______. The key decision was ______, because ______.
My part:       I built ______. I decided ______. I fixed ______.
What's next:   It is ______ (status). A limitation is ______. Next I would ______.

Checklist

Write the four parts for each project on your résumé.
Say each one out loud and time it: about two minutes.
Prepare answers to the six follow-up questions.
Practise drawing the architecture in five boxes.
Use “I” for your work, and be honest about limits.

For the step before the interview, see how to prepare for your first software engineering internship; for working through a problem live, see how to approach an unfamiliar coding problem.