The savvy entrepreneur knows an A-plus team is the difference between successfully launching a product and staring down the cold, hard barrel of failure. Hiring developers can be one of the most daunting tasks when it comes to choosing team members, especially for the entrepreneur who might be flying blind with little-to-no coding skill.
I reached out to Taso Du Val, CEO of Toptal, a network of engineers created by engineers. Only 3 percent of engineers considered are accepted following a rigorous screening process. Here’s 10 tips Du Vall offered for evaluating a developer:
Write down all the “must-have’s” the person needs to fill the position, and the “like to haves” that the ideal candidate will have. No one will be the perfect candidate, but you can come close. If you’re hiring an iOS developer and he or she must have Objective C, story boarding and multi-threading, that must be evaluated during the initial call.
If it would be “nice” if they knew Java for back end or sockets, but it won’t be required on a daily basis, don’t toss out candidates because they don’t have that experience. That pickiness results in a longer hiring cycle while companies look for engineering unicorns.
If you’re a remote team, it may be a bad culture fit to pick someone who needs hand holding daily. It’s also tough to work with some “hacker” personality types if your entire organization is extremely professional. Know your company culture and ask questions about what type of working environment the engineer prefers.
Some entrepreneurs think they can grab great talent at a discount price. Engineers are in demand, and the demand is only going up. Freelance engineers will have a range in hourly rate for their skill. You better know the market price or you may underbid and lose them to another opportunity, or overbid because they know you aren’t savvy. They may be expensive because they are the best, or maybe because they think you’re naive. Have a budget, and know what skill set you’ll get for that budget.
Engineers are notorious for being lone wolves who like to work alone. This is fine when they’re typing code all day but they need to respond to requests in a timely manner, and can’t complain about participating in mandatory daily and weekly SCRUMs. Ensuring they will communicate daily and help team members who fall behind are important for the project.
Product roadmap deliverables and iteration cycles are what drive software development, and these are always tied to deadlines. Ask questions about hitting deadlines, what happens if they don’t hit their deadlines, and what they’ll do to alert their manager when they fall behind.
“The biggest nightmare is an engineer who tells you he’s on course, only to find out on delivery day he’s not even close to submitting. It sets your whole team back, and possibly your whole company,” explains Taso. “Be sure to really vet the engineer’s ability to not only hit deadlines, but communicate accurately when he or she might be falling behind.”
I’ve personally noticed this problem when outsourcing some of our development work for Due to agencies. They miss deadlines and aren’t ever on-time with deliverables. This caused me, and I’m sure many others, to start looking elsewhere.
Determine an engineer’s standards when coding to determine whether or not you’ll have bugs and crashes. You’ll also want to make sure they’re not causing any problems for the next developer working on the code, so knowing how they comment could be vital. Standards consistent with every aspect of your business should be implemented and followed to ensure quality.
One of the biggest problems that any employer faces is an employee who can’t take feedback. A great employee who takes coaching, and even wants coaching, is an employee who will have long-term viability at any company.
Surprisingly, some engineers will send you links to their portfolio proudly, and its a buggy product. Ask to see a demo of their portfolio and always check their references to rest assured that they actually worked on the project.
Rapid prototyping a feature to see if an engineer really is adept at a certain skill setisn’t that uncommon these days. Some CTO’s at larger organizations have been known to have developers rapid-prototype feature sets for hours to confirm their skill set, all while he sits there, looks at emails, and occasionally watches. Watching the developer code and having him or her walk you through the process, what they’re doing and why, will help you understand if they will be a good fit.
Rushing will often get you the wrong fit. Create a process that includes a phone screening, an in-person interview, a peer interview, and a rapid-prototyping test. These steps will assure you the person is skilled, a cultural fit and will reveal to your team any red flags before you hire.
Last but not least, does this person have access to other developers? Hiring developers is very expensive, and an engineer who can convince others to join your team down the line clearly has leadership potential, is a team player who is well liked, and a great asset.