Article Discussion
How to Interview a Programmer
Summary: Recognizing good programmers among job applicants is not easy. This article contains interview techniques, garnered from a recent summit on writing better code, that can help you can find the most qualified programmers for your project.
43 posts on 3 pages.      
« Previous 1 2 3 Next »
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: October 13, 2011 9:47 AM by
Bill
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
How to Interview a Programmer
February 24, 2003 0:08 AM      
Recognizing good programmers among job applicants is not easy. Artima.com has published an article that contains interview techniques, garnered from a recent summit on writing better code, that can help you can find the most qualified programmers for your project.---xj40dkcfea73---Recognizing good programmers among job applicants is not easy. Artima.com has published an article that contains interview techniques, garnered from a recent summit on writing better code, that can help you can find the most qualified programmers for your project.

http://www.artima.com/wbc/interprog.html

Here's an excerpt:

Dave Thomas: Hire for talent. One of the biggest mistakes companies make is to recruit from a shopping list: I need a programmer with six years Java, three years Oracle, and two years EJBs. The world changes, so you need to hire folks who change with it. Look for people who know computing, not necessarily particular narrow niches. Not only will they adapt better in the future, they're also more likely to be innovative in the present.

How do you interview a programmer?
Daniel
Posts: 1 / Nickname: danielholm / Registered: February 24, 2003 2:21 AM
Re: How to Interview a Programmer
February 24, 2003 8:17 AM      
An interesting question I use for interviewing new college hires is to ask which non-computer class they thing is most relevant or helpful to programming. One answer that I liked was foreign language (any really), because it helps to separate the thinking of what you want to say from the language it is expressed in. Shows a good understanding of the separation of design from coding.
Ryan
Posts: 3 / Nickname: rshriver / Registered: October 23, 2002 5:18 AM
Re: How to Interview a Programmer
February 24, 2003 9:55 AM      
Part of our interviewing process asks a candidate to solve a simple coding problem in a language of their choice, and then in a language which they've never used. The problem is small enough that picking up a new language and implementing it shouldn't take more than a couple of hours. They must also submit a test case with each solution verifying it works.

This exercise is done after their first interview but prior to follow-up interviews. It lets us get a feel for how well this person can adapt to new technologies and it also re-enforces our idea that we don't hire just "Java" or .NET programmers, we hire skilled programmers who can work in either environment if needed.

-ryan
Frank
Posts: 135 / Nickname: fsommers / Registered: January 19, 2002 7:24 AM
Re: How to Interview a Programmer
February 24, 2003 10:48 PM      
The most important criteria for me in hiring is to judge the candidate's passion about his work. I think there are, basically, two kinds of candidates: the one considers his work merely a job, while the other thinks of his work as a way, a vehicle, to contribute to some project, or cause, in a significant way.

I typically don't ask many questions, but rather let the candidate ask the questions. Their questions will reveal their level of curiosity, and often even aspects of their character. Also, the kind of questions they ask, and the process of their probing about a job or a potential company, hints at a candidate's way of thinking and problem solving.

But I also think that character is more important than skill or enthusiasm. In a job, there are always crises, and it is in those moments that a developer's character really matters. Is he going to put his temporary frustration aside, and responsibly finish his work? Is he going to deliver things in a timely manner? Is he going to boost the morale of those around him? Or is he a complainer? Is he going to jump ship at the earliest opportunity, and go over to the enemy camp (i.e, my competitors)? I think someone's resume tells a good part of that story. I just don't believe that someone who worked for 10 different companies in 5 years is going to stick around for very long. In other words, I need to be able to trust the person completely and unconditionally, and if I can't, I just don't want to hire them.

Next, I look for a sense of taste in the person, the candidate's aesthetic sense. So I like to informally talk to the person about what he does in his free time, what he majored in college, what music he listens to, where he travelled to, etc., Then I just pick one of those things (the one I'm familiar with), and try to find out why the person likes what he likes, what led him to be attracted to those things. I think if a person is attracted to beautiful and pleasing things, that person will also be attracted to well-designed, elegant software, and he will demand of himself the hard work needed to build such software.

Finally, I always prefer candidates who believe that software is not an end in itself, but simply a way to express their ideas and, especially, a way to benefit others through their effort. In other words, I look for people who always, at every moment during their work, have their users in mind, and who respect their users, and try to make them the hero and focus of their work. That way, they also will be in agreement with the entire reason for going to work every day (at least where I do the hiring).
Frank
Posts: 135 / Nickname: fsommers / Registered: January 19, 2002 7:24 AM
How to inverview a programmer
February 24, 2003 10:56 PM      
The most important criteria for me in hiring is to judge the candidate's passion about his work. I think there are, basically, two kinds of candidates: the one considers his work merely a job, while the other thinks of his work as a way, a vehicle, to contribute to some project, or cause, in a significant way.

I typically don't ask many questions, but rather let the candidate ask the questions. Their questions will reveal their level of curiosity, and often even aspects of their character. Also, the kind of questions they ask, and the process of their probing about a job or a potential company, hints at a candidate's way of thinking and problem solving.

