Esta página aún no está traducida al español. Ver las páginas en español · Ver en inglés

How to answer: “Tell me about a technical problem you solved on your own.”

How you approach a technical problem on your own: reproduction, diagnosis, a bounded fix, verification and communication.

The answer, step by step

  1. Situation: the problem and its impact.

  2. Diagnosis: how you reproduced and narrowed it down.

  3. Fix: what you changed and how you verified it.

  4. Result: what improved, and what you learned or documented.

A strong sample answer

Benchmark answer for this question

Fictional example for learning only. It is not your experience; replace every detail with facts that are true for you.

During my internship at a logistics startup in 2024, our weekly sales report started showing duplicate rows for some accounts, and the finance team couldn't trust the totals. I reproduced the problem with one account and a small test input, then checked the query step by step. I found that a join to the contacts table returned one row per contact, so accounts with three contacts appeared three times. I changed the query to join on a deduplicated list of primary contacts and wrote a small test comparing the report totals with the source invoices. As a result, duplicate rows dropped from about 40 a week to zero, and the report totals matched the invoices for the next eight weeks. I documented the cause in our wiki so the next person who touched the query would know. It was a good lesson in programming and data analysis together: test the data, not just the code.

Why this example works

It shows a reproducible diagnosis, a specific root cause, a bounded fix with verification, a measured result and documentation.

  • Sets the scene: “our weekly sales report started showing duplicate rows for some accounts”
  • Says what YOU did: “I reproduced the problem”, “I changed the query”, “wrote a small test”, “I documented the cause”
  • States the result: “duplicate rows dropped from about 40 a week to zero”
  • Specific, not general: “about 40 a week”, “eight weeks”, “three contacts”, 2024
  • Connects to the role: Names programming and data analysis

What you can learn from it

Explain your own debugging steps and how you knew the fix addressed the cause.

Make it yours — with true details only

Use a real problem you solved — code, a spreadsheet formula, a network or device issue. Describe your actual steps; if someone helped, say what part was yours.

From generic to evidence

Generic: “I'm good at solving technical problems. I fixed a bug in a report once.”
With evidence: “I reproduced the duplicates with one account, traced them to a one-to-many join, deduplicated the contacts and added a test; duplicates dropped from about 40 a week to zero.”

Mistakes that cost points

  • “I fixed the bug” with no steps — Describe how you found the cause
  • No verification — Say how you confirmed the fix
  • Jargon overload — Explain simply, then go deeper if asked
  • Claiming solo credit for team work — Be clear about your part

Before you answer, check

  • Did I explain how I reproduced the problem?
  • Did I name the root cause?
  • Did I verify the fix?
  • Did I state the result?

Practise it in your own words

Write your version and get instant, explained feedback. Nothing is stored.

Practise this question

Related questions

All interview answers