It was 6:30pm on a random Tuesday evening in Cambridge. There I was, carefully counting a wad of crisp $100 bills in an unmarked white envelope.   I was parked in my car on Main Street, a block from the MIT campus.  The bills were new enough that they sort of stuck together.  The first time I counted them, I counted only 28 and had a brief moment of panic. There were supposed to be 30.  But, two more recounts, and I was fairly certain that there was $3,000 in the envelope.  This was the closest I think I've come to feeling like I was doing something illicit.  I was just waiting for a police officer to walk up to the car and tap on my window.

I was scheduled to hand this cash over to people I had never met.  At 7pm.  In a classroom at MIT's Stata Center (it's the building that Frank Gehry designed that looks like it came out of a Dr. Seuss book)

The $3,001 was payment for what was intended to be an inbound marketing contest.  The funny thing is, I inadvertently ended up running a hacker contest.  But, looking on the bright side, the payment could have gone as high as $50,000 (which would have maybe required a black briefcase and sunglasses).  So in some sense, I got off easy.  "This could have been much, much worse," I told myself.

Here's the story of how I ended up handing an envelope full of $100 bills to two complete strangers.

The Founder's Journey Class at MIT

Back when I was a grad student at MIT (this is back in the 2005/2006 timeframe), I took a class called “New Enterprises” with Ken Zolot and Howard Anderson.  It was the class to take if you were a student at MIT and had entrepreneurial leanings.  It's where I wrote the original business plan for HubSpot (the only business plan I've ever written).

Ken Zolot went on to teach a new class called “Founder's Journey” (6.933) .  Students were primarily undergrad computer science majors.  Ken invited me in as a guest speaker, and I've been a regular guest lecturer ever since.

My topic at this guest lecture  has generally been inbound marketing.  To make things fun and interesting, I often hold a small contest/exercise during class (I've done this in other classes I teach as well).  The cash prize was generally between $20 and $100 (usually based on how much cash I had in my pocket at the time, and the nature of the exercise).  It often involved some sort of inbound marketing task:  Write a title for this blog post, figure out some SEO keywords for this company, etc.

 “Hey, why don't we make this more interesting…”

A week before I was scheduled to speak to the current Fall term class of “Founder's Journey”, Ken reached out to me and suggested we might want to try a more “in-depth” exercise.  Something the students would have a few days to complete, instead of a few minutes in class.  I thought that was a good idea, and noodled on the idea a bit.  I then sent Ken this fateful email.

I will summarize the rules for you:  Each student first sets a goal for themselves in terms of how many retweets they're trying to get.  They then try to post a tweet that gets that many (or more) retweets.  Simple enough, right?

Now, the astute among you will immediately recognize a couple of issues with this proposal:

1. I don't specify a maximum payout.

At the time, what I had in my head was: “It's kinda hard to get people to retweet something that much.  I have 160,000+ followers on twitter, and even one of my popular tweets might get 100–200 retweets.”  None of these students is going to have that kind of following, ergo, the likely payout will be $20 –  $50.  And, if someone's really good and gets a couple of hundred retweets, so be it.

2. I'm not explicit about what methods are considered legitimate/fair to acquire the retweets.

My topic was inbound marketing, and part of what I was hoping to  teach/convey is that a) it's hard to get people to retweet.  b) it helps to experiment with different kinds of tweets (humorous, useful, controversial, social good, etc.)

What ended up happening was this “perfect storm” of mistakes in structuring this exercise/contest.

“I thought to myself:  Self, we have a problem…”

So, on Thursday night (t minus 6 days to the class), tweets with the #foundersjourney starting showing up on my radar.  Not surprising.  That's the evening the class is held, so Ken had clearly given the students their assignment and the game was on.

Several of the tweets were amusing, like this one:

But, when I saw this tweet, I knew I had a potential problem.

Uh oh.  Exactly 300 retweets (as stated in the tweet) — all of them looking like bots.  That's when I thought to myself, “Self, we have a problem…”  I realized that I had not explicitly stated that one couldn't set up a robot army to do the re-tweeting (that kind of defeats the whole purpose  of the exercise, which was meant to be about inbound marketing).  But, the rules are the rules.  I had set myself up, and was prepared to pay the price.

Now, I just needed to figure out what that price was going to be.  So, I sent an email to Ken to ask the simple question: What were the top 5 retweet bids/projections?  (Remember, per the rules, I wouldn't have to pay out any more than what someone had bid).

"The top bids are: 50,000, 11,000, 10,000, 5,000, and 3,000", he said.  “Holy crap!”, I thought.  This is going to get interesting.

Later, I saw this tweet.

The tweet didn't have 3,259 retweets at the time — but it was climbing steadily.  The contest ran for 3 days, and as you might expect, I watched intently as the story unfolded.

Once the contest ended, I knew I was likely going to be out a fair amount of money.  I didn't know how much, because I didn't know what Paul's bid was.  But, I had a sneaking suspicion it was going to be relatively close to the 3,259 bid.

So, I figured, what the hell — let me just reach out to this guy and get the skinny.  It's also when I had the idea to write this blog article.  I figured “Hey, maybe we can turn this into somewhat of a happy inbound marketing ending. ”  I later learned that Paul and Tim (a classmate) had agreed to join forces and attack the challenge together.

30, Fresh, Crisp, $100 Bills

So, last night (Tuesday, December 5^th), I went in to teach the Founder's Journey class (as scheduled).  I met Paul and Tim for the first time, handed them an envelope with 30, crisp $100 bills, while their classmates looked on with a combination of admiration and envy, and then went about my business of convincing a bunch of undergrad computer science students that marketing was usually necessary, and that inbound marketing was the way to go about it.

Paul tweeted a picture of the cash later that night.  Here's that picture.

Here's a video of them hacking away (don't worry, there's no sound, so it's safe for work -- or classrooms

CAPTCHAs, consoles and cash, Oh my!

I went ahead did an email interview (this is all before I actually met the guys).  Here are the questions I asked, and their responses.  Only minor editing..and I've added some of my thoughts in italics.

Closing thoughts and lessons learned

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).

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!