Interviewing Tips

At my current gig, we are hiring Perl programmers. Lots of them. I mean, not tens of thousands, but we are actively interviewing people. And as I interview these applicants a few things have jumped out at me. I'll confess I thought all these things were obvious and self-evident. But after half a dozen candidates all making similar mistakes, I figured maybe I'd post about it. Following my tips won't get you a job, but it might prevent you from losing an opportunity you might have been well-suited for.

---

1. Know Your Target Company

Like I said, I thought this was obvious, but apparently not. If you are applying for a job at a company, a few minutes on Google will tell you quite a bit about that company. Why you would ever apply at a company you don't know anything about is beyond me.

Perhaps you are desperate for a job and so you sent out hundreds of applications? I'm not sure how wise a strategy that is, but you have at least 5 minutes before the first phone call to do some sleuthing. If you are in such dire straits that you are sending out applications willy-nily, surely 5 minutes to do some basic research about the company would be a good idea?

This is especially important since companies like to think you are interested in them. For some reason, we aren't too keen on hiring people who could care less about our goals and interests. Just sayin' ...

2. Tell Me Why You Should Have the Job

Ah, the lost art of the cover letter. It goes hand-in-hand with #1. If you know anything about the company and you have any related job skills, you should have a clear idea of why the company should hire you. Let me give you an example:

You write Perl. You see my job posting for Perl programmers specializing in MVC. You look up my company and see we are into making websites. Ok, here's you chance! Tell me why I should hire you. It should be obvious, right?

• I've been writing Perl for X years, and I have successfully completed Y number of projects that allows customers to create websites. I wrote several specialized toolkits for easy processing of data and creating HTML pages from it. Blah, blah, blah.
• I've also been experimenting with iOS/Android/WebOS/WP7 (God help you), and I have some experience in making websites scale to these emerging platforms. While this may not be your current target, I believe my experience here could blah, blah, blah, blah

See what I did there? I took related skills, and I combined them with a cursory knowledge of the company and position. With that very simple combination, I specifically show how you could be useful to the company.

This is apparently a new concept to a lot of people. My mother—the long-suffering English teacher—is shaking her head right now, as she has taught this to High School Juniors for years. It's called a "cover letter". You don't even need the formal cover letter in today's email-centric world. Just give me a blurb about your experience (executive summary tailored for my job posting) and another realistic blurb about how you think your skills would be a good fit. Put it right there in the email where you send me your resume (in PDF, for crying out loud—what's wrong with you?).

Really, it's not that hard. And you would be surprised how much it impacts your interview process.

3. Know Your Stuff (Duh)

If you are interviewing for a Java job, you better know your collection classes. If you are interviewing for your Perl, you better know how to use regexes to capture text. If you are interviewing for JavaScript, you better understand prototype-based inheritance.

Here's a tip: before the phone interview where I (or someone else) calls you and grills you about your technical knowledge, why not brush up on what you are interviewing for? Seriously.

If you are interviewing for a Perl job, I expect you to know regexes. I'm not expecting you to be the Regex God, but I am expecting you to know how to capture text with regexes. You might slip on some syntax here or there, but you need to know the basics.

Kind of obvious, but again, I've been seeing problems :-(

4. Know How To Say "I don't know" Properly

Question: how do the Perl functions exec() and system() differ?

Now if you know the answer, awesome. But eventually, you are going to have that interview where you will not know the answer. The following are two examples of saying "I don't know."

Answer 1: I don't know.

Answer 2: I don't know. But I know that system() does X, Y, Z, so if I were to guess, about exec(), maybe it's about A and B? Can you give me a context in which they might be used?

I'm going to give you exactly one guess which one helps you in an interview.

5. Know How to Be Wrong

Along with knowing how to say "I don't know properly" is the valuable skill of knowing how to be wrong in an interview. Because eventually, you are going to get an answer wrong. It happens to the best of us, and I'll let you in on a secret: most interviewers are purposefully trying to make you screw up.

