If you don’t necessarily have a technical background and you’re thinking about bringing in a developer, how do you assess them? How do you even know if they have the very particular set of skills your site or application needs?
On this Founder Friday, Mattan and Chris tackle how to win devs, and make an exciting announcement for all you geeks on the comic book side of the spectrum.
Programming is its own language. Or rather, it’s a language with lots and lots and lots of different languages that different developers speak. But as a non-speaker, there are several ways you can break through all the C++ and CSS to get an honest, accurate picture of a potential developer.
1: Master The Phrasebook
The hard truth is if you’re hiring someone to code for you, you should learn at least a little bit of code. That takes time, and some effort, but it’s worth it for a couple of reasons.
The first is that you need to know what you’re talking about, at least at the surface level, because that’s going to inspire confidence and trust in your developer that they’re working for someone who knows what they’re doing; that they’re working for someone who values their contribution.
But beyond that, you need to, at least on the surface level, know what they’re talking about, and the basics of the argument they’re making for themselves. There are many places all over the internet you can get access to an hour of code, just to start you off.
But rather than leaning only a little bit of HTML, or a little bit of Java, the best play is for you to develop (ha) a holistic sense of what code is and how it’s useful to your business/startup/site. More about that at the bottom.
2: Check The Portfolio
It’s not your job to know everything, however. The best lens into a developer’s skills and experience is through a portfolio of their work.
Whether it’s just screenshots or whether they’re able to bring in an application they worked on, actually being able to see examples of their work can give you a sense of what they’re capable of.
But you can’t just look at webpage. You need to be strategic in how you’re ask a potential developer to describe their experience, and drill down on their portfolios. Find out what their personal contributions were. Push for the reasoning behind why they make that choice and not a different one. Get them to describe how they worked on their projects, whether it was remote and freelance or leading a team.
Look not only for their expertise, but how engaged they are in telling those stories. It’s worth taking at least 5 minutes on each example to really get a candidate talking. People will reveal themselves once they’re put in the position of having to relate their experience.
You want someone who’s thoughtful and excited about what they do, not disengaged, condescending to a non-programmer, or talking over your head.
3: Ask For Recommendations — From the Candidate
The other way to get a thorough, but thoroughly non-technical, sense of a good developer is to ask for recommendations. Before you make a call or shoot off an email, ask the candidate what they think their references are going to say.
Before you actually call and contact the references, ask the candidate what they think their references will say. This will tell you a lot.
Again, pay attention to the language they use — whether they’re hesistant or dismissive or really eager to talk about their old team.
Don’t worry about the imagined imposition of reaching out to someone who’s worked with a candidate. It isn’t one.
Talking to someone on that person’s team can give you a whole other window into not only what that person’s skills are, but how effective they are in accomplishing projects and collaborating.
Whatever you need a developer for, you’re going to need them to keep you in the loop. So, just keep the “no jerks” rule in mind. No jerks. Don’t do it. You want someone on your team to be on your team.
And lastly… Should you require a developer test or not? Some specific questions to ask if you do:
There are a few additional ways to judge a developer.
A trial period, or beginning a working relationship with someone on a project basis, is almost never a bad idea. It gives you a chance to test their ability to contribute effectively to your team — and see the progress they make with their code — without the full commitment of a salary and benefits.
Ask them what their experience with and how open they are to regular check-ins. Again, good developers won’t just be able to code. They’ll also be open to feedback and willing to present their ideas to non-technical teammates.
Some specific questions that can help you gauge a developer: ask them what their favorite stack is, what language do they like to code in and why? Do they do any testing, and if so, what kind of system? Do they use version control, like Git? Just because someone’s been coding for a while, that doesn’t mean they’re good.
Look for someone who’s open to trying new things, and who seems like they can adapt to the constantly changing methods and technology.
It’s really that willingness to communicate, and the ability to explain themselves and be held accountable, which separates good developers from just developers.
Even if you only need some one-off help, you’re bringing someone into your team’s locker room. It’s not enough that they can code. They also have to communicate.
