How to recognize a good programmer? [closed]

Question

Our company is looking for new programmers. And here comes the problem - there are many developers who look really great at the interview, seem to know the technology you need and have a good job background, but after two months of work, you find out that they are not able to work in a team, writing some code takes them a very long time, and moreover, the result is not as good as it should be.

So, do you use any formalized tests (are there any?)? How do you recognize a good programmer - and a good person? Are there any simple 'good' questions that might reveal the future problems? ...or is it just about your 'feeling' about the person (ie., mainly your experience), and trying him/her out?

Edit: According to Manoj's answer, here is the question related to the coding task at the job interview.

Answer 1

Get them to talk about what they're interested in. I have yet to meet a developer who is really passionate when talking about programming but can't actually code. They may well exist, of course - and your interview should check for competency as well - but passion is a good indicator in my experience. (Note that that's not the same as being able to "talk the talk" in terms of buzzwords.)

Ask them what they don't like about their favourite language or platform. How would they fix things? What would they like to see in the next version? Do they have hobby projects? If they've got a blog, read it. Check their general online presence.

Answer 2

Hiring good people is hard.

It has taken some real mistakes for me to get better at it. You start to trust your intestinal tract a lot more after the first couple of times you don't trust it and regret it.

I have a great respect for Steve Yegge's phone screen questions and have used this as the basis for interviewing people with some success.
I also think that I became better at interviewing people after reading Joel's guide to guerilla interviewing (now at version 3.0, that's ahead of the version for the web and everything, it just has to be good).

There are also 57 other questions (as of 20/11/2008) on Software Engineering Stackexchange tagged with interview and some of them look very relevant, so check those out.

Answer 3

Some ideas:

• Ask several open-ended questions from several different angles:

  • Review some code. What's identified? Technical errors, style inconsistencies, comments, algorithms, maintainability, etc...
  • Write some code. Look for process, bullet-proofing, readability, etc.
  • Create a high-level design for a small system. Look for comprehension of the problem, approach, communications, completeness, detail.
  • Describe the software development process. Look for design, collaboration, review, testing, good/bad habits, and overall experience.

• Pick something—anything—the candidate claims to know well. Ask a simple question and then, based on the answer, ask another, slightly more detailed one, and continue "digging" until you reach the limit of the candidate's knowledge. This gives you an idea of:

  • Honesty: does s/he know as much as claimed?
  • Depth of knowledge: how well does s/he learn things?
  • Communication: how well does s/he explain something unfamiliar to you? Is the thought process logical?
  • Reaction to stressful situations: how hard does s/he work to answer? Does s/he fake it? Is the inevitable "I don't know" easy or difficult?

• Ask how the candidate dealt with various situations a previous jobs: teamwork, overdue projects, debugging, etc. Are the answers positive or negative? Passionate? Intelligent? Arrogant?

I find the best candidates to be enthusiastic, seasoned, confident but polite, and most important, present. You need to know there's someone inside. :-)

Answer 4

To recognize a good programmer, you have to be a good programmer. That means you have to know programming very well to see through the stuff that is said and done in the interview, and you have to know what questions to ask.

I have seen candidates given the wrong answer at the interview, but their explanation have shown that they knew the subject (and therefore could easily get the right answer by searching the net). To see that, you have to know the subject you are asking question about very well.

Another thing is to avoid questions about details that could easily be googled. Those question only shows how good the candidate is to remember things, not if he or she really have the knowledge and understanding you are looking for.

My recommendation is to get help from someone that knows a great deal of programming, and have good people skills, to help out with the interviews.

Edit: I also wrote a comment about interviews here.

Answer 5

Remember that programming ability isn't everything. You could have the best programmer in the world working for you, but if they hate working with other people you will not find them very useful.

A programmers personality should be higher up on the list than most employers seem to rank it. In my current workplace they are very careful about hiring the correct type of person.

People can generally learn to be better programmers, people can not generally learn to be better human beings.

Answer 6

I like the passion answer. I believe you have to be passionate for what you work with to actually be very good at it.

A good programmer programs on the side besides work (once in a while at least). He/she likes to solve programming problems. And when he/she can't find a program that solves a particular need at home, he will typically try to solve it himself.

