You’ve scoured the earth to find a promising web development candidate – and now it’s time for the interview. Your candidate seems smart, has a decent portfolio, and says they can do it all. But how do you know if they’ll really get the job done?
Successfully vetting a developer is a huge challenge – especially if you’re not a full-stack developer yourself. Here’s how to make sure your developer is really an all-star – even if you don’t have the experience to review and judge every line of their code.
What agency owners say…
“Some developers show portfolio items that turn out to be done by others on the team. Yes, they were part of the project, but were they the driver, or are they taking credit for the entirety of the project when they had nothing to do some parts of it?”
“There isn’t a standard program of education to compare developers or determine qualifications.”
“I’d say one big challenge in hiring would be coming away with a good understanding of the person’s troubleshooting, deductive logic, problem-solving, etc. Beyond code, if they hit a wall are they able to research, test, and come up with a solution on their own?”
“Since interactive projects are team projects, it is difficult to decipher the developers’ individual responsibilities and achievements when looking at past work.”
Say no to code reviews
Many web developers will maintain a public Github account or offer to show you examples of their code. This is cool, but it’s not a particularly helpful way for you to measure how the candidate will operate in the real world, which is where you need them to help your business succeed.
The problem with code reviews is that they lack crucial context. For starters, looking at a Github repository if you’re not a full-stack developer feels a lot like staring into the Matrix. Even if you can successfully dissect the code, you have no idea if this project took them a few hours or a few years. And you have no idea how much of their code is pulled directly out of the copious open-source examples and libraries, which means you really don’t get a great sense of what they’re thinking and what they can do on their own when there’s a deadline approaching.
At the same time, you’re missing critical information about the goals of the client for whom the portfolio project was created. It’s not uncommon, for example, for a dozen team members at a client company to contribute to a project – often asking the developer to do things in a way that pleases the client but doesn’t really conform to best-practices. When you’re looking at a finished product, it’s very difficult to know exactly how much of it came directly from your candidate, and how much was influenced (in good or bad ways) by their client or other members of the project team. You may even disagree with a client’s decision – or focus intently on something the actual client didn’t consider important – and end up giving your candidate demerits for something that wasn’t their decision or their fault.
Interview for communication and enthusiasm
So without putting a ton of weight on a code review, how do you know if your candidate is right for your company? Start with a brief, one-on-one interview (I do mine via Zoom). The goal of this interview is not to ask questions with right-or-wrong answers, but to chat and get a sense of the person’s ability to do three things:
- Schedule an appointment and communicate effectively via e-mail
- Speak comfortably and professionally in a business setting
- Tell you a story about a project they really enjoyed, with lots of specifics about their favorite parts and their challenges
It’s your job to simply ask questions and let the candidate regale you with tales of development projects past. Ask questions like:
- What are your favorite types of projects to work on?
- What’s the coolest thing you’ve built recently?
- What was your most challenging project in the past year?
- What was your most rewarding experience in the past year?
Notice that these are all broad questions with the goal of getting them talking. You’re not quizzing them or putting them on the spot to prove anything to you right now.
If you want to get more specific, you can ask about things you know you have in the pipeline. Here are two of mine:
- Have you ever built a custom WordPress plugin? Tell me about it.
- Have you connected WordPress to an outside API? Tell me all the details about what you built.
By the way, those two are my sweet-spot qualifier questions, and you should experiment with creating your own. If a developer has done both of those things, they’re generally going to be what I consider a Software Engineer – which is akin to a Level II web developer from a hiring and compensation standpoint. In other words, they’re beyond entry-level, and thus they’re likely well-qualified to work at Howard Development & Consulting.
If your developer candidate can tell you some cool stories about things they’ve built in the past if they seem really excited about it, and especially if they can show you that they have experience on your “sweet spot” tasks, you’re ready to rock. Wrap it up with some small talk and get to know them personally a bit, then offer them a test project.
The test project
This is where the rubber hits the road. You’re about to offer a paid, one- to two-week project where your developer can show you how they work in the real world.
You’ll frame this by saying, “This will be an opportunity for both of us to test out working together. If for any reason either of us finds it’s not a good fit, we can part ways with no worries whatsoever.”
Your test project should require about 20 hours of work and come in one of these two forms:
- Ideally, a small project on a relatively loose timeline, allowing them to take a little longer (or mess up completely) without affecting your relationship with your client.
- If you don’t have a small project ready, have them re-do a project you completed in the past year.
The benefit of having them do a real project is that you actually get something done and you get paid for it, but you do run the risk of them failing and pushing your schedule back a couple of weeks. Paying them to re-do a previous project is a cost out of your pocket, but you get the benefit of taking a safer approach to your test.
Notice that neither of these options allows you to drop the developer into your most important, hugely expansive, extremely high-value project for your best client that’s already a month behind. Don’t do that.
During the test project, you’ll want to give very clear instructions, but also find places to ask your developer to “use your best judgment.” In fact, seeing how they act when they use their best judgment is the whole point. You can hire lots of developers for $5 an hour who can work their way down a meticulously defined checklist – but you need someone who has the initiative and experience to take basic instruction from you and extrapolate it into something that’s pretty close to what you would have done yourself.
That way, you’re actually saving time and getting huge value from your developer (because they can make reasonable decisions without you), as opposed to painstakingly micro-managing every pixel and line of code.
One of my largest clients once asked me, “You’re the only developer I’ve seen that has scaled up without reducing quality. How do you do it?” (Yes, that was really their question, verbatim.)
My response: “We have problems with hiring from time-to-time, but it’s on test projects so you never see it.”
That’s the beauty of the test project. You keep it low-stakes and force your new developer to show you how they behave in a real-world environment, and only once you know they’re up to the task do you assign them mission-critical work.
If they succeed, you’re ready to roll. If not, it’s a small cost and you can part ways amicably and move on to your next candidate, without doing any damage to your business in the process.
“When we’re choosing a new designer, we hire each of the finalists for a week, pay them $1,500 for that time, and ask them to do a sample project for us. Then we have something to evaluate that’s current, real, and completely theirs.
What we don’t do are riddles, blackboard problem solving, or fake ‘come up with the answer on the spot’ scenarios. We don’t answer riddles all day, we do real work. So we give people real work to do and the appropriate time to do it. It’s the same kind of work they’d be doing if they got the job.”– Jason Fried and David Heinemeier Hansson, founders of Basecamp, in It Doesn’t Have to be Crazy at Work
