I recently had an interview for a senior software developer position. One question was along the lines of, "if you're working on something and you get stuck, what do you do?"

I've been asked this several times before and never had a great answer. I said I'd research the problem and look for technical docs and other people asking about the same problem online. "What if you were still stuck?" I said I'd ask a more knowledgeable colleague in the development team. "What if you were still stuck?" In the end I just said I guess I'd tell my manager, but they didn't seem too impressed with that either.

What are interviewers getting at when they ask this question? What do they want to hear?

  • Does this answer your question? How are tough introspective or behavioural type interview questions assessed?
    – gnat
    Aug 25, 2022 at 5:07
  • 2
    This is an incredibly stupid interview question. You gave the right answer, as far as I'm concerned. I'm not sure what kind of work the company is doing where you can't solve the issue by searching for it on google or asking a coworker what to do. It might take a long time to solve the issue, but the set of issues that are not solvable that way is so small that it should almost never come up in a real life situation.
    – Ertai87
    Aug 25, 2022 at 16:45

6 Answers 6


I suspect they wanted you to be even more proactive and look for solutions that may not give you 100% of what you need, but may meet business objectives.

You would then discuss the options with your peers, and run it past management to see if it's suitable.

It really depends what the interviewer means by "stuck" however.

  • Yeah. I think possibly one thing they were looking for was about meeting business objectives and considering whether what I was doing could be achieved in another way that still achieved those objectives but that I was able to more easily implement.
    – Jez
    Aug 25, 2022 at 7:54
  • 3
    My first response would be to ask for a definition of "stuck". It doesn't mean the same for everyone. Stuck for me involves having already consulted the internet, peers, subject matter experts, etc, and no resolution has presented itself as obvious. Aug 25, 2022 at 18:29

The definition of "stuck" is unclear , but I'd say the following :

My first few attempts would be to identify the specific problem , look for references . Then I'd need to look at the bigger picture and rethink the overall approach . (give example)

Afterwards I'd ask colleagues for help . (give example)

If I'm still stuck I'd rethink my priorities , whether I really need to solve this problem or alternative approaches . (give example)

Finally I'd summarize my attempt and ask my manager . (show that I'm well prepared before asking)

*giving examples or experiences could make your answer more unique than other candidates


It's not obvious what answer the interviewer wanted, but diagnosing why you are stuck, and being able to articulate it, can be an important step toward resolution.

If you're stuck because the task will need a hundred men to complete and you're already exhausted, then "consulting the technical docs" alone would be persisting along the line of failure, so diagnosis is clearly an important step.

I would say in development, the kind of "getting stuck" which is the most subtle and dangerous is when scale has been completely underestimated, but nobody knows (or will acknowledge) it to be so.

The classic symptom of this situation is an interminable lack of progress for no overarching reason, or for wooly reasons, but where the proposed solution is more time and resources.

Almost any problem can be solved given enough time, except the problem of taking too much time.


The question is rather vague and they may be looking for various answers, but here is what I usually go with:

  • When I "get stuck" on something (30 minutes or less when I am clueless), I will "search the internets"; Note: I don't consider myself really stuck until I've done this step
  • When I have no luck online, I will try to work on something else for a moment or go for a walk (or literally distract myself with anything else, from looking out of the window, going for a tea, ...) and then get back to that (and possibly start over, resp. "take a step back")
  • If it takes too long (and here I say we've agreed within team that too long is x hours), I will ask the team (or whomever who could help me)
  • We are having daily stand-ups, so I will bring it here and we will try to find a solution (meaning a colleague will offer to pair with me on that, we will find somebody who understands this (cross-teams) etc.)
  • If nothing helps, we will discuss it as a team (stand-up) and try to find a workaround and inform whoever needed the task about the outcome (impossible to do, possible workarounds, ...) and discuss options.

Then I will say something along the lines that this applies to regular tasks, if there is a priority or something, the flow is changed ofc. (like not waiting for SU to bring it up).

In my opinion what they are looking for is if you cooperate with team well, if you have/follow procedures and whether you can admit you cannot do something.

Every time you move to the next point, you should repeat all previous ones :-)


Not so much what you will say in an interview, but what you do in real life:

  1. Step back from the problem, do something else, wait for enlightenment. This works surprisingly often.

  2. Explain the problem to anyone willing to listen. They don’t even need to help, just the fact that you have to explain the problem clearly to someone willing to listen will often help.

  3. Check if there is anyone more clever or more experienced than you who can solve the problem. Or knows a strategy that might. At least that shifts the blame somewhat - unless you are supposed to be the person solving the hard problems.

3a. Same, but the more experienced person tells you this isn’t possible.

  1. Figure out this problem is really hard and cannot be solved by one person in a reasonable amount of time. Like your boss asks you to write software for a self-driving car.

4a, but it cannot be solved by you. Maybe someone more clever, who will be more expensive.

  1. Reading. Investigating. Using problem techniques. Tenacity is good.

Eventually you ask how important it is to solve this problem and not a slightly different and simpler one.

  • "At least that shifts the blame somewhat". IMHO, the word "blame" may lead to friction or conflict between team members. Try not to blame anyone. Always work nicely together as a team to solve tech problems. That will be better for everyone in the long term. Aug 29, 2022 at 16:39

In the form you give it above, "if you're working on something and you get stuck, what do you do?", it's not a great interview question. It would probably get better answers by turning it into a behavioural interview question about a particular time the interviewee got particularly stuck.

However, I think it is a reasonable thing to want to find out about a new team member, especially a senior one. The behaviours I would be looking for are things like:

  • Recognition. Noticing when it is a difficult problem, and switching to different approaches. (Other answers mention this, and they're right.)
  • Systematic Exploration. Difficult problems require more organized problem solving. It's not clear what data is important until some digging has happened. The issue may be crucial, but hard to reproduce. It's also hard to keep track of what has been tried and what hasn't. Detailed note taking, almost similar to a laboratory scientist, become much more valuable in these circumstances.
  • Systematic Reproduction. Difficult problems might often require more careful construction of repeatable tests. Did you change your testing environment accordingly, add tests, or change test approach, in a way that could catch the issue repeatably?
  • Pushing beyond technical boundaries. Ok, so the exception seems to be coming from that third-party library, or Python itself, or that third-party Java library that you don't have the source for. And you don't know the language it's in. Did you debug their code anyway? Can you reproduce the behaviour on a simpler test case? Did you decompile the library?
  • Pushing beyond organisational boundaries. Don't have access to some useful information owned by another team? Did you do anything to get it - talk to people directly, use backchannels, escalate? Maybe the network team can use tools you can't to show you what was on the wire when the incident happened.

I have worked with a lot of developers over the years, junior and nominally senior, who have not been able to do this. When they hit a genuinely tough bug, they got stuck in a loop, just looking at the same code in the debugger, looking at the same stackoverflow posts for error messages, and saying "the code looks ok to me". They often weren't bad developers. Were they senior, though? By contrast, a friend calls devs who take the approaches bullet-pointed above as "fearless engineers". "Fearless", in this case, means that they push beyond their own personal mental comfort zones in order to solve difficult problems.

If you're ready for a senior role, you'll be able to find examples from your work that fit the things above, or other things I haven't thought of, but which show a similar track record of digging deeper when solving hard problems.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .