[romey]

How do you strike a fair balance between ridiculous interview questions (such as the example here, write code interfacing with some library from memory) and actually finding out a candidate's chops (assuming they don't have an open source history / github account). I think requiring candidates to have contributed to open source to be an unacceptable solution (although I can certainly see lending some weight to candidates with such credentials)

Anecdotally: We had a guy in for interviews a few months ago. In the phone interview prep by HR, it was mentioned that there would be some written “tests,” and the guy was extremely resistant. We had him in anyway and he did very poorly. The test was pretty simple: some stuff about magic methods in php, a fizzbuzz type question, and a few jquery selector questions (it was for a front- and back-end position), etc. Were we to granular with the questions? Did we fall into the same trap as Ted here?

[aidenn0]

1) You do what Bob did; have them write code and then ask why they did it that way.

2) Were the written questions on paper or a whiteboard? If so, you should at least give them the option of doing it on a computer with a screen editor (you know the way that almost everyone has written code since the 80s). We have a few computers with just about every editor known to man (well win32 and *nix only, but we could probably scrounge up a powerbook if we needed to) installed on them along with gobs of syntax-highlighting themes so that candidates can feel comfortable when writing code.

Ultimately some good programmers have trouble writing code on paper, and most good programmers have trouble writing code on a whiteboard (though they should at least be able to sketch out an algorithm graphically or with pseudo code as that's a useful communication tool).

[qdog]

I agree with #2 a lot, although when I start interviewing not sure that would make the first couple of interviews go smoothly. Usually takes me 3 or 4 interviews to get warmed up to the type of problems people like to solve in whiteboard interviews.

When I just randomly interview a single time, I feel like a dolt, do pretty miserably. After a few interviews all the whiteboarding starts to take effect and I do much, much better.

When I interview people I usually explain a problem I'm working on and see if they can think through it, then ask a lot of questions about what they've learned from their past failures. People that can go into detail about something they failed at and learned from usually impress me, as I suspect they won't make the same mistakes over and over. Also, if you haven't failed spectacularly with something very hard and you've been a software dev for 10+ years, you might not be doing it right.

Obviously, I've been a dev for 10+ years, and I can't pass whiteboard tests very easily, so I suppose maybe I'm not doing it right, either...

[jseims]

If I were to ask 2 questions, I would:

1) Ask something simple, like FizzBuzz. You'd be shocked at how many people talk a good talk but can't actually write basic code.

2) Ask an open-ended question, like "how would you design a multi-player chess game". That leads to a discussion that lets you assess all sorts of traits, the most important of which is communication style.

[philwelch]

So "ability to write basic code" and "communication style" are your top two priorities?

[dennisgorelik]

These two are "must have".

[kragen]

Yes, in the same way that "breathing" and "drinking water" are the top two priorities for my life.

[philwelch]

By that analogy, it seems odd to hire someone only to find out they can't eat, and then a month later you need to hire someone again.

[kragen]

It's sort of more like embarking on a months-long nuclear submarine journey only to discover that nobody packed any food.

In this analogy, you are the company hiring programmers, and the things you need to survive are that your programmers can write basic code, can communicate effectively, and some other things — probably "can design software" or "doesn't rathole excessively" is the next item or two on the list. You're still in a lot of trouble if your submarine doesn't have any food onboard, but the situation is not nearly as bad as if the submarine lacks means for producing air and drinking water.

[EvilTerran]

One option would be to ask them to bring in some code they've written, and then talk through it with them in the interview. Even simple stuff like greasemonkey scripts could be pretty informative as to the candidate's level.

I'd be very wary of asking questions about potentially-obscure corners of tools (I don't know how obscure magic methods are in PHP) -- in a real work environment, you could look it up in a moment, but you usually can't in an interview. You could easily trip up a programmer who thrives with the references to hand, but isn't yet confident enough with the tools not to struggle without the references.

[bithive123]

Simple tests (what is this jquery doing? why is this ruby script failing?) are great as bogofilters as long as you actually use jquery and ruby on the job.

I interviewed somewhere a few months ago and had a former programmer turned product manager grill me about b-trees (this was a Ruby on Rails position). I was not surprised to hear later that he was the one who gave me the final thumbs-down, I assume he thought I wasn't worth it because I didn't work at the same level of abstraction that he did when he was a coder.

[spitfire]

He was seeing if you had a depth of understanding. I do that too.

I want to see that people are aware of what's going on below them. Not that it's just "magic" to some keyboard basher. ruby on rails attracts an extreme number of keyboard bashers, so they get extra scrutiny.

[scarmig]

That's very different from grilling someone about b-trees, though. B-trees are fairly irrelevant to Rails development; it'd be like grilling the interviewee on assembly.

That's not to say that you don't need to weed out the people who only know how to recite various incantations to make magic happen; a knowledge of what's actually happening is very important. But at this level of abstraction, the correct focus should be on different, more relevant things: HTTP, caching, security, etc, which Rails (I'm guessing) handles for you but you should still know.

[bithive123]

I get that, but when the interviewee is not just a "keyboard basher" then it suggests that the interviewer is the one lacking depth of understanding as they are conflating superficial ignorance with fundamental incompetence.

[codeonfire]

It makes it worse that you just know that guy stayed up the night before studying b-trees for hours just to show you up.

[richardlblair]

I think you were fair. jQuery selectors are pretty easy stuff, and you can pretty much guess at the jQuery interface and probably be right.

This is coming from a python guy who does very little javascript.

If he did get some of the methods wrong you could always ask the candidate what he thought the method did. If he knew there is a method to accomplish a specific task and he just got the name of it wrong that I'd say he is good to go. He can always google that kind of thing on the job.

[horsehead]

I had never heard of the fizzbuzz question, so I googled it. This is what I found: http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

..... I sincerely hope he's kidding. Having less than 8 months experience with a language (AT ALL!) I can write code out on paper that works. IS this 95%+ figure correct ? :S It's come up a couple times in google results, but I dont see where people are getting the number.

[sp332]

If you write it on paper, are you sure it's correct?