Ask HN: Hiring Decisions | Hacker News Reader

Ask HN: Hiring Decisions

24 pointsrivo60 comments

It is always said that you should hire the best people possible. Let's assume you have two candidates:

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.

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.

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 really need to hire now and can't afford to wait.

(Substitute "he" with "she" if you wish.)

View on HN

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.

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.

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.

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.

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

http://www.joelonsoftware.com/articles/GuerrillaInterviewing...

'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)

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.

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.

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.

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

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.

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

I think this is completely wrong. See my reply to edw519 for my reasoning why, but the abstract is that I don't think potential is a constant across the population, or even a subset of the population -- like programmers. Aptitude = effort + potential. A good teacher can help, but won't overcome an incapable student, as much as the student may want to please the teacher.

Attitude is a lot harder to change than skill.

This has been said by a couple of others, and my first thought is really that it depends on exactly what people mean by changing a person's attitude. The theme seems to be that candidate A types are just antagonistic pricks who either want it their way or no way at all.

From the perspective I've gained, it's rarely that simple. When an employee gets branded as having an attitude problem, I'll see as often a problem manager as I will a problem employee.

In the cases of the problem manager, what I'll find is a manager who believes that the hierarchy is as hard as stone, and that employees have absolutely no place to question their judgement or the judgement of those above them. Any employee who might offer any sort of commentary or criticism are immediately branded as an attitude problem, and threatened into submission. The subsequent rebellion may take multiple forms, including them just going off into the weeds without listening to anyone about anything. Immature, perhaps, but in a pot and kettle sense. If you find disrespect going in one direction in a relationship, it's worth seeing if that same disrespect flows in the other direction.

Asserting more absolute authority, which seems to be the most common response, will only make this worse. Not everyone's value judgments are subject to overridding by fear and a desire to please others; I don't think we would want them to be, either.

I think this is mostly an issue of degree, not a boolean one.

Sure, potential is not a constant, but most people can go well above the level they're currently at, all it takes is time and effort.

The manager/employee issue is very true, probably there is a bit of both there, but the bigger issue than manager/employee is employee/other employees. If someone is disruptive to the team he or she is working in then their amazing skills are totally irrelevant.

A skilled person that is also a team player is of course ideal, but if you already know that you are going to be working on a team effort to take someone that would not thrive in that situation would be a mistake.

Managers that only select 'yes men' around them are to be avoided like the plague, no contest there.

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.

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.

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

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.

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

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

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.

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

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.

Agreed

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)

It is implied, but not a given that A is an a-hole. This detail bothered me too. There are a huge number of intangibles needed to actually gauge whether A or B is a better fit.

With such a sparse description of A and B, it seems like many of us are filling in lots of details based on our interpretation of the situation.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

Sometimes following orders is not the correct thing to do and it takes an above average intellect to challenge and to put the brakes on bad decisions.

I am in sharp agreement with swombat.

You have taken candidate B and idealized him much more than I think is fair. You have made him into a fledging version of A, by assuming he can be taught to the roughly same level eventually, but without the attitude. You then offer a backhanded jab by saying if B is unteachable to nearly the level of A, it is the teacher's fault. This is an unfair conclusion to jump to.

A positive attitude and a brilliant teacher aren't all that is needed for training to be successful; you also need a capable and curious student. They have to be able to learn this stuff, and they want learn it for reasons other than pleasing the teacher. Where these qualities aligns, the student is bound to do some learning on their own; unless they elect to learn the exact same things as everyone else, they are bound to have something to teach others. That the OP mentioned no one really learns anything from candidate B suggests he doesn't have the drive and curiosity; these are warning signs.

Furthermore, you can't teach creativity. You can't provide someone with a list of steps to follow every time they want to create something new. The list represents the creative product, and the list is just someone following by rote.

What you can do is sow the seeds of creativity; you can inspire. You can ask questions to help guide someone's thinking, and get them past mental roadblocks. You can throw in ideas and expose flaws. But you can't teach someone to be inspired and come up with new ideas. You can't draw them a map, and then expect that with that training alone they'll be able to draw the next one. You have to rely on their brain's capability to form new connections on its own.

Disagreement is healthy and appropriate. How else could we discuss this.

My post is based upon my own experience. I have seen enough instances of programmer behavior to appreciate patterns. They may not be fair or conventional, but they are most definitely my experience.

Two of the biggest things I've observed are...

1. Senior people usually have set practices that work very well for them. That's probably how they became so senior. Unless those practices mesh well with your organization, there will always be uncomfortable potential energy, which can quite possibly have a negative outcome.

2. I have never met anyone (myself included) that performs anywhere near their potential. This applies to everyone, not just programmers. There are as many reasons for this shortfall as there are people, but the biggest ones I've seen are the belief they can't be better and the belief that "speedbumps" are "roadblocks". I have hired many Candidate B's and all have become better, often much better by improving their environment, removing obstacles, providing better tools, and most of all, getting them to believe that they could become excellent. From OP's original question, I believe that this can be exactly the outcome for Candidate B.

Hire one A every n B.

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.

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.

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.

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.

    A for programming the system
    B for maintaining the system

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

Reply on news.ycombinator.com