Tell me about a time when you didn't know what to do next or how to solve a challenging problem.
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see how you behave when the path is unclear, not just when you already know the answer. They want evidence that you can turn uncertainty into progress through reasoning, learning, and action rather than freezing, thrashing, or waiting passively for rescue. At higher levels, they are also looking at whether you create clarity for others, not just for yourself.
Key Insights
- You do not need a story where you eventually had a brilliant answer immediately. A strong response often starts with genuine uncertainty, then shows how you reduced that uncertainty step by step.
- Do not make the story about being stuck until someone senior told you exactly what to do. Even when you ask for help, show how you framed the problem, tested options, and drove the next move.
- Name the decision process, not just the ending. Interviewers learn a lot from how you narrowed possibilities, chose what to try first, and managed risk while the answer was still unclear.
What interviewers probe atlevel
Top Priority
For junior candidates, interviewers are looking for a simple but disciplined approach: observe, narrow, test, and learn.
Good examples
🟢I started by reproducing the problem consistently, then changed one variable at a time so I could tell which assumption was wrong.
🟢I split the task into smaller questions, like whether the data was wrong or the display logic was wrong, and tested those separately.
Bad examples
🔴I wasn't sure where the issue was, so I tried a few changes that seemed reasonable and kept going until something passed.
🔴I read a lot of documentation and examples, but I didn't really have a plan for how that reading would help me decide what to do next.
Strong answers show an intentional learning loop; weak answers sound like activity without a method.
Valuable
Example answers atlevel
Great answers
During my first few months in my last role, I was asked to fix a bug where some users were seeing stale profile data. I honestly didn't know what to do next at first because I was new to that service and there were several places the issue could have been coming from. I started by reproducing the bug consistently in a test environment, then I split the problem into smaller questions: was the data wrong in storage, or was the app showing old data? After narrowing it down, I asked a teammate one specific question about how the caching layer worked, and that helped me confirm the real issue without handing the problem over. I made the fix, added a small test for the case we missed, and wrote a short note for the team because I realized my biggest lesson was to make the unknowns explicit early instead of just reading code and hoping the answer would appear.
On a project where I was building a simple referral flow for our mobile app, I hit a point where I honestly didn’t know what to do next because the product requirements were vague and different stakeholders had conflicting ideas about privacy and user experience. I stopped trying to guess the right implementation and set up a short meeting with the designer and product manager to list the concrete outcomes we needed and the restrictions we couldn’t break. With those constraints clarified, I made a quick runnable prototype of the UI and a stubbed backend so we could try the flow on a device and get feedback from QA and support. That prototype revealed two edge cases we hadn’t considered, so I implemented a minimal, test-covered solution behind a feature flag and asked for a small beta rollout. The release went smoothly, and I learned how much time I save by turning uncertainty into a tiny experiment and involving the people affected early instead of coding in isolation.
Poor answers
I had a ticket once where an API call was failing and I wasn't sure why. I spent a couple of days going through different files and trying changes until I couldn't think of anything else, so I asked a more senior engineer and they showed me the problem. After that I updated the code and it worked. It was a good experience because sometimes you just need to keep digging until someone who knows the area can point you in the right direction.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid August, 2024
Hello Interview Premium
Your account is free and you can post anonymously if you choose.