How We Interview Developers at Security Compass
I wrote what follows for the internal wiki at Security Compass. I have new people helping to interview, so it felt like a good time to document how things work so everyone understands our process and the reasons why it is the way it is. Since I'm sharing job postings here on LinkedIn, it feels like it might also be useful for future candidates to understand how things work as well. (We are hiring right now!) And if you're trying to design an interview process for your own company, maybe what follows will serve as useful inspiration.
Goals
I have a lot of strong feelings about the state of interviewing in the tech industry, and how it’s mostly a lot of nonsense and garbage. I have yet to encounter a situation where someone knowing how to balance a binary tree or answer cute brain teaser questions has proven useful while doing actual work. I don’t even think it’s a good indicator of future success at a company. Silicon Valley companies, filled with people from ivy league schools and Waterloo graduates (hey it’s me!), engineer an interview process that biases towards hiring those same people. People read blog posts or experience these interview processes, ape them for their tiny software companies, and then lament the state of diversity in the tech industry. So, to start, none of that.
Over any specific technical skills, we favour a capacity to learn, motivation to do so, and a desire to take the initiative when there is work to be done. We want to hire people who are friendly and supportive over the savant-programmer no one wants to work with. This is a team sport. It’s easier to teach someone Django than it is to teach them how not to be dreadful.
Process
Everything begins with a job posting. We have tried to write ours with language that is inclusive, to encourage people of all backgrounds to apply. We review postings with our People and Culture team before they go live, so the recruiters understand what we’re looking for in the next batch of hires. (Maybe we want someone who is stronger at front-end programming this time around, for example.)
Recommended by LinkedIn
The recruiting team reviews resumes and organizes interviews. They are the first point of contact for candidates, and will phone screen candidates. This is a basic assessment of the candidate, what they are looking for, if they seem like a match for the job. If they seem like a good match, the recruiter will pass the candidate on to the development team to interview. This whole process is managed via a tool called Greenhouse. Interviewers will get invites from Greenhouse about interviews they are to conduct, and can also use the tool to record notes and scores for candidates.
The development team conducts two interviews, both of them done by a pair of individuals. We ask a consistent set of questions so that there is standardization across all our interviews. Both of these things hopefully keep the process fair for all candidates.
If the development team is keen to hire the candidate they move on to a final interview with someone from the executive team, usually Rohit (our CEO) or Michelle (Chief People and Culture Officer). We may try to align this interview with the preceding behavioural interview to speed up the interviewing process.
The recruiting team picks things back up if a candidate makes it through the process, dealing with offers, getting contracts drafted, and all that good stuff.
Then we wait eagerly for our new team member to arrive.
A short caveat: "But Ram, what about Google, they must get thousands of applicants for their jobs ..." I appreciate wanting to turn your interview process into a real gauntlet if you have a large pool of candidates you need to make more manageable. Trying to recruit people who remember their 2nd year computer science classes the best, or are willing to study for an interview like they'd study for their CS 444 exam, is one route to take, for sure. Is it the best one? I have my doubts. And if you don't have the problems of Google, you certainly don't need their solutions.