in reply to Re: Evil Interview Questions
in thread Evil Interview Questions

And how exactly does the interviewer know that your years of experience translates into skill? Given your years of experience, I'm sure you've met other developers who, even though they have many years under their belt, could hardly barely write a "hello world" program.

Simply put, testing helps find out if the candidate is fibbing about their skills or not. And yes, a lot of people lie (or exaggerate if you wanna be nice about it).

Replies are listed 'Best First'.
Re^3: Evil Interview Questions
by locked_user sundialsvc4 (Abbot) on Feb 12, 2008 at 00:09 UTC

    I know that a fair number of candidates are fibbing lying about their past experience. They have to, as long as gatekeepers filter-out resumes based on the field-names they put into a “skills” array and the numeric value of that field.

    The best solution that I have found for this phenomenon is to talk about soft skills in the job-requisition, and hope that enough of it makes it through the HR-gauntlet to be useful. Describe what the candidate will be responsible for, not in programming-terms but instead in business-terms.

    A problem that you will very-frequently encounter is that candidates simply don't have “business” skills to begin with. Nothing in their formal education (that they might well have spent tens of thousands of dollars for) has prepared them for this. So they have studied “wrenches” for years, and they've maybe even torn-apart and rebuilt an engine, but if you make the mistake of asking them an abstract question you get a blank stare. But when I'm interviewing, it's those abstract questions that I want to get answers to.

    One of my favorites:   “In your opinion, what makes a Truly Great piece of software, and why?” Notice that there is no right answer. That throws a lot of people... I wish it didn't, and I don't mean for it to. It's another chapter of the story of folks who get out of school with a perfectly-honed ability to take tests, and no practical knowledge whatever. That's a failing of our educational and training system, not of those people.

    Let me put it this way:   “around here, we don't ‘write programs in Perl.’ Well, that's what we Little-D-Do. What we Big-D-Do is to build solutions to business problems for people who, quite frankly, don't want to give a damm about computers except to use them. We intend for them to find that our solutions are technically flawless (“but of course”) ... and to find that our solutions are great.”

    I'll omit all mention of what programming languages we are using, if I can. The folks who don't particularly care what language we're using are the ones I want to talk to. The ones who know how to design-and-build Great Software... in anything.

    It can, of course, be problematic to get these things through “the HR gauntlet,” and yet you have to work with these guys and do things their way, because they're the ones who make it their business to keep you from getting sued. “Hell hath no fury like a lover loser-candidate spurned...”