Over the last few months I have been speaking to a variety of companies about joining their security teams. If you’ve done any software interviews, you’re probably pretty familiar with how these things go: an hour is usually divided into two parts, the first part being roughly 45 minutes long, with the interviewers asking you questions. The second part is left for you to ask any questions you think are important.
I have always been slightly surprised by how neglected the second part of these interviews typically is. Over the years, I’ve interviewed hundreds of people and have generally found that they either don’t prepare for the questions section, or have a set of questions that are not well thought through.
On the rare occasions where I have met a candidate who has asked interesting questions, this has been a strong point in their favour; when the baseline is so low, it isn’t particularly hard to make a good impression. It’s also worth remembering that you’re potentially going to be working with the people in your interview for years - don’t you really want to be sure you’re making the right choice? After all, they have just spent 45 minutes making sure you’re the right choice for them.
Some general principles that I find useful for the questions I ask in general (and these could really apply to any job interview, not just security engineering):
- Minimise qualitative questions: Questions like ‘How well is the security team regarded within the company?’ are not going to get you a useful answer. No one - in my experience - is going to lie outright, but they are trying to hire you. Even if the CISO was intentionally locked in a meeting room last week while the rest of the company proceeded to ship a highly vulnerable release, the best you are going to get is a vague answer referring to ‘the need to ship regularly and the healthy tension between that and security’.
- Do ask quantitative or process-oriented questions: It is more difficult to gloss over shortcomings when asked a question that refers to a concrete process or has a specific numerical answer. ‘What is the ratio of application security engineers to developers?’, for example, has a specific answer that can tell you a lot about the extent to which security is prioritised within an organisation. It also can lead to an interesting discussion about why the ratio is the way it is - has there been rapid and recent growth? Are there turnover issues within the security team?
- Use the cultural interviews to learn about the team you will be joining: The culture-fit interviews will frequently be with people from outside the team that you will be working with, which is a good oportunity to find out about how the team is perceived. I would expect mature security teams to work with a wide range of people across an organisation, from finance to operations, and the question ‘When was the last time you interacted with the security team and how did you find the interaction?’ is surprisingly insightful. When I was interviewing at Sourcegraph, a particular team member’s name came up multiple times in a very positive light - a sign that there are some high-performing individuals in the team, the sort of team you want to be joining.
Keeping all of that in mind, here are some more of my go-to questions for security engineering interviews:
- When developing a major new feature or product, how are the product requirements scoped?: The main thing you’re looking for here is whether the security team is mentioned at all in the process. Are they included, or will they have to find out about the feature/product on their own? Obviously, the former is preferable.
- If a developer wants to use a new open source software library, what is the process in place for them to do so? Are there any guardrails to ensure the library is safe?: The ideal answer here is one where there is a light (and potentially automated) review of licensing, whether the library is being actively maintained, and whether there are any known vulnerabilities. The introduction of a new software library introduces a significant ongoing burden to an organisation, especially one that ships software externally, so the decision shouldn’t be taken lightly.
- If I joined your organisation and we were looking back a year from now, what would a successful year look like for me?: This is a good question to understand what the pain points are that the company is looking to solve. Is is regulatory certification, expanding client requirements, or just to beef up existing operations? Is this something that you want to be doing? Is there a plan, or are you in charge of making the plan?
- What does a successful security team look like to you?: This is a good question to ask senior execs outside the security team, should you get that far into the interview stage. I’ve received a range of answers, and while there’s no one correct response to this, I tend to find the most attractive organisations have executives who see the security team as a group who can actively contribute to an organisation’s overall engineering excellence, rather than as a dull but necessary regulatory function.
- What is the most common type of security incident your organisation faces? How are you tackling this? A relatively easy question that helps get into some interesting areas. The things I’m looking to understand are whether there’s a well-defined incident response process, whether the company is collecting metrics about the incidents that are affecting them, whether the security engineers are aware of what those metrics look like, and finally whether their response plan includes post-mortems and further improvements that are actually put in place. There are also technical aspects to this answer which might be interesting depending on the issues the organisation might be facing.
- How do you decide whether to build or buy security tooling? This is really a personal preference in terms of where you want to work, and I think I stand somewhere in the middle of the spectrum. It is important, however, that you receive some sort of conscious opinion here, and that this opinion chimes with your own. Businesses that are non-software at their core (do these still exist?) might have a reasonable bias towards buy, while large software businesses might have very good reasons for building most of their tooling. At its core, the question you should be asking yourself is whether the answer you are given makes sense given the business in question and their engineering principles.
There are other questions that will be specific to the organisation that you are joining. These types of questions are already well covered in other interview guides available online, but I would stick to the following basic points:
- You may be interviewing for a ‘pure’ security role, but understanding the wider context of the market the organisation is operating in is essential. Ask senior leaders questions about the product range, and gauge whether their answers make sense to you - it’s your dinner on the line if they get it wrong.
- Understand the regulatory and competitive pressures for the business. Security requirements are fairly frequently derived from a combination of internal engineering attitudes, regulatory requirements, and competitive pressure. Ask questions about how the business is planning to meet regulatory requirements and exceed their competitors’ offerings in terms of security. Does the business perceive security as a potential USP of the product?
I hope this is useful to other people out there interviewing! I’ll be joining Sourcegraph as a Security Engineer in January 2022.