You can explain your work without revealing confidential material. Describe the problem, your responsibility, the decision and a permitted outcome. Remove private identifiers and do not share files or details you are not authorized to disclose.

This is a practical communication guide, not legal advice about a particular contract. If a disclosure boundary is uncertain, use approved public information or ask the appropriate owner before the interview.

What can usually be made more general?

Replace customer names with a generic description. Explain a service's role without its private address or credentials. Describe the kind of failure without showing actual customer records. Use a public architecture pattern rather than an internal diagram.

Removing a name alone may not be enough. A distinctive combination of dates, volume, location and incident details can still identify a customer or project. Review the whole example.

How can you preserve useful detail?

Keep the reasoning specific. You can explain that a stale cache caused a mismatch, that you compared the authoritative record with a derived view, and that you added a regression check. You do not need to show a private database export.

Illustrative fictional answer: “I worked on a service that displayed records from a derived view. I cannot share its internal data, but I can explain how I traced a mismatch, identified the update path and verified the correction with a small synthetic fixture.”

Adapt that structure only to work you actually did. The example demonstrates a boundary statement, not a personal achievement you should claim.

What if the interviewer asks for a number?

Use a metric only when it is accurate and permitted to share. If it is confidential or unavailable, say so and explain the observable outcome you can discuss. Do not replace it with an invented approximate improvement.

A result can be meaningful without a percentage: an error no longer reproduced under a defined test, a required workflow became available, or a review found a specific risk before release. Keep the claim within your evidence.

What should you avoid showing?

  • Private source repositories without permission.
  • Credentials, tokens or connection strings.
  • Customer or employee records.
  • Internal incident reports or screenshots.
  • Employer interview prompts that you agreed not to distribute.

Check browser tabs and desktop notifications before a screen share. Use a separate synthetic demonstration rather than navigating through an employer's production tools.

How do you decline a request politely?

Keep the boundary short and offer an alternative: “I cannot share that internal document. I can walk through a generic version of the decision and the checks I used.” Do not blame a former colleague or provide more sensitive context while explaining why it is private.

If the permitted alternative still feels uncertain, choose another example. You do not need to reveal protected material to prove that you have experience.

Prepare a safe evidence set

Choose a public project, approved portfolio item or newly created synthetic example. Clearly label what is original demonstration material and what reflects a past responsibility. Keep your role and the team's role separate.

Practice explaining the decision with that evidence before the interview. The best replacement for a private screenshot is a clear account of the problem, your reasoning and the result you are allowed to discuss.

References and next practice

careerservices.fas.harvard.edu — career · careers.umd.edu — preparation

Browse interview topics · Practise a question in Interview Challenge · How to Prepare for an Interview