How to explain your project in an interview: one project at 30 seconds, 2 minutes and 5 minutes

Key takeaways

• One structure for every project: problem, role, architecture, decision, result, change.
• Prepare 30-second, 2-minute and 5-minute versions of the same project.
• Spend the most time on the hardest decision; that is where interviewers dig.
• Draw the architecture in under two minutes, with 5–8 boxes.
• Under an NDA, describe the industry and the system, never the client.

What does the interviewer want when you explain your project?

The interviewer is checking whether you built something real, which part was yours, whether you know why it was built that way, and whether you can explain it clearly. For freshers, the project stands in for work experience; for experienced engineers, many technical rounds open with it.

Whatever you mention, they will ask about, so mention only what you can defend.

How to explain your project: the six-part structure

The same six parts work for a college project, an internship or a production system. Only the depth changes.

1. The problem. Who had it and why it mattered. “Students kept missing college buses” beats “I built a bus tracker”.
2. Your role. Team size and exactly what you owned.
3. The architecture. The main components and how a request flows through them. The stack goes here, not first.
4. The hardest decision and its trade-off. A real alternative, why you chose yours, and what it cost. This is the heart of the answer.
5. The result, with a number. If nobody used it, give a test result.
6. What you'd change. One concrete improvement.

Can you use the STAR method for project explanation?

Yes, with one change. STAR (situation, task, action, result) fits questions about a moment in the project, such as “a challenge you faced”. For “explain your project”, plain STAR skips the architecture, which technical interviewers most want. Map it like this:

For challenge-style questions, write full STAR stories; our behavioural interview story bank has a template and eight worked examples.

One project at three lengths: 30 seconds, 2 minutes, 5 minutes

The same project gets one sentence in “tell me about yourself”, 30 seconds in an HR round, and five minutes with a whiteboard in a technical round. Prepare all three so you never cut it down on the spot.

The 30-second version

My final-year project was CampusRide, a live tracker for our college's 12 buses, because students kept missing buses whose timings changed with traffic. In a team of four, I built the backend: a Spring Boot service that takes GPS updates from the drivers' phones and pushes bus positions to students in real time. About 900 students signed up in our pilot semester. I'm happy to walk you through how it works.

The last sentence hands the interviewer a topic you're ready for.

The 2-minute version

Our college runs 12 buses, and students used to wait at stops for up to 20 minutes, or miss the bus, because timings changed with traffic. CampusRide shows each bus live on a map, with an arrival estimate for your stop.

We were a team of four. Two teammates built the drivers' Android app and the students' web app, one handled testing, and I built the backend and the real-time layer.

The driver app sends a GPS location every five seconds to my Spring Boot API. I keep only the latest position of each bus in Redis, with a short expiry, so a bus that goes offline disappears instead of showing a stale location. Routes, stops and accounts live in Postgres. Each student's browser holds a WebSocket connection, and the server pushes every new position as it arrives.

The hardest decision was WebSockets versus polling. Polling every ten seconds was easier, but positions would lag by up to ten seconds, and a few hundred students opening the app at 8 a.m. would mean a flood of repeated requests. WebSockets made updates instant and cut traffic. The trade-off is that each connection is tied to one server, which makes adding servers harder. For one college on one server, that was the right call.

About 900 students signed up in the pilot semester, and at peak we had around 600 open connections on a single 2 GB server. If I rebuilt it, I'd buffer locations on the driver's phone, because we lost updates whenever a bus passed through an area with no network.

The 5-minute version

This is the 2-minute version with the diagram drawn and three things added:

1. Problem and role (30 seconds).
2. Draw the architecture (60–90 seconds), talking as you draw. The diagram is further down.
3. Trace one request (60 seconds): the API checks the bus ID, writes the position to Redis with a 30-second expiry, and pushes it to every student watching that route.
4. A second trade-off (60–90 seconds): Redis versus Postgres for positions. Postgres could easily take 2.4 writes a second (12 buses, every five seconds), but the app only needed the latest point.
5. One bug (30–45 seconds): arrival estimates jumped because GPS drifts while a bus is parked; ignoring moves under 15 metres fixed it.
6. Result and what you'd change (30 seconds).

Pause between parts, and follow the interviewer if they cut in.

How to explain your final year project in an interview

Freshers get the longest project questions, because the project is their best evidence. For college work:

• Pick the project closest to the job. For a backend role, the API project beats a prize-winning ML one.
• For ML projects, the architecture is your pipeline: data source and size, preprocessing, a baseline, your model, and the metric you chose and why.
• If nobody used it, say so and give a test result instead. Inflated numbers fall apart under follow-up questions.
• Know your report and README. Interviewers sometimes have them open while you talk.

Your project also belongs in your self-introduction; see how to answer “tell me about yourself”.

Examples: an internship, a client project under NDA, and a backend system

These three are illustrative and a little under two minutes each.

An internship project

At my internship, a 40-person edtech startup in Bengaluru, the sales team onboarded each new school by typing student records in by hand: about two days per school.

I owned a bulk-upload feature, with a senior engineer reviewing my code. The admin uploads a CSV straight to S3, a background worker picks up the job from a Redis queue, validates each row, writes valid rows to Postgres, and saves a report of rejected rows to fix and re-upload.

The main decision was processing the file inside the upload request or in a queue. Large schools upload 50,000 rows, and the request would time out, so I used the queue. The cost was making the worker safe to retry: I hashed each row and skipped rows already imported.

