How we think about hiring

Gradient is growing, and we need to hire. We are kicking off our process this week. It’s funny, along with sales, how to hire well is one of those crucial, practical things they don’t teach you in business school. We have been sort of flying by the seat of our pants each time when we run this process.

In our typical fashion, we decided we would try thinking things through and doing them a bit differently. For our last process, we decided very early on that we would not think about defining a “role” and finding someone that could be slot into that. I basically don’t believe in defined roles for knowledge-work. The whole idea is that it’s something that requires creative thought, so how can you predict in advance what will be needed?

Anyway, even if defined roles make sense elsewhere, work at Gradient is far too fluid for it to work with us. We all need to pitch in on all areas of the business: building statistical models, hooking up our CRM system to our email system, evaluating different AWS servers, and so on.

So the way we did it last time was to define a whole bunch of

  • Experiences (projects or models they had built in the past that were synonymous with what we do)
  • Skills (things they know how to do, from statistical modeling to server management and so on)
  • Traits (most importantly: do they want to work remotely?)

And give each of them a weight. People that had a bunch of highly-weighted attributes were more attractive to us than people that did not, simple as that. We even automated a large part of this process, having interested candidates take a survey that gave us a score. Take it here, if you’re interested — although consider this one obsolete.

I think that for the next hire, we’ll follow a similar process. It maps well to my mental model of how our company works and worked very well for us last time.