You may have noticed that we’ve chatted with a lot of really smart people through our Inside Look interview series. As we wrap up 2015, we’re revisiting some of the sage advice we’ve encountered from these founders, CTOs, and engineers.
Today, let’s close out the year with tips about what to look for when it’s time to add new talent to your team. What should you keep your eyes open for when you’re hiring developers?
[Tweet “”What to look for when it’s time to add new talent to your team?” – via @codeship”]
I think what we really look for is grit, the ability to learn, and gallows humor. I think that gallows humor is highly correlated with the ability to survive in a high-energy startup. You know, you need to recognize that everything is miserable, and it’s unlikely to get better; but that, ultimately, that’s what we’re doing for our users. We suffer so that, hopefully, other people won’t have to. I think that if you can’t laugh at that, you’re really going to have a hard time. Databases in particular are miserable, you know?
[Tweet “”What we really look for is grit, the ability to learn, and gallows humor.” @pvh on @codeship”]
One way we talk about our goal internally is to just try and claw back the misery of using databases just a little bit. Databases are still terrible to work with, but I think we have managed to make them more approachable and more joyful for developers to use. And, ultimately, that’s what we’re in the business of doing.
I think it’s important when you hire remotely that people have drive. They need to have some ‘startup DNA’ in them so they can thrive when things get turbulent. So they can be proactive even when communication isn’t optimal and always ask: “What can I do?”
I think it’s vital to get the right people early when you have remote offices.
[Tweet “”They need to have ‘startup DNA’ to thrive when things get turbulent.” @primdahl on @codeship”]
Good communication skills are crucial, perhaps even more valuable than technical aptitude. We’ve interviewed quite a few individuals who are clearly extremely technically competent but who have had difficulty clearly communicating the reasoning behind their decisions. They very well might be able to churn out an absolutely brilliant solution if they are left alone for a long period of time, but that’s not necessarily valuable to us.
Collaboration is key, and code written in isolation is code that’s liable to become a problem. It’s difficult turning down people who are very technically qualified, but we feel it’s best in the long run.
[Tweet ““Code written in isolation is code that’s liable to become a problem.”
We are also just looking for passion, like every company. One of the strongest indicators is when someone comes in and communicates how they think indico could be made better. That’s a huge positive indicator.
We look for really entrepreneurial folks. We have people who are independent and don’t need a central authority figure to tell them what to do, because we don’t have that. And then there are some specific values that are really important to us — things like introspection; humility; honesty; not shying away from difficult conversations, but understanding that difficult conversations can be had with grace and with empathy.
On the engineering side, I think all that applies. There’s lots of different problems here, so sometimes we’re looking for folks to help out with specific pieces of our stack. So, we certainly hire (have hired and are continuing to hire) some of the best distributed systems engineers in the world.
[Tweet “”You don’t need to already have all the answers to be here.” @dkador on @codeship”]
We’re also hiring people who just want to be one of those someday. You don’t need to already have all the answers to be here. We want people from all walks of life. So, we do a lot of distributed systems engineering. We do a lot of data engineering. We do a lot of amazing visualization work. We do a lot of amazing front-end work. It’s full stack. There’s lots and lots of pieces to work on here.
We don’t have product managers, at least not today, at PillPack. So we expect all of the team members to participate across the spectrum of product development. Our product team is a combination of designers and engineers. We believe strongly that you have to get close to the problem that you are trying to solve.
Therefore you need engineers and designers that can collaborate together on the user research, requirements gathering, and ultimately the creation of new product experiences. When you silo these activities in different disciplines like design or product management or engineering, you end up requiring a lot of handoffs and subsequently losing much of the context critical to designing and building great experiences.
So when we’re hiring engineers, we look for an aptitude to participate across this spectrum. It’s important that they write great code, but it’s also important that they write the right code.
[Tweet “”Write great code, but also write the right code.” @elliotcohen on @codeship”]
We look for people who are really curious. It’s pretty easy to gauge curiosity based on someone’s responses in an interview. When we start talking about different aspects of the business, do they ask thoughtful questions? It’s really telling what questions people ask.
[Tweet “”Motivation and curiosity are what matter.” @brendan on @codeship”]
Sometimes engineering candidates are only curious about technical things, but we look for a broad curiosity. Some people ask about the business side of things because they’re genuinely interested — that’s great. I’ve also talked with plenty of people who got burned working for a company because the business model was bad and they now recognize how important it is to understand that. It’s not great that they got burned, but it’s amazing they have that newfound motivation and excitement to get involved in more parts of the company. Motivation and curiosity are what matter to me when hiring.
Maybe this is basic. But I think a key is to have really well-thought-out job descriptions. What do we expect this person to do, do we expect this person to get critiques, what outcomes are we expecting? We need to figure that out. I want someone to know they’re being measured and what sort of metrics they’re measuring against and making sure that those are within their realm of influence.
I’m a fan of putting the KPIs in the job description. Letting people know exactly how the success of a role is going to be measured. I’ve been told, “Well, that’s kind of heavy for a job description. Maybe we should have a conversation about that.” But, regardless, you should know that if I’m hiring you for this role, this is how we’re going to tell whether or not you’re successful. And if you don’t feel comfortable being measured on that, obviously we can talk about that if you still want to apply for the job. But also maybe it’s not a good fit.
[Tweet “”What To Look For When Hiring Developers” – via @codeship”]