A Guide to Hiring Developers for Non-Technical Leaders

Do you have a great idea for an app?

Are you the founder of a tech startup?

Are you a product manager operating in the pressure cooker between business, design and technology?

If you answered yes to any of the above then finding a great developer is already on your to-do list. If you’ve been around a while, maybe you’ve already learned the hard way by hiring the wrong developer? Heck, maybe you’ve hired wrong more than once?

As a company that’s been specializing in end-to-end product builds for nearly a decade, and having hired and fired dozens of programmers, we’ve come to learn a thing or two about what makes for great talent.

But when you’re not a technical person yourself, how can you be sure the developer you’re hiring is good?

How do I know if I developer is good or not?

The truth is, this task is as tricky as buying a used car when you’re not a mechanic or buying a fixer upper when you’re not a contractor, and typically it’s approached just as methodically — by going with the gut.

But in the crowded and increasingly commoditized landscape of programmers, everybody is angling for the job and, when it comes to selling skill, most candidates are either lying to you or else kidding themselves.

So here are some practical tips for separating the wheat from the chaff when hiring developers, without reviewing a single line of code.

How can you tell when someone is not so good?

• Does your developer start coding right away as soon as the assignment is created? If so, you might be in trouble. Just like creating an Excel spreadsheet or going grocery shopping, programming tasks and time spent are infinitely spared by some simple planning up front. Look for people who keep a notepad and sketch. Celebrate the stoics and window gazers — these are the kinds of developers who tend to “measure twice and cut once.”
• Can you explain it back to me? True problem solvers must first understand the problem itself. Many programmers find themselves facing challenges but are unable to clearly articulate the problem to others. If they can’t explain it, they don’t understand it.
• When will you be online? Generally speaking, freelancers are used to making their own schedule. Chances are they became freelancers just to be able to make their own schedule. Generally speaking still, freelancers are also terrible at managing their own time. In fact, most lack any connection to time consumption at all — see the ugly truth about timesheets. Time management skills and routine are indicators of discipline. If your programmer isn’t disciplined, there’s little hope that their code will be either.
• Can you tell me about a past problem that was particularly challenging to solve? Programming is nothing if not solving problems. A truly passionate developer would rather chase problems down the rabbit hole than let them go (a simple truth that, by the way, leads to a different issues when estimating and managing technical projects). If your developer can’t readily recall one or several memorable problems, they’re either overly confident (no good) or generally in over their head (no good).
• When you say “design patterns,” they say “huh?” In programming, design patterns are descriptions for how to solve a problem that can be applied in multiple situations. If you’ve heard terms like “MVC” (model-view controller) or “factory method” these all relate conceptually. Design pattern thinking goes hand in hand with planning upfront — it keeps you from repeating mistakes and refactoring code over and over. Professionals don’t like to waste their own time.
• The Handbook of Relational Database Design and more. Last but not least we need to remember that programming is computer science. Way back when people went to school for years to learn how to do it right. With so many online and part-time courses out there (itself another wheat / chaff situation), you may increasingly encounter people who have not truly given their time and energy to learning the discipline holistically. Theoretical knowledge of concepts like classes, inheritance, and object oriented programming are essential.

How can you tell when someone is great?

There are just as many tells for a great programmer as there are for a poor one.

• Excitement meter reads 10. Does your candidate talk excitedly about trends in the field? Can they answer with specificity and zeal what they think is great about programming? Do they want to be doing this job or would they rather be doing anything but? Life is an attitude, do they have a good one?
• Don’t know much trigonometry, don’t know much about algebra, don’t know what a slide rule is for. This may have been fine for hopeless romantics like Sam Cooke, but if you’re hiring a developer it means a lot if they know about math, physics and logic.
• Why PHP vs ASP.NET? It doesn’t much matter if you don’t know the answer yourself, a good programmer should have a clear POV on the benefits of different programming languages and frameworks. What you’re looking for is whether they are versed and opinionated. You can cross-check their ideas against popular opinion with a few pointed Google searches.
• Give me three reasons why documentation and testing is important. Bonus points if you can also comment on why these aspects are typically “left behind.”
• A bug in the bonnet. Great programmers leap at the opportunity to solve problems, especially pernicious bugs that cause their beautiful code to fail, and equally do not feel that debugging and refactoring are beneath them / for “lower level” developers. Dangle this carrot and see what kind of response your candidate gives you. Caveat: great and less great programmers alike hate debugging other peoples’ code, especially when it’s poorly written, but only the former knows the difference.
• Opposites attract. Put simply, if they exemplify the opposite of any bad habits cited above, they likely swing senior and strong.

Qualities to look for

• Problem solving. Can think of a problem in a number of different ways, does not give up easily, knows to research online, looks to peers as resource and isn’t afraid to ask for help. ‘
• Communicates with ease. Able to articulate problems clearly and logically. Can use metaphors to bring stakeholders with differing technical expertise into alignment.
• Sound theory and logic. Likes (and has studied) math, physics, logic or statistics. Can quickly break apart a complex situation into logical component parts, has a grasp of some programming patterns, even if only their own, and can explain them.
• Work ethic. Is disciplined and approaches work methodically, values documentation and clarity, even if just for themselves. Wants to be professional and have others easily understand (and even praise) their work.
• Good at making decisions. Does not rush into coding, fully grasps a concept, plans out the approach (even if just mentally) before writing a line of code. Asks questions and takes time to understand priority and impact in order to work on the right things at the right time.

Take them to the test

At The Development Factory, we’ve developed a series of tests to help us determine candidate suitability and, more importantly, to match their skill level — junior, intermediate, senior — with our own established parameters of skill level.

If you have an in-house or consulting CTO or Technical Lead, we highly recommend having them create tests of your own.

Here is a FREE DOWNLOAD to our own Frontend Programmer test, complete with downloadable assets.

Do you have more tips on how to hire great developers when you’re not technical? Leave your comments below or tweet us @devfactoryLA