3 Tips For Hiring Developers That Don’t Suck

4898034060_dd6fbaae43

It’s one of the biggest problems that new companies have when they’re just getting started, how to take a great idea, and build a great team to make it happen. Now as many of you know I’m a huge proponent of the Lean Startup Methodologies and highly recommend that you spend time working with real customers and validate your idea BEFORE writing any code. However, once you’ve proven that your assumptions are true, or false and have iterated onto something that is seeing traction, then it’s time to build.

Here’s the catch. Hiring terrible developers could sink your company before it even starts. Ask anyone who has scaled a company and they’ll tell you, hiring developers is hard. Yes, there are plenty of people who can code, but not all of these coders are reliable people who write good code and get things done at a reasonable pace.

We’ve all heard stories of companies who sunk tons of money into development only to be riddled with bugs and a team that isn’t motivated to fix them. Having hired quite a few developers in my life, and having helped IBM hire developers from Carnegie Mellon for two years I’ve learned a few things about finding good developers, you know, ones that don’t suck.

  1. Check References – it amazes me how few people check references, and for those who do, how many don’t look-into who those references are. Don’t just talk to someone’s friends, talk to previous employers who know how well they work. Ask questions, and really dig in deep to understand how they performed at their last job. Remember, just about everyone says they left a company, it’s up to you to determine if that’s what really happened or if they were told to leave for one reason or another. Getting ahead of any potential problems is critical and it all starts with references.
  2. Code Samples – sure, someone may know HTML, CSS, PHP, Java, etc. but unless  you see some code you don’t really know how good they are. If you don’t know how to code yourself, find someone that you know and trust to look over their code. Sloppy code with limited error checking can get you in trouble very quickly and something may look great on the outside, it’s what’s inside that counts.
  3. Trial Period – start with a trial period. Most people will kick ass their first couple of months, it’s what happens after the new car smell has faded away that will show you how they really drive. I’ve heard of varying trial period from 3 months all the way up to a year. No matter how long you decide to pick for the trial period the old mantra “try before you buy” can and should be applied to hiring whether it’s a developer, salesperson, or office manager.

As always feel free to share your own tips below or comment on any of mine.

Photo Credit: Official GDC via Compfight cc

Morgan Linton

Morgan Linton