There's one thing this article misses, and one thing I totally disagree on.
Hiring for prior experience - the author emphasizes this, and based on my experience this should be de-weighted. The issue is that as soon as you start to define an area of experience, your hiring pool shrinks dramatically. Consequently you are more likely to pick a less powerful engineer. Another, bigger downside here is that companies are terrible at figuring out what they really need. Consequently you've hired someone who can do A and B but one month in you realize that the thing you were missing is really C. A less powerful engineer will have a harder time transitioning over to doing C work, and you'll be worse off. Moreover they might be upset - they came in with the expectation of doing A & B, and they're sitting here doing something unrelated instead. Can't count the number of times I've seen this happen, to both the employee's and company's detriment.
The thing that this article misses is how to avoid hiring jerks. Terrible employees can be a net negative to a company. Jerks, particularly those in senior positions, are the thermonuclear version of terrible employees. They can demotivate and destroy the productivity of entire teams and cause your best engineers to rage-quit. The best interviewing tactic I've seen to weed out these people is watching how someone behaves when you "play dumb" in an interview. See if they're happy to explain something to you, or if they get impatient with your lack of knowledge. A related trick is challenging them on something that is obviously correct - see if they carefully prove why their answer is correct, or become antagonistic. Really smart people are good, but much more effective are those that can help bring everyone else up to their level.
Being partly facetious here: I don't know how you actually propose not to hire jerks. The industry is full of jerks. Jerks are doing the interview much of the time. The industry wants people who claim to be the best, and that's hard to do while also selecting for niceness.
Personally, I have a bias against subjects who claim to be the best. Some of the best people I've worked with, would say things like, "Oh, I guess I'm ok at that" and then blow me away. It's the Dunning-Kruger effect [1] in action.
Because of that, I generally avoid people to self-evaluate versus others. I think it's ok to ask them to compare on purely internal things (e.g., "What languages are you strongest in"); people seem pretty good at that.
I think that approach makes it a lot easier to hire nice people; niceness and humility are correlated.
The industry wants people who claim to be the best, and that's hard to do while also selecting for niceness.
Absolutely true. The reason I point this out is that the cost of a jerk goes up as the size of the team he/she is on increases. If you are a 3-man start-up, hiring a superstar coder who's sometimes a PITA can be worthwhile - have them work on some part of the project where they drive the whole thing. At 20 people, that person can become a huge liability - they will misdirect the team, demoralize other engineers, and eventually cause your best people to leave.
My examples illustrate how you might identify people with an uncontrollable mean streak during the candidate process, and hence filter them out. If you're building a scalable organization you must start with founders that aren't jerks and weed these people out of the candidate pool. If you start the company off with such a person, well, either live with it or find a new company.
Great point about not hiring jerks, and those are some excellent ideas about how to avoid it. Having worked with, and currently working with, that kind of jerk I've seen how destructive they can be.
Raw smarts is one thing, and experience with a particular platform/problem space is another, and both are valuable on the job, and both should be weighted in hiring.
Sometimes it's appropriate to hire a brilliant person who's unfamiliar with your problem space, but not often. Sometimes you need an expert who already knows what they're doing and doesn't need to ramp up on the company's dime.
Hiring for prior experience - the author emphasizes this, and based on my experience this should be de-weighted. The issue is that as soon as you start to define an area of experience, your hiring pool shrinks dramatically. Consequently you are more likely to pick a less powerful engineer. Another, bigger downside here is that companies are terrible at figuring out what they really need. Consequently you've hired someone who can do A and B but one month in you realize that the thing you were missing is really C. A less powerful engineer will have a harder time transitioning over to doing C work, and you'll be worse off. Moreover they might be upset - they came in with the expectation of doing A & B, and they're sitting here doing something unrelated instead. Can't count the number of times I've seen this happen, to both the employee's and company's detriment.
The thing that this article misses is how to avoid hiring jerks. Terrible employees can be a net negative to a company. Jerks, particularly those in senior positions, are the thermonuclear version of terrible employees. They can demotivate and destroy the productivity of entire teams and cause your best engineers to rage-quit. The best interviewing tactic I've seen to weed out these people is watching how someone behaves when you "play dumb" in an interview. See if they're happy to explain something to you, or if they get impatient with your lack of knowledge. A related trick is challenging them on something that is obviously correct - see if they carefully prove why their answer is correct, or become antagonistic. Really smart people are good, but much more effective are those that can help bring everyone else up to their level.