> I will never accept a job candidate who will "learn what they need to learn".
That's funny, because I would say the opposite, if they do NOT, "learn what they need to learn", I would find it problematic.
I'm not a Java programmer, but it happens regularly that when java programmer truly get stuck, I go through their code and find the bugs, learning what I need to learn on the fly. Let's say they're having problem with network connectivity, I can learn how that should be done, reason about fault tolerance and teach myself how to look at the traffic in wireshark.
I'm not a infrastructure operations person, but if there are strange behavior in the trace, I can sit down with those who are, understand the network topology, and understand where and why the tcp connection may have issues, teaching myself what I need as I go.
Then I bring the network person and app developer together, go through the findings, explain to the developer what this looks at from the network side and explain to the network infra person what that means for the programmer. If there are some kinds of network instability that is irreducible, I can show the developer design patters that ensure that the code he's writing is resilient to that kind of problem.
I'm also not a Data Scientist, but when the Data Scientists are having problems, I can sit down and look at their problem, learn about the methods they're using, find patterns they did not see, prerequisites that were not met, or find errors in their math.
The key is to have both deep and broad knowledge of the basics of the technical
and mathematical fields. THOSE I do mostly know pretty well, from half a lifetime of being curious and taking the time to really understand things, instead of just memorize them. If you know the foundations well enough, learning a given application can be learned very quickly.