

Ask HN: Hiring Decisions - rivo

It is always said that you should hire the best people possible. Let's assume you have two candidates:<p>Candidate A is a great programmer. He is unbelievably fast, very creative, has a lot of knowledge. He sees a problem and has brilliant solutions at hand very quickly. He just gets it. But he is not a team player. He'll go off and do stuff his way without telling anyone. Nobody sees his code before he's done. He hates discussions. He might just ignore any decisions that were made. And you never know if he'll quit tomorrow.<p>Candidate B is not the most creative type. His code is acceptable but you can see his limited experience. He is still good and he certainly gets the job done but there's not much you can learn from him. But he's extremely reliable and very loyal. He's happy with any work that comes along. He's a very good team player. He will give his input but accept decisions once they're made. People enjoy working with him.<p>What would you do? Pass on both of them? Hire A? Hire B? Wait for somebody who is a programmer as A but as reliable as B (and risk waiting forever)? Oh, and let's assume you <i>really</i> need to hire now and can't afford to wait.<p>(Substitute "he" with "she" if you wish.)
======
gcv
It depends. How much do you need the project done? How quickly?

If you will be dead in the market if you don't ship in six weeks, hire A. Let
him work the way you know will make him productive, because your product
depends on it.

If being fast does not matter, if you know that the candidate has to deal with
external clients, if you know that he will have to play politics, then hire B.
Don't expect too much brilliance, but if you don't need fast, you don't need
brilliant.

In a startup, I would hire A and give him an area of responsibility where his
drawbacks will cause fewest problems. In an "enterprise," I would hire B.

------
jerryji
You didn't mention if A documents.

If A does excellent documentation, give him your toughest nut to crack as the
whole team can learn and progress from his contribution even after he is gone.

Otherwise, go for B.

The worst can happen is to hire A, and when he leaves, B has to maintain A's
code with no documentation.

~~~
diN0bot
or A solves the wrong problem in the wrong way and you ultimately are left
with nothing.

at least B is likely to make progress in the right direction. the OP did say
B's solutions were acceptable. if acceptable is true then i see no reason not
to hire B. you get the solution you want with a good teammate who will
eventually be as good as A technically but with a whole bunch of other
goodness.

note that team instability is the largest downfall i've seen in the handful of
MIT startups i've witnessed. it's crucial that people work _together_. i'm
married to my startup partner, so working together is one of the first things
we ironed out. if you're committed to that, then you can give strategy and
execution an non-distracted chance.

------
azanar
I would pass on them both. As desperate as you may be, you need to not give
into it. If you hire either of these people, I suspect you will end up with a
few weeks of comfort before desperation sets in again, and now with an
employee you don't want. This is a harder position than you are in now.

So a little reasoning why I am put off by both:

Candidate A has a huge ego. He knows enough about what he is good at to think
that he knows enough to be good at everything. Whenever he finds he is
mistaken, it will likely be very expensive to you, because he's more likely to
go off into the weeds for months than ask someone else for the knowledge he is
missing. You may get something brilliant on the other end, but the odds aren't
wonderful that it solves the problem you have -- just the problem he _thinks_
you have. Whatever impeccable domain knowledge he does have won't rub off of
anyone else, because he's never talking to anyone else. You also run the risk
of him becoming extremely bored and leaving. This sounds like a bad deal.

Candidate B is everything candidate A is not, both good and bad; candidate B
sounds like a doormat, but a friendly and gregarious one. He sounds like the
typical career programmer: learns what they need to know to stay hired, but
not much else; does what they need to do to stay hired, but not much else; and
makes sure people would feel like they are firing a friend if they ever need
to fire him. If all you need is someone to bang out acceptable code according
to someone else's specification, and otherwise shut up and keep ideas outside
of his specific title to himself (or just not have those ideas, since they're
not his business anyway), this might be your guy. However, if you want someone
who will be thinking and throwing around ideas outside of his specific set of
duties, this candidate may be a drag on the team.

