Month: August 2010

Tips on passing the phone screen

If you’ve made it to the phone screen, you’re doing better than *half* the people I look at on a regular basis.  Most fail with their résumé.  Now the tough part: You’ve got to sell me during the phone screen. When I walk out of the phone screen, I’ve got to feel like you’re not going to be a waste of time to bring in for an interview.  You have less than an hour to convince me.
As Sun Tzu once said, know thy enemy.  There are well documented methods to phone screen candidates:
Steve Yegge’s Five Essential Phone Screen Questions:
 

  1. Coding: The candidate has to write some simple code, with correct syntax, in (insert favorite language here)
  2. Object Oriented design: The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
  3. Scripting and regexes: The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
  4. Data structures: The candidate has to demonstrate basic knowledge of the most common data structures.
  5. Bits and bytes: The candidate has to answer simple questions about bits, bytes, and binary numbers.

 
Joel Spolsky’s Phone Screen Questions:
 

  1. Career History: The candidate should be able to describe what they’ve worked on and tell me about themselves. During this part of the process we’re looking for evidence that the candidate is a problem solver, or in Spolsky’s words, someone who “Gets things done.” There are two parts to a candidate’s history that are especially important, Technology and Politics; Technology is what they used to solve their problem. During this part, I’m looking for detailed answers about what they used to solve a problem, and it helps to determine how much of that process they were actually part of.  I had a candidate who had written that they had “Designed and implemented an IM client/server solution for their client.” Turns out the candidate had implemented the user interface for the software, but not any of its innards. Talking about politics with the candidate is really about finding out the story behind where they’ve worked. It’s about parsing the action verbs in the résumé from what they say to what they mean.  In a recent example a candidate talked about pushing unit testing to the entire team. It turns out they didn’t mean automated unit testing, just the testing of a component before throwing it over the wall to QA. I wish I were joking.
  2. Technical problem: It boils down to this: How would you design a data structure of block of code to do X? 
  3. Allowing the candidate to interview me.
And these are two of the most well known. I would say that these two phone screens will cover a good bit of ground. You can’t go wrong by being prepared for these questions.
The phone screen is your time to pitch me on the idea of you.  You’ve got to control your speaking.  You’re nervous and your brain is in fight or flight mode, but in order to succeed, you have to control that.
  • Smile when you answer the phone. A genuine smile makes you sound much more approachable.  You should act as if this person is the person you’ve been looking forward to speaking to the entire week. They probably are. Act that way.
  • Don’t take too long to answer the question: If I ask you about your job history, the answer should take less than a minute. Go ahead, time yourself talking about your job history.  Can you do it in less than a minute and still say everything you want to say?
