3 ms·
There is often a lot of criticism of "learning by rote" and often the blanket rebuttal is "we all have access to Google" etc. however there is a very big differ
by lbriner 4y ago
There is often a lot of criticism of "learning by rote" and often the blanket rebuttal is "we all have access to Google" etc. however there is a very big difference between someone who knows something and someone who has to look it up, which is why I will never accept a job candidate who will "learn what they need to learn".
How long would an experienced dev honestly take to learn a mid-level amount about e.g. Kubernetes or Go or Rust? at least months and months of common usage, not something that is comparable with someone who already knows stuff and can get cracking on day one and already avoid lots of the footguns that exist in our industry that you normally only learn the hard way.
Let's stop pretending that the internet is a replacement for education, in most cases it is far too unstructured, which is why people still take courses and why education and school still exists.
- urschrei 4y ago> an experienced dev honestly take to learn a mid-level amount about e.g. Kubernetes or Go or Rust? at least months and months of common usage, not something that is comparable with someone who already knows stuff and can get cracking on day one I'm not sure how this is relevant? You seem to be trying to make a point about hiring people with specific skills vs candidates with proven ability in the field, broadly speaking, before committing an apparent non-sequitur in which someone (it's not clear who) is "pretending that the internet is a replacement for education". Do you often interview candidates who learned K8s (or Rust!) as part of their education? I assume (given your apparent strong feelings on the issue) that you have some familiarity with CS curricula, but perhaps not. As a related issue, you're certainly sending a strong signal to the candidates you're hoping to attract, judging by your profile. Whether it's a positive one is left as an exercise for the reader.
- trashtester 4y ago> 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.