But I also think that character is more important than skill or enthusiasm. In a job, there are always crises, and it is in those moments that a developer's character really matters. Is he going to put his temporary frustration aside, and responsibly finish his work? Is he going to deliver things in a timely manner? Is he going to boost the morale of those around him? Or is he a complainer? Is he going to jump ship at the earliest opportunity, and go over to the enemy camp (i.e, my competitors)? I think someone's resume tells a good part of that story. I just don't believe that someone who worked for 10 different companies in 5 years is going to stick around for very long. In other words, I need to be able to trust the person completely and unconditionally, and if I can't, I just don't want to hire them.

Next, I look for a sense of taste in the person, the candidate's aesthetic sense. So I like to informally talk to the person about what he does in his free time, what he majored in college, what music he listens to, where he travelled to, etc., Then I just pick one of those things (the one I'm familiar with), and try to find out why the person likes what he likes, what led him to be attracted to those things. I think if a person is attracted to beautiful and pleasing things, that person will also be attracted to well-designed, elegant software, and he will demand of himself the hard work needed to build such software.

Finally, I always prefer candidates who believe that software is not an end in itself, but simply a way to express their ideas and, especially, a way to benefit others through their effort. In other words, I look for people who always, at every moment during their work, have their users in mind, and who respect their users, and try to make them the hero and focus of their work. That way, they also will be in agreement with the entire reason for going to work every day (at least where I do the hiring).
Bill
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
Re: How to Interview a Programmer
February 24, 2003 11:05 PM      
I found this weblog entry on "The Fishbowl" about the Interview with a Programmer article:

http://fishbowl.pastiche.org/archives/001258.html

I couldn't figure out who actually posted it. Here's an excerpt:

When I'm presented with a design problem to solve, you won't find me sitting in a chair with a piece of paper. You'll find me wandering aimlessly around the office with a can of coke, or tossing my pen in the air and catching it. You'll see me doodling on a whiteboard. You'll see me wander out the front door with my iPod playing at maximum volume, and walking around the block. When I need to think creatively, I get my best ideas when my feet are moving, not when I'm sitting in front of a computer, or in a meeting being pressured to come up with an answer right now.
Bill
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
Re: How to Interview a Programmer
February 24, 2003 11:09 PM      
Another weblog entry about the article:

http://www.cardboard.nu/archives/000024.html

I can't tell who posted this either. I wonder why these webloggers don't make their name more obvious. Here's an excerpt:

My favourite set of questions for interviewees starts by asking them to describe a large system that they've worked on before - I pick an appropriate one off their resume - and getting them to draw the system on a white board.
Brian
Posts: 1 / Nickname: brian / Registered: February 4, 2003 9:33 PM
Re: How to Interview a Programmer
February 25, 2003 7:25 AM      
I find that giving out a coding problem prior to interview is invaluable. Firstly it immediately weeds out a large number of people who simply can't be bothered to do the problem. Secondly you get a sample of the persons code in a situation where they could spend as much or as little time as they wanted solving the problem, this is a very good indication of what their production code will be like, and thirdly you get something concrete to talk about during the interview.

The problems we give out are small but interesting enough that some level of design is required. For example, write a program to convert a number into words e.g. 1023 into "One thousand and twenty three".

During the interview I often use a couple of the refactoring exercises from "The Pragmatic Programmer", asking people to describe their thoughts as they look at the unfactored code.

As mentioned in the article, I also like to ask people what was the last book/best book on software development that they read. Obviously I much prefer interviewees to mention something like "Refactoring" or "Peopleware" rather than "Teach yourself EJB's in 10 seconds". ;->
Ani
Posts: 1 / Nickname: anidutta / Registered: February 25, 2003 3:18 AM
Re: How to Interview a Programmer
February 25, 2003 8:47 AM      
As someone who had to grow a 15 people team and deliver a project in 6 months I had to find an effective way to pick talent. The approach that I found worked well is
a following 5 step process.

1. Put the candidate at ease.

There is no sense in putting the candidate under stress by inviting a committe of people to interview him/her. I consider this a serious mistake. Although finding their true character under stress can be valuable, most of their productivity will come from peforming their best on a daly basis. Rome was not build in a day and neither are software projects. Therefore I am trying to find their true self under normal conditions and making them feel comfortable in the first couple of minutes will go a long way towards setting the stage for this discussion. Informal comments about the weather or the communte to the interview will tend to accomplish this. I am trying to bring out the best in the candidate.

2. Ask them why they are looking to change their job.

The answer to this question will reveal quite a bit about
their character. I am hoping that the reason is to grow and take on more challenges.

3. Ask them to discuss the project on a whiteboard by
drawing block diagrams, interfaces to other projects, hardware, software packages etc.

This accomplishes several things:
-- demonstrates their technical knowledge
---demonstrates their communication skills
---demonstrates their presentation skills
---gives a natural forum for asking in depth technical
questions without putting the candidate on the
defensive. Since the candidate is familiar with the
project, it provides a stressfree backdrop for tough
questions. One of my favorite questions is "If you
were the technical leader of this project" how would
this solution be different.

