Practice

Tell me about a technical problem you solved on your own.

Read first: a strong sample answer and why it works

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

Now try your own version (optional — get instant feedback)

Use only details that are true for you. The benchmark below is fictional.

What you type here is sent to JoRoute's server to produce this result, then discarded. It is not stored or logged, and no account is needed.

Next in your job search