Aaron N. Tubbs bio photo

Aaron N. Tubbs

Dragon chaser.

Twitter Facebook Google+ LinkedIn Github

I’ve talked a little bit before on interviewing and recruiting, though with no particular depth or focus.

At the bank, I did a large amount of phone and in-person interviews, for entry-level, intern, and experienced hire management. At my current job, I have not had as much involvement, though I recently realized I’m past the wounded-animal feeling I had for the longest time after leaving the bank, and it’s time to start getting more involved.

In any event, almost every time I get involved in interviewing I have to deal with resumes. Sometimes I take a lot of time to do a careful study of resumes and everything on them. Other times, the resume is 10 pages long, and I realize that the candidate has missed the point, and I skim it at best. I know part of this is the CV format in action, but I think it all has to stop.

When it comes right down to it, resumes are brochures with which we try to sell ourselves. Like product advertisements, many resumes are full of padding, half-truths, and outright lies, and come with suggestions on how to save the world. Like an educated consumer, a good interviewer knows how to read between the lines on a resume and try and salvage the portions that are important to them.

So, if I’m recruiting for a software engineer position, there are some very specific things in which interested. Though I tend to be a technical interviewer at my current job (I was involved in more fit interviews at the bank), I think this framework works from both sides. The perfect resume I’d want to land in my lap looks something like this (yes, I know this disagrees with official counseling on resumes, and no, I don’t represent anybody other than myself with these thoughts):

  1. Your name – it would be nice to know what to call you
  2. Current email/cell phone – so we can contact you if we want to hire you, we’re going to want to get access to you quickly if this is the case, and aren’t going to trust that your postal address is up to date
  3. Mailing address – somewhere to send the official rejection letter
  4. School – where did you go, how long were you there, when did you graduate, what degree, and your GPA. This is just a heuristic, not a deciding factor, but it gives a sense whether one’s base abilities may have been picked up along the way or while in higher education. The GPA itself is a heuristic, and I don’t put a lot of weight into it, but a missing GPA, 4.0, or 2.3 are all things that throw up red flags in my mind. These things are often easy to resolve.
  5. Last several jobs. For each one, list start and stop (if these things aren’t listed, they’re usually trying to hide a gap, month resolution is fine), company, title, location, and a 1-2 sentence description of the role.
  6. Top three programming languages ordered by skill

Let’s dig a bit more into this. First off, there’s no objective. Objectives are stupid, and only useful in determining a) the candidate put no effort into the resume or b) the candidate has no idea what they’re applying for. They objective can only harm one’s chances of getting hired. Remember, I’m talking software engineering right now. Secondly, this thing should occupy half a page, maybe a full page with a large typeface. I want something that I can quickly use to get one’s background, and that I can use as a starting point for discussion during the interview. Navigating a 10-page CV during an interview is a nightmare.

I don’t really care that at your fifth-most recent job you lead a project to integrate a SQL Server back-end with a ASP.NET web front-end utilizing a proxy adapter factory pattern and some consultants in Bangalore. For the fit interview, this sort of stuff is going to come out when one is asked about a “difficult management situation” or a “project that failed” or “a project in which you went above and beyond the stated goal.” If I’m interested in technical challenges it’s going to come out when we try to discuss a technological problem that you solved in an innovative fashion" or we talk about a “really difficult bug to track down.” Almost every time I get in a discussion with somebody about past projects, it’s not the ones they have highlighted on their resume. Anything past a sentence or two is just more opportunities to make dumb spelling and grammar mistakes, and increases (exponentially) the likelihood people aren’t going to read it.

The opinions out there seem to be pretty mixed on whether to list languages and technologies on resumes. I think I see a lot more with it than without. Here’s what usually happens. A software engineer, whether entry-level or 10-years in industry, is going to be able to easily list a dozen or two languages and technologies they’ve used. If you don’t believe me, go ahead and start penning them down, you’ll be surprised. Most times you start asking somebody about the third or fourth item in their lists, you’ll discover they played with it for a pet project for three days, and know virtually nothing, or it was something they used half a decade ago and can’t really recall.

So, why list languages at all? In a technical interview with a candidate, I’m going to ask programming problems, I may have them look at code, I may have them write code. I need a language with which I can communicate. I’m fluent in a few programming languages, and chances are the guy next to me is as well. I can just as easily work with a candidate that knows C#, Java, and Lisp as one that knows C, assembly, and Ook!. So, knowing which languages a candidate is strong in provides a common mechanism for dialog on technical problems throughout the interview. Secondly, in a few seconds I can find out the candidate’s perceived talent in those languages, and pretty quickly determine if it matches up with reality. In addition, once we know a candidate’s top three languages, it provides a means of comparing language features, and how to determine the right tool for a job. Finally, forcing a candidate to list their top three programming languages makes them think a bit. Do they have a clear sense? Is there something interesting in there? Sometimes we get candidates in that have worked on obscure (to me, anyhow) functional languages while in school, or maybe have a lot of experience in something a little out of the mainstream. Talking to these folks is fun. Another interesting way to approach this is talking about not the top three languages based on ability, but talking rather in terms of favorites. People without favorite pet languages worry me.

As an aside, asking somebody what text editor they use, why, and what’s wrong with it is one of the more fascinating discussions one can have with a good engineer.