Today's Question:  What does your personal desk look like?        GIVE A SHOUT

Redesigning the Technical Hiring Process

  Jean Hsu        2011-09-14 12:01:37       2,270        0    

Since my last post on technical interviews, I’ve been fairly involved in hiring at Pulse as we grew our team from 6 people when I joined last November to 14 full-timers. In my previous post, I suggested that technical interviews, in the conventional sense, are not especially effective (by technical interviews, I mean the traditional 45 minute coding-at-a-whiteboard and algorithm puzzlers interviews). Those do a great job of telling you how well a candidate is at acing those types of interviews, specifically coding on a whiteboard while someone watches over your shoulder, and how well they’ve memorized and understand basic algorithms and data structures. The trouble is, this is probably pretty far from what that person would be doing on a day-to-day basis if hired. What you really want to know is how strong they are technically, how well they will work with and add to the existing team, how quickly they can pick things up, etc.

At Pulse, we’ve kept these goals in mind as we continue to shape our hiring process. Adding someone new to your existing team really should be about finding a two-way fit between the candidate and the company. The hiring process should be as much about giving the candidate the opportunity to see if it’s a place they would like to work as it is about assessing his or her technical prowess. When I joined full-time, it was after working as a consultant for a week, but full-week interviews are obviously not a possibility for most candidates, and also not very scalable as Pulse grows.

Our current process, which is constantly changing as we get feedback from candidates, varies a bit, depending on availability and location, but here’s a pretty typical flow from receiving a resume to getting a full-time offer:

  • Resume comes in – If the candidate looks like a potential fit, we follow up and schedule a phone call, or sometimes if they’re local or were personally referred to us, we just have them come by for lunch.
  • Phone call/Lunch – This is generally just to tell them a bit about Pulse, and for them to tell us a bit about their previous work experience, personal projects, coursework, etc.  Local candidates often come by for coffee or lunch and meet whoever’s around, and we get a chance to chat with them about Pulse, their experience, and non-work-related things.
  • Project – If all goes well up to this point, we invite them back in for at least a few hours to work on a small project. Usually the specifications for the project are pretty flexible, but we try to keep it as relevant as possible to what they might work on if they joined full-time. If they are particularly excited about something or suggest a project, we generally just run with that. If they are not local, obviously we give them the chance to do it remotely.  If it’s something we might use at Pulse, we pay for their time and do the appropriate paperwork.
  • Demo – After they’ve spent a certain amount of time working on the project, we ask them to give us a demo, and then we break off into smaller groups to ask some questions about design decisions, technical implementations, etc.

By the end of this process, we have enough information to decide if we want to extend a full-time offer. Here are some highlights of what this process provides us:

Code

The project is really the technical crux of the entire process. Rather than have them write out a method on a whiteboard, we have a small-scale but significant project that they have written. This is code written on their own, with access to their usual development environment (auto-complete…), Stackoverflow, Google…because frankly that’s usually how we code on a daily basis.  From this project, which could be a simple Android or iOS application, web app, or backend project, we get a strong sense of the candidate’s coding style, how they structure their code, how much they know, and how quickly they learn (since we have previously asked them about their experience).

Communication

Throughout the process, and especially during the demo, we  see how well the candidate communicates with the team. During the demo, we have the opportunity to see how well the candidate responds to feedback and criticism, if they are defensive about their work, or open to suggestions. We can also see how they talk through their design decisions, and what they would do next if they had more time. Some candidates demo applications that are in half-working states because of time constraints, but are able to tell us exactly what needed to be done, and that can demonstrate extremely deep knowledge of the platform.

Culture

Since the process involves us working closely with the candidate on a project, it is very similar to what they would be doing if they were working full-time. This type of hiring process does require involvement from more of the team; rather than just having a few people in charge of interviewing, everyone is involved, whether it be having lunch with candidates, working with them on projects, or sitting in on demos. The process gives us an accurate idea of how they  fit in with the rest of the team, not just the one or two people they would work closely with.

Our hope is that by the end of this process, they also have a good idea of whether or not they’d like to work with us.  Throughout the entire process, we answer questions about Pulse that may not be immediately obvious. What is our release process like? What version control system do we use (git)? How do we iterate on designs for new features? How often do we do user-testing for our app? What times do people usually get in to the office?

The process as it is now retains a lot of what I loved so much about the one-week period, but it is also way more scalable. In comparison to a more traditional technical hiring process, which may consist of a phone screen and a day of interviews, we spend about the same amount of time per candidate. Since a lot of the time they spend on the project is spent coding independently, we probably actually spend less “active” time with them, but in my opinion, gain and provide much more relevant and meaningful information.

Right now, almost all startups and companies are hiring aggressively, and accepting a full-time offer is a big decision…a huge decision!  If you extend a full-time offer to someone, it’s likely that he or she has other competitive options as well. We hope that the process we’re iterating on gives us enough information to decide if we’d like to extend a full-time offer, while providing more of the information needed to help someone make that important decision.

Also, we’re hiring for web and iOS, so if Pulse sounds like a place you might like to work, we’d love to hear from you!

Related posts:

CAREER  RECRUITMENT  PROCESS  DEVELOPER  SKI 

Share on Facebook  Share on Twitter  Share on Weibo  Share on Reddit 

  RELATED


  0 COMMENT


No comment for this article.