A portfolio introduction should prepare the interviewer to understand the work you are about to show. State the problem, the audience, your contribution and the limits of the demonstration. Then move to the artifact rather than giving a long biography.

This guide is for the opening of a walkthrough, not a general “tell me about yourself” answer. Its purpose is to give the viewer enough context to judge your decisions.

Choose the first artifact deliberately

Start with an item that matches the role and that you can explain well. A small complete workflow can be more useful than several disconnected screenshots. Check that you are permitted to show the work.

If the project is a prototype, say so. If it uses sample data, label that data. A demonstration should not imply real customers, production traffic or business results that do not exist.

What should the opening contain?

  • Who the project is intended to help.
  • The problem it addresses.
  • What you personally designed or built.
  • What works in this demonstration.
  • The first decision you want to explain.

Keep team contributions accurate. “We built the app; I owned the search interaction” gives a clearer starting point than either taking all the credit or hiding your own work behind “we.”

Illustrative walkthrough opening

Fictional sample: “This is a public sample app for organizing reading notes. I built the search and empty-state behavior. The demo uses synthetic notes and runs locally; it does not include accounts or cloud synchronization. I will first show how a reader finds a note, then explain why I kept the filter visible when no results match.”

Replace the project with your own permitted work. This example is a communication model, not a project history you should claim.

How do you transition to the screen?

Give the viewer a task to follow: “Suppose the reader remembers a phrase but not the note title.” Then perform the relevant steps. Explain decisions at the moment they become visible instead of narrating every click.

Pause for questions at a natural boundary. If the interviewer asks about a different part, follow that interest. A walkthrough is a conversation about evidence, not a fixed tour that must visit every screen.

What if the demo fails?

Prepare a permitted backup such as screenshots, a short recorded local run or source excerpts. Label the backup clearly. Do not pretend a screenshot proves the current deployment works.

If a failure occurs live, describe what you can observe and use the backup if needed. Avoid inventing a cause. A concise statement of the limitation is better than spending the whole interview guessing at a network problem.

Which follow-ups should you prepare?

Be ready to explain one rejected alternative, one test and one unresolved limitation. If you used a template or external library, distinguish its contribution from yours. Keep sensitive repository content and credentials off the shared screen.

Rehearse the opening with someone who has not seen the project. Ask them to name the user, your contribution and the demo boundary. If they can do that, you have given them a sound basis for evaluating the work.

References and next practice

careerservices.fas.harvard.edu — career

Browse interview topics · Practise a question in Interview Challenge · Tell Me About Yourself: An Answer Framework You Can Adapt