I disagree. The answers to these situational questions say a lot about a candidate, and their importance is often underestimated by inexperienced interviewers, IMO.

In this specific question, a few things I'd be looking for are:

* Was the candidate proactive in resolving the challenge? Many people just complain when they run into hard problems and expect someone else to pick up the slack.

* Did the candidate learn something, or step outside of their comfort zone? This could be as technical as "I had to learn how this legacy codebase's build scripts worked" or "I had to research postgres' MVCC implementation" to something as nontechnical as "I had to schedule a meeting across 10 different departments and get agreement on changing an internal process."

Coding challenges are just one piece of the puzzle. I've previously made hires who were great at the coding part but gave weak answers to situational questions and they ended up not working out; they were excellent coders but would never really push anything forward beyond whatever tickets were assigned to them. By that I don't mean "they didn't work 60 hours a week," I mean that they never wanted to take the time to think about the current state of how things were done and come up with ways to improve the situation. This type of developer would probably be fine in a larger organization, but when you're hiring a senior dev for your 20-person startup, a hire like this can be a disaster.