
Is “Hiring only the Best” a really Practical Advice? - nsoonhui
http://programmers.stackexchange.com/q/72336/468
======
dwc
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?

~~~
joe_the_user
A good engineer isn't one who designs a building with the thickest walls
possible but with walls having appropriate thickness.

And generally, I don't think everyone at the top of their field necessarily
gives the advise to use the absolute best tools and materials. A lot would
instead give the advise to use _appropriate_ tools and materials. A lot of
good programmers can recognize that a quick but inefficient VB script can do
better.

~~~
jamesbritt
_A lot of good programmers can recognize that a quick but inefficient VB
script can do better._

Quite so. Some "best practices" only earn their keep once they become
ingrained and automatic. Prior to that there's additional cost that only makes
sense when amortized over a long enough time. If there's no real reason to
expect that payoff then there's no good reason to make that extra effort.

------
onan_barbarian
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'.

~~~
xiaoma
The main takeaway I got from Joel's essay was that companies _whose focus is
software_ need to hire better programmers. Maybe the 99th percentile is
extreme and it should have been 9th. But it isn't difficult for me to imagine
that the vast majority of programmers work at companies whose focus isn't
software, and whose work is mostly things like connecting to legacy telcom
systems. That vast majority of programming work doesn't need to be done by
crack teams of algorithm gurus.

If your company is working in something more performance bound, such as CG
animation, then you probably _do_ need top programmers. Salary won't be the
only way to get them, though. People with a true love of CS probably get bored
with all the database driven CRUD apps.

------
CoffeeDregs
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.

~~~
samuel
I agree with this. Having A-players, recognized and respected as such may get
the best of everyone. Lots of very capable people simply have had the bad luck
of reaching teams without this kind of references and never were forced out of
their "comfort zone". It's shocking when, having formed a great concept of
yourself after years of practicing your craft, suddenly you find someone that
outsmarts you in such a massive way.

------
acgourley
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.

------
snorkel
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.

~~~
rickmb
That's what I consider "the best", but unfortunately that kind of
professionalism even rarer than the "superstar" programmer. Which is very
unfortunate should you manage to hire one of those "superstars", since they
need at least three of those guys to clean up after them...

~~~
neilc
A "superstar programmer" that doesn't "write clean, readable code, with
comments, error checks, clear log messages, and tests" is simply not a
"superstar programmer."

------
shr30
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.

------
lichichen
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>

------
bugsy
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.

------
silverlake
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!

------
josefrichter
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.

------
capstone
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.

~~~
leftnode
If you've ever dealt with code that Gets Things Done but is not Smart, you'll
know why it's in the title. There are a million ways to skin a cat with
programming, and you can pick a stupid(er) way or a smart(er) way. I'd much
rather work with the person(s) who pick the smart(er) way.

The "perfect code" part of your comment above implies smartness. Dumb people
don't write "perfect code".

~~~
Luyt
That reminds me I once came along code written like this:

    
    
      function MakePrintable(nr as Int) 
      {
        Str as string
        if nr=1 then Str="1"
        if nr=2 then Str="2"
        if nr=3 then Str="3"
        ...
        if nr=27 then Str="27"
        if nr=28 then Str="28"
        if nr=29 then Str="29"
        return Str
      }
    

This code worked in the program it was used in (it Got Things Done), but in a
dumb way (lazy? ignorant?).

I admit this is a rather extreme example, but it provokes the universal
feeling when you look at gravely suboptimal code: "What did the programmer
think when he wrote this? Didn't he know that ...., it's so obvious!"

~~~
chopsueyar
Buffer Overflow Exploit Prevention?

------
risotto
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.

------
StavrosK
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...

~~~
arctangent
There are two main problems:

(1) Who will you learn from? Successively hiring only people equal to or less
than the current skill level within the company inevitably leads to a gradual
lessening of talent within the company.

(2) How will you stop the talented staff leaving? By hiring untalented people
you shift more work onto the most talented. Since they also probably don't
want to work in a place that is known for hiring people without talent they're
going to be very likely to leave. This will exacerbate the brain drain within
your company.

~~~
StavrosK
Oh, I'm not saying this a good way to aquire all your devs. Sometimes, though,
if you just need to hire one extra person to write tests or do some
supplemental work for the main devs, a rockstar is overkill.

~~~
arctangent
In that case I agree with you completely :-)

------
Duff
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.

------
danielrhodes
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.

------
kstenerud
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!).

------
saalweachter
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.

------
ksolanki
"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.

------
geekam
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.

------
gersh
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.

------
neuroelectronic
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.

------
georgieporgie
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.

------
kabdib
"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.