One thing you didn't clarify in your definition of B: when he gives his input,
does it contribute anything useful to the discussion?

But yeah, neither sound wonderful. But which concerns are a bigger deal
depends on what role the person will fill. It's probable that one or the other
will look more attractive once you start thinking more specifically to the
position being hired for, and less about the generic cookie cutter programming
position.

~~~
garnet7
> I would pass on them both.

What? C'mon. You gotta give people a chance. Not everyone is going to fit into
your expectations of the perfect employee.

~~~
dcminter
[http://www.joelonsoftware.com/articles/GuerrillaInterviewing...](http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html)

'Never say "Maybe, I can’t tell." If you can’t tell, that means No Hire. It’s
really easier than you’d think. Can’t tell? Just say no! If you are on the
fence, that means No Hire. Never say, "Well, Hire, I guess, but I’m a little
bit concerned about…" That’s a No Hire as well. Mechanically translate all the
waffling to "no" and you’ll be all right.' -- from 'The Guerilla Guide to
Interviewing' (linked above)

------
sofal
The big question is: does B have a thirst for learning and improving himself?
I have seen a lot of type B people in a big corporate environment. They make
good corporate team players and good friends. They put their head down and do
whatever they're commanded to do, but they don't try to stretch themselves.
They stick to whatever has been beaten into them and don't question anything.
They don't learn anything new until it is mandatory. In short, they are a
perfect fit for where they are. If you're hiring for a big corporation, this
is a no-brainer.

But don't assume that since he is happy and loyal that he is teachable. On the
other hand, if all he lacks is experience, then there's a chance he might be
good long-term.

------
far33d
Only hire A if he completely loves what you are building. If he thinks he is
"above" your real problems he'll be brilliantly, independently kicking ass at
something that you didn't ask him to do and isn't helping you succeed at all.
Worst case, they'll actually make it worse, since he might build complicated
systems you will have to work around.

Only hire B if they would rather jump off a cliff than come in late on a
project or be a missing link. In a startup, finishing is of utmost importance.
Also, only hire if he is motivated to learn. Mediocre people who work hard but
aren't interested in learning new things are pretty dangerous as well.

------
jacquesm
Hire B.

Skills can be learned, it will take some time but if someone is a real team
player he'll make the effort.

Attitude is a lot harder to change than skill.

~~~
jbellis
> Attitude is a lot harder to change than skill.

Disagree. _Both_ are hard to change. Don't hire a B expecting that practice
and mentoring will make him a prodigy.

~~~
jacquesm
So what if he's not going to be a prodigy ? There is very little application
level code that requires prodigy level coders.

I've also been a boss, hiring both 'A's and 'B's. The 'B's worked out fine
over time, all the 'A's caused more trouble than their skills ever made up
for. Maybe I was unlucky, who knows.

Managing programmers has been compared to herding cats, for continuity reasons
it is usually a very safe bet to get people on board that are not in the
'artiste' class because your company is a multi-year project and prima donnas
have a very bad record when it comes to staying the course.

They also absolutely loathe to maintain their own code.

Unless your project is something one guy can do, is something that you don't
plan to maintain long term get a steady performer.

------
jerf
Well, I made sure to scroll through, but this hasn't been said much yet: You
have not provided enough information to answer the question.

Every programmer has different skillsets. It is important to match programmer
skillsets to their jobs. (Anything that you might object to about that
statement, I would consider part of the "matching"; for instance, I can and do
match "what the programmer should be learning" to the job too.)

Both A and B here have their place; what you haven't described is the type of
work you need done. Are you an early phase startup where this is going to be
one of two or three critical guys, and working on intensely technical stuff
that will be the foundation of the company? Are you a medium-sized company
with a lot of grunt programming work that needs to be done competently, but
without the need for a lot of creativity and experience? Hopefully it's
obvious how I've stacked the deck on those two descriptions, and more likely
it's something in between. What is it?

This is the first question to answer before you can answer the "whom should I
hire?" question. It is likely that once you answer this question, the choice
will be obvious.

~~~
rivo
This is HN so I assumed an early startup environment. But of course as the
startup grows, this will change. So I'm also looking at it long-term.

------
ph0rque
_[Candidate B]... is very loyal._

Apologies for going on a tangential rant, but why is it that employees are
expected to be loyal to companies, but companies can lay off employees on less
than a day’s notice? This is something that angers me.

I told my current company that my loyalties to the company will be symmetric
to their loyalties to me. Surprisingly, I still got hired.

------
sunir
Candidate A is unhireable. Programming is more about communicating with people
than machines, and I say this even as a former embedded systems programmer.
I've worked with A's before and they are A-holes.

Candidate B is very hireable, but only in the context of an established team
with functioning leadership--both technical and business--as well as people
who can help them develop their skills and career further. That is, I would
hire them into a team, but not to start a team. They are clearly happiest when
other people are making decisions, which is actually amazing when you have
decisionmakers in place.

That being said, I take the view that whomever you hire you are married to.
That is a two way street. You are stuck with them whether they are good or
bad, and you are responsible for their success as well. If you hire the
A-hole, then you'll regret it. If you hire Candidate B but into a situation
where they will fail, you're doing everyone a disservice.

Just with marriage, wait until you found a good match.

------
andrewf
If you _really_ need to hire now, then you've got something that needs doing
right away. Can Candidate B do it?

------
joechung
False dichotomy. Don't hire either. Keep looking.

~~~
berntb
I don't know where you are, but how many "A":s will you have the possibility
to hire in a given year?

Edit: I liked byrneseyeview's idea of giving A incentives to care about the
success of the team.

------
alex_c
One meta-observation: given the emphasis in Valley (and YC) startups on
"rockstar hackers", I am surprised that most replies so far tend to favor
candidate B.

Maybe it's because the PST workday is just starting and the advice so far is
more east-coast :p

------
jgrahamc
Do not hire A. I don't care how good the a-hole programmer is it doesn't
matter.

I have worked with many and they are not worth the strain.

~~~
bhousel
Ouch... One thing I took from this post is that I came to the realization that
I might be an A. It describes me pretty well except that I won't "ignore any
decisions that were made." (If a decision is _that_ bad, I will at least say
so and let them see it through as a learning experience.)

