Hiring software developers is hard. It’s hard when you are a software developer and have intimate knowledge of the skillset required. It is even harder when you don’t have that skillset. I’ve met many entrepreneurs who are in the latter situation. How do these folks go about hiring developers for contract or full time?

Many try by just talking to a developer. At that point you’re effectively just listening to a sales pitch. That’s an important skill for developers to have to get jobs, but that’s not the skill you would hire a developer for. You hire them to write software. Being able to pitch themselves does not correlate to being able to build software well.

At that point, some may consider doing due diligence by checking the developer’s pedigree such as years of experience or places worked. Unfortunately both are faulty. I’ve met plenty of great developers with 20+ years of experience, but I’ve also met plenty of developers who stopped learning new things 20 years ago. Software development changes quickly enough that not learning for even a single year can put one at a severe disadvantage. That makes developers who have stopped learning for decades marginally more effective than a college intern if not worse.

Previous places worked can be a good signal, but that doesn’t necessarily mean the developer is a good fit for you. I’ve met a couple of people who have hired ex-Google developers simply on the basis that they worked at Google. The problem these employers faced were that they ran startups. The developers they hired had an extremely high standard for software quality. That sounds great, but that doesn’t necessarily match up with a business’ needs. If your business is a low volume business like art procurement or selling commercial real estate, you probably don’t need software that can handle millions of requests per second. You probably only need to handle a few dozen requests per second. That means the extra time spent on making your software scale to a point it will never hit is wasted. That means the money you spent on that time is wasted. That being said, one of the best developers I have ever worked with used to work at Google. They have a high bar for hiring and have a lot of great talent. The problem is they also have thousands of developers and those developers are not interchangeable. You need to judge the talent of the individual yourself.

So how can you judge a developer’s actual ability to build great software when you yourself are not a developer? Well, you should still know your product. If you know your product then you also understand the various pieces of data used in your product. For example, an e-commerce website obviously has users and products. But what about orders? Do orders belong to users or do they belong to the product? What information is part of an order and what information is part of a product? Do users have a single address in your application or multiple addresses? You should have a mental model of this data if you are the founder of an e-commerce website.


This data model is also critical when building software. If the data is not stored properly, the software code will not be built well. It would be like trying to build a skyscraper on sand. So a good developer should also be able to create a good data model for your product. In many cases they may not have the domain knowledge that you do. That is ok because they should be able to ask the right questions in order to create the proper data model.

This is also a fantastic opportunity for you to test out working on real problems with the developer. Many of your interactions with a development team would be about product use cases and the necessary data involved. If you find that you and a developer are communicating well on this issue and you think they have a firm grasp of the data needed in your product, then they are likely to have a solid foundation for the software that needs to be built. This isn’t a perfect correlation with great coding ability, but great coding ability won’t matter if the software is built on a poor foundation.

This is also a great segway into asking them to describe how they would implement your project. You would want a developer who could communicate with you. No decisions in software development are perfect. Every single one has some kind of trade-offs and you would want to help your developer make the right ones by explaining what your business’ goals are. I frequently have discussions with product managers that boil down to “I can write code in one of two ways. Each will make building some things in the future harder and some things easier. What is the direction we want to go with this feature?”

How well this communication is done upfront will be an indicator of how well you will enjoy working with that developer. Don’t hesitate to ask for clarification if something doesn’t sound quite right to you. If the topic starts to get very technical, ask the developer to explain it to you anyway in a way you can understand. It most likely won’t be a short conversation, but it’ll be a worthwhile one. Do not accept “oh you just don’t understand technology because you can’t code.” This could be a sign that that developer also doesn’t understand the technology involved and is trying to fake it.

These steps won’t ensure a 100% success rate when hiring developers. Like I said, it is a hard problem even for seasoned developers. While these steps will increase likelihood of success, there is still lots of risk. Good hiring is never a guarantee. But then again, neither is starting a successful business.