How to Explain Your Projects in a Technical Interview

"Walk me through a project you worked on" sounds like the easiest question in the loop. In practice it is one of the most common reasons strong coders get rejected. Candidates either give a feature tour ("there's a login page, then a dashboard…"), or recite the tech stack, or claim the whole team's work and then fall apart at the third follow-up. Interviewers notice all three.

This guide gives you a structure that holds up for a short overview at the start of a coding round and for a dedicated 45-minute project round (common at Amazon, Microsoft, Atlassian and many Indian product companies). It also lists the follow-up questions you should expect, and walks through four complete sample answers: a product-company backend system, a service-company client project, a fresher's college project, and an ML project.

What Interviewers Are Actually Evaluating

When an interviewer asks about your project, they are filling in a rubric that usually looks something like this, whatever the company calls it:

The project is just the vehicle for these signals. That is good news: a modest internal tool explained with depth and honest trade-offs scores higher than a famous product you touched lightly.

The 6-Part Structure for Explaining Any Project

1. Context (1 sentence). What the system is and who uses it. "It's the reconciliation service for a payments platform; it matches bank settlement files against our transaction records for about 40 merchants."
2. Problem (1–2 sentences). Why the project existed, and what was painful before. "Finance did reconciliation in spreadsheets; mismatches were caught days late and took a person two days a week."
3. Architecture (3–4 sentences, plus a sketch if allowed). The main components and how data flows. Stay at the box-and-arrow level.
4. My part (2–3 sentences). Precisely what you owned. "I designed and built the matching engine and the retry logic for failed file ingestion."
5. Key decision and trade-off (2–3 sentences). One interesting decision, the alternative, and why you chose as you did. This is where good answers stand apart.
6. Outcome and learning (1–2 sentences). A number, plus what you would do differently.

This adds up to about 12–15 sentences, or roughly two minutes spoken. Then stop and offer a direction: "I can go deeper into the matching algorithm or the failure handling, whichever is more useful." This hands the interviewer control and nudges them toward the area you know best.

The 2-Minute Version: A Complete Example

Here is the six-part structure applied end to end. Read it aloud and time it. It takes about two minutes.

"The project I'd like to talk about is the reconciliation service at my current company, a payments aggregator. It matches daily settlement files from partner banks against our own transaction records, for around 40 merchants and roughly two lakh transactions a day.

Before this, the finance team reconciled in spreadsheets. Mismatches like a missing refund were found three or four days late, and it took one person about two days a week.

The architecture is simple. Bank files land in S3 over SFTP, an ingestion job parses them into a staging table in Postgres, and a matching engine compares them with our transaction table and writes results to a mismatches table. A small dashboard shows exceptions, and alerts go to Slack.

I owned the matching engine and the ingestion retry logic. The interesting decision was how to match. Banks don't send our transaction ID reliably, so we couldn't do a simple join. I proposed a two-pass approach: an exact match on UTR, the bank reference number, where it exists, then a fuzzy match on amount, date window and merchant for the rest, and anything ambiguous goes to a human. We considered doing fuzzy matching for everything, but it produced false matches, and in reconciliation a false match is worse than an unmatched record.

The result: mismatches are now flagged within a few hours of the file arriving instead of days, and manual effort dropped to roughly an hour a day. Looking back, I'd have added idempotency to the ingestion job from day one. We had one incident where a bank re-sent a file and we double-counted until I fixed it. Happy to go deeper into the matching logic or that incident."

Notice what is there: a scale number, a before/after, one clear decision with a rejected alternative, a candid mistake, and an invitation to go deeper. Notice also what is not there: a list of every technology, every screen, every sprint.

Drawing the Architecture (On a Whiteboard or Screen)

If the round is in person or the interview tool has a whiteboard, sketch it. An interviewer who can see your system asks better questions, and those are questions you can answer. Keep it to 5–8 boxes:

Rules for the sketch: label the data stores, show the direction of data flow, mark the components you built (circle them or say so), and leave out things like the load balancer or CDN unless they matter to the story. If the interview is voice-only, describe the flow as "data comes in from…, goes to…, ends up in…", which is the spoken version of the arrows.

The 30 Follow-Up Questions to Prepare For

After your overview, the interviewer will pick a direction. These are the follow-ups that come up again and again, grouped by what they test. For your main project, you should have an answer to every one of them. "I don't know, but here's how I'd find out" counts for a few.

Design and architecture

