Hiring, Auditions, and Interviewing For Success

Today Sam Altman, one of the Y Combinator partners, posted an article called How to Hire. There’s much to agree with in here, and a few points that I think are wrongheaded (mostly around the overused-and-underdefined phrase “culture fit”, and some assertions which are really just ageism), but the point that generated the most discussion on Hacker News was the idea of an audition.

Have people audition for roles instead of interviewing for them.

This is the most important tactical piece of advice I have. It is difficult to know what it’s like working with someone after a few interviews; it is quite easy to know what it’s like after working with them

Whenever possible (and it’s almost always possible), have someone do a day or two of work with you before you hire her; you can do this at night or on the weekends. If you’re interviewing a developer, have her write code for a real but non-critical project. For a PR person, have her write a press release and identify reporters to pitch it to. Just have the person sign a contractor agreement and pay them for this work like a normal contractor.

I’ve seen this discussion happen a dozen times, and the sides break down the same way:

–Pros: Whiteboarding is artificial, and real coding is a better reflection of skills; hiring is a two-way street; wouldn’t you want to really get to know your colleagues?; I wish someone would test me that way.

–Cons: it’s simply not true that people have “a day or two” to give you outside of the interview process – some combination of work, family, and personal obligations. “The developers who know what they’re worth won’t put up with this.”

The best answer, of course, comes from remembering the goal of interviewing in the first place: to find people you should hire, and then hire them. Obvious stuff, but there’s a less-obvious corollary: if there’s part of your process that keeps you from finding people you should hire, you should change that process. No matter how awesome your company is, asking for homework as part of the interview process will keep some people you would want to hire from interviewing.

If you think that a working session will give you different data than a whiteboarding session, then integrate it into your interview day: instead of five hours of whiteboarding, do two hours of whiteboarding, two hours of real-world programming, and an hour to establish values alignment.

Real-world programming could be pair programming, or could be what one of our clients does, where they ask the candidate to bring a laptop with their development environment, and a VGA connector (or they’ll provide one), gives the candidate a problem and a projector, and watch while asking questions.

With a setup like this, you give the candidate multiple ways to show success (i.e. he freezes at the whiteboard but can write great code the first time through; she takes a while to get into a problem but clearly understands data structures), and you gather a wide variety of information.

(BTW, many companies actually don’t have a contractor agreement – and even more individuals wouldn’t know what to do if they were paid as contractors. Don’t hand-wave this away.)

(Pedantic note: the use of the word “audition” in the original context doesn’t make sense. An “audition” is an interview, but with singing and dancing, or crying on command. If you audition for a play, they don’t have you come spend a few days as Peter Pan before someone decides if you get to stay.)

Remote interviews: no more excuses

We’re the impetus for ~20 engineer-to-engineer interviews/week – either clients talking to candidates or internal technical screens to validate quality before the client sees the candidate. Some of our candidates are from out of town or out of state, and our consultants can’t leave their office for every interview they’re going to do – so we want to make remote interviews work.

The good part is that the technology is really there: I’m asked enough how we do it that I wanted to write it up quickly. You really just need two tools: Google Hangouts and Collabedit.

Google Hangouts: This is the first 1-1 or multi-user video chat that I’ve found just works almost 100% of the time – very little video stuttering, no terrible echoes just because your mike and your speaker are on the same piece of hardware (i.e. your laptop), and really easy to get going. We tell candidates we’re going to use this ahead of time and ask them to get it set up – and while some candidates don’t have webcams, that’s becoming rarer and rarer. We send out a Hangout link ahead of time when we can (as Google Apps users, we get access to those), but you can easily just use gmail chat and go right to video.

I can’t emphasize enough that Google Hangouts have demonstrated that the future is here – you can legitimately start these conversations on the fly and feel confident that they will work at least as often as your cell phone connection will. I’ve never been able to say this about skype or other solutions.

Also note that Hangouts have a one-click screen sharing option, so either the interviewer or the candidate can replace their face with a window at any point. But why do that when you have…

Collabedit: Collabedit is a real-time shared coding window: you create a link on the fly (and can share it via chat), pick the language for formatting, and then ask questions and see real typed-out answers. There are similar solutions, other EtherPad-based clones like Stypi – I’ve just been consistently happy with Collabedit. I’ll often start the interview with the question I want to ask in a comment that I can just paste into the collabedit window, so the candidate doesn’t have to remember what I said out loud.

Note that we’re using this to replace the traditional technical phone screen as often as we can – I’d like to be there 100% of the time soon. There are many problems with the typical phone screen – I’ve found at least two of them to be improved this way:

  • Interviewers focus better. It’s easy to get distracted by incoming email or a piece of code if nobody can really see what you’re doing, and information just disappears. The video requirement really does mean you get better feedback.
  • Fewer forgiven sins. Even with just a small amount of data, it’s clear that we’re passing fewer candidates with video/code than we did with phone screens. Since we go into every screen wanting the candidate to be successful, it’s easier to paper over flaws you think might be there when you’ve just heard voices – it’s harder to do that when you’ve really interacted.

