multipart-mixed

Dear Programming Job Applicants...

I know this might come as a shock to you, but most programming job applicants suck. I've interviewed my fair share this month, and it'll be a lot easier for all of us if I tell you upfront what I'm looking for.

As a hiring manager, my job is to make sure you can do the job you're applying for. For programming that means you need to be able to program. So when I whip out a laptop in our round-one interview and ask you to write some code, try to hide your terrified expression.

Reasons for Suckitude

Bit Rot

A common sucky interviewee is the guy whose last job was management and he apparently thinks, "since I was a programmer before, this should be a piece of cake." As it happens, if you haven't been programming for a while, you can't program anymore. Programming is not like riding a bike, it's a skill that requires constant use, because:

  • It's a highly detail-oriented activity. Computers are real persnickety about details like pointers versus values, where you stick your semicolons, and the types of variables. (I'm talking C here.) If I tell you to return a long and you start typing int everywhere, I'll give you a test case that'll overflow your ints.

  • Programming languages move on. Even C moves on. Have you heard about C99? It appears that most C programmers haven't. I know, I know, it's hard to keep pace with technology and it's only been a decade since the standard was released.

  • Computers think differently than humans. If you're not fresh on thinking algorithmically, then you won't be able to flip into that mode on the spot. You need to be able to reason through a problem in a way that you can then express in code.

I brought in a guy that hadn't programmed professionally in years, in fact he didn't even have programming on the first page of his resume. However, he had been practicing while looking for a job and he rocked my programming interview. He reasoned through the problem, wrote the code, it ran perfectly the first time. I hired him.

Over-Hyping Yourself

Whether in your resume or the initial phone screen, a lot of candidates hype their skills to make it into the in-person interview. Here's the problem: I set the difficulty of my programming interview to match what you say you can do. If you say you're a master of network protocols, guess what, I've maintained a TCP/IP stack, and unless you're really a master I'm going to bury you.

Be honest, tell me what you do and don't know. If you wrote some Scheme in college but have mostly forgotten it since, tell me that. If you say you're still good at Scheme, I'll brush up on Scheme myself just so I can give you a Scheme programming question. And yes, I actually do that, because it's worth a few hours of my time to prepare for an interview if it saves me from making a bad hire.

Not Understanding The Problem

Generally I consider it a good thing when someone starts typing away. Better than the blank stare, certainly. But before you type, make sure you understand the problem. If the question isn't so easy that you know the answer offhand, then:

  • State the problem, out loud, in your own words and get my agreement that you understand the question correctly. Example: "just to be clear, you want me to reverse the characters of this string in place. I shouldn't allocate a new buffer for the reversed string." Now's the time to ask questions about object/memory ownership, size of data types, performance expectations, etc..

  • State how you intend to solve it, again out loud. Example: "I'll find the length of the string, iterate over the first half of it, and at each offset I'll swap the character with its corresponding character offset from the end of the string. For an odd-length string the middle character will stay where it is."

  • Now start typing.

I've interviewed several people that couldn't write Fibonacci sequence. I'd tell them what it was and write on the whiteboard the first ten numbers so they could see it. They'd start typing and immediately go into the weeds. I would ask, "tell me in English what the n-th Fibonacci number is." And they wouldn't say anything, they'd keep trying to type. I didn't hire any of them.

Forgetting How To Test

With the problem understood, how can you test that your program is correct? You don't need to go all xUnit-crazy, just write some asserts that test boundary conditions. If you screw up your code, you should be the first to know. Don't make me point out cases where your code breaks.

One other thing: if I ask for a program sample ahead of an interview, don't even think about sending in code that doesn't include unit tests.

Forgetting Basic Debugging

So, your code isn't working, what do you do? Stare blankly at the monitor? No. If you've got a source-level debugger handy, use that. Otherwise just use printf(). Keep it simple and keep going. I'm happy to wait while you work through the problem, in fact it's refreshing to see someone that's undaunted by a bug.

If you're still stuck, start sketching out the problem on paper and start asking me questions. I'm happy to answer questions if you're taking charge and just need a second opinion.

Editor Flailing

It's funny how many people can't edit text on any machine but their own. I tend to interview people on a laptop running Ubuntu, and I open gedit for them to use, with the offer that they can use any other Unix editor they like. Most can barely navigate gedit, and it's stupid simple.

Don't ever let yourself get hung up on the editor. If you can't figure out the magic command keys to indent code the way you like, just press the damn space bar and indent it yourself. Flailing in the editor wastes time.

I interviewed a guy that was a Windows programmer but he could barely use vi. He went ahead and, without much elegance or speed, plowed ahead with vi. He gave up on pretty formatting, instead he stayed focused on the problem and wrote solid code. I hired him.

Getting Out of Teh Suck

Say you're a manager and there's no management jobs around, so you decide to go back to programming. There's a simple way to prep for a programming interview: program. Shocking but true. Don't think about how you'd reverse a string in place or determine if a number is prime (common interview questions) but actually write the programs. You'll be surprised how rusty you've gotten.

