I had a chat a little while ago with an entrepreneur. Smart guy and with some good early traction. He comes from a commercial background, far from tech and product.

He wanted to chat about hiring the first technical person to join his team. It’s a conversation topic I’ve had a few times in the past, so I thought I’d share my braindump here.

1. Find a product-oriented developer

Some developers love the deeply technical challenges, for example, making something happen 10x faster than before. Others like solving immediately practical problems, like helping buyers meet sellers.

If you’re reading this, chances are that you need a developer who likes solving those practical problems. Find the one who likes making things that people use.

How? It’s not always evident from their job, so ask about their hobby projects. Ask about what they were trying to do or solve. Why this approach over that approach? How did the product evolve? How did they come up with the UI? How did they get user feedback?

Look for signs that they care whether their product is being used or not (it may not be successful, but they should at least care).

2. Full stack!

Developers generally specialize in front or back-end. But if she’s your first developer hire, then try to find someone who has a reasonable level of comfort with both. She won’t be expert at both, but should be good enough in one and very good at the other.

Similarly, don’t hire a one-trick pony, which is someone who really only develops in one language. I’ve seen a startup re-write their entire codebase into a different language, because their key hire was a one-trick pony.

3. Don’t outsource

It might be tempting to hire an agency, but don’t do it. Consider it a test to sell someone on you, the vision and the company by having them join you with a proper level of commitment.

The reason not to use an agency is because things never go according to plan. You need the close working relationship to zig-zag your way through problems. An agency isn’t committed enough (even with equity) to put in that extra effort when the setbacks happen. And chances are that your working relationship won’t be close enough to make sharp left turns on a moment’s notice.

An agency also won’t live/ eat/ breathe your customers. So many product decisions are made on gut feel at an early stage and you need some pretty sharp guts to make good calls.

Outsourcing makes a bit more sense when you have a bigger team that is an organizational foundation and you have discrete chunks of work that you can pass off externally.

4. Get them to explain stuff to you clearly

I say this a lot, but if they can’t explain a past project without using lots of jargon and making it understandable to a non-expert, they probably aren’t good. The great ones will be able to cut through all the complexity and explain the heart of the matter.

5. Be wary of the document-ers and process-ers

I’ve come across devs who are really into documentation. Or process. Before writing a line of code, you need to spend a few days writing a 10 page spec doc of some sort, getting it reviewed, signed off, blah blah (someone please shoot me at this point).

A bit of paper and a bit of structure is not a bad thing. Sketched mockups. A checklist. Some post-its. Whatever. But you really don’t need much at the start, especially if the team is just 2 or 3 people. Less is more (but you definitely need more than zero).

If you see any hint of Microsoft Project, just pull the handle and eject. “Oh look, my cat texted me to tell me the house is on fire. Gotta go!”

6. Try before you buy

A CTO friend once warned me that with interviews, you can work out if someone is roughly ok. But until you work with them, you don’t know if they’re excellent or actually kind of mediocre.

If you can agree a small chunk of (paid) work that the person can do, it will tell you 5x more than any interview. It should be real work, something that you need (but something you can afford to go a bit wrong). This often isn’t practical for a number of reasons, but if it is ever an option, take it.

7. Enlist a trusted tech friend to do a technical assessment

Talking is nice, but ultimately you do need to see if the dev can actually write code that works well. This is the minimum skill set required. Get someone to assess that for you.

 

Hopefully this list saves someone a bit of pain and uncertainty. This is not easy. Recruiting developers is tough. But if you’re in the middle of it, I wish you luck and look forward to hearing your stories about it.

---

GS Dun builds new ventures and products, including international expansion ventures. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.