It's about understanding if a person is capable of grappling with hard problems, if they can quickly pareto down to the 20% of the part of it that's going to be tricky (big conference -> breakfast -> early morning -> fresh squeezed). Anyone can quote a big top-line number for the whole shebang, but that just tells you they haven't thought it through and any "real" hard problems that materialize are going to be met with last minute, slapped together solutions.
As a mid-career software person, one of the most important things I've recognized is that my trust for my colleagues hinges on them knowing their limits and knowing when and how to escalate hard problems. I don't want to hear about small problems— those they can solve themselves. But they need to know which problems should become a quick slack message, a whiteboard chat, a revisiting of the design doc, or even questioning the fundamentals of the whole project. A person who slaps on duct tape when they should have engaged a war room discussion is someone who ends up needing almost constant supervision.
As a mid-career software person, one of the most important things I've recognized is that my trust for my colleagues hinges on them knowing their limits and knowing when and how to escalate hard problems. I don't want to hear about small problems— those they can solve themselves. But they need to know which problems should become a quick slack message, a whiteboard chat, a revisiting of the design doc, or even questioning the fundamentals of the whole project. A person who slaps on duct tape when they should have engaged a war room discussion is someone who ends up needing almost constant supervision.