How to Answer ‘Tell Me About a Project You Worked On’

The seven-part project answer

1. Situation: what the product or system did and why it mattered.
2. Task: the problem, constraint or goal you owned.
3. Action: the important decisions and work you personally drove.
4. Technical depth: one architecture choice or difficult trade-off.
5. Result: the observable engineering and business outcome.
6. Learning: what you would repeat or change.
7. Pause: invite the interviewer to choose a deeper thread.

STAR is useful, but technical interviews need an extra layer: the architecture and reasoning must be visible without turning the opening into a 10-minute lecture. Think of the first answer as an index. It should create several honest follow-up paths—scale, reliability, data model, rollout, conflict or failure.

A 90-second backend example

Notice what the answer does not do: it does not list Java, Kafka, Redis and PostgreSQL before describing the problem. Those tools matter only when tied to a decision.

A 75-second SRE example

How to choose the right project

• Choose a project relevant to the role’s seniority and problems.
• Prefer work where your decisions are distinct from the team’s output.
• Pick a project with a trade-off, incident, ambiguity or stakeholder constraint.
• Avoid confidential details you cannot discuss safely.
• Keep a second project ready in a different area: delivery, reliability, leadership or failure.

Answer ownership questions precisely

Use “we” for the team outcome and “I” for your contribution. For example: “We migrated 20 services; I designed the compatibility layer and owned the rollout dashboard.” Senior interviewers will test the boundary. If you claim the whole design, expect questions about alternatives, failure modes, capacity, schema changes and operational ownership.

Prepare the technical depth behind the summary

Common follow-up questions

• What exactly did you own?
• Why did you choose this design over the alternative?
• What failed in production?
• How did you measure success?
• How did you handle disagreement?
• What would break at ten times the load?
• What would you do differently now?
• How did you protect customer data and secrets?

For security questions, describe safe patterns without exposing real credentials, internal hostnames or exploitable production details. Explain controls such as least privilege, parameterized queries, validated inputs and secret stores at the design level.

Weak patterns to remove

• Starting with a long technology inventory.
• Giving company history instead of the project situation.
• Using only “we” so ownership is impossible to see.
• Quoting a result you cannot explain or attribute.
• Describing the happy path but no failure handling.
• Speaking for five minutes without checking the interviewer’s direction.
• Blaming another team when explaining a delay or incident.

A 20-minute preparation drill

1. Write one sentence for each of the seven parts.
2. Record a first take and stop at two minutes.
3. Remove tool lists and company background that do not change the story.
4. Ask a peer to interrupt with five why/how questions.
5. Prepare one architecture sketch using only components and arrows.
6. Verify every metric and anonymize confidential data.
7. Repeat until the opening sounds conversational, not memorized.

Support the project story with stronger evidence from How to Quantify Achievements on Your Resume Even If You Don't Work With Numbers, How to Master Behavioral Interviews and ‘Googleyness’-Style Questions.

Conclusion

The best project answer is short enough to follow and deep enough to investigate. Give the map, make your ownership clear, show one meaningful decision and let the interviewer choose the next layer.