Ask HN: Hiring Decisions

It depends. How much do you need the project done? How quickly?<p>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.<p>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.<p>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.<p>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.<p>Otherwise, go for B.<p>The worst can happen is to hire A, and when he leaves, B has to maintain A's code with no documentation.

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.<p>So a little reasoning why I am put off by both:<p>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 <i>thinks</i> 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.<p>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.<p>One thing you didn't clarify in your definition of B: when he gives his input, does it contribute anything useful to the discussion?<p>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.

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.<p>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.<p>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.<p>Skills can be learned, it will take some time but if someone is a real team player he'll make the effort.<p>Attitude is a lot harder to change than skill.

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.<p>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.)<p>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?<p>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.

<i>[Candidate B]... is very loyal.</i><p>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.<p>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.<p>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.<p>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.<p>Just with marriage, wait until you found a good match.

If you <i>really</i> 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.

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.<p>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.<p>I have worked with many and they are not worth the strain.

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

From experience: hire the team player.<p>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).<p>Candidate A is problematic. You will have difficulty changing anything about him, especially those areas which are most important to change.<p>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.

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.<p>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.<p>On the other hand if your "problem" requires highly creative and "thoughtful" solutions then your going to have to risk A :)<p>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...<p>but here's something to think about:<p>If you hire A, the next person that you interview will see A and think "there are geniuses here".<p>If you hire B, the next person that you interview will see B and think "there are mediocre players here".<p>Of course, there's a third option: defer hiring until you find the perfect guy.<p>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.

<p><pre><code> A for programming the system B for maintaining the system</code></pre>

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 <i>have</i> those tangents, that little spark of something-else -- hire A. Give her 20% of her time her own, and watch magic happen.<p>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.<p>If you have problems that <i>need</i> brilliant solutions, A sounds like (s)he might be a fit.<p>If your problems are more mundane, and need lots of communication between team members, B could be better.<p>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.<p>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).<p>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 <i>really</i> 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.<p>If your A isn't able to hold intense discussions and sometimes lose, he's useless.<p>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?

B

it seems you are already working with both. so it's not a hiring decision.<p>Keep A and learn how to motivate him. it's more effective then keeping B and making him smarter.