Almost universally, the answer is "asker".
For non-core engineering/science roles, the "hacker" simply isn't an option. You cannot "hack" business development - there isn't documentation about clients, for example, that would allow someone to work out anything meaningful without asking. You cannot "hack" management, because that's a relationship role, and if you're not forming relationships by asking questions and interacting with people then you're on course to fail.
Basically, you won't be able to "hack" non-engineering roles, because there isn't the documentation to "hack" it.
So the only role where the "hacker" is viable is a core engineering/science role. Note the "core" - the same restrictions above apply to sales engineering, for example.
Within this narrow band of roles, the only time the "hacker" is potentially better is where it is a sole-worker role. ie you've been hired to work on a problem and you're the only person working on it - eg the only engineer for a small company. Even then, if you're not asking about the business purpose...
For other roles, while there might be code that can be hacked, the business reasons behind the code won't be "hackable". Code only has a purpose when it solves a business problem. The business problem is rarely evident from the code, so the hacker will not be able to contribute meaningfully to solving business problems. Also, by the question, the hacker isn't talking to the business department to find out what they need solved, or if the solution presented really addresses the problem. The mythical "super-genius" who can solve problems perfectly and understand the business perfectly is exactly that - mythical.
Also, asking how to solve problems isn't "essentially getting others to do the work and tying up other's time in the process". It's forming relationships with your peers, it can involve pair-programming, and it is a much much faster way of learning than just sitting looking at code on your own. Nobody learns faster in isolation.
Asking stops wasted time and effort solving the wrong problem, or solving a problem that has already been solved elsewhere. Please be the asker, not the hacker. Companies like askers, not hackers.
The only time a hacker is potentially better is for a solo-development role.