Resumes from the interviewer's perspective

A job or two ago, I worked for a major online retailer based in the Pacific Northwest. One of their prime tenets was that software developers (SDEs) were an integral part of the recruiting process. The HR/Recruiting folks pre-screened resumes, presumably looking for obvious clunkers like someone with only two years of VB programming seeking a position for a senior C++ developer (>10 years experience), although honestly, I never asked them what their criteria were. I assumed they added *something* of value to the process, though I was never clear just what. (Only kidding, Robin.)

However, I would periodically get called (or emailed), and asked to phone screen a candidate, or to be part of their in-person interview loop. When that happened, we were added to the candidate's recruitment entry in the tracking system, and could, amongst other things, access their resume. I often spent very little time reading their resume. Usually, I would look for a project they had worked on in an area I knew something about, so I could see what they knew about it.

For example, I spent several years of my life doing low-level network stack hacking, and know a thing or two about network programming. However, I am quite good at "playing dumb" and would ask a candidate basic questions, to see if they really knew the area that they claimed as well as they implied on their resume or not. I once interviewed a candidate who claimed to have worked on reliable delivery for UDP, so presumably she* knew something about networking. However, when I asked her to explain how to establish a TCP connection, she could only come up with, "You call the 'connect' method on the object."

An aside, for those of you who aren't networking geeks: A detailed answer would have explained the series of calls: A 'SYN' packet from the client, a 'SYN-ACK' packet back from the server, and an 'ACK' packet back to the server. A really detailed answer would have even explained piggy-backing the first data packet in the 'ACK' from client to server. An acceptable answer to that question would have included the phrase '3-way handshake', which is the usual way network geeks describe the above sequence. But "You call the 'connect' method on the object" just doesn't cut it from someone who claims that kind of in-depth knowledge.

However, other than looking for an area on which to quiz the candidate, I don't pay much attention to their resume. I don't look at their GPA, even for new college grads. I have know some great programmers with lousy GPAs, and some lousy programmers with great GPAs. I generally don't look much at their work history, because it doesn't really tell me much about what kind of programmer they were, or what kind they would be for the company if we hired them.

I do look for what I call "resume fluff", such as a resume that mentions knowledge of both "C++" and "Visual C++". This suggests that perhaps you are padding your resume, because you feel it is too thin, or that you really think it is important that I know you know *both*. But I don't care what development environments you know well. I assume that anyone we hire is going to be smart enough to pick up whatever environment is used in-house. And I *really* don't care if you know MS Office. If you were being considered for a business role, that might signify, but for an SDE?

I also look for someone who claims deep knowledge (i.e. several years of good experience) in more than about two or three programming languages. I myself have been programming professionally for almost 18 years, and I would only claim deep knowledge of two languages on my resume: C++ and Perl. Sure, I have worked in another dozen or two (no kidding! It's amazing what languages a stint as a mainframe programmer in the late '80s/early '90s will expose one to), and there are probably six or eight in which I could be reasonably productive in less than a week's time. But a candidate, especially one recently out of school, who claims deep knowledge of any language that wasn't invented at his school is a bit suspect.

Note that this is different than saying that you have done some development in a language. This is good, because each new language teaches different ways of thinking about problems, and solutions, so having been exposed to several languages is good. Note also that this contradicts the notion of listing every language you have ever worked in, so that when your resume gets entered into some recruiter's database, no matter what they search for, your resume pops up. I am not going to take a position on that right now. You decide. Maybe in a future rant I will post my thoughts.

So really, I am skimming your resume to see if you are just "making stuff up" (which does happen), and to find areas where you claim detailed knowledge of something I know about, so I can gauge the depth of your knowledge. After all, if I find that you exaggerated your level of knowledge in one area, you probably did in others as well.

So what does that leave for us to talk about during the interview? What else? Programming. I will ask you to write code, to design classes, to discuss tradeoffs, in short, to do the things that you will need to do if we hire you. But that is for another day.