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.

  • 3
    <joke> To recognise a good programmer, I always use The Programmers Dress Code as a yard stick. ;-) </joke>
    – Galwegian
    Commented Nov 20, 2008 at 9:49
  • 7
    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. :) Commented Nov 20, 2008 at 10:02
  • 6
    Related or duplicated: programmers.stackexchange.com/questions/4614/…
    – Maniero
    Commented Jan 5, 2011 at 17:14
  • 1
    here is another view of the topic - How to interview a programmer
    – user83299
    Commented Mar 5, 2013 at 15:22
  • 2
    This question was a good fit for this site, in 2008 when asked. Five years. FIVE YEARS later, Prog.SE turned into SO2, the duplicate.
    – Warren P
    Commented Jan 20, 2015 at 7:11

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.

  • 3
    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
    Commented Nov 20, 2008 at 9:41
  • 26
    Passion doesn't necessarily translate into professionalism or teamwork. They might just want to code what's cool/fun, not what needs coding.
    – Preston
    Commented Nov 24, 2008 at 1:50
  • 23
    @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
    Commented Nov 24, 2008 at 7:34
  • 36
    – bobobobo
    Commented Apr 21, 2010 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 Software Engineering Stackexchange tagged with interview and some of them look very relevant, so check those out.

  • 2
    Hiring good people is NP-hard. :) Commented Aug 4, 2016 at 16:19
  • 7
    The phone screen question stuff starts off good, but then more and more of the questions become ridiculous. I for one don't think a good programmer must know 2^16 by heart. And the fast track version at the bottom is just a poor parody.
    – Peter
    Commented Nov 21, 2016 at 18:34
  • The SO links seem broken (no results or 404). Commented Dec 20, 2017 at 12:13
  • @StijnGeukens, looks like that tag has been migrated to Software Engineering. I have updated the link. Commented Jan 3, 2018 at 18:29

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

  • 4
    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
    Commented May 20, 2013 at 19:48
  • 1
    @Dustin IMO it was pretty careless(?) on their part to just leave the comments in the code that the candidate is supposed to review. That basically gives them a free answer or confusion, based on what the comment contains.
    – cst1992
    Commented Nov 13, 2017 at 13:08

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.

  • 4
    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
    Commented Nov 20, 2008 at 9:47
  • 2
    "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
    Commented Nov 20, 2008 at 9:48
  • 7
    Having great people skills usually conflicts with being an abstract thinker. Not being an abstract thinker usually conflicts with being a good programmer.
    – Tomalak
    Commented Nov 20, 2008 at 9:51
  • 7
    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
    Commented Nov 20, 2008 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
    Commented Nov 20, 2008 at 10:14

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.

  • 1
    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. Commented Apr 15, 2011 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. Commented Apr 15, 2011 at 11:42
  • 8
    No, actually, many people cannot learn to be better programmers. And frankly, if they have 5-10 years experience, I would expect them to already know how to, you know, do their job. This is NOT an answer to the question; you're just saying "you identify good programmers by not caring whether they are good programmers"
    – Benubird
    Commented Jul 3, 2015 at 8:13
  • 1
    @Benubird my point was that interpersonal skills can be more important that raw programming talent, especially when it comes to working in a team. I'm not advocating hiring people who cannot do their job. It's not worth hiring a "rockstar" programmer if they're not going to work well in your team. It's not worth the friction and hassle. Commented Jul 3, 2015 at 11:35
  • @DoctorJones and I agree with you; you're not wrong at all. It is just that the answer you have given, is not an answer to the question "How to recognize a good programmer?"
    – Benubird
    Commented Jul 6, 2015 at 9:34

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.

  • 2
    Inspiring question - "Why did you educate yourself as an programmer?"
    – gius
    Commented Nov 20, 2008 at 10:08
  • 5
    We lose all resources sooner or later. Only the rocks are forever. Commented Apr 21, 2009 at 14:31
  • 1
    A bit short sighted. "Schlubladendenken"
    – Tom Schaefer
    Commented Jun 26, 2009 at 14:36
  • 6
    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. Commented Jun 27, 2012 at 17:03
  • 5
    You have a different definition for a "Hacker" than I do. A "hacker" to me is someone who "hacks" things together as quickly as possible until they get a result (of sorts), but have left behind a trail of destruction and horror because they haven't followed a single best practice. A "hacker" is unprofessional. Commented Mar 11, 2014 at 20:54

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.

  • 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
    Commented Nov 20, 2008 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
    Commented Nov 20, 2008 at 9:56
  • List of their favourite blogs would be a great indicator!
    – gius
    Commented Nov 20, 2008 at 9:58
  • 6
    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
    Commented Nov 20, 2008 at 10:00
  • @gius - I think you should ask that question.
    – Manoj
    Commented Nov 20, 2008 at 10:25

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.
    – DarenW
    Commented Sep 10, 2010 at 23:08
  • 22
    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
    Commented Jan 5, 2011 at 14:58
  • @Cercerilla Right! it's hard enough to even find time to interview let alone have a practice run of working for them for a week.
    – eaglei22
    Commented Nov 29, 2018 at 16:45

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.

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.

  • I like the idea of not only looking at the employee but also at your own organization and the processes inside.
    – gius
    Commented Nov 20, 2008 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...


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

  • 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
    Commented Nov 20, 2008 at 9:51
  • 3
    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
    Commented Nov 20, 2008 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
    Commented Nov 20, 2008 at 12:08
  • 3
    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
    Commented Jun 27, 2012 at 22:31
  • 6
    "If the person is worth his salt he will not object" - well, this developer here would say "fuck that" and find a better job.
    – gnasher729
    Commented Nov 21, 2016 at 20:26

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