Think of it like "Programming Kata," practice you do daily to keep your head in the game. Google for common interview questions and write them. Write simple programs in every language you know. Try pushing yourself, too--struggling through a problem is a skill in itself. This isn't something you need to spend all day doing, but spend at least a half hour each day.

Pre-Interview Research

First of all, if we get to the point of the interview where I ask if you've got questions for me, and you say, "so what does your company do?" the interview is over. Sure, I'll humor you and answer the question, but I've mentally stuck your resume in the trash can. There is absolutely no excuse for not looking up the company's web site and seeing what we do.

There are fair variants of the question. For example, "what part of the product does your group work on?" That's not obvious to an outsider, and you should ask that question so you know what you're getting into.

Second, if the HR person scheduling the interview tells you any names of people you'll be interviewing with, write them down and Google them immediately. If you're interviewing with me, guess what you'll find? (If that's how you got to this page, congratulations, you'll probably do well in my interview.)

Finally, brush up on any technologies mentioned in the job post. You don't need to be an expert, but you better at least have a looked-it-up-on-Wikipedia level of knowledge. When I say, "we write our management GUI in Ruby" and you reply, "what's Ruby?" then the interview is over. It was in the job post--duh.

Thank You

Thanks for taking the time to prep for our interview. You'll know how to impress me and other technical hiring managers. I haven't given away any of my secrets (in particular my Kobayashi Maru interview question for systems programmers that get cocky) but now you know what to expect.

I want to close with a bit of perspective: if you're a solid programmer, the programming interview should be fun. Show me the passion you've got for your craft and we'll be pals real quick. I'm not trying to beat up candidates because I'm a sadist, I'm looking for people I want to work with. So get ready to type, I'm looking forward to it, and so should you.

Comments

@Bit Rot
I agree it's /not/ like riding a bike. But I hadn't programmed perl in 2-ish years and it took a 1 day - 1 week to get back to my level of competence it in. I don't think that's bad... given you should probably practice a language before an interview...

I wish more programming interviewers would actually test you. Too many don't test applicants. I personally am horrible at self-marketing but I suspect I can do the job.

I also think that all applications should have some basic programming test submitted with them. Please submit resume with a module that does the following... this helps on both ends. You weed out people who are too lazy to do it, or even incapable of finding a way to cheat on it. Given you still will want a test in building to see if they cheat.

but I would also say that you should allow a developer access to any of the resources he would actually be able to use on the job. Books, internet, forums, external libraries, etc.

do you look over peoples shoulders or do you monitor with, something like vnc or screen? also do you get annoyed if they immediately start coding boilerplate? If someone asks me to code a perl script I might just start typing to get started with boilerplate tasks.

The worst candidates I've seen:


1) rattle off some elegant explanation without actually understanding the explanation:

LASER is "Light Amplification by Stimulated Emission of Radiation" and many people can recall the acronym yet cannot explain what radiation is.


2) Decided to put every language under the sun on the resume yet falter on each. I like asking one question for each of five minor languages mentioned in the resume.

One candidate decided to put LISP on the resume, so I figured I'd ask a basic lisp question about car/cdr. The rest is history


3) Use third-party technologies, expecting we are not aware of them. This is rife with pitfalls, and I like to ask nontechnical questions about them.


4) WORST WORST WORST thing ive seen: Linux/Unix programmers who are unable to work on a terminal. Not every machine has X, and not every machine has Eclipse!

So, at what point do you ask those irrelevant cookie cutter "behavioural" questions.

I watched computers grow up. I saw my first computer when I was four years old. It was and old IBM mainframe with a card reader input and a printer output. I taught myself basic on an atari 400 with a “kingdom” program by breaking it and playing it until I ran into a “syntax error” accidentally discovering basic debugging and unknowingly teaching myself structure by mimicking the way that programmer used gosub in my own programms. I taught myself assembly with the monitor function on an apple II plus and got stuck trying to interface a library of machine functions with apple basic until my step-dad asked if I had ever heard of C. I then learned C and Pascal via Borland Inc. I always coded for fun and really enjoyed making simulations of formulas found in nature. I later found out that was called artificial life programming. I have continued programming and when I found myself without a computer for many years, I had some floppy disks with and old copy of Turbo Pascal for my simulations and some with Netwide Assembler for my DOS low level playing. I have learned and forgotten Java and Javascript and have dabbled in python and program in Visual C++ still trying to understand windows. But finally attacked lisp and though it might have been nice to learn it first, I am glad I learned it now.

Thirty years later and many disciplines later, I find my mind soaring. I bounce back and forth between CL and Scheme like I use to bounce between C and Pascal. I am about to leave the military and I was curious to see what programming jobs might be out there for Lisp when I came across this page. When my Dad was the age that I am now, he went from being an electric engineer to a lawyer which is what he really wanted to do all along. He did engineering because he excelled at it but that failed to be enough on its own after twenty years. I have honed the art of management of which I have great talent but I want to make my living programming because that is what I love to do. This page makes that seem very possible for me. This is more of a thank you for the inspiration as I would also like to live in Texas not Colorado.

One note though, I have always started my programs with pencil and paper. And, when I get stuck, I go back to the pencil and paper.

Post a comment