[luhn]

The argument I usually hear is that many people don't do well under pressure or with others looking on. So by doing coding tests or whiteboard tests or whatever, you're selecting for people who do well in high-pressure situations, rather than people who are talented coders.

But I agree with you. I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz.

[inframouse]

On the one hand, there a significant number of people that can't fizzbuzz applying for the jobs.

On the other hand, there are a significant number of people that can only do the interviews and are not good engineers in general once hired.

This is made even worse by 1) the cottage industry teaching people to crack/break the interview process, and 2) the number of people hyping their personal "brand" via conf talks, standards nonsense, etc. as a way to sidestep more engineering vetting. (Not everyone does this of course -- but there's a significant number of people that do it just for career upside).

Personal anecdote as a hiring manager: I've found that some of the best interviewees but mediocre mid-level engineers are those with a history of low to mid-level jobs at the largest companies.

[lj3]

> I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz.

And I've interviewed many people who can do fizzbuzz because they studied for it (CTCI) and wind up being terrible programmers.

The end result? Technical interviews are, at best, a completely random hiring signal. You'd be better off flipping a coin. It's better to be lucky than good, so why not use luck as a selection criteria?

[jakewins]

But, if you aren't hiring a developer specifically to implement fizzbuzz for you, why are you giving them that as a problem to solve?

Hiring someone to work on a Flask REST API? Make them add a REST endpoint to a little flask app. Hiring someone to do CSS? Make them style a form. Hiring someone to build a database? Make them safely write to disk.

This is far from random - it's been almost twenty years since Schmidt and Hunter showed that a work sample is one of the best predictors of future performance, 24%, vs 3% for unstructured interviewing.

http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...

[lj3]

I couldn't agree more. The problem with most work sample tests is the length and the format. Most are too long and they have you start with nothing. Adding a rest endpoint to a little flask app is perfect.

It's a shame nobody actually does this kind of work sample test. And thanks for that study. It'll make for some nice ammunition. :)