10 Ways to Identify Great Developers

“Developers, developers, developers, developers.”

We all know the quote from Steve Ballmer and the classic video of him showing his support for Microsoft engineers.

Ballmer’s quote holds especially true today as startups and Fortune 500’s alike viciously compete to acquire the top programming talent. This means that identifying and recruiting world class software developers is not only crucial for tech companies, but also more difficult than it has ever been. 

Throughout my experience as a web developer, entrepreneur, and Student Fellow at .406 Ventures, I’ve met amazing software developers. Here is my short list for finding the great ones: 

1. Ability and willingness to learn

I don’t care how much you know right now. Instead, I care how fast you are able to learn new technologies, adapt, and implement them. My partner last summer came into the venture as a PHP novice. The code he wrote the first month was clunky. However, he loved learning to improve the code, absorbing pages of the PHP manual like a sponge. Within months, he became a sharp PHP wiz, re-building the old code in hours even though it took him days to first write it.

2. Passion for problem solving

Writing software is all about solving a problem. Any great programmer must have that innate passion for solving problems, boldly taking on challenges and ultimately conquering the unknown.

Maybe they solve the 6 Rubix cubes on their desk in under a minute or they spend every morning manipulating a Soduku puzzle. Either way, having a knack for problem solving in an efficient, salable, and manipulable way is paramount.

3. Logical and mathematical thinking

At a very basic level, any software program is a series of commands (logic) that goes through situations and takes some sort of action based on the situation. For example: IF it is raining THEN I’ll take an umbrella ELSE I won’t take an umbrella.

Great developers will many times think, speak and act in similar ways that they program. If I videotaped some of the arguments my CTO and I had, I bet we could easily transcribe them into basic logic arguments and turn them into a web app. Look for people that love math and logic, those skills translate well into development.

4. Flexibility

If a developer seems married to one programming language or stack, run away. It might be Ruby on Rails today, Python and Django tomorrow and picking apart some Node.js or Scala next month. Once you understand the fundamentals of Object Oriented Programming (OOP), it is fairly simple to go in between these different languages. You want someone that is flexible, a jack-of-all-trades in the programming world. They don’t have to start out this way, but must have the willingness to learn and explore at a rapid pace.

5. Readiness to re-code

When I was was first learning to program, it drove me nuts that I had to constantly re-do work. But that is the nature of the beast: as you learn and get better, it is essential that you optimize whatever code you are working with to function at its best, and unfortunately that usually means scrapping old code and starting from line 1. Any experienced developer knows this, and they need to be ready and willing to re-code when necessary without grumbling about it. I was a grumbler, and I learned fast the error of my ways.

6. Being a team player

Every engineering team is just that, a team. There are multiple developers working towards the same goals and writing different parts of the same application.

That means you want someone who doesn’t mind picking up where someone else left off, deciphering someone else’s code or comments and ultimately working in a collaborative environment. Developers that go with the attitude of “mine mine mine!” are probably not going to be a good fit.

Make sure they take this very seriously, even if it’s a team of 1 right now. 

7. Playing well with non-techies

Any strong startup team is not just made up of developers. There are designers, business people, and investors, just to name a few. The engineering team must be comfortable working with other stakeholders in a cross disciplinary environment. There will be project managers and product folks suggesting ideas for the product, which at times might be unfeasible or simply wrong.

I want to hire the engineer that doesn’t criticize or shrug off a flawed proposal, but instead takes the time to explain the problem to decision makers that might not have a technical background.

8. Code formatting

When most developers start out, their code looks like crap. Nothing is indented, views mix with business logic, and the madness goes on. A good developer quickly learns that formatting code well so it is readable and properly commented is very important. When responsibilities shift, it makes a world of difference for engineers to be able to look at code and understand exactly what it does and what other pieces of code it interacts with.

9. Emphasis on documentation

In addition to clean formatting of code, having proper documentation can make everyone’s lives a lot easier when code needs to be reviewed or edited down the road. Keeping a log of every function (along with its parameters), file, and database table is a great habit to get into. It is not as annoying as it sounds, and the consequence for not doing it is a guaranteed headache when you have to sort through 50 files to figure out what 5 little lines of code do.

10. A fun, hardworking, good person to be around

I follow the golden rule of “do not work with assholes.” I don’t care how much of a code master you are, if you’re not nice to other people in the company, if you put others down, or don’t respect authority, then you won’t work with me. I’d much rather train a hard-working, smart, and fun new developer then a self-labeled expert that is rude or arrogant. Choose your team with this rule, hire slowly and fire quickly when there is a culture problem.

If you need to figure out how someone’s going to treat the other people in your company, take them out to a meal or two. When you get a chance before you order, take the waiter/waitress aside and ask them to bring out the food either late or slightly incorrect. Then, see how the engineer reacts to the situation. Do they complain or talk beyond the server’s back? Or do they politely communicate the problem like a nice, understanding human being?

Every startup is going to have ups and downs, and if someone loses their cool at a minor issue in a restaurant, you might not want to be rely on that person when it’s crunch time and you’re a month away from running out of money. 

Are you ready to become a great developer? Awesome! Here’s what you should do:

  • Get on Codecademy: It is the hands down best place on the Internet to learn how to code, co-founded by my friend Zach Sims.
  • Get some books: I recommend ones like the PHP Cookbook that walk you through every key area of the language and provide a ton of real world examples (with real code) to play around with.
  • Start hacking: Play around with code. Make up an idea for a mini application and hack it together piece by piece. It’s going to be clunky – that’s ok, you’re learning!

Good luck!

Thanks to Kirill Klimuk and Drew D’Agostino for their input on this post.

Need more help?
I do a limited amount of consulting each month.


Join the discussion