i find that difficulty of finding the right person increases with the amount of responsiblity you want a person to handle. Interviewing a fresher, senior developer, architect, team lead, project lead... selecting the right candidate becomes more and more difficult .
there are people who have the right expirence, there are people who don't have the expirence but are good problem solver , and then there are who would score not so gr8 technically, but have very good attitude at job . who love what they are doing. Sometime you are lucky, you can find all three in a candiadate .
i blv an org should have a mix of all people. so its not one type that you look for, you look for people who have thier own niche. if the team is full of over qualified techies..they are going to have a lot of ego problem.
how do you select a person then, look at the current team, and then select a person who will fit better.

>
> How do you interview a programmer?

I'm facing that very dillema right now. I work for a company that does a lot of work with high-traffic websites (500K+ hits per day for most of our sites) and we're a month into a project to create an online dating site. We're using eXtreme programming (very cool) and are looking to add two more programmers to the team, so we're focussing on intermediate level programmers (2 to 4 years experience) in the holy trinity of Open Source web programming (PHP/Perl/MySQL).

The current strategy is for myself and the team lead on the project to scan through the resumes, look for those who have the experience we want and then do the first interview.

Personally, I think we've been asking too many b******t questions that have nothing to do with the test, and since we're starting a second round of first interviews in about a week, I'm gonna push hard to revamp the questions. Too many questions that only really have one good answer that everyone spits out:

"If you have a problem with a co-worker, how do you handle it?"

"What would you say your three best traits are?"

If we like the person's potential, then we give them an hour-long written test (created mostly by me) that covers pretty much the basics of what we need: write some small scripts to connect to databases, process information posted to that page by a web-based form, create a sample SQL query and so on.

Of 14 applicants, only 3 passed the test. But that makes me very confident that those 3 can do the job.

I like the idea of getting the applicants up in front of a whiteboard, but what to ask them? A question about the design of the dating site?

Any thoughts?

Judging ones technical ability and overall intelligence and wit is relatively easy. Where it gets difficult, is judging ones true persona, character and their interpersonal dynamic, how they will work and interact with the rest of the team.

I feel that I am a pretty good judge of character, even during the brief time I get with an applicant. But I still get, on average, about one bad apple out of twenty. And although this seems like a pretty good ratio, and not too difficult to manage, ocassionally you come across someone that just sucks the life out of you and the project. Unfortunately these people don't show their true colors until after a fair amount of time is invested in them.

Only if people could be introspected as easily as Java classes.

I found this topic very interesting and helpfull as well. Though I'm not a recruiter nor an experienced project manager, from my working experience as a team player I've made my own idea of how to deal of choosing a software programmer if I would be in such a position.

On the technical side if I had to choose from, let's say, five programmers the key test would be something like this: put them in front of a computer with a sheet of paper and a pen and ask them to solve a quite easy (but not at all trivial) programming problem (not to take more than 15-30 minutes). The first one who take the pen and draw something on the paper would be hired.

The idea is that I see too many programmers who in the second minute you ask them to implement something they start coding, without trying to design first or think what is the bigger picture; not careing a bit at how their part should be integrated with other people's work; not asking "why". Using a sheet of paper to try to schetch a design even for a simple task is an engineering reflex that could prove the person is more likely to write quality code, I think.

-adip

>...
> On the technical side if I had to choose from, let's say,
> five programmers the key test would be something like
> this: put them in front of a computer with a sheet of
> paper and a pen and ask them to solve a quite easy (but
> not at all trivial) programming problem (not to take more
> than 15-30 minutes). The first one who take the pen and
> draw something on the paper would be hired.
>...

Try posting that on the XP mailing list and watch the reaction you get :)

That is a bit silly and arbitrary. You might just be filtering for people who like to doodle. It is pretty unfair to filter people by how you like to work. It is not unlike the whiteboard criteria (which I think was already mentioned). I'm sure there are plenty of people who like to sketch things out, but still end up cranking out crap.

