How we interview engineers
Relationships are what I want to build with my employees. It’s how I know I can trust them, how far I can push them, and ultimately, how I can help them achieve their dreams.
There are two parts to a relationship - buying and selling. Whether it’s with your friends, your employees, or your mother. With friends, I buy their shoulder, their time, their companionship, and I sell those things of mine right back to them. With employees, it’s more concrete. I buy their productivity, and I sell them their salary. With my mother, it’s less quantitative. I sell weekend chats and vacation photos and talks about her future grandkids, and I buy homemade meatloaf or a nice story about how my father went fishing and caught the biggest catfish ever.
You’re always giving and taking. Relationships are best when there’s a lot of trade activity.
An interview is like that; it’s about gauging the worth of the trade. Most companies out there focus on what the employee can give to the company, but as with any trade, if it’s one-sided then it’s too hard to find out what the other party is really offering, so I like to put what I offer on the table first.
Before I jump into buying and selling, you’ll need to know the basic structure of an interview:
1. Research Phase: CV or referral or I spam their LinkedIn 2. Flirting Phase: Phonescreen 3. Homework Phase: Take home quiz 4. Dating Phase: In-person interview
I want to sell two things - What the company does and how the company works
I like to give candidates ample opportunity to research me and the company. They can find a plenty of things about Rentify on our github page or engineering blog. They can find out about me on my github page or my personal blog or Twitter. I let them know what kind of company Rentify is by publically talking about our methods, kind of like what this very blog article is doing. The more information for them, the better. I expect them to use this information as a basis for discussion points in the later interview phases. They should know a little about what Rentify does and the kind of culture we expect to maintain.
I write all these blogs and make things public because I want the candidate to be armed with questions, concerns, or ideas for improvements. I want them to have an idea of what I’m selling.
It’s my job to clarify all the muddled points that I couldn’t convey properly over blog articles. Usually I go in depth over a topic that they want to know more of, e.g. deadlines, I might explain: “I preach that we don’t have deadlines at Rentify, but keep in mind that while I’m very adamant about not making arbitrary deadlines, the entire company has a deadline of shipping things fast to our users because we have a finite amount of venture capital.” A good candidate should understand that if by going from the “startup standard” 18 months of run time, then we have 18 months to make the product work.
During the flirting phase, I spend time talking about Rentify, touching on our company goals, explaining our current pain points, being uncomfortably transparent. I usually tell them a story about high street letting agents and how landlords and tenants are feeding money to a black hole. I tell them how Rentify solves problems for tenants and landlords with technology, and how the candidate will be a part of that technology that literally changes the way the industry operates.
I will sell them the culture, about how Rentify engineers like to hack after hours or on the weekend if they are interested in a project. I talk about maintaining a healthy work / life balance, our unlimited vacation policy when we need a break, our friday (or thursday (or whenever)) beers, our food challenges (they’re epic). I talk about my personal goal as a CTO, how I want to make sure that they attain enough skills and knowledge that when they walk away from Rentify, they are equipped to be technical product managers, or CTOs, or CEOs of their own.
I sell them this dream because I’ve seen it before at Eventbrite. I myself have lived this dream. If people chose to do so, I want this opportunity to be available for everyone who works beside me.
The take home quiz is always reflective of the kind of job they’re going to be doing at Rentify. If they’re a full stack guy or gal, I’ll ask for a small project that does one difficult thing, then I tell them they can add all the bells and whistles they want in order to showcase their abilities. I make the challenge vague enough to where they should ask me a few questions about it. This is another selling point - that I don’t tell them how to complete their work. They should research and decide for themselves the best course of action. That’s how the Rentify world is. Specs are meant to be broken, cut down, expanded upon, or even thrown away sometimes. I’m selling them that they won’t be zombies. They’ll have brains. And they will use them.
When the homework comes back, I look at it. If it’s worthwhile, I’ll show it to the team. They’ll comment and critique and I’ll do a quick skype call with the candidate to go over the homework if required.
The in-person interview is a gauntlet run, so I start out the interview with selling them a comfortable setting. I walk them through the office, introduce them to the entire team (everyone in the company), tell jokes. Before they arrive, I give them a breakdown of what their schedule may look like:
1100 - Luke and Jerome about databases 1145 - Ryan about architecture 1230 - lunch with Amaresh and Tom about product/design 1330 - Pair programming with Drummond 1530 - Pool game with George to talk about company vision 1600 - Alex about web 1645 - Coffee with Buf about next steps
It’s just common courtesy to give people an idea of what they’re walking into. Plus it helps to align the team so they don’t overlap questions or waste time by asking “fluffy” questions. I make sure I work with my team so that the interview questions are relevant to the topic. Luke and Jerome would ask about joins, indexes, storage engines and performance. Alex would talk about the lifecycle of a request. Drummond would pick a card out of Trello and literally let the candidate build a feature for Rentify.com and launch it. George would talk about company vision. I would finish it up about logistics, start dates, salaries, expectations. Et cetera. Et cetera.
Now the candidate knows the whole team, they’ve seen how we work, they’ve asked their questions. We’ve sold them all we have to offer. And that’s all we can do. I want them to leave the Rentify office thinking, “Jesus, I’m going to build so much cool shit there.”
I want to buy three things from a candidate: 1. technical abilities 2. ambition 3. culture
When I’m researching a candidate, I want to see github profiles and applications they’ve built. I don’t care where they went to university. I’ve met and worked with a person that went to Stanford who was inept and a person who dropped out of highschool and then went to prison who was one of the best ops guys I’ve ever met. In fact, I don’t even look at what school the candidate went to.
I look for clear, concise code on github. I look for people who write code as a passion, not as a job. I look for extra curricular activities. I look for social activity on Twitter. If they’re tweeting about technology, it’s an indicator that they enjoy it. If they have a blog writing preaching test coverage, I’m interested.
I’ll go over their cover letter and drill into a listed topic until either A) they don’t know the answer or B) I can’t drill down anymore because they know more than me. It doesn’t matter which outcome it is, only that we have a good discussion. I might do this over another topic for a greater sample size.
I’ll ask about what they want to get out of the role at Rentify. If they don’t have a compelling answer here, I’m not buying what they’re selling.
I love seeing homework with a readme detailing the choices they’ve made. I hope to hear back from the candidate one or two times with questions. The homework should show that the candidate exerted effort, and that s/he enjoyed the homework. Enjoyment shows in the work itself from quality and attention to detail. The more communication, the better. I once got homework back from a guy who recorded his screen as he coded, talking through his choices, mistakes, and refactors along the way. He delivered the screencast and the code, and received an instant “hire” vote from almost the entire team. (Not because he sent a video, but because the video proved he was good.)
If a candidate makes it all the way to the dating phase, there’s magic in the air. I want them to ask everyone on the team questions, about testing, process, design, new product ideas, hackathons. The more questions the better. In fact, the more questions the candidate asks, the less judgemental the team is. We’re so busy painting the picture of our ideal work environment and how we’re making a difference that we unconciously blend all those good feelings and thoughts with the candidate’s presence. If the conversation is good, the team feels like the candidate understands and can help drive us forward.
Besides communication, the basics are checked. Is the candidate an asshole? Would they not fit in with the team? Are they French? If yes, then we decline them, doesn’t matter how great of an engineer they are. (Just kidding, we hired a French guy, and he’s awesome.)
After the Dating Phase, I check with the team to see if we want to buy what the candidate is selling. We go through a debrief to vote on “Hawaii” or “New Hampshire” (hire or no-hire), a process that I blatantly stole from my time at Eventbrite. The entire team makes this choice, and we only hire candidates who are unanimously voted as Hawaii. If the trade happens we celebrate, and then, of course, we get back to work.Sharing is caring -