Still, I don't think I'm an a-hole. I really do get along with everybody, and
try to add value and contribute to any place that I work. I just don't think
that there are previous employers out there cursing me out because I was too
much trouble.

Are you sure that A == a-hole? (This is probably going to bother me all day)

~~~
jacquesm
It very much depends on how you go about it.

I fit the 'A' category (so effectively I'm telling people to never hire me ;)
), over time I've gotten better at communication and I work better together
with others now than in the past, but there is still a lot to be solved.

The best spots to 'plug me in' are when everybody else is ready to give up and
it's a real challenge, or when I can write tools for others. (or under extreme
stress). Those are the times when I thrive. If you want me to do the front-end
of your web-app together with 5 others then please look somewhere else.

Whether or not A is an asshole is a call you can't make with the information
given, it's perfectly possible to not be a team player and not be an asshole
at the same time, if someone ignores decisions that were made then maybe that
indicates they're working for the wrong boss or at the wrong level.

------
tom_b
Perhaps you should start by altering your definitions - to be a great
programmer or hacker requires the ability to work with others and explain
yourself coherently. So candidate A is not really a great programmer.

I think you have to keep looking for candidates or assess why you haven't had
better candidates apply. Hackers should be hired based on examples of previous
accomplishments that they can explain to you.

I'll spare everybody the long rant I originally had planned . . . maybe I'll
follow up sometime with my own Ask HN if my thoughts come together.

