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

{ 1 comment… add one }

  • Summer Daza April 5, 2013, 3:19 pm

    Simple tips but very important!
    If I could share a small advice about hiring not just developers but in general; I find one successful CEO’s advice unique and I think you might also find it interesting.
    “I keep my eye out for someone who has achieved a lot, so they’ve been a great athlete or on a great team, but then something didn’t go quite right, and they’re still very hungry and want to be C.E.O. of something. I like to bet on people, especially those who have taken risks and failed in some way, because they have more real-world experience. And they’re humble. I also like to hire people into one position below where they ought to be, because only a certain kind of person will do that—somebody who is pretty humble and somebody who’s very confident.”
    – Mark Pincus, co-founder and CEO of Zynga

    Reply

Leave a Comment