“Tell me about a challenging task”: how to answer

Some version of this question comes up in almost every interview. Here are a few from the Sobes question bank:

What was the most difficult task you've had recently, what did it involve, and how did you solve it?

Tell me about some complex, interesting tasks from your recent work experience.

What was the most difficult technical task you've implemented?

The first one alone has been opened almost 4,500 times in the Java section. And the Python section has a follow-up that explains a lot: "Did you resolve the difficulties on your own or by discussing them with the team?"

The interviewer doesn't care much about the size of the project. They want to understand what you consider hard, what you did yourself, and how you think when the solution isn't obvious.

How to choose a story

A good story for this question is:

Recent, from the last year or two. A task from five years ago leaves you with nothing but generalities.
Yours. You were at the center of it, not watching from the side while the team rewrote the core.
Genuinely hard: an unclear cause, tight constraints, conflicting requirements.
One with a result you can name.
One where you can handle three or four follow-up questions in a row.

Weak choices:

"The hardest part was learning Kubernetes." Learning can be hard too, but it's not a task.
"We rewrote the monolith into microservices", if your part was small. The very first "what did you do?" will put you in an awkward spot.
A project you can barely talk about. If there's no other option, see how to talk about a project you can't disclose.

What counts as difficulty

"There was a lot of work" doesn't count. The difficulty is whatever kept you from solving the task head-on. Usually it's one of these:

the cause is unclear: a flaky bug, a problem only some users have;
tight constraints: a deadline, legacy code, you can't stop production, no budget for hardware;
conflicting requirements: the business wants one thing, security wants another;
people: you need to get another team on board, and they don't need your task.

Name the difficulty in one sentence at the start. "It was hard because we couldn't reproduce the bug" gets the interviewer interested right away.

How to structure the answer

Aim for two or three minutes:

Context, one or two sentences: what the product is and what the situation was.
What made it hard.
What you did. This is the longest part. Don't be afraid to mention dead ends: "at first I thought it was the database, but it wasn't."
The result, with numbers if you remember them.
What you learned or would do differently.

Frontend example

I'm a frontend developer on a product for accountants. At some point we started getting complaints that the reports page froze for some clients. For us, everything was fast, and that was the main difficulty: we couldn't reproduce it.

I asked support to find out what the clients were using. It turned out the complaints came mostly from cheap office laptops, and their reports were huge, several thousand rows. I turned on CPU throttling in the browser, loaded the same amount of data, and finally saw the problem: on every character typed into the filter, the whole table re-rendered.

I changed it so only the visible rows were rendered, and the filter ran after a pause in typing instead of on every keystroke. Typing in the filter stopped lagging, and the complaints to support stopped.

My main takeaway: test heavy screens on more than just your own laptop. Our release checklist now includes a check with CPU throttling.

Why it works: the difficulty is named right away, you can see how the candidate searched for the cause, and the takeaway changed how the team works.

Backend example

I'm a backend developer at a logistics company. Every night we generated reports for the warehouse: the job started at 1 a.m. and had to finish by 7 a.m., when the first shift arrives. The data kept growing, and at some point the job started finishing around 10. The shift was coming in to empty reports.

The budget didn't allow for more servers, and we couldn't stop accepting orders while the job ran. I profiled it and saw that most of the time went to database queries that fetched one record at a time in a loop. I rewrote the job to process data in batches and split it by warehouse so the parts ran in parallel. I also had to get the database admins on board with a new index: they were worried about write performance, so we tested it together on a copy of the database.

In the end, the job took less than an hour. If I did it again, I'd add monitoring for the job's duration from the start: we found out about the problem from the warehouse, not from our dashboards.

Why it works: clear constraints, the candidate's own decisions, working with other people, and an honest takeaway about what was missed.

Follow-ups to prepare for

A good story always gets follow-ups. The most common ones:

What did you do personally, and what did the team do?
What options did you consider, and why did you drop them?
How did you know the solution worked?
What would you do differently?
Did you solve it on your own or with the team?

You don't have to answer the last one with "all by myself". It's fine to say where you handled things alone and where you brought in colleagues, and why. It shows you know when it's time to ask for help.

If you don't have much experience yet

A junior without commercial experience can talk about a study or personal project, a hackathon, or a course project. The scale will be smaller, and that's fine. "I couldn't figure out why the form was losing data and spent two days digging into it" is a challenging task too, if you tell it well.

Prepare two stories

One technical and one about people: for example, how you got another team on board or argued over a decision. Sometimes that's exactly what the interviewer means by a "challenging task".

Rehearse both out loud in a mock interview or with a friend who asks follow-up questions. If you use Sobes Copilot, add both stories to your notes: then hints for questions about your experience will draw on your real details.

For more on talking about your experience, see “Tell me about yourself”: examples for developers.