------
radu_floricica
My limited experience involved exactly this situation. The biggest problem
with A (when he left) was that we ended up with a larger then necessary, very
smart, un-maintenable app instead of the simple hack we actually needed.
Because if was obviously smart we kept dragging it, when we should have
scrapped it the day he left and rewrite from scratch a simpler one.

edit: B on the other hand progressed steadily for a couple of years and wrote
a whole lot of code still in production. Needed debugging and refactoring but
lives.

------
byrneseyeview
Hire A, with lots of options and long-term vesting. Successful companies are
full of smart weirdos.

~~~
jacquesm
If A is motivated by money then that might work, but not everybody is
motivated that way.

But the principle may hold true regardless of the method of rewarding.

~~~
byrneseyeview
Yeah, unfortunately it's very hard to provide praise, or technical challenges,
with vesting:

" _Great job!_ Is what I'll tell you about the project you just finished. But
only if you're still here in two years!"

The nice thing about money is that it's so easy to fiddle around with it to
get the incentives right. But I agree -- this doesn't work if the person
you're dealing with isn't strongly motivated by money.

------
sos3
From experience: hire the team player.

I hired several top programmers, they wrote good code but lived in another
dimension or even universe. They were no fun to have around.

------
edw519
Hire Candidate B. He's almost perfect. He has all the things going for him
that are difficult or impossible to change in another person (reliable, loyal,
happy, team player, accepts decision, enjoy). His biggest weaknesses are in
exactly those areas (not the most creative, limited experience) that make him
teachable, and of course, you're a great teacher. (If you're not a great
teacher, you're in the wrong business).

Candidate A is problematic. You will have difficulty changing anything about
him, especially those areas which are most important to change.

Have an urgent project that requires Candidate A's assets? Contract him to do
that project and have Candidate B make it "repository worthy". Include in
Candidates A's contract the requirement that you ascertain that Candidate B
will be able to maintain Candidate A's work before payment. Candidate A does
great creative work, Candidate B learns something new, you have a cohesive
team, an emergency resource, and maintainable code, and your project comes in
on time. Everybody wins.

~~~
swombat
I completely disagree.

Brilliant people are often hard to work with (they tend to be opinionated,
want to do their own thing, etc), but I'd much rather work with someone who's
brilliant and hard to work with than someone who follows orders but is just
average.

For a start-up in particular, you find yourself relying on your early people's
brilliance to make the impossible happen. Normal, easy to handle people rarely
produce exceptional stuff.

 _His biggest weaknesses are in exactly those areas (not the most creative,
limited experience) that make him teachable_

I couldn't disagree more. You can't teach brilliance. You can teach (or
manage) teamwork issues.

~~~
jacquesm
> You can teach (or manage) teamwork issues.

That's completely opposite of my experience. My experience is rather limited
(2 companies, 10 people in one, 15 in the other) so maybe that is a factor
here, but I've _never_ been able to make a loner a team player and I've
managed to assist people to improve their skills with great regularity.

Brilliance is not a requirement for every job out there, it may be a help to
have it, it may even be a hindrance.

------
zjj
Hire one A every n B.

------
rgrieselhuber
It kind of depends on the stage. If it's you and A and you're creating the
first version of something awesome, he can be good to have. If you're at a
later stage of product maturity and you can use less-skilled people in simple
ways to create something complex a la emergence, then this might be a good
candidate.

I personally wouldn't hire either one.

------
ErrantX
Hire B. He might well have unplumbed depth's of creativity you didn't get to
see in the interview process. Even if they don't they are at least good team
people.

On the other hand if your "problem" requires highly creative and "thoughtful"
solutions then your going to have to risk A :)

The position your filling is one of the most important aspects.

------
pg
Incidentally, if you're funding rather than hiring, you generally want A.
That's one reason I'd rather be an investor than a boss.

------
tjic
A has his problems, and I'm not sure that I'd hire him...

but here's something to think about:

