Totally agreed. "Fizzbuzz" has become a bitter joke among good developers, but it tests something (sadly) important: can you write a basic loop and conditional statements? Or more cynically, are you a total fraud? You don't have to ask Fizzbuzz to test that, but you do have to ask something.

For me, if you pass the test of basic competence, and you can demonstrate evidence of accomplishment in any language, and you seem to pick things up quickly, then you're probably a risk worth taking.

(Actually, ignore everything I'm saying. I don't want the rest of the market to catch on. :)

If you're hiring a HR manager, do you have them take a basic English skills test?

If you hire an electrical engineer, do you test them on understanding Ohm's law?

If you hire a window washer, do you test them on cable strength integrity questions?

> If you're hiring a HR manager, do you have them take a basic English skills test?

Yes, an interview in English is an English skills test.

Programming has the odd problem where you want someone that speaks code so you need to ask them to speak it in some form or other. Yet, if you ask someone to demonstrate even the most basic form of competence some people lock up.

IMO, the best option is to give programmers the same kind of fuzzy test your giving HR managers. You don't need someone that can decode for (int i = -6; i++ < ++j; k++) ... but they need to be able to understand how to use a loop to get something done.

Yep, that's exactly my point with the HR example. The interview itself should be the programming test, not some artificial, condescending introductory literal test.

If interviewers dealt with candidates from any other professional field in the same way that software professionals are commonly interviewed, there'd be a ton more people walking out of interviews.

The problem is the number of people that fail FizzBuzz or morally equivalent interview questions. It's so bad I think companies that don't ask candidates to code could skip interviewing about general background entirely, replace it with a 15 minute trivial coding exercise, hire anyone who passes, and be noticeably better off.

Maybe this isn't universal, but I'm used to most applicants being hopelessly unqualified.

Is this actually true? How many candidates have you failed for FizzBuzz specifically? Personally I've found it to be almost always passed. My previous company would ask for a simple implementation of pow() and strpos() and that had a decent filter rate.

1. Damn right (more specifically I'd ask them to write something simple)

2. Damn right (more specifically I'd ask some kind of basic problem about circuits)

3. Of course not - don't be ridiculous. I'd test them on their knowledge of chemistry, fluid dynamics and celestial mechanics (duh).

I'm not sure about the point of your post, but to respond:

1) No - you screen those out with spelling mistakes in their resume

2) Maybe? I'm not sure - I'm not an electrical engineer. Then again, credentialing an EE is probably easier than a programmer.

3) This one's not even a good analogy - of course not.

What makes programming a little different is that it's turtles all the way down. While you might not need to find the average of an array, you will need the ability to reason about such things. You'll be reducing a collection of items, or mapping them or summing them.

You basically must deal with abstraction as a computer programmer. (And I'd argue that yes, assembly deals with abstraction)

1) But you don't use the resume to detect whether somebody is blowing BS about their software understanding?

3) It's a very apt analogy. Tons of especially lower level candidates are doing weird tricky CS problems at interview even if they're building yet more basic reporting systems.

Regarding abstraction, why don't you ask them to describe projects they did, instead of grilling them on concocted problems you know are beneath the level of person you wish to hire?

Google et al aren't asking to find the average value in an array. They're asking questions that boil down to "do you know the Boyer-Moore string search algorithm?" or "Can you correctly identify this problem as a rephrasing of the boolean satisfiability problem?" which, in the context of an interview, correlate only weakly with whether you're a good software engineer and instead correlate most strongly with how frequently you took or refreshed your Data Structures and Algorithms courses.

>>instead correlate most strongly with how frequently you took or refreshed your Data Structures and Algorithms courses.

It is well known that this companies test for this knowledge. They even tell you about it during their process so you will be ready for it. At the very least, it tests that you can learn this things from study. If you fail at them, you either did not prepare in the way they told you to, which is a failure to follow instructions, or you tried to study and it wasn't enough, which is a failure of ability to learn. There are probelm with this; the conext on which you are evaluated is vastly different than the environemnt wher eyou will ahve to apply it. But that doesn't mean the assesment is completely random. It tests for some qualities that will be important on the job.

This is complete BS. It's possible you got a bad interview, but this is not remotely the pattern. If it were, Google would struggle to be hiring hundreds of developers a week.

Given the number of developers I've seen who list SQL as "expert" and can't write a simple JOIN, or actually cannot complete the FizzBuzz challenge. As an example, I've been a pretty big fan of JS for a long time (since well before 'The Good Parts'), and after "AJAX" became the next big thing, wound up on an interview panel, and man, the number or developers putting "Expert" on their resumes who didn't even know some fundamentals were staggering.

Maybe it's just me, but when someone uses the term expert, I tend to be doubly suspicious. Especially if they use that for more than one or two skillsets.