That’s it: two tools that make hiring folks in other locations a more comfortable and confident experience.

Leaving Microsoft: Software Development Skills

Every week or so, we’ll talk to an engineer who thinks she’s interested in leaving Microsoft. (We heart Microsoft! They’re a great client! This is reality. Back to the show.)

Leaving usually means wanting to go to a startup or smaller company, and (even) in Seattle, the vast majority of those are based on open source technologies – they’re most often Java, Ruby, or Python shops. But many of those companies don’t have time to train up someone who’s spent her entire career on Microsoft technologies – they look at a resume with nothing but C# and ASP.NET for the last ten years and start to imagine how long it will take that person to be productive, and then they move on. (Companies with primarily Java stacks may be more willing to budge on this.)

So how do you get yourself technically ready to be an attractive candidate?

There are two paths: one obvious, one less so.

Obvious path: start building things. Go spend six months in your I-want-to-leave-so-I-made-some-free time actually building something “real” that runs on an open source stack, in a language that might be interesting (the ones above are good choices, especially Ruby or Python). Make sure the application does something that someone can see. It doesn’t have to be complicated, it doesn’t have to be great – the bar here isn’t “are you an amazing Ruby developer” but “did you take learning a non-Microsoft technology seriously.” That’s part of the secret: if you’re a good developer with solid CS fundamentals, and you’ve made a concerted effort, that makes you a viable candidate.

Less obvious path: move to front-end web development. There’s one set of technologies that Microsoft uses that matter a lot outside of the company – client-side web technologies! At this point, the web client side is where the Microsoft-specific and other stacks converge. Javascript & jQuery at a software engineering level and CSS expertise in particular matters a lot: experience with something like Backbone.js is even better, though I don’t know how much of that is being done inside Microsoft walls. Go over to one of the Bing groups (or some of the Windows groups) that are writing high-quality web client side code, get yourself on that team, and go build things people will see. This is real engineering, and the world outside of Microsoft knows the difference between a webdev whose skills are more around pixel perfection and a software engineer who can write client-side Javascript.

(This is the first post in a will-really-be-ongoing series called “So You Think You’re Ready to Leave Microsoft.”)

Creating a synchronous hiring process

I sent a mail to a client today that looked like this.

Here’s why.

One topic I always cover with potential new clients is “what does your interviewing process look like.” Here’s how this conversation often goes:

Client: “Send us the resume, I’ll send it to the hiring manager. If she likes it, we’ll schedule a phone screen. If that goes well, we’ll do another phone screen, and then bring him in for a set of interviews, usually with 3-4 people. Then we can make a decision.”
Me: “Great, that makes sense. How long does that take?”
Client: “Well, it depends.  The hiring manager’s really busy, so it can take her a few days to get back to me. Then I have to find a spot on an engineer’s calendar, then I need to review the feedback with him and sometimes the manager, then schedule a second one. Then our admin will help coordinate an interview day. I don’t really know.”

This is a common answer, an understandable answer, and a terrible answer. In engineer-speak, it’s taking something that’s time-critical enough to be synchronous and making it asynchronous. In human-speak,  it’s allowing all kinds of delays in a process where you lose if you are slow.

Your process needs to be fast, and making it fast means putting it all in sync. This includes things like

  • Expect fast turnaround from your managers. If recruiting is really Job #1 for your company right now, then the internal admin/HR/recruiter person should be able to walk up to the manager at any free moment, have her spend 90 seconds reading the resume, and then make a decision on next steps. Sitting in an inbox (or printed on a desk) is time wasted.
  • Every interviewer knows and can act on the next step in the process. Phone screen goes well, you want another one? Great. When you’re talking to the candidate, ask him his availability; jump on Outlook or Google Calendar, see the free/busy times for the engineer you want to schedule, and book the appointment while you’re on the phone. Boom, you just skipped another runaround and another few days’ worth of delay. You think the candidate is ready to be brought in to interview? Great, you’re empowered to find a day when talking to her and then get someone to actually schedule the right interviewers, and you can even book the conference room (the one with the whiteboard, close to the bathrooms). This means HR and mgmt needs to inform interviewers of the process and empower them to make the next decision (if it’s a positive one).
  • Set an SLA of <48 hrs between steps. There should be a reportable reason why the next step in the process takes more than 2d in every case. Try to keep it to 1. Look for ways around artificial constraints (the “right” interviewer is out of town? Can you find another one? etc.)
  • If you’re going to want something else, ask for it in advance. If you want a coding or test plan sample, ask the candidate to bring it with her on interview day. Have that ready for you.
  • Debrief always happen the day of interview. Scheduling an interview should always include scheduling the debrief (however your company does it), and it should always happen on the day of the interview, so that there’s a consistent practice. (There may be advantages to a day’s delay to allow folks to cogitate – I haven’t seen that be true in general – but let that be the exception, not the rule, and then schedule a second debrief – again, while you’re in the first one.)

Note that being fast and being thorough are not in conflict. You can have as many steps as you need, as long as you keep them close together. We’ve had two candidates join teams in the last month, both at companies with a four-step, ~8hr process, both which made it happen in four days. It’s the delays, not the steps, that kill momentum and lose candidates. (Ideas on evaluating your steps will come in a later post.)

