Project Work

What they are looking for

When you walk through a project, interviewers are evaluating a few things in parallel. Can you communicate clearly? Can you explain the problem, your solution, what you specifically contributed, and what the results were? Was the project genuinely complex? Was the scope senior or staff level? And critically: what did YOU do?

Teams are great, but this is not the time for "we did this" and "the team built that." They want your contribution. Use "I" deliberately and often.

What to talk about

Skip the small stuff. Focus on your two biggest and most complex projects from the last five years. At a minimum, know one of them cold. Practice talking through it until you could do it half asleep.

For both projects, write out a full description in a Google Doc before you start interviewing. This forces you to structure your thoughts and surfaces gaps in your narrative before the interview does.

The STAR method

Use STAR as your structure for every project story. It is not just a format. It maps exactly to what interviewers are evaluating.

Situation

Always open with the original state of the system, or the absence of one, and what the problem was. Give them just enough context to understand why the project existed.

Task

Describe how the project came to you. Oversell how ambiguous and underspecified the requirements were. The more design that was handed to you upfront, the less impressive your contribution reads. Interviewers want to see that you started from minimal requirements and drove the shape of the solution yourself.

Action

This is the bulk of the story. Cover how you gathered requirements, and be explicit about who you met with. If anyone was outside your immediate team, call that out. Interviewers respond well to cross-team touchpoints. Walk through how you approached the design, got feedback, built MVPs, iterated, and wherever possible, multiplied your impact by distributing work to teammates.

For senior and staff roles especially, make sure you talk about how you made the system fault tolerant, resilient, available, and maintainable. This is where a lot of candidates leave points on the table. Specifically, did you:

• Add monitors and alarms?
• Scale the services?
• Make workflows replayable and idempotent?

If you did any of these, it belongs in your story.

Result

Do not skip this and do not be vague. "Customers were happy" is a wasted opportunity. Quantify everything you can. Estimate cost savings in dollars if it is reasonable to do so. Talk about which metrics you used to measure success and how you tracked them. This is not the time to be modest. Talk up every part of your contribution, including the parts that might feel obvious to you. Did you implement something without a written design? Then you designed it too. Say so.

Demonstrating technical complexity

If you can point to a genuine piece of complexity in the project, great. If not, this is where Designing Data-Intensive Applications (DDIA) earns its reputation as interview prep material.

Pick a few topics from DDIA that connect to something in your project, even loosely. Interviewers tend to check the "technically complex" box quickly when they hear you engage with concepts like:

• Idempotency or deduplication in some operation
• Database isolation levels
• At-least-once vs. effectively-once semantics
• Issues with timestamps or clock skew across services
• Reducing latency on a critical workflow
• Moving from synchronous to asynchronous processing
• Implementing a message queue
• A consistency problem, whether around data integrity or timeliness (see the note on the Process page about the word "consistency")

You do not need to have solved all of these. You just need to have thought about them in the context of your project and be able to speak to why they were relevant.

Demonstrating scope

Cross-team collaboration is your strongest signal here. Make sure interviewers understand how many stakeholders you worked with. Do not exaggerate, but do not leave anyone out. The stakeholder you met with twice who seemed minor at the time is still a data point that signals broader scope.

If you participated in any weekly or monthly sync for the project, you were part of leading that meeting. If you influenced any decision from a stakeholder or product partner, that is a story worth telling. You need at least one example where your technical perspective changed someone's direction or unblocked a decision.