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 moths of work, you find out that they are not able to work in a team, writing some code takes them 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 out?

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

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

12 Answers
12

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.

Great ideas - especially hobby projects and problems with their favourite language seems really good to me. It should reveal more about their relation to programming. A blog is also a good idea. Unfortuantely, usually they have no blog :-(. Thank you...
–
giusNov 20 '08 at 9:41

9

Passion doesn't necessarily translate into professionalism or teamwork. They might just want to code what's cool/fun, not what needs coding.
–
PrestonNov 24 '08 at 1:50

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

I remember my first programming interview I was asked to review some printed code. At the top there were some comments that explained what the code did. I verified this by reading the code then I basically read the comments verbatim and they said "Very good!" I said, "yeah it pretty much says that right here in the comment block." They were pretty embarrassed.
–
DustinMay 20 '13 at 19:48

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.

You are completely right about googling - a good programmer does not have to know everything but he should be able to find out quickly.
–
giusNov 20 '08 at 9:47

1

"someone that knows a great deal of programming, and have good people skills" ...and that's the problem - it's not easy to find one. Usually they have only one skill of these. That's why I am doing my best to improve both branches :-).
–
giusNov 20 '08 at 9:48

3

Having great people skills usually conflicts with being an abstract thinker. Not being an abstract thinker usually conflicts with being a good programmer.
–
TomalakNov 20 '08 at 9:51

2

Gius: If you are lucky, you find programmers who understands that humans are biological computers, and therefore interested in how we work/think. Those have often developed good people skills too, since they are interested in improving themselves in that area too.
–
EigirNov 20 '08 at 10:06

Eigir: I agree. But as someone here already mentioned - if you find someone, you hit the jackpot ;-). I hope we'll be fortunate.
–
giusNov 20 '08 at 10:14

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 actualy solve the problem.
And as Jon Skeet mentioned, make them talk about programming, their language of choice and things like that. You can recogonise the passion in a good programmer.
Ask how many programming related sites they follow- like stackoverflow. The blogs they follow als can be a good indicator.

I like the idea of actually giving them a coding task (can be done before the interview) and then use the code as a subject at the interview. Make them explain why they choose the different solutions and so on...
–
EigirNov 20 '08 at 9:48

Generally, the idea about the coding task is very good. But I am afraid that creating a task that would really show what's in them is quite hard - and a good topic for another pretty long (but very inetersting!) discussion. ...should we Ask a question about it here? ;-)
–
giusNov 20 '08 at 9:56

List of their favourite blogs would be a great indicator!
–
giusNov 20 '08 at 9:58

3

I have had a coding interview. The interviewer insisted that I talk through my solution with him. I would put forth an idea, he would suggest ways in which it might fail. In this way, he learned how I work through a problem. It was the hardest, and the most fair interview I have ever had.
–
e.JamesNov 20 '08 at 10:00

@gius - I think you should ask that question.
–
ManojNov 20 '08 at 10:25

If they disdain working with other people, how could you call them “the best programmer in the world”? Programming is certainly not just about talking to the compiler and chunking out code, most tasks of a programmer/software developer do require a certain amount of cooperation.
–
Christopher CreutzigApr 15 '11 at 11:23

I see your point, but in this context "Programming" is just about coding otherwise I'd have used the term "Software Developer". The terms "Programmer" and "Software Developer" are not synonymous.
–
Doctor JonesApr 15 '11 at 11:42

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

Great answer! I disagree with your comment about leaders, though: I do my best to lead by example, so in addition to keeping my hands constantly dirty, I'm generating more good programmers (assuming I've recognized myself accurately).
–
Adam LissNov 20 '08 at 12:15

3

We lose all resources sooner or later. Only the rocks are forever.
–
Carl ManasterApr 21 '09 at 14:31

I would vote this up if it wasn't for the "You probably don't want a programmer that has leader ambitions". Employees that want to take responsibilities are vital and you should find ways to advance them within your organization.
–
Danny VarodJun 27 '12 at 17:03

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.

This is a great idea, and I'd like to see it be standard practice. As one who has been fired from several jobs for not fitting the company culture, or from misjudgment of skill levels, I'd love to test the water first.
–
DarenWSep 10 '10 at 23:08

6

The problem with this is, if someone already has a job they can hardly take off a week to go work for another company just to find out if they really got the job.
–
CercerillaJan 5 '11 at 14:58

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

You are completely right, but if he is not good for you, you still lose one or two moths, his salary, and the work of people getting him into you project. So it would be good to avoid this situation.
–
giusNov 20 '08 at 9:51

2

The problem is that good programmers have probably other job offers and if you only offer them a temporary job at the beginning, they can chose someone else ...
–
RexxarNov 20 '08 at 10:29

@Rexxar: They will still leave if they don't like it. It's just more honest and upfront to offer it that way, IMO. At least for me it'd be a plus, not a minus (given that's a short temp contract and that at its end it gets either permanent or it's a goodbye).
–
Vinko VrsalovicNov 20 '08 at 12:08

@gius: True, it would be ideal to avoid the situation, but you will never be sure until you test it for real, it's a 'wicked problem'. So while you can take many measures to prevent it as per the many suggestions here, you will never be sure, thus it's still a good measure to take.
–
Vinko VrsalovicNov 20 '08 at 12:10

1

I need to keep paying my bills, I owuld never consider taking a job for only a omonth and giving up a permanent job for it. If you are unemployed or have a rich spouse this could work. Other wise, you lose a lot of good candiates because they can't afford to take the chance that you aren't lying to them about being made permanent.
–
HLGEMJun 27 '12 at 22:31

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.

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.

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