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.

No alt text provided for this image

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.)

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.

  • The first interview is a technical interview. The focus is on trying to understand the person’s programming experience and problem solving ability. We try to ask open-ended questions that will prompt discussions about software development.
  • If this interview goes well we ask the candidate to do a short programming assignment to get a glimpse of what their code might look like. This should ideally take 1-2 hours of their time. This assignment is marked “blind”, by people who didn’t do the first round interviews, which hopefully removes any bias. We normally don’t reject a candidate for an assignment we felt was weak, but would likely do a follow up technical interview to discuss their work further and understand how they came to the solution they did. If someone takes the time to do an assignment, it only seems fair that we take the time to talk to them. (Unless it truly feels like it would be a waste of everyone’s time.)
  • The second behavioural interview is focused on soft skills. Usually managers or senior developers on the team perform these interviews. This is where we would try and assess people’s alignment to our core values: Customer Focus, Collaboration, Ownership, Authenticity, Respect. We have tried to pick interview questions that highlight each of these values. 

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.

To view or add a comment, sign in

More articles by Ramanan S.

  • 10 Years (and change) at Security Compass

    I wrote what follows for a work newsletter. Our office manager wanted me to comment on my impending 10th year of…

    19 Comments

Others also viewed

Explore content categories