Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not constructive by Yannis Rizos Mar 5 '13 at 16:16

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.

1  
<joke> To recognise a good programmer, I always use The Programmers Dress Code as a yard stick. ;-) </joke> –  Galwegian Nov 20 '08 at 9:49
4  
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 Nov 20 '08 at 10:02
6  
Related or duplicated: programmers.stackexchange.com/questions/4614/… –  bigown Jan 5 '11 at 17:14
1  
here is another view of the topic - How to interview a programmer –  user83299 Mar 5 '13 at 15:22
    
I think that there is a good question lurking here. I've tried to answer it in my blog a while back: startersquad.com/blog/how-to-recognize-a-great-developer I hope it helps someone some day. –  iwein Jun 28 '13 at 9:23

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.

share|improve this answer
2  
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 Nov 20 '08 at 9:41
8  
Passion doesn't necessarily translate into professionalism or teamwork. They might just want to code what's cool/fun, not what needs coding. –  Preston Nov 24 '08 at 1:50
12  
@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 Nov 24 '08 at 7:34
15  
CHECK THEIR BADGE COUNT –  bobobobo Apr 21 '10 at 19:39

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.

share|improve this answer

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

share|improve this answer
    
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. –  Dustin May 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.

Edit: I also wrote a comment about interviews here.

share|improve this answer
    
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 Nov 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 :-). –  gius Nov 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. –  Tomalak Nov 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. –  Eigir Nov 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. –  gius Nov 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.

share|improve this answer
    
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 Nov 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? ;-) –  gius Nov 20 '08 at 9:56
    
List of their favourite blogs would be a great indicator! –  gius Nov 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.James Nov 20 '08 at 10:00
    
@gius - I think you should ask that question. –  Manoj Nov 20 '08 at 10:25

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.

share|improve this answer
    
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 Creutzig Apr 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 Jones Apr 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.

Thats my opinions.

share|improve this answer
    
Inspiring question - "Why did you educate yourself as an programmer?" –  gius Nov 20 '08 at 10:08
    
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 Nov 20 '08 at 12:15
3  
We lose all resources sooner or later. Only the rocks are forever. –  Carl Manaster Apr 21 '09 at 14:31
1  
A bit short sighted. "Schlubladendenken" –  Tom Schaefer Jun 26 '09 at 14:36
    
@Carl: No, they are not. Rocks crumble to stones (mostly due to temperature variations and water) which produce gravel and sand, within a reasonable geologic time span. –  Christopher Creutzig Apr 15 '11 at 11:27

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.

share|improve this answer
    
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 Sep 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. –  Cercerilla Jan 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).

share|improve this answer
1  
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 Nov 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 ... –  Rexxar Nov 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 Vrsalovic Nov 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 Vrsalovic Nov 20 '08 at 12:10
    
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. –  HLGEM Jun 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.
share|improve this answer

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.

share|improve this answer
    
I like the idea of not only looking at the employee but also at your own organization and the processes inside. –  gius Nov 20 '08 at 10:00

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

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.