[inputvolch]

Those were the only `hard` skills they could come up with? This reads like someone who is trying really hard to validate their life decision to spend many, many years in higher education.

I mean:

> we still say (and write) things such as ‘heuristics’, ‘confirmation bias’ or ‘family-wise error rate’

If you came out of a PhD and think these are challenging concepts to pick up, or that they somehow make you more valuable than your average technical employee, well, I don't know what to tell you.

I generally avoid hiring PhDs onto my teams unless the problem I'm faced with is PRECISELY what they researched. 9 times out of 10 a highly motivated generalist is far more valuable than a PhD.

[barefeg]

Do you have examples of how hiring PhDs can go wrong? I have a similar feeling that generalists are usually better unless the problem is exactly what they studied. But I don’t have number nor stories to back this claim

[rovr138]

I'll only comment on this,

> Do you have examples of how hiring PhDs can go wrong?

Not so much wrong, but there's a curve IMO. This is biased and based on my limited experience.

Writing code or working on production systems sometimes they have trouble working the code bases. They can code, but don't necessarily have developed yet the skills to dig into code. I think everyone has this issue starting. There's also a big difference in code from academia to industry.

Same with problems. We need a solution and a usable one. It doesn't have to be THE theoretical best thing always. It has to work. For example, you can't just not consider constants in complexities in production. Those constants take time.

An example can be Netflix's challenge, https://www.techdirt.com/articles/20120409/03412518422/why-n...

----

I don't necessarily agree with the generalists part. I think we all specialize over time and have some of the same issues changing language or even frameworks. We just don't have or know the best way of doing things within it yet.