Here’s my one minute job history:
I started programming when I was just old enough to touch a PC, have been around PCs ever since. In college I wrote a Winforms client tracking application for a non-profit, and while in the Army I wrote an application that assisted with the daily strength of the unit and sent that report to various agencies, reducing reporting time by a factor of 8. After the Army I took a web programming contract in Perl writing software that allowed companies to test their employees on Compliance (like Sarbanes Oxley training), and after that took a dual sysadmin/programmer role at an Auto Auction. In that time I wrote an application that automated point of sale setup by 67% for the 20 aucion lanes; after that I spent a year writing features that improved sales for a Human Resources Performance Evaluation product. Most recently I’ve been leading a team that writes code for the Army that allows them to document the breakdown of their units.
Notice the highlights. I don’t tell the interviewer just what I did, I tell him things that improved performance or improved reporting time (and ultimately saved companies money).  This is my first impression. This is what they learn about me: Whatever I do, I make sure it has a solid impact on the company I work for.  If they ask about these things, they find out that that in at least half the situations I was in, I came up with solutions that no one else thought about. No fluff, just the facts.
  • Not being specific enough. If I ask you a question about how to create a memory leak in a .NET Winforms application, that’s a specific question with specific answers (register an event handler to code that has a different lifespan than the code registering, and don’t dereference the event handler when you’re done in the code with the shorter lifespan (through its Dispose(), or Close() method). You can also create a memory leak by creating static collections and never cleaning up the collection when you’re finished with it (I’m thinking about those ugly global collections that people insist on creating for ‘performance’).  But notice the answer, I used specific .NET terms (Close(), Dispose(), Event Handlers, and static collections). I didn’t say, “By creating a list and never cleaning it up”.
  • Bullshitting the interviewer.  If a candidate puts ‘expert’ on their résumé, I’m going to take that ‘expert’ tag for a spin.  I’ll ask them them to describe garbage collection in .NET. I’m not looking for an ‘expert’ answer, I’m looking for the Reader’s digest answer.  Invariably the experience of the candidate inversely correlates to the adjective they put on their résumé. It has a little brother:
  • Don’t fudge your involvement in a project. If your résumé says that you implemented a solution, then you should be prepared to tell me top to bottom about that solution. You implemented it, remember? If you can’t, then you should rethink it’s position in your résumé.
  • No practical experience. I like to ask a lot of questions that reflect problems I’ve had to solve while working with C# and .NET. In ASP.NET, memory issues come up because most programmers don’t realize you need to unsubscribe from event handlers when you dispose of the form.  It happens in Winforms as well; and it’s something that anyone who has spent any time with a production application has run into.  In other cases, candidates will put object-oriented design as a skill on their résumé and not be able to tell me about how virtual and ‘new’ work in class methods. Knowing C# *does not mean* that the person knows what object oriented programming is.  The number of terrible C# applications out there attests to that.
  • Missing the trick question. I like to ask candidates how they rate in their favorite language (usually C#) on a scale from 1-10. Invariably, *everyone* says ‘8’. Taking a page from Eric Lippert’s play book, I ask this question to see how they’ll respond.  The best candidates will ask questions about this question, they know it’s never as simple as 1-10. Or, I’ll directly contradict something that .NET says about a class. For instance, since Generics are all about type-safety, I’ll saying something like, “I don’t like to use Generics because I have to constantly box and unbox items that I view in a generic collection.”  Good candidates will find a way to tell me that I’m an idiot, and bad candidates will agree.
  • Not asking questions about the company or team.  Every software team is different. There are different personalities, different management styles, and different goals.  You will never find two teams that work exactly the same, so why wouldn’t you ask the interviewer how his team works? Good candidates will ask questions like: What development methodology does your team use and why? Do you have Unit tests? They may even pull out questions from the Joel Test. Especially confident candidates will ask more probing questions. The fewer questions a candidate asks, the more it shows they don’t care about where they work, and that’s a red flag.
  • Practice, practice, practice. By the time the phone screen comes around, if you don’t know the subject matter, you’re probably not going to make it.  Even if you do know the subject matter but can’t explain that to the interviewer concisely and completely, then you may not make it.  Get on the phone with a friend or co-worker and have someone go through and ask you questions. Get on skype and use free recording software to record your performance.  Listen to it. Note whether you’re rushed or slow, whether you say ‘um’ and how confident you sound about your skills.

You only get one chance to make a good first impression, and the phone screen is that one chance. Make the most of it.

 

11 Ways your resume can help (or hurt) you

turn your resume up to 11

We’re in a recession. If you believe the austrian economists, it’s not going to get any better anytime soon. Now the good news: There are plenty of software developer jobs out there. Bad news: Everyone and their brother is applying for the same job you are.

Not all programming jobs are created equally. Working at a hipster media engagement firm is different than developing an internal line-of-business app, which is different than game programming or non-profit work.  

Most programmers work dull jobs in a corporate environment developing bespoke software.  It’s a living.  My advice won’t help you land a job at Fog Creek Software, or Amazon, but it will help you everywhere else.

1. Pare down your résumé. I don’t read pages worth of résumé. I just don’t.  It’s not interesting, and it tells me little about a candidate.  When I find a résumé with one page, that makes me a happy camper. I get grumpier with each subsequent page. 

2. Tailor your résumé to the position you’re going for.  If I’m hiring for a Winforms job, I’m looking for experience with C# and Winforms. I think it’s cool that you know Perl, and we’ll talk about it during the job interview, but don’t spend bullet points devoted to it. If you don’t tailor your résumé, it’s an indicator that you don’t care or are desperate.  You may be desperate, but pretend this is dating: Don’t show it.   

If you feel the need to include those jobs for the years of experience myth, then include the header and the position title. I don’t need gory details. If I care enough, I’ll ask in the interview. 

3. The minor details matter.  It’s not ‘dotNet’ or ‘.Net’, it’s ‘.NET.’ If I see dotNet on a résumé, I automatically file it under, “This candidate doesn’t pay attention to detail.” No squiggly lines, either. Most résumés these days are sent electronically, and those squigglies show up.

4. Skip the boring stuff. Every programmer debugs and writes code. If you feel a need to include it, do it as the last bullet point in each position. Otherwise, I want to read about the exciting stuff: How you saved them money or time, or sped up the code through doing something neat.  Show me the numbers. 

5. If you write it on your résumé, be prepared to talk about it.  It may seem cool to put ‘JavaScript’ on your résumé if you’re an ASP.NET developer, but if all you’ve done is copy and paste a JavaScript script off the internet, you aren’t a JavaScript developer. Litmus test: If you can’t create a memory leak in your favorite language, you aren’t competent in that language.

6. Get rid of the objective statement. They take up space, they are horribly written, and they all sound the same.  I skip them.  If I see an objective statement that says, “I want a job that doesn’t suck.”, then we’ll talk. Otherwise, keep it out of your résumé.

7. I don’t care about your references. I’m not going to contact them. If you’re smart enough to be a developer, you’re smart enough to get people that will say good things about you.

8. I want to see that you code in personal projects.  The vast majority of programmers are 9-5 programmers, for various reasons. All else being equal, I’m going to hire the programmer that codes on their spare time.

9. I’m going to google you. Have a web presence. We’re 16 years into the adoption of the World Wide Web.  If I don’t see your name online by now, you’re 16 years behind the curve. Get a LinkedIn Profile, a blog, and spend time on programmer websites (+1 if you have a Stack Overflow profile).

10. No walls of text. Don’t overwhelm me with what you’ve done; I’m not actually reading it anyway. I’m only skimming, and I’m looking for specific things: Highlights, numbers, words that don’t belong and your grammar and spelling. 

11. Include a cover letter. Woo me there. Give me the stuff that doesn’t fit in your résumé there. Make it interesting. Fact: I’ve received dozens of résumés, none that had a cover letter. Zero. That means if you give me a cover letter, you’re already ahead.

Next time I’ll go over what to do (and what not to do!) in the phone screen.

"It's done"

When I was a young sergeant in the Army, I had the honor of serving under a Staff Sergeant who had spent 18 years in the Army.  We worked in a unit that handled the administrative functions surrounding wounded and injured soldiers.  The unit itself was rather large at the time (this was in 2005, at the ‘height’ of the Iraq war) and as such there was plenty to keep us busy. He was nearing retirement, this would be his last assignment, but you’d never know it by talking to him.  

We hung out a lot at work, and daily there’d be something that he’d wonder about.  He did that a lot, just wondered aloud why something was the way it was; or how we would go about doing x.  Invariably I’d talk to him the next day and he’d have asked the right person or already gotten x done. This Staff Sergeant batted 1.000. You could bet that if he ever brought up a task that wasn’t assigned to you, he’d already have it done by the time it came up in conversation again.

I’ve never seen anyone work like that.

He would give me tasks to do, and he’d give himself tasks to do.  In the beginning I’d ask him about the tasks he’d assigned himself, curious since I hadn’t seen any visible progress.  As it turns out, I never saw visible progress because he’d already have it done by the time I asked.

Pretty incredible.

It wasn’t just the small things that he seemingly got done, it was everything.  If he brought up a topic, I could bet money that before we talked about it again, it would be done. Without fail.