Is “Hiring only the Best” a really Practical Advice?

This comes up pretty often. Here's a sentiment that is often present:

    I heard that to get excellent results I should do X,
    but I don't see a really painless and trivial way to
    do X. X doesn't seem practical.

When I work with non-coders to help them with their scripts or whatever, I commonly see all kinds of things that should be done better: simplify this, refactor that, etc. I have learned the payoffs for doing things the right way, and I try to pass some of these things on. Usually the response is "I understand. That would be a better approach." but then they go back to their old ways. They just want to get the immediate thing working and move on.

It's not at all surprising that advice from smart people with a lot of experience seems like a lot of work to those of us just trying to get today's problem solved. But take a step back and look at anyone working at the top of their field and you'll find them doing lots of things that are hard, involving doing things right rather than just getting a task crossed off the list.

"Wow, that chef keeps everything spotless and sharpens his knife a lot, and only uses the best ingredients."

"That master carpenter sure spends a lot of time caring for tools and doing a lot of other things that aren't cutting wood."

Why should hiring coders be any different, unless you believe that coders are a commodity?

The terms of this debate often seem wildly 'provincial' for want of a better word. 99% of the people yammering on about 'hiring the best' don't operate companies that could hire the actual 'best' under _any_ circumstances.

Unless you can offer some combination of industry-leading salaries, major prestige, the opportunity to publish and/or work on their own stuff (if that's what people want), etc. you're not getting the best. Maybe very, very good. But not 'the best'. If you're not hiring for a Tier 1 research university or Google or Microsoft Research (in a different era), or paying massive salaries in the financials, ... think about it.

This isn't simply snark. As long as people aren't getting to hire Thompson or Knuth or Lampson or whoever, they are in fact making compromises of sorts and should be thinking hard about what those compromises mean, rather than just proclaiming that they only hire the 'best of the best'.

In my experience, it's critical to hire a great "anchor team". Thereafter, the hires become a little less critical. The worst work situations I've seen or been involved with had a weak anchor team. There's an expression that "'A' players hire 'A' players and 'B' players hire 'C' players" and that's definitely true in small organizations. For larger organizations and the reason I think the anchor team is so crucial is that an 'A' anchor team can make 'B' players play like 'A-' players and 'C' players play like 'B' players. The infrastructure, thinking and processes put in place by 'A' players can make other less capable players much more comfortable and productive. Make sure your team is supportive of all members and everyone will be better as they play up to the high quality of the other members (when playing sports, I always play better when playing against people who're better than I am).

That said, it's certainly a matter of focusing the anchor team on putting in place excellent practices. Huge problems can still occur if you have a great anchor team but they focus only on solving their own particular problem. You wind up with the best authentication system ever and a broken payment system or with the most incredible sales pipeline ever and technology that doesn't match what was sold.

Clearly, "hire only the best" is impossible for every company and business model. Also, clearly, this discussion is mostly about capability, knowledge, etc; fit with the organization must always be superb.

These discussions often rank all hires from 1%-100% as if they all fit on one dimension. That is an unfortunate simplification.

I don't know what the right classification system is, but it's certainly more complex. For example, teams can tolerate a certain amount of new-but-promising talent, as long as they have guidance from experienced programmers. In fact that balance is important. Secondly you need people who can work together effectively. Both of these ideas indicated that you can only evaluate a hire in the context of the team they are joining. So arguments that "you can never hire the top 1%" add nothing to the conversation.

What I've found to be more valuable than the superstar programmer is the competent coder that writes clean, readable code, with comments, error checks, clear log messages, and tests. When one coder interviews another simply ask to see a sample of code they've written, any code, and then decide if they have a coding style you can work with. Once a coder is part of team of competent coders who are engaged with the project you then can use code reviews to help each other improve.

There are un-fun things to work on in life and if you are going to hire a "non-superstar" and have them work on a non-critical part of your company, it's not that bad.

If someone has a outside passion - say sailing and wants to just get a job to help them pursue it, more power to them if you can adequately utilize the talents in 30-40 hours versus a powerhouse 90 hr die-hard talent.

Personally, I find fulfillment in my 40-80 hr "day" job and then go pursue other fun activities; a lot of my (especially engineering - non-cs/ee) friends want a 30-40 hr job and some play power, others trade stocks, others play sports rabidly every evening - you must respect the personal motivations and find a way to align it with your organization / startup, if you cannot, then yeah, it's done.

There are a lot more factors to look into other than the level of proficiency in programming: I would hire a so-so programmer who have room to grow in addition to being able to follow directions and schedule over any super star.

Related article : Are smart people overrated? - Malcolm Gladwell http://www.gladwell.com/2002/2002_07_22_a_talent.htm

There is a huge problem with the linked article. He asks the rhetorical question: "is hiring only the best practical" for every situation. The answer is of course no, you can get by with competent or very competent and don't need the absolute best in a field, which few can afford.

But the question asked is a giant red herring that has nothing to do with his stated problem!

His actual situation, as he explains, is not that he is trying to choose between the best and the merely excellent. He is trying to choose between the completely incompetent (the only applicants he has) and no one!

That is an entirely different problem from deciding whether or not to hire the very best.

I know of an investment bank that explicitly avoids hiring "overqualified" devs. They don't want someone rocking the boat. They just want drones in the back office IT dept, for whom they pay 2X the market rates. Geniuses!

Obviously not always. It's like in football. Often better get someone with potential and turn him into star.

+ every company needs B-players as well. Nothing wrong not being top notch hacker but rather a reliable loyal worker.

There is one big problem with JS's paradigm of Smart and Gets Things Done that I never see addressed. It's right there in the title. If a programmer Gets Things Done, what does Smart add to the equation? Say you have a cat who habitually walks all over your keyboard and bangs out perfect code, every time. Do you really care?

No one would praise a program that takes 2 steps to do something that can be done in 1 step. So why does Smart and Gets Things Done get so much credit? I'd understand Gets Things Done and Gets Along much better.

Hiring only the best is impractical unless you are Google and can pay the best for the best.

A much more practical strategy: hire people that can learn, and train them in best practices.

I don't see why you always have to hire better people than you, or people at least as good as you. If you don't mind people taking some time to learn, you can just hire good problem solvers and let them learn as they work...

It's a great thing to say, because how can anyone argue about hiring the best people?

The problem is, the statement is rhetorical, there is no "best" -- a superstar in a big bureaucratic organization might be someone who "gets" process and following through on certain things. In a startup or other type of company, there are attributes separating "best" from the rest. The process superstar from MegaCorp might destroy a startup!

At the end of the day, management adds value when they take a bunch of people with a base level of knowledge and helps them deliver whatever the product is that is being developed. The trick is finding folks with good work ethics who have the base level of knowledge that you need. There's no magic.

Clearly it's not practical advice. It's simply a reminder that just because the person can code does not mean they are worth hiring. For a lot of founders, they are under such pressure to produce output, the mere indication that a person wants to help them do that makes them not want to pass up the opportunity.

Startups have a hard time hiring because the benefits are not as solid as a large company, there is almost always not enough bandwidth to weed out the ridiculous number of bad candidates, and there are rarely hiring processes in place. However, for a smallish startup, hiring a bad person can literally ruin the company.

There are a lot more variables when hiring a person for a startup. For example, is there a strong cultural fit, is the person financially stable enough, is the person technically competent in the areas that need competence and able to learn new things, is he/she willing to spend what many regard to be extreme hours working and sacrifice normal aspects of their life, can he/she work quickly and also not cause friction, etc. Nobody is perfect and a lot of people simply don't prioritize their job or life this way, which is totally fine, but it's much harder for a startup to absorb those differences in the same way that a large company can. Therefore, there needs to be an emphasis on hiring the absolute best candidate you can find.

To translate this into practical advice: take a long time to hire a person (don't rush), only do so if you are absolutely sure that you want to hire a person, and even then hire them on a contract-to-hire basis, and be quick to let them go if things are not going smoothly.

For companies:

Hire the absolute best you can find. Your goal should be to find people who are better than you at what you do. You need to hit every source of talent and try your damn best to get the best. Failing that, settle for someone who is only as good as you are. This is monumentally important with your first 4-5 hires as it sets the bar and sets the culture.

For job seekers:

They are interviewing you, but YOU are also interviewing THEM. If you are not passionate about what they are doing, it's probably not a good fit. If they are unwilling to listen to you give a better solution than the one they thought of, there's probably something wrong with their culture. If they are offended that you found a bug in their code or test, that's a huge red flag already.

Now, in big companies you can get away with coasting along, working as a simple code monkey. If that's what you want (not saying it's a bad thing), then you need neither passion nor aptitude to get a decent wage working an easy job.

If, however, you crave something bigger and more rewarding, you need to seek out companies that are passionate about the same things you are. In a market as hot as this one, there are a LOT of passionate companies looking for talented people (especially startups!).

I think this is inherited from the mathematical side of computer science. In mathematics, there's a strong sense -- and it's even true to some degree -- that all progress across the history of mathematics rests on the shoulders of a few great mathematicians, prodigies.

But you are not a computer scientist. You are a software engineer.

The accomplishments of engineering are not built on the inspired work of a handful of geniuses. They are built on the careful toil of tens -- hundreds -- of thousands of good enough engineers. Every day you use dozens of pieces of software and hundreds of real world objects designed by an endless army of good enough engineers. Engineering is not like mathematics. You don't create timeless works which will be a monument to your greatness for all time. You create something which will be serviceable for a few years, and then replaced. Even if you are perfect, the best, and create the best possible program or device, the world changes around you and your device is no longer needed or new computers change the constraints and let you write an even better program than was previously possible.

"Superstar" programming is a function of the talent as well as the environment. The standards set by the team during one's formative years has a lot of bearing on his/her eventual superstardom. I tend to look for motivation and willingness to learn, in addition to smartness and ability to get things done.

My comment to the most voted answer:

I think that as an 'interviewee' things are not on your side to begin with. You are the underdog, no matter what the interviewer or the company which is interviewing claims. Esp. the new graduates are nervous. I think @Developer Art at least gave an alternate solution in his interview, most folks will find it easier to accept what interviewer said.

Are your people better than the competition? If your competitors have great engineers, you may top talent to compete. If it is some forgotten nitch, you may be able to get away with less.

Get the right person for a job. No reason to hire a MIT graduate to architect your MySQL DB for 1,000 customers a month.

These types of articles seem absurdly generic, given the wide range of software complexity.

Like with everything else in life, get the best value for money. Sometimes the Porsche is exactly what you need. Other times, the Honda Civic is better for your requirements.

"A" people hire "B" people.

"B" people hire "C" people, and you are doomed.

Hire the best you can. Wait. Hiring the wrong person (and I have done this) will be the worst possible thing you can do.