Just to play devil's advocate, there is also the type of person who tends to get stuck down rabbit holes more than they should. There's a skill not just to solving problems but avoiding them in the first place. Usually this requires not just engineering talent but the ability to see the bigger picture, in terms of product and business goals. If someone is banging their head against the wall, it may be because they are trying to solve a necessary difficult problem and are discovering valuable knowledge, or it could be because they are foolishing running into a wall that they could easily go around if they stepped back for a second and considered what they had set out to do in the first place.
In your race condition example, it would be the difference between an engineer debugging a race condition in mission critical code, and debugging one that is incidental complexity in a unit test or ancillary tool that could be refactored to be single threaded, or just omitted altogether. Heck, even in the mission critical code case, it's worth considering how many users it effects, how it effects them, and at every moment considering if the time spent so far on the problem (and its associated opportunity cost) is still justified. (Taking into account the fixed costs of switching context into the problem again.) It's very easy to get wrapped up in an interesting problem and forget about the eject button.