From: Steven D'Aprano on
On Tue, 10 Aug 2010 16:44:17 -0400, J Kenneth King wrote:

> Fizzbuzz is annoying in interviews.

It's not for the benefit of the interviewee, but for the interviewer.

> I've never worked at a job where I was under a timer while a group of
> people sat across from me and scrutinized everything I was doing.
>
> I don't see how it can honestly tell you anything useful about the
> person you're interviewing either. Do you really think that what you
> assume about the interviewee based on characteristics you can infer from
> their solution to be really, honestly true? They might even completely
> bomb the solution and still be a brilliant programmer, but you'll never
> know that if you trust this simple "fizzbuzz" test.


I think you've missed the point of the FizzBuzz test. Nobody should judge
your skill as a programmer from whether you can write FizzBuzz in 3
minutes during an interview. The test is to weed out the people who
aren't programmers at all, but think they can bluff their way into a
programming job.

Sounds ridiculous, but apparently there are vast hordes of people who can
barely program "Hello World" applying for programming jobs. One figure
bandied about -- how accurately, I don't know -- is 199 out of every 200
job applicants for programming jobs are barely capable of writing a line
of code.

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Fizz Buzz and similar tests aim to weed them out, *quickly*, so you can
spend more time interviewing people who actually are programmers.

I personally know somebody who got his start as a professional programmer
through pure bluff. He had read up just enough about the language to be
able to toss in the odd buzzword, his CV was a masterpiece of
imagination, and he was applying for a job during the Y2K panic when
companies would hire anyone who could spell COBOL correctly by the third
attempt.

The other reason for starting with something like the Fizz Buzz test is
precisely to see how the interviewee will react. Do they ask for
clarification if the question is underspecified? That tells you they're
smart enough to *notice* when something is underspecified, and confident
enough to raise the issue in an interview. That's 100 bonus points right
there. Do they go to pieces? That tells you they don't perform well under
pressure. Do they argue with you that the question is pointless? That
tells you that they're very confident, and quite likely arrogant enough
not to worry about offending a potential employer (and maybe even
deservedly so). This means they are potentially difficult to deal with.
That doesn't mean you don't hire them: some people are so good that they
deserve to be prima donna. But if you're not looking for a prima donna,
then it's better to find out early, so you don't waste either your time
or the other guy's.


> I've been in those interviews on both sides of the table. Neither side
> was a good experience.
>
> If a test is necessary, make it a take-home or demand source code if
> they have it. Read their code and judge for yourself the quality of
> their work.

Getting interviewees to do a take-home problem just means you hire the
guy who is friends with a good programmer, rather than the good
programmer.



> Any questions in an interview should be the usual "get to know you" type
> stuff. "What was the most difficult challenge you've faced on the job?
> How did you respond?" That sort of thing.

I *hate* those questions. For many people, the honest answer would be
"Nothing I've ever done in my job has been even half as difficult as
getting through the interview, because I'm bad at selling myself", but if
you say that, it just sounds like you're trying to bullshit your way
through the interview.


--
Steven
From: Roy Smith on
In article <4c6298c1$0$11101$c3e8da3(a)news.astraweb.com>,
Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> wrote:

> Sounds ridiculous, but apparently there are vast hordes of people who can
> barely program "Hello World" applying for programming jobs. One figure
> bandied about -- how accurately, I don't know -- is 199 out of every 200
> job applicants for programming jobs are barely capable of writing a line
> of code.

By the same token, there are lots of people with advanced degrees in
computer science who can't code their way out of a paper bag.

One advantage of the take-home test is that you can prepare the test
once and amortize the preparation cost over many applicants. It's a big
investment of time to interview somebody. By the time I get up to
investing an hour or so of my time on a phone screen, I'd like to weed
out the obvious rejects as cheaply as possible.

Even more interesting is to publish some problems on your web site and
instruct applicants to submit a solution to one of them along with their
resume. This makes the per-applicant cost to administer the exam
essentially zero. It also has the nice side-effect of weeding out the
resume spammers. To be honest, I've never done this, but I've seen
companies that do. I may try it sometime.

I still want to see the candidate write some code during the interview.
This gives me a chance to feed them a problem incrementally and see
where they take it.
From: Ben Finney on
Tim Chase <python.list(a)tim.thechases.com> writes:

> Unfortunately there are candidates who would give your answer but then
> have trouble with "Then why are the Last-Modified HTTP headers showing
> a date several months before our interview?"

My response: “Ha! That's a trick question; 'Last-Modified' is a field in
the header, not a header itself”.

That might lead to the “why are you interested in leaving your current
position” question rather precipitously, though.

--
\ “Courage is not the absence of fear, but the decision that |
`\ something else is more important than fear.” —Ambrose Redmoon |
_o__) |
Ben Finney
From: geremy condra on
On Wed, Aug 11, 2010 at 6:04 AM, Roy Smith <roy(a)panix.com> wrote:
> In article <4c6298c1$0$11101$c3e8da3(a)news.astraweb.com>,
>  Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> wrote:
>
>> Sounds ridiculous, but apparently there are vast hordes of people who can
>> barely program "Hello World" applying for programming jobs. One figure
>> bandied about -- how accurately, I don't know -- is 199 out of every 200
>> job applicants for programming jobs are barely capable of writing a line
>> of code.
>
> By the same token, there are lots of people with advanced degrees in
> computer science who can't code their way out of a paper bag.
>
> One advantage of the take-home test is that you can prepare the test
> once and amortize the preparation cost over many applicants.  It's a big
> investment of time to interview somebody.  By the time I get up to
> investing an hour or so of my time on a phone screen, I'd like to weed
> out the obvious rejects as cheaply as possible.
>
> Even more interesting is to publish some problems on your web site and
> instruct applicants to submit a solution to one of them along with their
> resume.  This makes the per-applicant cost to administer the exam
> essentially zero.  It also has the nice side-effect of weeding out the
> resume spammers.  To be honest, I've never done this, but I've seen
> companies that do.  I may try it sometime.

I can't recall who it was, but I remember being very impressed by a
company that did a variant of this a few years ago: they put
programming problems on the sides of pay phones, taxis, etc. with a
note that said 'If you can solve this, call us'. I have zero doubt
that they got some top talent that way.

Geremy Condra
From: Paul Rubin on
geremy condra <debatem1(a)gmail.com> writes:
> I can't recall who it was, but I remember being very impressed by a
> company that did a variant of this a few years ago: they put
> programming problems on the sides of pay phones, taxis, etc. with a
> note that said 'If you can solve this, call us'. I have zero doubt
> that they got some top talent that way.

Several companies have done that. You might be thinking of ITA
Software:

http://www.itasoftware.com/careers/puzzle_archive.html