Now sometimes that's because you are being interviewed by a sadist (it happens). But usually, it's because the interviewer is trying to find out what you know, and they can only do that by asking you a whole range of questions. But more important than what you know is how you handle what you don't know. In software, you are always having to learn new things, always getting tossed into the deep end (sometimes with some bowling balls to juggle). We interviewers know this. So we purposefully try to find holes in your knowledge or trip you up. We want to watch how you think, how you react, how you approach being in over your head.

Sometimes you can get more than half the questions wrong and still pass the interview with flying colors. No joke.

I'm not sure there's one, right way to handle being wrong. But I can tell you some very unhelpful ways to handle it:

Defensive: It's an interview. Breathe. It's ok. We all hate being wrong (trust me, I get it). It's not the end of the world, and no matter how much you want this job, being defensive about being wrong is not going to get you the job. Quite the opposite, actually.

Excuses: There's a fine line between explaining how you got tripped up (sometimes useful) and making excuses. Tip: don't blame the interview question—even if it was a crappy question :-)

Dismissive: "I don't see why you would do that anyways." Oh boy. It's an interview question, my friend. Of course, it may be contrived. It might even be purposefully confusing. That's not the point. The point is that you were asked a question, and the interviewer wants an answer. You may think it's a dumb question, but saying so isn't winning you points. Just sayin' ;-)

6. Be On Your Best Behavior

Unless you are interviewing with some very, very weird company, they are probably looking for an individual with the following traits:

• Friendly
• Able to get along with others
• Not prone to outbursts of anger
• Willing to give the benefit of the doubt
• Hard worker
• "Team player"

Companies are made up of people. People need to (more or less) get along. During the interview is not the time to highlight how you do not suffer fools or idiots. It's not the time to brag about how you had this manager who was an idiot and they dismissed your idea—and how you went around them and triumphed. It's not the time to talk about how much your current job sucks.

I cannot underscore the importance of this one. We'd rather hire a humble, friendly intermediate programmer with a lot to learn than some rock-star programmer who treats everyone else as lesser beings beneath his brilliance. All the better if you are a rock-star and know how to get along with people!

7. Work On Your Resume (Please)

This may be because my mom was an English teacher or because I took English Literature as a major, or just because I like to read. Whatever the reason, I highly recommend you put some work into your resume.

As for me, I found a really good format that worked for me and worked for my interviews. I've been using the same format for years (literally since 1997), and it serves me fine. But I update it every year, and I always check it for typos or awkward wording. Not because I'm looking for a job, but because that resume is such an important part of my career.

Don't just slap your resume together. Don't give me the same resume you gave the other guy—especially if we are not in even remotely related fields or vertical markets. I'm not saying you need to customize your resume for each job; I am saying you need to consider it though.

Say you made your bread-and-butter in Java like I did, and you are now applying for a job at a Mobile App company. Now is the time to go back and change your resume to highlight all the skills or projects that make you an ideal fit for this Mobile company. Don't give me a resume all about your EJB experience when all I care about is your iOS or Cocoa experience. Instead, highlight how your projects were about distributed apps, high volume processing, high reliability, flexible UIs based on clients, etc. I.e. give me something that shows that even your experience from 10 years ago is actually an asset—one I should not go another day without having on my team!

Oh, and give me the resume in PDF, type-set in all its awesome glory. Don't give it to me in DOC or DOCX where it might not display on my version of Word or on my Mac. Why short-change yourself? Just print it to PDF (take a look at PDF Creator if you are not blessed to be running a Mac) and make it as portable and beautiful as possible. Or send me both. But make sure I get the PDF.

---

There are many more tips, but I thought I'd just get these obvious ones out of the way.

To those out there job hunting, good luck! I mean it. I've been on both sides of the process, and I know how nerve wracking it can be to be out there, searching and searching for a job. Just take the time to work on these simple points and your interviews will be a lot more productive!