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?