How to tell if a developer is “good” if you’re not technical

If you’ve ever been asked to interview a software developer, and you’re not technical, it can be a little daunting. What should I ask? What are good answers vs bad answers? How do I know if they're just BSing me? I feel like I don’t even speak the same language? 

This guide can help you evaluate a software developer candidate even though you might not have experience or exposure to software engineering. 

What Not to Do

Have your technical friend interview them 

“Can you interview this developer and tell if he’d be a good fit for my project?” This is usually a terrible idea. Conducting a good technical interview is difficult and requires two conditions to be successful. 

First, the interviewer must be well versed in the actual technology that will be used in the project. This is why it doesn’t make sense to get your neighbor who helped write a top iOS app to interview the dev who’s going to write your awesome new web app in React. Your neighbor may be awesome, smart, funny and make great burgers but they probably don’t know anything about modern web technology. Technology moves ahead at a merciless pace and keeping current is both difficult and rare.

Second, it requires a common shared experience. If you haven’t worked with the person requesting the interview on a project together it’s a stretch to interpret their feedback. There’s no shared experience in common to use as a yardstick. Their good may be your terrible.

Google some technical questions and ask these

Just don’t do it…your judgement isn’t tuned to choose relevant questions nor adequately evaluate responses to them. 

What about references?

Unless the reference is someone you know well, their feedback is quite hard to interpret. This is, unless of course, it’s a terrible review. Then run.

But what if they worked at Google/Facebook/Twitter/Netflix?

It is very common to think “they worked at Google, they must be smart.” We’ve had enough inside experience to know that there are always well run projects and disasters. Look at peers you’ve worked with and you can identify rockstars and slackers. The same is true for every company big and small. Just having a famous name on your resume is no assurance that the developer in question participated in one of the better projects. Even Googlers have come to this conclusion.

So what are some better approaches?

So where does this leave us? What can you do yourself to figure out if this person is a fit? 

Interview them yourself and look for the following:

Ask them to explain their last two projects. They should start with the business goal and then explain the project management solution they used (agile, waterfall, any tools) and then finish with the technical solution and what they specifically contributed to it. Here are the things to look for:

Project Goals:

• Make sure they understood the business goals of the project.
• Ask questions and challenge the business goals. See how they handle criticism, conflict and if they really understood what they were doing.

Project Management Methodology:

• There should be some agreed upon methodology in place.
• There should be some sense of how communication worked and how feedback was handled.
• Ask about negative feedback. They must have done something wrong. How did they handle fixing it?
• Look for collaborative language versus criticism. If they bash on the PM or business users you can count on the fact that they’ll be saying the same thing about you.

Technical Solution:

• Use of metaphors.  A lot of software development relies on abstraction. Great developers will be able to communicate these abstractions to non-technical users via metaphors. If you immediately get a bunch of acronyms you don’t understand this is not a good sign. 
• Self reflection. A good developer will highlight what they did well but also flag what they learned and would change next time.
• Overstating their contribution - In a one person team they obviously did all the work. If they were part of a 7 person team and they claim all the credit, that’s a bad sign.
  

Finish the interview with a final communication test

Small projects fail more often because of communication, not technical hurdles. Just ask yourself do I really think this person understands what I am saying? Do I understand what they are talking about? 

Explain your project and have them repeat it back to you. Have them give you the elevator pitch back. If it doesn’t sound right you can bet that they’re not going to translate it into software properly.

After you’ve hired them, look for predictable & repeatable results

If they do good work, then they’re good.  It’s amazing how often this idea is seen as novel. Set up a trial period (say two sprints, ~30 days) and actually work together. Agree to share some of the risk. Perhaps if the work isn’t up to quality, the developer agrees to half their billing rate. Then if it goes poorly you’ve wasted time and some money, but the same goes for the developer. At Admios we offer to drop the invoice entirely if you don’t like our work in the first 30 days, but our scale is different than that of  individual contractors.

Your top takeaway is to look for solid repeatable results. Here’s a decent checklist:

• Work was delivered on time.
• If there was a delay, the developer communicated it early and clearly.
• The developer proactive flagged any technical unknowns (these are always present).
• Feedback from Team Lead and client is positive.
  

You don’t need to be technical to interview or evaluate software engineering candidates. Hopefully this guide gives you a bit more confidence to have an engaging and informative conversation. If you’re reading this because you’re looking for developers to help your project, we’d love to have a 15 minute conversation with you to see how we might be able to help.