If there's anything I've learned from working with software developers over the last 6 years, it's that they are some critical mofos when it comes to the technical skills of those that they interview for open positions.

Sample questions (I'm making them up, but you'll get the gist) from a normal live group technical interview in a  software company (that almost always includes a whiteboard - your first sign that this can get ugly quickly):

-Hey Johnny, walk us through how you'd optimize that Oracle database to run in a pure SaaS environment on the whiteboard.

-Moose, glad you're here for the third round.  Let's start by you walking us through how you prevent a class from being inherited in a development environment like ours on the whiteboard.

-Don't you hate it when people don't know the difference between a stack and a heap, Melissa?  Byron here struggles with that, so why don't you take the marker and draw it out and explain it to him.

Translation for the non-techies: "We think you're OK, that's why you've made it this far.  Now we're going to attempt to publicly humiliate you by not only asking you for answers to these questions, but you're going to draw it out for us while everyone watches you.  Then we're gong to pick you apart.  If you survive, we'll move on in the process."

It's a pressure environment, but it underscores something software developers do better than practically any other job class in America - figure out if the person can actually do the job.

Most of us are pretty good at doing an interview and talking about someone's experience.  A few of us are really good at behavioral interviewing.  But the software developers?  They're going to make you work on something and prove that you can do the work, or at the very least that your thought process stands up to their standards.

I'm not talking the legendary braintwisters at Google.  I'm talking about task-related questions that really test your knowledge.

Here's another example from the boys and girls over at RethinkDB:

"In the interest of openness, we’ll post the smoke test that makes us turn away 19 out of 20 candidates within half an hour of a phone conversation (and that’s after screening the resumes). We don’t ask people to code a solution to a complex algorithms problem. We don’t ask to solve tricky puzzle questions. We don’t ask to do complex pointer arithmetic or manipulation. Here is the question that the vast majority of candidates are unable to successfully solve, even in half an hour, even with a lot of nudging in the right direction:

Write a C function that reverses a singly-linked list.

That’s it. We’ve turned away people with incredibly impressive resumes (including kernel developers, compiler designers, and many a Ph.D. candidate) because they were unable to code a solution to this problem in any reasonable amount of time."

Lesson for HR pros everywhere.  Whether it's a spot in your own department or a group that you're recruiting for, what exercise can you put a candidate through that will actually give you line of site to a) what they really know, and b) how they perform?

What if you asked your next HR Manager candidate to create a non-traditional job posting that would help in the marketing efforts to tough to reach candidates?  And what if they had 20 minutes to do it and you were watching as they drew it up on the whiteboard?

Tough?  Of course.  Fair?  By the letter of the law, yes.

Effective?  Depends how bad you want an exceptional candidate.  If you want a great HR Manager as bad as the team at RethinkDB wants great programmers, you wouldn't be shy about trying to embarrass someone.

On to the whiteboard.  And BTW, the development teams I work with would have DISMANTLED that long-haired UPS guy...