How To Hire Superstars: Collaborate Early!

My sister bought me a book called "The Truth About Managing People" by Stephen Robbins for Christmas.  Not sure if she was trying to tell me something about my managerial skills, but I am enjoying the book.  Chapter 3 in the book is "Tips for Employee Interviews" which I found to be rather uninspiring and it led me to think a bit about how we do hiring at HubSpot/SB2.0. 

We have three interviews in the next week.  One is a developer/designer type and two are marketing types.  All three are folks were introduced to me through colleagues as top performers.  I suppose the "traditional" hiring workflow would be as follows:

1. Have each come in for an hour for a formal interview with me where I ask them some stupid questions and review their resume. 

2. If one seemed sharp, I would have invited my two colleagues to sit down individually with them for an hour each to do the same. 

3. If they both liked the candidates, we would ask for "their references" and check them.

4. If that worked out, we would make an offer to the employee along our standard guidelines and at the end of the negotiation, end up giving them 3-5% more than what was in the offer.

For some reason, I never even considered doing this type of process with these candidates.  Here's our new, improved workflow which seems to be working well for us these days:

1. I have a brief meeting with the candidate to see if they are relatively sharp; see if they understand what we are up to at HubSpot and are interested in our mission; and see if there is a cultural fit (it turns out we are all rather analytical at HubSpot).

2. If that goes well, I invite the candidate to come back with a project to work on with Patrick, Dharmesh, and I together over the course of an hour.  For example, for the marketing guys, they both are working in medium sized businesses and use sophisticated tools for marketing, so we asked them to demonstrate their toolset to us, describe the aspects of them they like, and describe (in that context) what the gaps were in terms of how the toolset works in for their business.  The session will be more of a strategy session where we all roll our sleeves up and strategize a bit. 

3. If we all thought the employee was sharp, got the mission, was analytical, and was relatively easy work with, then we would go find our own reference points on him.  ...I have never found people whose given references had anything valuable to say that really impacted a hiring decision.

4. If that works out, we would try to come up with an incentive program that maximized benefit for both sides.  (I realize this does not scale particularly well, but it is pretty early days at HubSpot/SB2.0)

What I like about the process is that we get to really work with the candidate together on a project and see what his ability to think on his feat is, what his cognitive capability is, and what his persona is like.  I also like that the candidate gets to see the three of us work as well which avoids a mismatch in expectations for them as well as lowering (or raising) anxiety levels about accepting a position with us.

Here are a couple of other best practices I have come across in the interviewing circuit:

1. At my first job out of college, my first interview was with the vp of sales (of a high growth software startup).  Before I even said hello or shook his hand he said, "I wouldn't wear that suit to a sh*tfight."  As it was for a sales job, I thought this was a pretty good tactic to see if I could think on my feet, see whether I could defray conflict while standing up for myself, and to see whether I had a backbone.  ...I don't necessarily recommend this tactic to everyone -- this particular interviewer is a unique guy that is currently a CEO of what became a large software company and he pulls this stuff off better than most.

2. I have stories from colleagues who have gone through the interview process at McKinsey.  Rather than bother with the standard interview drivel, they give verbal case studies to potential hires asking them to understand a set of facts, ask intelligent questions, and quickly get to the crux of the business problem and solve it.

3. I have overheard pieces of Patrick interviewing developers.  He gives them a hard math problem to solve on the whiteboard -- something about glass balls dropped from a building.  I'm hoping he doesn't ask me to solve it for him some day!

Do any of you have any great interview best practices out there you could share with us?

-- Brian Halligan.