But there are several types of programmers.

• You have the ones that loves documenting. Personally I hate documenting. But documenting what is done can be important.
• You have the "hackers". The ones that are hellbent on solving a complex puzzle where if you where to google for it, probably wouldn't find a solution. They can solve "any" problem as long as they got the tools they need.
• You have those who educate themselves to be programmers just because the market was good for getting hired for programming. Those are usually mediocre because they lack the passion.
• You have those who are superb at communicating and they "can solve anything" but once they get the job they hang over everyone else to get help for the problem they are solving.

If you can find the "hacker" that also documents very well and has superb communicating skills, I would believe you have hit jackpot.

Oh, and one last thing. You probably don't want a programmer that has leader ambitions, as he will only use programming to launch off. That means you'll loose that resource sooner or later.

A question I would ask when hiring a programmer would be: "Why did you educate yourself as an programmer?". That would be a dead giveaway if they hesitate there.

That's my opinion.

Answer 7

Make them code. Give a problem which can be solved in say 4 or 5 hours and inspect the code for documentation, style of coding, how he planned the solution before actually starting to code etc. He need not have to actually solve the problem.

And as Jon Skeet mentioned, make them talk about programming, their language of choice and things like that. You can recognize the passion in a good programmer.

Ask how many programming related sites they follow- like StackOverflow. The blogs they follow also can be a good indicator.

Answer 8

A friend of mine is working in a company where they have an additional step in the hiring process: after initial screening and interview, an applicant has to "test work" for a few days. He told me that even though one candidate had every skill and talent needed, they did not hire him because he was an a not a nice person to work with.

Answer 9

It's very hard to recognize a programmer based on a job-interview alone.

Some things that decide that someone is a good programmer are:

• able to work in a team
• writes good code that is understandable and maintable
• is able to learn about new technologies

So you have some little hints you can find out about in an interview:

• Does the candidate know one technology/programming language or does he know multiple? If he know different languages he seems to be able to learn new things and he possibly know about the downsides on his current preferred technology/language. So ask for knowledge besides the technology you use in your company.
• Ask for projects he already worked in, especially hobby-projects and open-source. Hobby projects show you, that he likes programming and do it even in it's spare time (and this way improves his skills). In an open-source project you can look up code he have written. If the project involves more than one person you may get hints about his team-skills. In an OS-project you can lookup the mailing-list-archives to know more.

Answer 10

You could perform some test in the interview.

But many times there is also a problem with the working environment itself. Surely this might not be the case in your organization, but it is quite common in the field of software industry that the technological debt becomes too large. Then when you hire new people, it doesn't much help if they are good or not, because of the debt. Maximizing the readability and understandability of your program code helps the newcomers to get into work.

Also many people are such that they can co-operate, but sometimes there is no way of co-operating. For example if all people are developers, they are supposed to do their job. Well, they do. But do you have an architect, that steers the development project and keeps meetings and such? Normal developers might feel that they don't have necessary mandate to start meetings and they might think that interrupting others now and then is not the way.

Communicating with one other should not be the end goal. The less communication needed, the better, but only if less is possible. Less becomes possible if you have an architect. The total amount of communication might stay at good level, but you get more results for the same amount of communication.

Answer 11

first I start with the usual interview stuff, I consider very important to see if the person in front of me worth something, and to determine his/hers skills and knowledge.

After that I use a couple of technics in the field of Java, like discussing some principles, mainly taken from Effective Java.

At this stage, when I think that I might have a good programmer in front of me, I give him a piece of code to code-review it. What I want to see is that he can pinpoint the dangerous parts of the code, give some pointers on improvements, find pitfalls on performance an multi threading AND that he can distinguish between important remarks and "taste-remarks". All this helps me to find a more proficient employee.

but in the end I always remember that hiring is a kind of gambling...very very hard to anticipate...

Answer 12

I know this does not answer what you are asking but I recommend, laws permitting, always hire on a temporary basis at first (two weeks or a month, depending on the job). If the person is worth his salt he will not object, besides it's a safeguard for both of you (you can let him go and he might end up not liking the job and leaving).