4. Ask them how they keep up with industry changes.

We all know that the more successful software engineers
have a passion for what they do. They don't work for just
the paycheck. They are constantly in tune with the newest
technologies, design patterns, and ways to cut the development effort. Let them talk and do a lot of listening. The good ones will mention journals, books,
news forum like this one, and user groups.


5. I like to conclude the interview by
-- asking them about their ideal job
---answer any questions they may have about our firm.

The good ones have a clear idea about where they want to go in their career and are looking for a place to help them get there. I want to make sure that I draw the path to their destination for them.

Ani Dutta
Charles
Posts: 1 / Nickname: carlfish / Registered: February 25, 2003 7:09 AM
Re: How to Interview a Programmer
February 25, 2003 0:38 PM      
> I can't tell who posted this either. I wonder why these
> webloggers don't make their name more obvious.

Well, I wrote the first one. The trick on weblogs is usually to look for a copyright notice at the bottom of the page, or check the front page of the site for contact info.
Bill
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
Re: How to Interview a Programmer
February 25, 2003 4:45 PM      
> > I can't tell who posted this either. I wonder why these
> > webloggers don't make their name more obvious.
>
> Well, I wrote the first one. The trick on weblogs is
> usually to look for a copyright notice at the bottom of
> the page, or check the front page of the site for contact
> info.

Now I see it. I did look up and down that page for an author, but didn't notice the small print. I did click on the Main link and went to the home page too, but I didn't notice your name there on the right, also in kind of small print. Now I see your name on the home page, and that you have an about page with lots of info.

One thing I've learned about web pages is people really don't see things even if they are right in front of their eyes. People are in a hurry and focused on the one thing they are trying to do, and they don't notice things outside their focus. Most everyone who comes to this site are "casual users," as Ken Arnold once put it. They aren't experts in how to use Artima.com and all its features, so if I want to get something across I have to make it big and obvious.

Anyway, I did like the little "tail -f /dev/mind > blog" script in the title of your weblog, and I wanted to know who did that. But then I couldn't find your name.
Joshua
Posts: 1 / Nickname: jsegall / Registered: February 26, 2003 11:37 AM
Re: How to Interview a Programmer
February 26, 2003 4:49 PM      
Effectively filtering out bad candidates is a very hard problem. Most of the techniques suggested rely on (A) detailed coding tasks or algorithmic problems, and (B) getting to know the person.

(A) is usually not very useful. You can weed out people who can't program at all, but it can also weed out good programmers that don't have the ability to think quickly under pressure (most development jobs don't require this ability). In addition, such tests are generally insulting to any interviewee who is not a recent college graduate.

(B) is useful, but almost impossible to do in an hour or so. In the end you usually end up hiring people that you like personally, or are like yourself. It takes a very talented interviewer to understand then exact sociological requirements and find them in a candidate. Even then you can easily end up with a homogenous pool of programmers.

I don't know that there is a really good way to interview. It all comes down to a gut feel, and maybe you just have to accept that some poor candidates will be hired and some great developers will slip through the cracks.

Of course, some positions do have specific needs that can be easily discovered through interviews, but the general case of finding a creative, enthusiastic, hard-working, good-natured and intelligent candidate is very hard.
Sebastien
Posts: 1 / Nickname: sebpaquet / Registered: February 28, 2003 5:24 AM
Before the interview: read his weblog
February 28, 2003 10:32 AM      
You can learn a lot about someone by reading a couple weeks' worth of postings. Makes it easy to find shared interests to talk about during the interview.

Phil Wolff wrote on this:

http://dijest.com/aka/2002/06/20.html#a1669

Checking out Technorati records can also be useful to coarsely assess social skills.
Paul
Posts: 1 / Nickname: reiners / Registered: March 4, 2003 8:25 AM
Re: How to Interview a Programmer
March 4, 2003 1:31 PM      
I would just ask them their TopCoder (http://www.topcoder.com/) rating. If they don't have one, I would ask them to come back after competing in some matches and obtaining a rating.
raj_shaker
Posts: 1 / Nickname: rajashaker / Registered: March 5, 2003 5:58 PM
Re: How to Interview a Programmer
March 5, 2003 11:15 PM      
I found that one way to interview a programmer is NOT TO INTERVIEW A PROGRAMMER. It's usually better that a selection should NOT be done in a half or one hour interview.

If possible, taking on a person for a internship or consultancy for a small time period, making him work with the rest of the develoment staff, getting him to work on various areas of coding etc help form a balanced view regarding his/her suitability for a programming job.

The cost of making a hurried decision by a senior person ( usually a manager ) who is probably non technical, is a lot more expensive to the organization in the longer run.

Everything else, coding style, personalaty, curiosity, etc can be judged over a longer time frame.

Just some thoughts...

raj
43 posts on 3 pages.
« Previous 1 2 3 Next »