If you hire A, the next person that you interview will see A and think "there
are geniuses here".

If you hire B, the next person that you interview will see B and think "there
are mediocre players here".

Of course, there's a third option: defer hiring until you find the perfect
guy.

I will note that I once hired a guy so good that on his first day I knew he'd
be leaving soon. He stuck around for a year and left. I don't blame him - he
got a much better deal - one so good that I couldn't match it. I got a ton of
great work out of him in that year though, so I'm still glad I did it.

------
known

        A for programming the system
        B for maintaining the system

------
jlees
I think it depends on your current situation. If you just need to get some
code written, hire B, assuming you can cope with getting B up to scratch to
write said code. If you're earlier stage -- you need to brainstorm, to _have_
those tangents, that little spark of something-else -- hire A. Give her 20% of
her time her own, and watch magic happen.

Disclaimer: I'm totally an A (although probably with more randomness and less
skill), so I might be biased.

------
MaysonL
It depends on what jobs you are looking to fill.

If you have problems that _need_ brilliant solutions, A sounds like (s)he
might be a fit.

If your problems are more mundane, and need lots of communication between team
members, B could be better.

A would probably fit better into a research establishment (think Bell Labs,
PARC, Microsoft Research, etc.), B into a commercial IT or software company
which is in upgrade release mode.

------
bhousel
I wonder if there are really ways to know this much about the candidates
before you hire them. Aside from knowing or working with them personally.

------
brk
Most suggestions would trend toward B. However, you have to take your short
and long-term goals into consideration.

This may seem harsh, but you are not making a life-long decision. You could
hire A to meet some tactical short-term goal, and then actually fire them and
hire B (or a parallel of B).

I couldn't make a suggestion for you without understanding the tasks and goals
at hand.

------
ckopec
If you have the time to wait and find the right person I wouldn't hire either.
Part of working as a team is that each is able to contribute and improve the
others. From your brief descriptions B is too unskilled and will slow down the
others on the team and A may get his work completed but Isn't improving the
rest of the team in any way.

------
stonemetal
Hire B he gets the job done and isn't creative. That means other people are
going to be able to work on his code if and when he leaves or you just need to
hire another developer. You really have to worry when people decide to get
creative with your code base especially when a straight forward solution
exists.

------
thenduks
Based on the assumption that you _really_ need to hire now and can't wait
(which I find unlikely, I believe it's always better to have no one than
'anyone'), candidate B. At least they can be a solid member of the team, if
not a superstar. Candidate A is just trouble waiting to happen.

------
elblanco
B. Better long-term prospects. Unless it's a consultant, no employee should be
viewed as short-term.

------
gte910h
I wouldn't hire either of those.

If your A isn't able to hold intense discussions and sometimes lose, he's
useless.

And B is useless in a startup as well. He's at the earliest employee 11 or 15.

------
kingkawn
B will support you or you will support A. Choose what you prefer.

------
startupdude
Why do think A will quit? You dint keep him happy? Its a tendency of great
hackers to quit if they throw crap at them. Remember programmers never quit
when they are happy.

------
herval
"hire for the personal values, train for skills". Skills are easy to acquire -
changing someone's attitude is not...

------
wlievens
Cat vs Dog? Is life really that black-and-white?

------
juvenn
B

------
gcb
it seems you are already working with both. so it's not a hiring decision.

Keep A and learn how to motivate him. it's more effective then keeping B and
making him smarter.

~~~
jownz
I was thinking the same thing! I wonder if the asker ever thought to talk to
the A? Maybe he's ticked off because he's had to fix countless careless bugs
produced by the 'B's for the past year? Maybe his salary isn't up to par?
Maybe he's not pleased with architectural decisions? Maybe his 'nix box was
pwned last night? The best way to fix an A is to talk to them. A happy A is
worth 10 'B's. 'B's produce redundant and infuriating sloppy code. Most 'A's
are self-taught for the most part and they play very well with people on their
level.

