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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

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

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)

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.

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.

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.

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.

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

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

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

I personally wouldn't hire either one.

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.

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

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

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.

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

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