How to Explain Your Project in an Interview

“Tell me about a project you worked on” sounds like the easy question. You know the project better than anyone in the room. But it’s easy to spend five minutes describing the company and the background, then run out of time before you reach the part you built.

Some companies give this a whole round and call it a project deep dive. Either way, decide which project you’ll use before the interview, and prepare a second one in case they ask for another.

Which project to pick

Pick one where you made design decisions you can explain, because “Why did you do it that way?” is coming. It should be recent enough that you remember the details. Choose a project with a hard part you can discuss and a result you can state, ideally with a number.

If two projects qualify, use the one closest to the job you’re applying for.

Two minutes, then let them steer

Give a short overview and let the interviewer choose where to go deeper. Cover these in order:

  1. What it was and who used it, in one sentence.
  2. The problem it solved.
  3. The team size and the part you owned.
  4. One or two design decisions, each with the alternative you turned down and why.
  5. The hardest part and how you handled it.
  6. The result.

Then stop talking. They’ll ask about whatever caught their interest, and that’s where the rest of the time goes.

An example

“I built the notification service at my last company. It sends the email and push notifications for our scheduling app, which has about 200,000 users.

Before this, every team sent notifications from its own code. Users got duplicates, and there was no single place to switch one off.

There were three of us. I designed the service and wrote the delivery pipeline, and the other two moved the existing notifications over.

I chose a queue with separate workers for each channel over sending directly from the API request. That way a slow email provider couldn’t slow the app down, and we could retry failures. I also chose to store every notification before sending it, so we could check for duplicates and show users their history.

The hardest part was duplicates on retry. If a worker crashed after sending but before recording it, the retry sent the notification again. I fixed that by giving each notification a unique key and checking the key before every send.

After the migration, duplicates dropped to almost nothing, and support tickets about notifications fell by around 60 percent.”

The interviewer can follow up on the queue, the retry bug or the migration without needing the whole architecture explained first.

Be exact about where your part ended. If every sentence says “we,” the interviewer has to ask what you did. “I designed the pipeline and a teammate built the admin page” gives each person credit for their work.

Prepare for follow-up questions

Go through your project beforehand and answer these on paper:

Look up your numbers before the interview: request rate, data size, team size, timeline. If a number is an estimate, say so.

If someone else made a decision, say so, and explain the reasoning as you understood it. You’re expected to understand the parts of the system you didn’t write too.

Confidential work

If the project is under an NDA, describe the kind of system and drop the names. “A service that matches incoming orders against inventory for a large retailer” is enough. The technical decisions are what the interviewer wants, and you can usually talk about those.

Student projects

If you’re a student or a new graduate, use the same structure for a capstone, an internship task or a side project. Explain the problem, the decisions you made, and what was hard. A side project with a handful of real users can give you plenty to discuss.