views:

2125

answers:

15

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.

+29  A: 

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.

Jon Skeet
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...
gius
Passion doesn't necessarily translate into professionalism or teamwork. They might just want to code what's cool/fun, not what needs coding.
Preston
@Preston: While that's certainly true in theory, I haven't met anyone passionate who hasn't been happy to gruntwork too. I've met prima donna coders who think they're above that kind of thing, but they're not generally passionate. Testing for professionalism is pretty difficult anyway...
Jon Skeet
CHECK THEIR BADGE COUNT
bobobobo
+18  A: 

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 SO tagged with interview and a couple of them look very relevant, so check those out.

Hamish Smith
Many thanks for the links...
gius
Yeah, some great articles there.
aib
+10  A: 

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.

Eigir
You are completely right about googling - a good programmer does not have to know everything but he should be able to find out quickly.
gius
"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 :-).
gius
Having great people skills usually conflicts with being an abstract thinker. Not being an abstract thinker usually conflicts with being a good programmer.
Tomalak
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.
Eigir
Eigir: I agree. But as someone here already mentioned - if you find someone, you hit the jackpot ;-). I hope we'll be fortunate.
gius
+3  A: 

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

Vinko Vrsalovic
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.
gius
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 ...
Rexxar
@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 Vrsalovic
@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 Vrsalovic
+10  A: 

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.

Manoj
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...
Eigir
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? ;-)
gius
List of their favourite blogs would be a great indicator!
gius
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.James
@gius - I think you should ask that question.
Manoj
Manoj: ok, it's here: http://stackoverflow.com/questions/304916/job-interview-coding-task
gius
+1  A: 

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.

Silvercode
I like the idea of not only looking at the employee but also at your own organization and the processes inside.
gius
+1  A: 

To recognise a good programmer, I always use The Programmers Dress Code as a yard stick. ;-)

Galwegian
Very funny ...and usually true ;-)
gius
A: 

First you should define exactly what kind of programmer you need. The following table may help.

+6  A: 

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.

Thats my opinions.

Wolf5
Inspiring question - "Why did you educate yourself as an programmer?"
gius
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 Liss
We lose _all_ resources sooner or later. Only the rocks are forever.
Carl Manaster
A bit short sighted. "Schlubladendenken"
Tom Schaefer
+2  A: 

Someone who is up checking for SO questions in the middle of the night :)

e.James
If they were good wouldn't they have a real job?
MusiGenesis
This isn't a real job?
e.James
There was another term for that.. OH YEAH. "Nerd" 8-).
bobobobo
How dare you? I'm insulted! `;)`
e.James
+1  A: 

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.
Mnementh
+12  A: 

I'm about 6', 185 lbs., shaved head and a goatee. I'm wearing Chuck Taylors and a blue t-shirt over a white thermal.

Please down-vote me gently - I did answer the question. :)

MusiGenesis
+1 for also answering, "How do you recognize a creative salesperson?"
Adam Liss
That's insulting. Salespeople are professional liars. I only lie about my abilities to the ladies.
MusiGenesis
Kudos to you sir... Kudos
DoctaJonez
Good one :) You just need to prove that you are a good programmer ;-)
Thorbjørn Ravn Andersen
Why do you shave your head?
bobobobo
@bobobobo: because my hair is grey and I don't like grey hair.
MusiGenesis
Hm, I figured you shaved your head to eliminate the fires.
AMissico
+8  A: 

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.

Regards,

Docta

DoctaJonez
+4  A: 

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.

Svante
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.
DarenW
+15  A: 
Adam Liss