Faking the art of interrogation

Brian Dillard, Tuesday, November 27, 2007 @ 4:55 am

Companies often ask their technical employees to interview job candidates, but they frequently fail to train them how to do so properly. I've working as a software engineer for more than a decade, but every interview technique I've been taught has revolved around how not to get sued. At a certain point in your career, your company probably figures that a previous employer taught you the ropes. That's unfortunate for both you and any potential hires who have misfortune to get stuck in a room with you.

How often have I been told to "just focus on the technical nitty-gritty and maybe talk a little bit about the culture?" I break out into a cold sweat when I hear these words. It's not that I've never participated in a polished, professional sit-down. It's just that whenever I have, it's usually been as the interviewee, not the interviewer.

Slowly, though, I've started to get a handle on the soft skills that come with a more senior role. I think I've finally figured out how a software engineer with little managerial background can fake it convincingly in the role of technical interviewer.

Start with the quiz

Even if you've been saddled with an ungodly long interview slot, you can fill most of it up with written or oral test materials. Of course, designing your questions so that they tease out intelligence rather than mere knowledge is itself a skill. Still, the straight-up technical grilling at least helps weed out the fakers from the folks with real programming chops. A thorough knowledge of relevant languages, trends and best practices isn't the only measure of a candidate, but it should give you a good baseline.

Ask for a self-appraisal

"Rate yourself on a scale of 1 to 10 on [insert name of technology here]."

This may seem like the cheesiest tactic in the book, but it can be useful if you use it as the starting point for a discussion about the candidate's skill portfolio. A colleague and I recently commiserated about rampant grade inflation; front-end candidates, for example, all tend to rate themselves as a 8 or above on JavaScript, CSS and markup. Compared to back-end programmers, that's probably accurate. But with UI development now finally accepted as its own discipline, the best candidates - or at least the most honest - will assess themselves against their own peers rather than against some mythical, DOM-fearing Java developer. Because you'll have conducted some form of test, you'll be able to compare the self-image with the reality. And because front-end work comprises so many different technologies, you'll quickly learn whether your candidate is a JavaScript geek who knows enough CSS to get by or a semantic-markup stickler who avoids the behavior layer like the plague.

You should also ask candidates to rate themselves on skills and technologies that fall outside their current specialization. This can help tease out their passions, their blind spots and the overall breadth of their resume. You'll learn whether they're at least aware of technologies they don't actually use. A .Net developer with a solid grasp of what's going on outside the ASP world may be a better fit for your J2EE shop than a long-time JSP-er whose horizon stops at Struts. Likewise, if you're an Agile shop with competencies on a number of platforms, then you want to know if your candidate is only dimly aware of this new thing called Rails.

Shut up as often as possible

At my old company in San Francisco, I had a colleague so taciturn that we'd ask him after each interview whether he'd made the candidate cry. You don't want to come off like some remote, remorseless hardass. But talking less will instantly raise your credibility - and the quality of the interview. For years, I would cover up my own nervousness as an interviewer by blathering when I should have been listening. If there's dead airtime, let the candidate fill it. You'll learn lots.

When in doubt, chat about the company and the team

Figuring out the "cultural fit" may seem like some esoteric human-resources pursuit, but general discussion about work habits, team dynamics and release cycles can give you more of a read on somebody than mere code talk. As the technical screener, you're better positioned than a manager or an HR rep to share information about the day-to-day reality of your company. Be honest but professional in talking about both the challenges and the rewards. Finally, don't wait until the last 60 seconds before asking if the candidate has questions for you. If they're not chomping at the bit to interview you, then they might lack the maturity and self-direction your company expects.

Have I missed anything?

For somebody who was just professing his lack of interview skills, I managed to spit out a lot of advice. Reluctant technical screeners of the world, what have I missed or misstated? Let me know in the comments.

Bonus question

In a future post, I want to tackle the best way to assemble the actual written or oral technical quiz for Ajax developers. If anyone has what they consider to be a killer question on JavaScript, CSS, XML, HTML or other related technologies, drop me a line at bdillard(at)pathf(dot)com. I promise to give you credit when I publish my post.

Technorati Tags

• JavaScript
• Ajax

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment