tl;dr: If you're trying to attract awesome developers, you need to create an awesome candidate experience (CX). Something that makes them go "WOW!". It's like UX -- but for the people interviewing to join your team.

It seems that every startup I know out there is trying to grow their development team. But given that there are always a hundred things going on, few startups spend the time thinking about their interviewing process (because we're all busy building products and delighting users). wow

Yesterday, I sat in a HubSpot "Tech Talk". The topic was "Technical Interviews". The idea was to share ideas and best practices across the product team so that we can better find and recruit great developers for the team. HubSpot has had a bit of an unfair advantage when it comes to technical recruiting. We're fortunate to have Paul English, founder/CTO as a friend (he's hands down the best recruiter I've ever met). Paul was kind enough to be "CTO for a day" at HubSpot. And, because Google Ventures is an investor, we've been able to have a Googler from their recruiting team spend a few hours with us, reviewing our practices and giving us tips for how we can improve them.

Ideas for Creating An Awesome Candidate Experience (CX)

Here are some ideas for what I think would make a great candidate experience. Many of these ideas are implemented at HubSpot -- and I'm hoping the others will get adopted too. We have some work to do ourselves, but we're passionate about building an amazing product team in Boston.

1. Decide to do it. The first step in creating a great candidate experience (CX) is deciding that it's important. Just like you'd commit time and energy for creating a great UX for your product, you need to devote some calories to iterating on your CX and working had to make it exceptional. There are a number of reasons you should do this:

a) Recruiting great people is hard -- and competitive. All things being equal, on average, if you can make the candidate experience better, you win. People will often take positions with lesser known companies simply because they had a great interviewing experience.

2. Focus on the entire experience. Designing a great candidate experience is not just about doing interviews well. A great CX starts from the moment a person connects with your company (like your website) all the way through the point that they are delivered a decision -- and every step in between.

3. Measure it to improve it. It's not possible to create a great CX without getting feedback from candidates. What I'd suggest is a simple NPS (Net Promoter Score) style survey at the end of the candidate interviewing process. The survey asks exactly two questions:

a) On a scale of 0-10 how likely are you to recommend that a friend or family member interview here?

b) Why did you give us that score?

You don't have to use these specific questions -- the benefit is that NPS is that it is simple, and widely used as a way to measure customer satisfaction (or more accurately, customer delightion). We use NPS in a variety of ways at HubSpot -- including measuring the happiness of our customers and team members.

Some quick notes on collecting this feedback: First, It should be collected before a final decision is delivered, so you get unbiased data. Second, it should be made clear to the candidate that they are doing you a favor. There's no harm in telling a candidate exactly why you're asking for this feedback. In almost all cases, the candidate would likely see this as a positive signal. It shows that you care.

4. Interviews are both a buying and selling process. One of the mistakes inexperienced interviewers often make is behaving as if their job is only to "be convinced" by the candidate that they'd make a good hire. As a result, they often have an "edge", aren't particularly friendly, and don't do enough to make the candidate feeel comfortable. That can be a bit disconcerting for the candidate, and creates a sub-optimal candidate experience. As an interviewer, your job is two-fold: One, make a rational judgment as to whether you think this person would be a good hire for the team. Two, ensure that the candidate wants to work at your company. It's both a buying and a selling process (not just buying). As it turns out, great people always have options. Even if they're not a good fit and you decide not to hire -- you want them to leave with as positive an impression as possible. They may have friends or family that are better fits. Quick mental hack: Pretend like every candidate you don't hire is going to become a future potential user/customer.

