Let's Resume

Please be prepared for one or two work-related posts. Don't worry, we'll swiftly return to the more pointless direction of this blog.

Several years ago I started interviewing candidates for various engineering positions. This has been a fascinating experience for me. After you sit on the other side of the table, you gain a much deeper appreciation of how hard it is to find good workers, and also learn a lot about the wide variety of skills and personalities that are out there.

I have to admit that at first I was a horrible interviewer. To start off with, I was nervous, even more nervous than when interviewing for a job. (Don't ask me why. It's a very irrational reaction - when I'm conducting an interview, I have all the power and nothing to lose, but when I'm an interviewee, there's a lot more on the line. It probably has to do with my general discomfort with occupying a position of authority.) The more interesting problem, though, was that I was unprepared for the need to exert control over the interview.

I had previously been in many different interviews throughout my life, from my first application to Frank's Family Foods up through the whirlwind Week Of Too Many Flights And Interviews just before arriving at my current position. These were with many different types of companies, but all had one thing in common: I was the person being interviewed. Because of my personality and my sense of etiquette, I approached all these interviews like a friendly oral exam. I would wait patiently for my interviewer to ask a question, formulate a response, communicate it, make sure they were satisfied with my answer, and then wait for the next question. At the end, if prompted, I would ask questions of my own.

This process seemed completely natural and right to me, so before I started interviewing others, it didn't occur to me that some candidates might have a different idea of their role in an interview. As a result, when I started my first interview, I completely lost control. I had diligently prepared my list of questions, carefully calibrated to evaluate the candidate along a set of criteria, and started with an icebreaker about his ride to the office.

That was pretty much it.

He just kept talking, and talking, and talking. I'd nod and say, "Yes," or "Mmm-hmm." If he asked me a question, I would respond. I kept waiting for him to finish so I could start with the next question, but seconds stretched into minute, and soon I realized that I had lost him. At the same time, though, I have this really powerful inhibition against interrupting people, so it was very difficult for me to cut him off. I finally did so, way too late, and asked a real engineering question, only to have the experience repeat itself. I think I only got through a handful of questions.

After personally debriefing my performance, I came to understand what had happened. What this person was doing wasn't wrong or bad, just different. While it didn't fit well into my style of interview, it did allow this person to demonstrate aptitude, to direct the conversation towards the areas that most highlighted their skills and abilities, and demonstrated their ability at communication. From an unemotional perspective, it's interesting to think of the trade-offs that this style takes. The downside is that you don't learn what the interviewer is looking for, so you risk wasting valuable time on items that won't help your case and may work against you. On the positive side, it may allow you to mask certain deficiencies and focus the interviewer's attention on your most positive aspects.

So that was interesting to think about, for the next time I interviewed. In the meantime, I had a job to do. As an interviewer, my responsibility is to evaluate a candidate's technical and personal skills, and present my employer with a recommendation (whether to hire, where they would fit, and at what level). Those early interviews kept me from being able to make strong recommendations one way or another, since I wasn't drawing out enough information on the most important areas.

Fortunately, as with most things in life, the longer I did it the better I became. I've become more comfortable responding to a variety of situations, such as really quiet candidates, ones who can't write code, or ones who have been programming for longer than I've been alive. I also have become more comfortable in my role, which has led me to be more assertive, which ultimately is better both for me and the candidate. Now, I typically greet the interviewee, introduce myself, and give a brief overview of the process. It might be something like, "Hi, it's nice to meet you! My name is Chris King, and I'm a software engineer here. We have about 45 minutes for this interview. I'll start off asking you some questions about your previous experience, then some programming questions, and we'll write some code on the whiteboard. I'll leave a few minutes at the end to answer any questions you have for me. Are you ready to get started?" I like this because it lets the candidate know what to expect, it puts me in control of the process, and provides an excuse if I need to cut things off at any time.

I wanted to share a few thoughts about the interviewing process. Note that this is not at all meant to be a generally applicable sharing of wisdom, just codifying the very narrow slice of existence I occupy (mobile software engineer living in the San Francisco Bay Area).

First, Tips For Writing A Resume.

• Most importantly, keep it short and focused. I should be able to read it in a few minutes and get a rough idea of what you've done, what you're capable of, and what you'd like to do.
• That doesn't mean you should cut out experience that you think is relevant. But if you worked on five projects at one company, you can list them all on a single line, not patiently explain for each one that you helped with the design, coding, and debugging.
• List your skills in a separate section. If you are stronger in some skills than others, either explicitly break them up (I like doing "Expert In", "Proficient At", and "Comfortable With"), or list them in order from greatest comfort to least.
• Remember, the resume's purpose is to get you an interview. It should make me want to talk with you, not be a closed book.
• Along these lines, you don't need to exhaustively explain everything you ever did at a company. Instead, pick the most interesting ones that you want to talk about and apply most to your current search. Make me want to learn more.
• Feel free to put anything on your resume. I'm used to at least seeing work experience and education, but if you have other things you would like to communicate (articles you've written, things you're passionate about, future career goals, etc.), go ahead and include them. This also includes sample code projects that you'd like to share.
  
• Edit your resume. I have been shocked at how often I see resumes with misspelling, poor grammar, or other basic technical problems. Remember, your resume is the first impression you'll make on me, and you want to make it a good one. Now, you can be a brilliant programmer and a poor writer; but, a new job is an important step, so take the extra time to show your resume to a friend or professional and clean it up. Granted, as an English Literature major I'm biased, but I automatically associate sloppy writing with sloppy thinking and a general lack of carefulness.
  
• Formatting is less important. I won't think less of you for using an ugly font in the same way I'll think less of you for confusing its with it's. However, it can make a slight difference, so if you feel like punching it up, here would be my advice:

1. Follow the standard resume format: Name at the top in big letters; then a Summary or Objectives section; then skills; then work experience; then education; then everything else.
2. Use plenty of whitespace to clearly separate sections. Label sections with a large-font title.
3. Use bullets where appropriate. Don't bullet a list of single words; this makes it look like you're padding. However, bullets can be perfect for listing project summaries or titles.
4. List the years that you were at each job. This isn't a big deal, but I'll be more likely to ask about something you were doing in 2006 than something you were doing in 1996.
5. Pick a readable font. Personally I like to use serifs for my text and sans-serifs for headers. In any case, you should generally avoid unusual fonts, italics, very small text, and wingdings.
6. Notwithstanding the cardinal rule to keep it short and simple, don't fret about length. I used to be maniacal about making sure my resume fit on a single page, but haven't received a single-page resume from anyone in all the years I've been interviewing. If your resume is longer than a page or two, ask yourself, does it need to be? If you can trim it down, great! (Once again: the purpose of the resume is not to document everything you've ever done; it's to start and guide our conversation.) If it really needs to be that long, then don't cut out good stuff just to decrease the size; but keep in mind that I may end just reading the first page or two, so be sure the most impotant information is up front. (I usually try to read through a whole resume, no matter how long, but if I learn at 12:50 than I have an interview at 1:00, that just isn't happening.)

Finally, a big one to keep in mind: be prepared to talk about anything you put on the resume. Listing cool languages and technologies may have landed you the interview, but to get the job you will need to show you actually can use them. If you can't write Java, that's totally fine, you'll still get a job. If you list Java as one of your skills, and can't write a simple class or describe what an interface does, then you won't get the job. We can train technical skills, but we can't train honesty and candor.

Along the same lines, be sure that you've actually read your resume and understand it. If I ask you about a project on your resume, it looks really bad if you need to think for a minute about what, exactly, you did for it.

All that being said, I look to the resume to guide me about what questions to ask. I'm not trying to play "gotcha" or catch you off-guard. If I see that a candidate wrote C++ until 2005 and then Java since then, I will be giving coding questions in Java. I'll still expect you to demonstrate that you have worked with C++ in the past (e.g., you should know what a template is and what a destructor does), but it isn't fair for me to judge you in a language that may be rusty for you. If you declare yourself a C++ expert in your resume, then you're saying that it's fair for me to ask you expert-level questions.

One side note: When I interview a candidate, I usually get a Word document copy of their resume. At many large companies, though, they actually accept resumes as plain text files, or convert Word to plain text, to make it easier to search. If you are planning on submitting your resume to multiple companies, consider writing it up in Word first. Then, manually create your own .txt file using Notepad or a similar program. Bring over all the content, but structure it so it looks better in plain text. This will probably mean using more whitespace and CAPITAL LETTERS. By having this in your arsenal, you'll be able to handle submission in any form, whether it's to an individual person, into a web form, or through a jobs database system. Finally, you might want to consider saving a .PDF version as well. This doesn't seem to be as widely used as Word, but it is more portable, non-editable, and stable.

Anyways, that's that! I don't know how much more interviewing I'll be doing in the future, but people who follow the above steps should find themselves in a much better position. Assuming that they are looking for a mobile software engineering position in the San Francisco Bay Area. Good luck! (And, seriously, don't take this as gospel; I'm sure every interviewer has their own preferences and quirks, and what annoys me might be wonderful to someone else.)