Onboarding went from about two days to under an hour. What I'd change: I loaded whole files into memory, which failed on an 80,000-row file. I switched to reading row by row, and I'd start that way next time.

A client project at a service company, under NDA

Check what your NDA allows, or ask your manager what you can say. You can usually still describe the industry, the problem and the system's shape; leave out anything that identifies the client. Saying “I can't share the client's name” sounds professional.

I work on a claims platform for an insurer in Europe; I can't share the client's name. Their agents saw a claim's new status only the next morning, because updates moved in a nightly batch.

We were three developers on the integration module, and I owned the consumer service that reads claim events from Kafka and updates the agents' view. Events that fail go to a retry topic, then a dead-letter queue the support team can replay.

The hardest decision was avoiding duplicate updates, because Kafka can deliver a message more than once. Exactly-once processing across the client's systems was complicated, so I made the consumer idempotent: it records each event's ID in the same transaction as the update. That costs one extra write per event, which was fine at tens of thousands of claims a day.

Agents now see changes in under two minutes, and fewer than 0.1% of events reach the dead-letter queue. What I'd change: an upstream schema change broke us in testing, so I'd add contract tests with that team from the start.

A backend system, 3–5 years of experience

I own the notification service at a consumer fintech app: about three million messages a day. The critical ones are one-time passwords; a late OTP means someone can't log in or pay.

I'm the lead engineer, with one other engineer. Services publish events to Kafka; my service checks preferences and a per-person rate limit in Redis, renders a template and sends through a provider. Delivery status goes to Postgres, partitioned by day.

The hardest decision was failover between two SMS providers. When the main provider slowed, OTPs arrived late, so if it doesn't confirm within a few seconds, we send through the second. The trade-off is duplicates. I added a short-lived dedupe key and accepted that someone occasionally gets the same code twice.

OTP delivery success went from about 96% to 99.4%. What I'd change: a marketing campaign once delayed OTPs because they shared a queue, so I'd give OTPs their own high-priority queue from day one.

In all four, the stack appears only in the architecture, there is one real trade-off, and each ends with a change.

What was your role in the project?

Most projects are team projects, and “we built” hides who did what. Answer this before they ask.

• Say “I” for your work and “we” for team decisions. “We chose Postgres; I designed the schema.”
• Name teammates' parts by role, to show you understood the whole system without claiming it.
• If your part was small, make it deep. “I only built the webhook handler, but I know exactly how it retries” is a strong answer.

Weak and strong project explanations, side by side

The weaker answer lists seven technologies and proves none. The stronger one gives a problem, a design, a number and a trade-off.

How to explain your project architecture on a whiteboard or shared doc

When the interviewer says “can you draw it?”, keep it small and talk while you draw.

1. Put the user on the left and follow one request to the right: API, services, then storage.
2. Put data stores at the bottom or right: Postgres, Redis, S3.
3. Draw queues differently, with a dashed arrow or a named box.
4. Label every arrow with what flows along it, such as “GPS every 5 s”.
5. Mark your part and say “this is what I built”.
6. Stop at 5–8 boxes. Add detail only when the interviewer points at one.

In a remote round you may get a shared doc or only a chat window. A text diagram works:

[Driver app] --GPS every 5 s--> [Spring Boot API]* --latest position, 30 s expiry--> [Redis]
                                        |
                                        +--routes, stops, accounts, history--> [Postgres]
                                        |
[Student web app] <--WebSocket push-----+

* the part I built

Practise drawing it in under two minutes, out loud. If they then ask about a hundred times the traffic, it has become a system design question; see our URL shortener walkthrough.

Follow-up questions interviewers ask about your project

Prepare a sentence or two for each; you will get several.

If you don't know, say what you'd check: “I didn't measure that; I'd start by load-testing the WebSocket server.”

Mistakes to avoid

• Opening with the tech stack. Start with the problem.
• “We” all the way through. The interviewer can't hire your team.
• No number. Find one figure, even from a test.
• A 5-minute monologue for a 2-minute question. Stop and let them choose where to go.
• Claiming what you can't defend. Mention Kubernetes and expect a Kubernetes question.

Prepare your project explanation in 30 minutes

1. Pick the project closest to the job that you know best.
2. Write one line per part, and find your number.
3. Draw the architecture in under two minutes.
4. Say the 30-second and 2-minute versions aloud with a timer.
5. Write a one-line answer to each follow-up above.
6. Explain it to a friend; strengthen whatever they question first.

Then fit it into tell me about yourself, turn its hardest moment into a STAR story for your story bank, and see software engineer interview preparation for the other rounds.

Questions people ask

How do I explain my project in an interview as a fresher?

Give the problem, your role, the architecture, one hard decision, a result with a number, and what you'd change, in about two minutes.

How long should a project explanation be?

About 30 seconds in an introduction or HR round, 2 minutes when asked to walk through it, and up to 5 minutes with a diagram when they ask for detail.

Can I use the STAR method to explain a project?

Yes: situation is the problem, task is your role, action is the architecture and your hardest decision, and result is the number plus what you'd change.

What if my project is under an NDA?

Describe the industry, the problem and a generic architecture, using orders of magnitude. Never name the client or share code.

What if my project is a common one, like an e-commerce clone?

Lead with what you did differently: a feature the tutorial lacked, a performance fix, or your own deployment. If there's nothing yet, add one before the interview.