5. Be at least a bit organized. Yes, you're a startup. Yes, everyone's already working away furiously and interviews are often an unwelcome irritant. But, that's our problem -- not the candidate's problem. Spend some time devising at least a simple process to ensure that meetings are scheduled appropriately, the candidate knows what the process is (and how long they'll need to be there) and always, always, always make sure they're feeling comfortable and welcome.

6. Make speed a feature. Just like great UX, a great CX is about speed. Faster is always better. I've never met someone that thought: "Boy, am I glad those folks took 2 weeks to get back to me on an answer...".

7. Have a "guest" tablet available for candidates. Make sure it's already on your WiFi network, the home page in the browser is your company website. The idea is to give the candidates something productive to occupy their time with while they're waiting. They can even play Angry Birds, if they want. Nothing's worse than sitting in reception, not knowing what the guest WiFi password is, and having to twiddle one's thumbs before an interview.

8. Don't repeat the same topics. Be organized enough that if the candidate is going to go through multiple interviews, you don't have them cover the same topics multiple times. That's annoying and a waste of time. If one interview focuses on their front-end development skills and how well they really understand jQuery, then perhaps the other interview should be more about work style and thoughts on team collaboration.

9. Have a clear feedback/rating system. You need to have a clear internal rating system so that interviewers can express their overall take. If the person is an absolute no-hire, that should be clear. So, your scale could be: absolutely no hire, leaning against, neutral, leaning in favor, absolutely hire them. One important point while we're on this topic: The rating scale is not about the person -- it's about whether this person should be made an offer at this point in time. I've sometimes seen people give a "high" rating (because the person was really, really good -- and interviewed really well), but then later heard "but I wouldn't hire them." The reason for the interviews is to make a hiring decision. Said differently, the ultimate return value of the function is a boolean hire/no-hire NOT awesome/good/not-so-good person.

10. Learn something. Make every effort to learn something from every candidate. Just because you're on this side of the hiring table and just because you may be more experienced does not mean you can't learn something from every candidate. You can. Try to draw out a particular passion that the candidate has. Perhaps a recent epic debugging victory. Or, why their editor is the One True Editor To Rule Them All. Doesn't matter what the topic. Find what they're passionate about, and genuinely get them to teach you something about it. (If they're not passionate about anything, you've got a problem).

11. Teach something. Whether the candidate gets an offer or not, they should have learned something from you. They need to walk out smarter than they walked in. (Note: This does not mean you spend 50% of the interview telling them about the proper Pythonic way to do something).

12. Be transparent. Make the conversation open. Let the candidate ask questions that are on their mind. It could be about team dynamics, work style/hours, financials (growth, cash, etc.), product strategy, dev philosophy, whatever. Be honest. If there are some things you can't answer, be honest about that. But, try to be as transparent as possible -- it makes for a much better candidate experience.

13. No leading of the witnesses. If you're having multiple people interview a candidate, you need to make sure that the early interviewer(s) don't unduly influence the later ones. This is important for a couple of reasons: One, you want multiple viewpoints, not the same viewpoint multiple times. Second, from the candidate's perspective, if they feel like they got off on the wrong foot in the first interview, you want them to have a reasonable chance of showing off their awesomeness in the subsequent interviews.

Warning: Controversial Idea coming up: One of the top areas of debate regarding technical interviewing is wheter you should "fail fast" (or not). Let me set this up with an example: Lets say you invite a candidate in for 4 hours for a series of interviews. Lets say after the first interview, the interviewer is absolutely sure that this candidate is a "no hire". What do you do?

a) Thank them for their time and stop the interview process? The advantage is that you're not expending further (very precious) developer time, when a decision is already made. The downside is that this is kind of disheartening and deflating for the candidate. If they were scheduled for 4 hours and you send them home after the first hour, that just doesn't feel good.

b) Continue the interview process? The advantage is that it's (arguably) a better candidate experience. You might even suggest that the later interviewers might like the candidate so much that they convince the first interviewer to change their mind.

My general leaning is not completely cut-off the interview process. Having said that, there are a few things I'd try:

i) One, when inviting candidates in, make it a time range instead of an absolute number of hours. Example: Please schedule 3-4 hours for your visit. That way, you could reasonably end the interviews without going through the full "maximum" time.

ii) Build a reputation for being super-selective, but fair. Be honest and open about this in the early conversations.

iii) Consider offering a $100 Amazon gift card for "early exits". Be transparent and honest. "I just don't think we have a good fit here and doesn't make sense to put you through more interviews." UPDATE: I reconsidered this one. The more I thought about it, the cheesier it sounded.

14. Get them to code, but let them pick the language. Coding exercises are a critical part of the interviewing prcoess. There is no substitute for getting a candidate to do a quick coding exercise (either on a computer or on a whiteboard). The intent for this exercise is not to test proficiency with a particular language -- but to see if they can "think in code" -- and how they go about doing it. My advice is to let the candidate pick whatever language they're comfortable with (amongst the mainstream languages available, like Python, Java, Ruby, PHP, Javascript, etc.). Any of these mainstream languages are more than powerful enough for a coding exercise, and even if you're not completely proficient in a langauge, you'll still get a sense for how the person goes about thinking about a problem and manifesting a solution in code.

15. Do a friendly follow-up after the offer. Generally, you'll have someone extend the offer in some formal or semi-formal form. In addition to that, have one of the designated interviewers follow-up with a quick email (perhaps with a "cc" to the others they met). Something like: "Hey, thanks for vistiing HubSpot. We'd be thrilled to have you join our merry band. If you ever want to grab coffee or a bite to eat, just drop me a note. I should probably tear myself away from the computer every now and then anyways..."

What's Your Take?

Whew! That was a much longer article than I originally intended. Now, it's your turn. What do you think would make a great candidate experience? Any tips or lessons learned from your own experience you'd be willing to share? Please put them in the comments.

<blatant_self_promotion>

Oh, and by the way, if you're an awesome developer (or know one) in the Boston area, you should know about the Boston Battle for recruiting great talent. Hint: There's potentially $10,000 cash in it for you. Why not take HubSpot's own Candidate Experience for a spin? I promise you won't regret it. If you're awesome, you can email me directly (dharmesh @ hubspot dot-com), with a link to some evidence of your awesomeness.

</blatant_self_promotion>

Look forward to reading your comments and feedback. As added incentive, if you share something that the community finds particularly insightful or useful, will send you a $25 Amazon certificate. No limit to the number of "winners". Ready? GO!

Hiring For Developer Positions

Entrepreneurship/Consumer Web Entrepreneur

Steps: