October 16, 2012

Thoughts on Recruiting Developers at Early Stage Startups: Determining Who’s Right for Your Company

I posted a little while ago about the job market for technical talent at early stage companies, and I promised a follow-up post on what you should look for in a developer when your company is at a critical, early stage. This is that follow-up ;)

Our company, MarkedUp, is still in the process of building out its early engineering team; however, we’ve had some success in finding the right type of people we want to work with – a process that wasn’t quick or easy, but will pay off massively in the long run.

When it comes to hiring developers for your early stage startup, here are the questions you need to think about:

1. What are you optimizing for?

At this stage in the evolution of MarkedUp, we optimize for changeability and reliability – the ability to change things on the fly quickly and do it in a way that doesn’t interrupt the service of our customers.

This means that we have to recruit people who are architecturally sound with .NET, are able to learn new technologies quickly, and are good at socializing / articulating problems and design considerations to the team.

When we evaluate a developer for who’s considering joining our team, we look to make sure that they have experience with multiple technology stacks, have a well-written technical blog or are at least conversant in their respective technology areas, are versed in design patterns and can explain their architectural thought process on-demand, and have well-defined goals with regard to how they want to grow and develop.

For your company, you might need to optimize your engineering team differently – if you’re building a big consumer app, you might need to optimize for developers who have a good balance of front-end and back-end skills initially.

Make a deliberate choice about what your engineering priorities are and let that set the top of the spec for your recruiting.

2. Do you need soldiers or chiefs?

One mistake a lot of startups make is the seniority issue: hiring people who are too senior or not senior enough.

People who are too senior might demand a lot more equity / money / power / titles early on in the life of your company, which creates problems if you ever need to bring in even more senior people over them if you don’t manage it correctly. Additionally, senior developers bring a career’s worth of habits and experience into your company – which isn’t always necessarily good.

Conversely, evaluating a fresh-out-of-college CS grad to CTO isn’t a great decision either sometimes – they might not even know just how horribly they’re screwing up your company’s technology until years after the fact.

On top of the issue of experience, you also have to consider the person’s ambitions – do they want to be an executive in the company one day and have people reporting to them? Are they even capable of doing that one day?

Again, make a decision: do you need people with experience and authority who will lead the engineering team or do you need people who just want to do the right thing and make a difference, but don’t yet want to be involved in management? Recruit accordingly.

3. Can your company afford to train developers on your technology stack?

Do you need people who’ve been working on a single technology for 5+ years, or just people who are smart and want to learn?

If you’re a really early stage company, then you don’t have the luxury of time or money to invest much into a new employee who is totally unfamiliar with your chosen technology stack.

If you have the time and money to invest into training good employees, do it.

Investing into training will widen the pool of acceptable applicants dramatically because you can tailor your recruiting process to target a smaller number of things. Be realistic about your resources and the availability of your existing engineers to train the new folks, and then decide accordingly.

4. What’s important for your engineering culture?

You know what makes a huge difference in MarkedUp’s culture? Being passionate about development – we like people who have pet projects in their spare time; take the time to learn new languages and platforms; and love to talk about what they’ve done and what they’re doing.

We build products for developers – passion for development makes us more relatable to our average customer, who is typically someone building a Windows 8 application in their spare time because they love doing it.

Your company may be different – you may want to recruit people who are really into music if you’re building a media-oriented company, or people who are very algorithm / math-oriented if you’re doing a lot of work in a field like NLP or predictive modeling. Maybe you want to run a really structured environment and want people who are going to be in the office every day.

Company culture is ultimately something that will take a life of its own, organically, but during the formational stages you have a massive amount of influence over it as a founder. Pick people who fit your vision for what the culture should be and be conscientious about it.

5. What’s your level of urgency?

Trick question. The answer is “super urgent” in every early stage company. Unless you’re profitable / growing, every day is a race against the clock and the bank account.

You can’t afford to keep people around who don’t get that and won’t work hard to make sure the hard problems are solved on-time.

A lot of developers, particularly ones who’ve been in industry for a while, approach startups with the expectation that they can still work from 9-5, get the same benefits they got at MegaCorp for some relatively low level of output, but get a giant chunk of equity and work on cool, consumer-facing startup products without any bureaucracy or managerial overhead. Avoid these developers.

Hire people who want to race the clock, because they believe in your company’s vision and want to work with other competent people who can move quickly. They’re out there.

Parting Thoughts

If you do a good job coming up with clear, thoughtful answers to these questions then good fits and bad will be obvious.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..