6 warning signs to look for when hiring your first developers

by Andrew Askins 6 years ago 4 min read

It's a common tale.

A founder decides to hire a developer to build their MVP. They might find a shop in Romania or a former senior engineer who’s freelancing and living in Thailand. They could find a couple of Computer Science students eager to learn and willing to work for equity.

Hiring contract developers can be an incredible way to prove your concept. Working with a freelancer or dev shop makes it possible to get your MVP to market quickly without dealing with the hassles of hiring or giving up equity. All too often though, founders end up wasting months building way more than they need. They invest tens of thousands of dollars and end up with an MVP that is barely viable.

In Paul Graham’s essay “The 18 Mistakes That Kill Startups,” number 6 is hiring bad programmers.

“In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he's a Microsoft Certified Developer) but who aren't. Then they're mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters.” - Paul Graham

He goes on to say that he doesn’t believe this problem is solvable. The differences between a good developer and a great developer can be hard to spot. But recognizing a bad developer is easy.

Here are 6 red flags to help you tell the difference between the good and the bad.

🚀 1. No experience working with early stage startups.

Developers who have never worked with early stage startups don’t always understand how to work within the unique constraints that startups face.

There are incredible programmers who would be a terrible fit in a fast growing startup. In the enterprise world, the emphasis is on stability and scalability. Software is designed to be solid, dependable and to handle hundreds of thousands of users. Developers used to this way of working can cause massive slow downs in a startup.

And avoid anyone who mentions “scalable micro services.”

👔 2. Zero interest in the business or users.

The standard mythos is that the best developers are grimy neckbeards who live in their mother’s basement cranking out code as fast as they can pound mountain dews. But when it comes to building early stage startups the neckbeard who only cares about code is not who you want.

Until you find product/market fit the only thing that should matter to you is finding product/market fit. To do this you need to listen to customers and constantly be adapting your product to fit their needs. This means you need developers who care about your business goals and your users.

The first thing we do when we work with a new client is establish their goals for the project. These goals then guide every technical decision we make. Writing beautiful code is not as important as building a sustainable business.

💻 3. No live projects.

This is an easy one. It is shocking how many clients never ask us anything about our past projects or even look at our portfolio. If a developer or team doesn’t have any live projects with real users - that’s not a great sign.

📉 4. A track record of under estimating.

Ask a developer about their estimates on past projects and how accurate those were. If they went over why was it? Did they miss some piece in the estimation process? Did the scope get expanded after they started the project?

If they can’t tell you then that’s a red flag by itself.

🐛 5. They don’t use source control.

Source control is a vital part of any modern development project. Source control provides a backup of your code. It also makes it possible to quickly deploy older versions if a bug pops up.I almost didn’t even include this bullet point, but it’s a good minimum test. If a developer isn’t using source control, chances are they don’t have any experience building real world products.

Note: Read more about source control in my technical primer for non-technical founders.

🔬 6. They don’t write tests.

This last one is tricky because it’s possible to overdo it with automated tests. As I mentioned earlier - the most important things are getting to market fast and listening to your customers. That said, writing automated tests can save tons of development time down the road. And for any experienced developer tests are a natural part of their workflow.

At Krit, we’ve been moving more and more towards Test Driven Development. This is a practice where developers write tests first, and then write the rest of their code to pass the tests. Good tests help you avoid unnecessary bugs and iterate with confidence.

For most early stage startups the right combination is to use automated tests to cover the simple parts of the software, and manual tests to handle more complicated issues. This lets your developers move quickly, while still having some coverage.At the end of the day, none of these are deal breakers on their own. But combined together they are warning signs for developers who are either inexperienced or not cut out to work with startups.

Takeaways:

Identifying the differences between good developers and great developers can be hard, but telling good and bad developers apart should be easy.

Stay away from developers who:

Have no experience working with startups.
Don’t care about the business or users.
Have no live projects they can show you.
Have a track record of under estimating projects.
Don’t use source control.
Don’t write any automated tests.