Job Interview Strategies (Part II)

[ This is part 2 in a 3-part series; if you haven't done so, you should start with part 1 ]

I recently saw a job posting that took a slightly novel pre-screening approach.

Expert Web Programmer Wanted!

To be considered, send an email to the reply address on this ad. Please include
1. A clean plain-text resume and (optional) cover letter.
2. Details of the 3 best web-based tools or systems you've built. Annotate each by describing what you've built, why it's cool, what your specific role within the project was and how well the system scales.

It's an interesting approach. They take some of the most basic interview questions, "Tell me about a project you did... tell me more about that..." and move them out of the interview and up to the application/pre-screening phase. In other words "Write an essay, telling us why we should pick you for this position". Of course, this is still an essay question; they've simply moved part of the standard interview Q&A earlier in the process.

The position referred to above is for an "expert" web programmer. The job requirements state,

• You must have expert-level web programming skills. We use PHP, but don't require PHP experience if you can demonstrate your skills in a different environment.
  
• You must have strong SQL experience, preferably with MySQL.
  
• You must be capable of doing basic UNIX/Linux systems administration.
  
• You must have excellent written and verbal communication skills.
  
• You must be able to read a spec. and implement it.
  
• You must be capable of testing and debugging your own code.
  

So now we come to my favorite personal objection to most technical job interviews. If they want an expert programmer, why ask all of these questions? Why give candidates puzzles and stress interviews and essay questions? Why not ask, instead, for proof of qualifications.

Why not ask to see code?

In the numerous job interviews I have had across two decades, I remember exactly one time that I was asked to bring code samples. The hiring manager opened the portfolio I had brought, flipped a few pages (assuring himself that yes, indeed, it was code all right), closed the notebook, handed it back to me and proceeded to ask questions (none of which related to any of the code in the portfolio). No one else during that day of interviews, or the two that followed, asked me about code.

Occasionally, since that time, a job description will mention code samples. To my knowledge, no one has ever looked at mine. No one has ever questioned me in detail about them.

On the flip side, I firmly believe in looking at code. In one former job I had, I was asked to interview a prospective employee. I requested a code sample before the interview. The candidate hemmed and hawed and finally sent us a Perl script. I did a code review, handed it back to the hiring manager and said "No". I never did the interview. I didn't need to. We weren't hiring anyone at that junior a level.

Some engineers and engineering managers have told me that they ask candidates to "work thorough a little problem" on the white board during the interview. One former colleague remembered a company he'd worked at that took this approach.

We used to give the candidate a piece of paper and say, "You're probably tired of talking. Why don't you write a program on this sheet of paper, any program you like, and I'll be back in about half an hour, and we can discuss it."

Personally, I've always hated that sort of open-ended non-assignment.

Someone else told me his favorite question is to ask the candidate to write a sort routine or a prime number generator or code to reverse a linked list. Why on earth would I want to write anything like that when I can find sample code that does those things on the web or in a book?

In the 70's, a sort routine was novel. Today, it's not. That's the problem with most of the quickie little mid-interview problems — most of them aren't real (or pertinent). In the real world of the job, most engineers aren't called upon to write routines they could pull out of a library; they're expected to kow how to use the library modules. In the real world, most of us are never called upon to design a program on-the-fly in half an hour under pressure in front of someone we don't know — someone with the power to grant a job... or not.

Interview techniques should probe to determine if the candidate will fit the job; to that end, they need some basis in the real world. They need to mimic some of the situations a candidate would actually face if he were to be hired.

I don't object to interviewers checking candidate's qualifications, but an interview shouldn't be some sort of closed-book, no-references-allowed pass/fail test. It annoys me no end that people feel they have to "cram" for interviews; there are even books of "sample" questions and "suggested" answers! - Whatever happened to truth?

My former colleague also told me,

We might ask, "Do you think this program has any bugs in it?" and see what they understood about software engineering.

I like that approach. Has anyone ever handed a candidate some code that someone else wrote and asked the candidate to do a code review? How about asking them to look for bugs and problems or asking them to document the code? How about having the candidate describe how one might test a particular piece of code?

Then there's a technique that a former manager used to use with me, after I got the job. He'd ask me to walk him through some code I wrote, explaining what it did. He'd ask me why I chose certain ways of solving the problem or of writing the code and he expected me to justify my answer.

I'd like to see this interview technique come into play for programmers. Ask the candidate to bring along some code he wrote. Then ask him to explain what it does and why. Ask probing questions. Find out what the candidate really knows.