1. Why did you choose this database? What else did you consider?
2. Why a separate service instead of a module in the existing app (or vice versa)?
3. Walk me through what happens, step by step, when [main request] comes in.
4. What is the data model? Show me the main tables or documents and the key indexes.
5. Was it synchronous or asynchronous? Why?
6. If you rebuilt it from scratch today, what would you change?

Scale and performance

7. What is the traffic or data volume? Peak versus average?
8. What happens at 10× the load? What breaks first?
9. What was the slowest part, and how did you find it?
10. Did you use caching? What is the invalidation strategy?
11. What are the p50 and p99 latencies, and how do you measure them?

Failure and reliability

12. What happens if [dependency] is down?
13. How do you handle retries? Can a retry cause duplicates? (Idempotency.)
14. Tell me about an incident or bug in production. How was it detected and fixed?
15. How do you know the system is healthy? What do you monitor and alert on?
16. How do deployments work? How do you roll back?

Data and correctness

17. How do you make sure data is consistent between X and Y?
18. What happens with concurrent updates to the same record?
19. How did you handle schema changes or migrations?
20. Where do you validate input, and what happens with bad data?

Testing and quality

21. How did you test this? Unit, integration, end to end?
22. What was hard to test, and what did you do about it?
23. How do code reviews work on your team? Give an example of feedback you received.

Ownership, team and judgement

24. What exactly did you build versus your teammates?
25. What was the hardest technical problem you personally solved?
26. Did you ever disagree with a design decision? What happened?
27. How did you decide what to build first?
28. What would you do with two more months on this?
29. What did you learn that you've applied since?
30. How does this connect to what our team does?

Questions 12–16 are where candidates from service companies and college projects most often struggle, because these concerns were handled by someone else or never came up. If that is you, learn how they would work for your system. Retries, backoff and circuit breakers and observability basics are good starting points. Then answer honestly: "We didn't have alerting on that. If I were to add it, I'd…"

How to Talk About Trade-Offs and Metrics

The trade-off formula

Every technical decision you mention should come with three parts: what you chose, what you didn't choose, and the cost you accepted.

• Weak: "We used MongoDB because it's scalable."
• Strong: "We used MongoDB because each merchant's config is a nested document that changes shape often, and we rarely join across merchants. We gave up multi-document transactions, which was acceptable because config updates are per merchant. If we'd needed cross-merchant reporting, I'd have picked Postgres with JSONB."

If the decision was made before you joined or by a senior, say so, and still give your own view: "That was decided before I joined. Having worked with it, I think it was right because…, though I'd reconsider X." Having an opinion is the signal they are looking for.

Finding metrics when you "don't have any"

Most engineers have more numbers than they think. Sources to check:

• Scale: rows in the main table, requests per day from logs or the API gateway, number of users or merchants, file sizes.
• Performance: latency before and after from your APM tool (New Relic, Datadog, Grafana), batch job runtimes from scheduler logs.
• Effort saved: manual hours per week before and after (ask the ops or finance team).
• Quality: bug counts, incident counts, test coverage, failed deployment counts.
• Delivery: how long the feature took compared with similar ones, release frequency.

Round sensibly ("about two lakh a day", "from roughly 40 minutes to 6") and be ready to say how you measured. If something is confidential, use relative numbers: "cut latency by about 70%".

Full Sample Answers for Four Common Situations

1. Product-company engineer: an API performance project

"At my current company, an online grocery app, I worked on the product listing API that powers category pages, about 3,000 requests per second at evening peak. The problem was p99 latency of around 1.2 seconds during peaks, and the data showed conversion dropping on slow loads. The API reads from a Postgres catalogue and calls a pricing service and an inventory service per request. I owned the performance work. Profiling showed two things: the pricing call was sequential per product, and the inventory check hit the primary database. I batched pricing calls into one request per page and moved inventory reads to a Redis cache with a 30-second TTL, refreshed by inventory-change events from Kafka. The trade-off was showing slightly stale stock for up to 30 seconds. We agreed that with product, and added a hard check at checkout so nobody could buy something that was out of stock. p99 dropped to about 300 milliseconds. If I did it again, I'd have added a load test to CI before the change, because we only found a connection-pool limit in production."

2. Service-company engineer: a client project

"I work at an IT services company on a project for a large private-sector insurance client. I'll keep the client anonymous. We maintain the policy-renewal system: a Java Spring Boot backend with an Oracle database that processes renewal notices for around 15 lakh policies a month through a nightly batch. My main contribution was fixing the batch, which had grown to over 5 hours and kept breaching the 6 am deadline. I traced it to an N+1 query pattern, with one query per policy for rider details, and a missing composite index. I rewrote the fetch as a paged join with a page size of 1,000, added the index after checking the query plan, and made the job restartable from the last committed page so a failure at 4 am didn't mean starting over. Runtime fell to about 70 minutes. The restartability is the part I'm proudest of, because it changed failures from an escalation to a non-event. What I'd improve is our test data. We tested on a small sample and missed a slow path that only showed up with policies that have many riders."

Service-company work is often described as "just maintenance". This answer shows that maintenance work, explained with depth, makes a strong project story. More on positioning that experience is in switching jobs at 1–3 YOE.

3. Fresher: a college project

"My final-year project was a doubt-solving platform for our college, a bit like a small Stack Overflow, used by about 400 students during exam season. Seniors' answers were scattered across WhatsApp groups and got lost. I built it with a team of three. I owned the backend: a Node.js and Express API with MongoDB, JWT authentication, and search. The interesting problem was search. We first used regex queries in MongoDB, which got slow and didn't handle typos, so I switched to MongoDB's text index with weights, giving the title more weight than the body. I looked at Elasticsearch, but running it on our free-tier server wasn't practical. The trade-off is weaker fuzzy matching. We also had a bug where two people upvoting at the same time lost a vote. I fixed it by using MongoDB's atomic $inc instead of read-modify-write. If I rebuilt it, I'd add rate limiting, because one student scripted thousands of upvotes during testing."

Freshers: interviewers will pick a technology from your resume and ask how it works (JWT structure and expiry, how a MongoDB index works, what happens on a race condition). Prepare one level below every buzzword you list. See also resume for freshers with no experience.

4. ML project

"I built a support-ticket classifier for our internal helpdesk, which routes about 2,000 tickets a day to 12 teams. Misrouted tickets added roughly a day to resolution. I started with a TF-IDF and logistic regression baseline, which reached about 82% accuracy on a held-out month, then tried a fine-tuned small transformer at about 89%. The interesting decision was deployment. Instead of auto-routing everything, we auto-route only when the model's confidence is above a threshold, and send the rest to a human queue. I picked the threshold from the precision–recall curve so that auto-routed tickets had about 97% precision, which covered around 70% of volume. Monitoring was the part I underestimated. A product launch changed ticket vocabulary and accuracy dropped, so I added a weekly evaluation on a freshly labelled sample."

Handling Tricky Situations

"I only did a small part of a big project"

Describe the system in two sentences, then go deep on your part. Depth on a small component beats breadth across a large one. Interviewers ask follow-ups about whatever you claim, so claim what you own.

"The project is under NDA"

Anonymise the client ("a large private bank"), round the numbers, and leave out security details. Explaining architecture and decisions is normal and expected. If something truly can't be discussed, say "I can't go into the specifics of that integration, but the general pattern was…"

"I don't know the answer about my own project"

Never bluff. Say: "I didn't work on that part, so I'm not certain. My understanding is X, and if I had to design it I'd do Y because…" That turns a gap into a demonstration of reasoning. Bluffing, then getting caught at the next question, can sink the whole round.

"The interviewer keeps interrupting"

That is good. They are steering to what they need to assess. Answer the interruption directly, then let them choose whether to go back to where you were. Don't push on with your prepared script.

"Which project should I pick?"

Pick the one where you can go deepest and that has a real decision in it, not the most famous one. If the interviewer asks for a specific type ("something with scale", "a time you led"), choose to fit the question.

Red Flags Interviewers Note

Your Prep Worksheet: Do This for Two Projects

Prepare two projects: a primary one you can discuss for 40 minutes and a backup for when the interviewer asks for "another example". For each, write down:

1. The six-part script in about 15 sentences. Say it aloud and time it at 2 minutes or less.
2. An architecture sketch you can draw in 60 seconds, with your components marked.
3. Three decisions, each with the alternative and the trade-off.
4. Five numbers (scale, latency, time saved, error rate, team size) and how each was measured.
5. One incident or bug story using the STAR format. These double as behavioural answers; see the STAR method guide.
6. Answers to the 30 follow-ups, at least in bullet form, including honest "we didn't do this; here's how I would" answers.
7. One "what I'd change" that shows growth, not a trivial point.

Then rehearse with someone technical who will interrupt you. The first time someone asks "what happens if Redis goes down?" in a mock, you will find the gaps that a solo rehearsal never shows. Your project story also feeds your opening pitch, so make sure the two match; see how to answer "tell me about yourself".

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.