How to judge the candidate you are interviewing

http://www.makinggoodsoftware.com/2009/07/16/3-tips-to-know-how-good-is-the-candidate-you-are-interviewing/

by wtfdeveloper • 17 years ago

24 33 17 years ago

mattyb2• 17 years ago

#1: Definitely agree, I'm surprised I don't hear this more often.

#2: ...Make him code using the same tools he would use in the position he is applying for....

What sort of tools is he referring to? I've always been given free reign on my work box, and I put what I want on it. It has to be interoperable, of course.

#3: Good idea, but why leave and come back? Why not just have them talk you through it? I much prefer interactive interviews.

#4: Make sure their personal website doesn't have a link to their Google Apps verification page.

http://www.makinggoodsoftware.com/google50f905a7cdbdd588html...

lhorie2• 17 years ago

>> What sort of tools is he referring to?

I assumed he meant languages, frameworks and other things in a project that can't be swapped out as easily as, say, text editors.

Periodic4• 17 years ago

It has to be pretty basic, as you obviously can't give him all your production frameworks and libraries to work with.

A reasonably competent program will be able to create reasonable code without the perfect environment. You probably don't need a full IDE and heavily customized desktop with test and development staging grounds and SCM just to write fizzbuzz.

tptacek2• 17 years ago

I prefer "make the candidate estimate some reasonably complex project" to "make the candidate design something". Design is fuzzier than estimation.

bigsassy2• 17 years ago

I've always thought the opposite, which is estimation is fuzzier than design. I mean, who here hasn't been off on an estimate in the last month or so? Developers are notorious for making bad estimates. See http://www.codinghorror.com/blog/archives/001284.html.

mattyb2• 17 years ago

URLs automatically become links, no need for tags.

tptacek2• 17 years ago

You could let a candidate be fuzzy with estimation, but it's much better to dig in. If they say something will take 40 hours, ask why. The "why" answers are going to tell you a lot about how they design, code, and test, and those answers are going to come under pressure (you want the smallest reasonable time, and they know it, but you also want to detect BS).

Also, I think design skills are less valuable than estimation skills. If you can estimate reliably, you can design. The reverse isn't true.

dfranke• 17 years ago

Everyone is notorious for making bad estimates. It's just that developers make estimates more often than most other professions do.

http://lesswrong.com/lw/jg/planning_fallacy/

tonystubblebine3• 17 years ago

When you have them do the estimation, is part of your expectation that the candidate is going to start decomposing the project? I like that.

lucifer• 17 years ago

These are all excellent suggestions.

Potential interviewers please note that leaving the candidate in a conference room with blank paper and pencil potentially filters excellent developers who are just not used to literally writing code on paper.

tonystubblebine3• 17 years ago

We used to call the code writing section of the interview a typing test. You could literally tell if the person was going to make it by listening to them type. Someone who is comfortable writing code types confidently and with long bursts. We saw plenty of applicants who talked a big game, but clearly couldn't put together even the simplest program without resorting to cut and paste.

Periodic4• 17 years ago

I still find it hard to believe that someone would apply for a programming job without being able to write fizzbuzz in the language of the position.

ice5nake• 17 years ago

Some interesting and good ideas. However, I don't think there is a recipe for finding good software engineers. If you always use the same method you're going to end up with a team of people with the same strengths. Know your teams strengths and weaknesses and find candidates that balance things out.

Periodic4• 17 years ago

I think this is very important to take into consideration. I've heard a lot of stories about like-hiring-like and ending up with an imbalanced team. Part of that is the interview process, part of it is the interviewers.

Good interviewers should be able to recognize strengths in the candidate that they lack.

clay• 17 years ago

I might sound a bit hypersensitive here, but couldn't the author easily avoid using "he" and "him" when referring to potential candidates for software programming positions?

rimantas• 17 years ago

I now see the opposite effect: everyone is scared to look sexist so everyone ends up putting "she". Maybe we should call programmers "it"?

nailer2• 17 years ago

'they' is a natural sounding gender neutral term.

evilneanderthal• 17 years ago

Although English doesn't emphasize gender in nouns, in romantic languages (which are the basis for English), that class of nouns is masculine.

Where the gender is not known, the correct pronoun is "he." A spokesman is a he; a spokeswoman is a she; a spokesperson is a he.

edw5192• 17 years ago

"Leave him alone in a room with a computer..."

I prefer to leave them alone in a room with only pencil and paper. I want to see every piece of paper when I return, including diagrams, notes, and most of all, the entire audit trail of what they did (cross outs, revisions, etc.) I don't care how it looks or how well it compiles or runs. What I really care about is the thought process they went through. Pencil and paper shows me that much better.

Quarrelsome2• 17 years ago

Am I the only person who gets insane cramp when having to write a lot on paper? Unless i've only got to write one short function i'm gonna be screwed up by your test.

edw5192• 17 years ago

"...i'm gonna be screwed up by your test..."

That's exactly what I want to see. I don't care how well you type or how well you navigate an IDE. I care how well you think and approach an unstructured problem under pressure in an unfamiliar environment.

(FWIW, I would never give a problem whose solution would require more than 30 to 50 lines of code. Lots of people would put in one line for the function and then explain the function to me later. No one has ever complained about cramping. You're the first.)

naz• 17 years ago

You could put some screen recording software on the computer. Of course it would be nice to tell them about it in advance.

Pistos22• 17 years ago

Or perhaps ask them to use version control and check in the code after each little step of the design or development.

Pistos22• 17 years ago

While I can't really argue with the points made (though perhaps the exhaustiveness of the list is debatable), the quality of the English significantly diminishes my opinion of the article.

Incorrect use of or failure to use indefinite articles; run on sentences or comma splicing (e.g. in point #3); subject-verb agreement...

I might have overlooked these things in another context, but the article is trying to present tips on "how to judge how good a candidate is", and even talks about communication skills.

HeyLaughingBoy• 17 years ago

These are good. One of my favorite questions is "what have you done in the past when you had conflicting requirements?"

If you say it never happened and have more than a year or two of experience, I'll be very surprised.

In our interviewing process we divide up the type of questions to ask the applicant with some overlap. So one guy will ask mostly process-oriented questions (what kind of unit testing do you do), another will ask CS/programming related questions (what are common problems in multithreaded apps and what are some solutions), and another will ask team-oriented and "soft-skills" stuff like the one I mentioned above.

It gives us a more rounded view of the candidate than whether or not he can code.

arohner• 17 years ago

My problem with the first point - Make them Design Something - is that design is a lot harder to grade than the second two. It's easy to see if someone can write fizzbuzz, or find the bug, but it's significantly harder to grade a design.

Good design operates in the face of real world constraints, unlike typical interview questsions (see the article on Apple design about Real Artists Ship).

As an interview question, I used to ask people to design the DB schema for Netflix. Almost everyone could get something that would kind-of sort-of work. Of course there was a gradient of bad to good answers, but a passing or better grade on the question did not help predict whether the candidate would get an offer. Asking FizzBuzz was a better predictor of whether they would pass the interview process.

How to judge the candidate you are interviewing

Related Stories