Turn a project into understandable evidence
A project discussion helps an interviewer understand how you think and what you actually did. A list of technologies does not explain the problem you solved, the decisions you made, or what you learned. By the end, you will be able to give a clear two-minute overview and prepare for more detailed questions.
Personal, academic, volunteer, and team projects can all provide relevant evidence when you identify the setting honestly. You do not need a commercially successful product. A small, well-understood piece of work is often easier to discuss accurately than a large application you cannot explain.
Choose a project related to the vacancy, reopen the repository or report, and check that your explanation matches what is there. Make sure any public demo works and that you have permission to share the work. Remove credentials, private user data, and confidential employer material.
Use the five-part explanation
Start with the purpose in plain English. Then explain your own contribution before describing technical detail. Pause after the overview so the interviewer can choose where to go deeper.
An outcome can be a tested feature, an analysis, a documented prototype, or a lesson that changed your approach. Numerical results are useful only when you genuinely measured them. State whether tests were automated, manual, or both, and explain what they covered rather than simply saying the project was tested.
| Part | What to explain | Useful prompt |
|---|---|---|
| Problem | Who the project was for and what it needed to do | What was difficult or missing before? |
| Personal contribution | The work you completed and what others did | Which feature, analysis, or decision was mine? |
| Approach and tools | How it worked and why you chose that approach | How did the parts fit together? |
| Challenge | One meaningful obstacle and your reasoning | What did I investigate, try, and change? |
| Outcome and learning | What worked, limitations, and improvements | What can I show, and what would I do next? |
Worked example: a task-management application
This illustrative personal project shows how the structure fits together. It is not a suggested claim that every beginner has built the same features.
Notice the boundary around the API: using a service is a valid contribution, but it is different from designing the service. This distinction makes the explanation more credible and gives the interviewer a fair basis for follow-up questions.
Prepare for technical follow-up questions
Review the project until you can trace one request or user action from beginning to end. Architecture means how the major parts are organised and communicate. A trade-off is what you gain and give up by choosing one approach over another.
- Architecture: Where is data stored, and how does it move between the interface and service? Sketch the flow before explaining implementation details.
- Technology choices: Why did you choose this tool, what alternative did you consider, and what limitations did the choice introduce? “I was learning it” is an honest reason; explain what you learned.
- Testing and debugging: Which important cases did you test, how did you reproduce a failure, and what remains untested?
- Scalability: What might fail with more users or data? Separate improvements you understand conceptually from changes you have actually implemented.
- Security and reliability: How were inputs checked, errors handled, and secrets protected? Do not claim the project is secure merely because it uses a popular framework.
Be precise about team contributions
Use “we” for shared goals and “I” for your individual actions. You can explain the overall system without claiming you built every part. Note which pieces came from a tutorial, starter template, external service, or teammate.
For a team project, prepare one example of coordination: how you agreed an interface, reviewed a change, resolved conflicting assumptions, or documented a decision. Give credit and avoid blaming teammates. If a feature was unfinished, describe what you completed, what blocked the rest, and how you would approach it now.
Avoid adding invented users, performance gains, or commercial impact. If a comparison was only a local test, name the conditions and limits. It is acceptable to say you have not measured something and describe a sensible way to investigate it.
Your two-minute project exercise
Choose one project and write a sentence for each of the five parts. Use this template as notes, not as a script to read during the interview.
- Give the overview aloud in about two minutes, then ask a partner to describe the project back to you.
- Answer three follow-up questions without reading the README. Reopen your work afterwards to check accuracy.
- Improve one confusing explanation or missing piece of documentation. Save a small diagram or notes for your next practice session.
Project explanation planner
Project and setting: [personal / academic / volunteer / team work] Problem and intended user: [what it addresses] My contribution: [specific work I completed] Approach and tools: [how it works and why] Challenge and response: [what I investigated and changed] Outcome and evidence: [what can be demonstrated] Limitations and next improvement: [honest boundaries]
Further reading
Use technical-interview guidance to practise explaining reasoning, not just producing an answer. Next, prepare genuine examples of teamwork and problem-solving using STAR.