Sometimes it's not about the person, it's about the team and environment. I've been both on the competent and not-so-competent sides, and the environment I'm working in made a ton of difference (note: it is a feedback loop, so mistakes and lack of delivery cause your environment to get tougher, and vice-versa).

Perhaps the guy felt he was going to get a raw deal and so was spending the few weeks looking for another job? Who knows. Lots of potential variables that might have turned an otherwise stellar coder into a quivering mess. The plural of anecdote != data.

The fact that someone was recommended by a chain of people doesn't mean that good, or even competent. Perhaps the old CTOs weren't competent to judge or didn't have enough experience to have a proper baseline.

It's quite possible that I could judge someone at some task (say cutting & laying intricate tiles), and think they're quite good. They may seem fast to me because they're doing something that would take me forever. But if you brought in a real professional, they may laugh and say worker is going to slow.

The author said that the coder in question didn't show any improvement after 2 weeks of coaching. The developers at the previous firm he mentioned were slowly improving, that's why he kept them. From my reading I got the impression that if the PhD candidate had improved, he would still be there.

I just had that happen at my company.

New Dev hired by the CEO without input from anyone else. She was not bad, but terribly sloooooooooooooooow. She indeed took 10x longer to do common tasks compared to other devs.

It's not that she wasn't smart or reticent to learn new things, just that her way of working through problems was incredibly long winded for some reason.

It's not something that you can easily re-train someone to fix, it's a fundamental problem and that combined with other issues made us let her go.