Oh, and the email? The number of days from Step 1 to Step 4 for a candidate at one client. Does that seem like a large number? Check your own stats.

The Middle of the Aloofness Spectrum

Real Story #1: John goes in and interviews for a C++ job he really wants. Knocks it out of the park technically, environment feels good, he walks away saying I’ll be shocked if I don’t get an offer. Client calls and says “John spent a lot of time talking about his other offers and about salary – he really didn’t ask about the work at all and we couldn’t tell if he wanted to be here.”

Real Story #2: Mark interviews for a Rails developer job at an entrepreneurial, family-friendly company. Technicals go great, Mark thinks an offer will be coming soon. Client calls and says “Mark was too excited and it made us nervous. Said this was the best interview he’s ever had, kept talking about how much he loved the culture, we don’t know why he wants it so badly.”

(BTW, in those two stories, the second one is usually salvageable, the first one is not.)

These are two sides of the aloofness spectrum – how much do you want to let an interviewing company know that you want the job, or how hard-to-get do you want to play?

The real goal, of course, is to come somewhere in the middle – confident, respectful, and genuine. Let’s dig in a bit.

  • Keep your comparisons to yourself. Both John and Mark above explicitly compared this interview/hiring process to another one with the interviewers. No good comes of this: filter it out when you’re talking, unless you’re explicitly asked a question.
  • Show interest in what the team is doing. I’m assuming this is a company you want to work at, and so you should be interested in it – don’t fake it. (If you are faking it, danger, go find something else to do.) If it is, make sure they know it. The engineers should be excited about their work – they want you to be excited too, so you can be part of the secret club and can help them recruit others in. Passion is always a plus.
  • Other options? Pick the right time and place to talk about it. If the company has an HR person (or you’re working with an external recruiter), that’s the person who needs to know about your other options, your salary requirements, etc. (Even if you are working with an external recruiter, tell the HR person anyway, because external folks forget to pass that info along.)The other engineers don’t need to know – the manager might. Also, this is a sentence or two, just one time: “I’m just letting you know I have another offer, where they’ve asked for a response by Wednesday.”  You’re setting yourself up for the right followup without dwelling or pushing.
  • Manage the squee. It’s great to be excited, and you should be energized by the opportunity. Sometimes we get overwhelmed by our own excitement and that filter goes away. Interviewing is dating, and you don’t want to scare them off with overexuberance.

That’s it. Be genuine, but stay within some guardrails, and you should walk away with more personal credibility than you had when you began.

Handling rejection

A few weeks back, we had a candidate interview onsite with a client. It didn’t end well. Some quotations from a mail we received the following day, errors left intact:

I was exposed to a couple of rank amateurs with an agenda.

If you wanted a code monkey, you should have advertised that fact and not waste my time.

I am not amused by seeing dogs running around in a business setting. It’s unprofessional and quite infantile. Indeed, the  the idom “The Country is going to the dogs” has become more than a metaphor.

Continue reading Handling rejection

Job Offers and College Admissions

I was doing my monthly poking around in Quora when I found the age-old question “How should I handle multiple job offers?” I started writing a response there but decided to keep it for ourselves, because I hit this scenario on virtually every position we work on, from exec to junior-level tech: a candidate starts looking for a job, gets a job offer, and wants to wait to make a decision until their other interviews/offers come through. Sometimes they think that will just be a few days: this person (who, to be fair, reads as somewhat new to the working world) wants a month.

Here’s what I tell every candidate who thinks this way: the job search process is not like the college admissions process, where every letter arrives at the same time. It’s easy to understand why you would want to wait until you had all the data and then give every company an answer on the same day, but that’s not how the real world works. You’re going to need to make decisions with limited information.
Continue reading Job Offers and College Admissions

Stupid Answers to Snappy Questions, or Making a Great First Impression

Happy New Year! I wanted to kick off 2012 (and end our December blogging hiatus) with a quick post continuing on a theme I started with The Power of Your First Question – setting the initial tone of a recruiting conversation at the level you want to be perceived.

We list a subset of the jobs we’re trying to fill at any one time from a link on our Careers page. We do this because those job descriptions get distributed to Indeed, Simply Hired, and other sources, and while there’s much more noise than signal, occasionally a great candidate finds us.

Every one of those jobs links to an application page: here’s the general one for an example. The application page is the same for each job – the idea is to make it easy for people to contact us – but there’s one question that requires thought: tell us “One interesting thing you’ve worked on recently.

Continue reading Stupid Answers to Snappy Questions, or Making a Great First Impression

The power of your first question

I’ve been doing a lot of interviews lately, and on Friday I did a power day, with six screens for the same position. (I do love it, but if you’re a great recruiter, I need your help.)

Each screen starts the same: an ice-breaking joke or two, then a monologue – 60-90 seconds about Rooster Park, 3-5 minutes about the job and the company. I pause just once to see if they are familiar with the company to inform the rest. At the end, I always say something like “that’s the overview. What else can I tell you?”

Continue reading The power of your first question