I much prefer the idea of giving someone a small project before the interview. Ask the person to bring in the related work (if it includes sketches, you'll be extra pleased) and review it together. (It would probably be useful and reasonable to also make your phone number available for clarification and/or discussion before the interview, while s/he is working out the solution). If it is excellent work and the discussion is good, then you probably a good candidate on your hands.

Most of the interviewing techniques discussed here are good for a personal interview. But what techniques would you use while conducting a telephone interview?
In the past I was a member of the panel that conducted telephone interviews. Below are few of the questions we asked.

1. Briefly explain about the projects they have worked on
and their role in those projects.
2. What kind architecture did they use? It is important that
the candidates understand MVC architecture, especially if
they are going to develop J2EE applications.
3. What design patterns have they used in their projects and
explain those patterns.
4. Then there were questions about the particular technical
skills we were looking for.

We could not do certain things like give a coding problem, discuss the project on a whiteboard etc because of telephone interview.
I would be interested to know other people's experiences in conducting telephone interviews and how to get the maximum out of it.

> The first one who take the pen and
> draw something on the paper would be hired.

For your own good: Spend some time on Paul Graham's site. In particular: http://www.paulgraham.com/hp.html

By your test, you wouldn't have hired him. He "sketches" in code. So do I. So does every programmer I'd hire again. (Sometime I sketch on paper, but only for fundamentally graphical problems like bit-twiddlers or funky data structures.)

If you worked for me, and I learned that this was your interview technique, you wouldn't be involved in the interview process any more.

Hello programmers. We are the WarlockTeam, a game-racing web-site and we are looking for some guys like you.
When you have interse.in php,.. and you always wanna
write some news,... we are the right team for you

Please write us a mail for more information on :
warlock@siol.com

Denis Lampret
WarlockTeam
www.warlockteam.com

What came to my mind several months ago:
Everyone talks about programmers, but to be correct, IMHO it should be spoken of developers. Or do you think, that there seems to be no or just little difference?
To give an example for distinction: In my eyes, a developer works more "academic" than a programmer. This is often reflected by the fact that a programmer does not necessarily need a final degree or extended knowledge of computer science.

Cheers

Klaus

I think titles are almost completely meaningless in this industry. You can choose to distiguish between different titles, but since there are no widely used standards, those titles won't convey any information outside your purview.

There are plenty of people with the title Software Engineer who stuggle to write a simple batch file or script and others who are very competent and talented. There just isn't much coupling between title and skill, talent, inclination, or even experience.

> ask which non-computer class they think is most relevant or helpful to programming...foreign language...helps to separate the thinking of what you want to say from the language it is expressed in.<

I agree. Superior coding knowledge and capabilities are useless without a capacities for conceptualizing the end-user's experience & developing creative solutions as well as the desire to take ownership of developemnt and make it work. I've always looked for two key indicators which show me I have found a curious, creative, self-motivated individual who will likely posses the aboove chaacteristics:
1. Do they interview me (Are they curious about our work or are they just looking for a job?)
2. Do they have something, some interest outside of work, that they have started and made work. (One guy ran a soup kitchen; one guys lead a band; and one girl managed her ultimate frisbee team. It doesn't matter what the activity as long as they started it and made it work.)

I've never found a good coder who was only interested in coding.

well, the article is fine.
except for the code snippet that looks broken.

on page 2, paragraph 2, Josh Bloch mentions "an optimal solution" to determine if argument is a power of 2:

((n & -n) == n)

it may be fast, but it ain't correct :)

if we wrap it in a function like this:

bool is_power_of_2(int n) {
    return (n & -n) == n;
}

then the following asserts fail:

assert(!is_power_of_2(0));
assert(!is_power_of_2(-2147483648));

besi des, the whole thing depends on negative numbers being represented as 1's complement.

makes me wonder if Josh Bloch really meant the code that appeared in the article :)

Ajit Fernandes:

Technical skills can be given a weightage of around 70%. The attitude has to be tested by devising proper what..if questions and also the patience need to be tested. The questions to test the above two qualities has to be compiled carefully over a period of time. Also the body language has to be studied carefully as a lot of information can be gathered from it. Technical skills can be easily upgraded if the candidate has the right attitude and patience.

Lot of companies focus more on Technical/logical and other exams but fail to the the two qualities mentioned above. This may create problems in the long run.

I really enjoyed the 5-step suggestions given by Ani Dutta, especially the one about putting the candidate at ease. I have found some of the best candidates absolutely detest job interviews because some in our field love to grill them. Many in our industry complain that we pay little attention to design during projects, yet when it comes to interviews, some expect candidates to start writing code on the spot.


And now I would like to offer a variation on Suggestion #2.
>
> 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.
>


As someone who's studied interviewing, I've found it vital to find questions for which a candidate will not be tempted to lie. People are coached in interviewing through numerous sources, from outplacement firms to books and Web sites. A candidate is told to always speak good about previous bosses and workplaces; if he is indeed upset with a situation or supervisor, the last place he'll reveal it is during an interview. I used to ask this myself, never to really find anything truly revealing. So much in interviewing can needlessly deteriorate into false posturing (which is why some tell me they love asking only "ya either know it or ya don't" technical questions.)


Still, I thought the move is indeed important. I'd like to know why they're doing it. However, the interview isn't really about why they want to leave their current place, it's about why do they want to come to mine. Remember, if interview is indeed a word representing 2-way conversation, then I have to sell them on my company. Why not do what a manager must do, i.e., delegate? In other words, have them sell me on my company.


So I now ask why they want to come work for us. Yes, that one also appears in those 101 Great Answers-type books. Yet I've found those candidates who have taken the time to study the company and its products will use this as an opportunity to describe what they like and how they wish to contribute. They'll inject the right programming concepts too. It's their chance to be a star.


Moreover, just because someone was good or bad in a previous environment doesn't guarantee they'll be the same in mine. Lots of variables contribute to a programmer's success or failure, many outside their scope and control. Personally, I despise the growing trend of "behavioral interview" questions, those that ask about what a candidate has done before. The moment that really matters most to the candidate and me is the present. That one's the toughest to lie about, esp. if both employer and candidate know what they want from each other. That's what I find most useful to focus on interviews, esp. to improve on the quality of hires. The programs you wrote for 5 others before aren't as important as the one you'll write for me.