Even a highly skilled IT security practitioner can be challenged by interview questions. They are often stump-worthy and contrived questions posed to job candidates to separate the wheat (skilled candidates) from the chaff (those who are not). By the time a candidate has reached the point in the interview process that someone is asking these questions, that candidate is usually hopeful of getting the job. A desire to perform well can translate to jitters, panic-induced brain freeze and all sorts of other mental states unconducive to clear, lucid and well-informed answers. Second, the questions themselves are usually designed to be challenging -- often in ways that aren't intuitive. For example, questions can include erroneous or misleading information, have multiple right answers or may test something other than what's immediately apparent.
With this in mind, we've put together a list of incident response interview questions you might encounter during an interview for an incident response position. We've tried to start with those more easily answered, building up to the more difficult. This is not intended to be a complete list of every question you might encounter. Instead, the goal is to help defuse the situation. Just like you'd prep for a security event by conducting a tabletop or other drill to test incident response planning efforts (ensuring you've thought things through in advance), so too can thinking through interview questions give you a muscle memory when you're interviewing for a job you really hope to land.
A few interview prep pointers
Start by brushing up on recent incident response frameworks from recognized information security standards organizations like NIST, ISACA and the International Organization for Standardization (ISO).
Before we get into the nuances of the questions themselves, it's useful to point out that there are a few different types of incident response interview questions you might encounter. There are technical questions, of course, designed to solicit how well you understand how to navigate the technology landscape you're likely to encounter on the job. But there are other types of questions beyond this. For example, there are ethics-based questions designed to assess how well your ethical compass aligns to what the organization expects. Likewise, there are culture-oriented questions designed to elicit what type of person you are -- i.e., your personality. There are also brain teaser questions, designed to evaluate how well you think creatively, solve problems on the fly, or how much you are curious about the world around you.
This article is part of
It's always useful to think about what type of question the one being posed is in formulating your answer. Answer honestly, of course, but be alert to what your response highlights about you along each of these axes: Are you demonstrating a full understanding of the technical space? Are you demonstrating the ethical framework the organization expects? Does your response align with the culture the organization embraces? The key to this is doing a bit of research about the organization beforehand -- for example, on the company itself and, when you can, the interviewer. A quick glance over the company's website or the interviewer's LinkedIn profile can give you some good insight into what might be valuable to them, allowing you to showcase these qualities in your responses.
The second thing to keep in mind is that you can always ask for more information. In fact, for some of the brain-teaser type questions, this is a near-must. For example, in response to a question like "Why are manhole covers round," you might ask for additional clarification -- are they looking at it from a manufacturing (minimization of deviance during manufacturing), a safety (minimization of the chance for the cover to fall through the open aperture) an engineering (minimization of warp or misalignment in cold temperatures) perspective, or something else?
Lastly, be honest. If you don't know the answer to a technical question, say so -- and then follow up with what you do know about the topic they asked about. Explain clearly where the boundary of your knowledge ends if you don't know it. Pretty much the worst thing you can do is try to bluff your way through it. If they catch you doing this (and if you do it, they will), it's usually a deal breaker. However, stating unambiguously and frankly that you don't know something can even sometimes serve to your advantage.
Most common incident response interview questions
Generic advice and caveats out of the way, let's look at a few questions that you might encounter. You'll notice that some of these are generic in nature -- that's by design, as each interviewer will likely put their own spin on it. Also, since some of the questions will be about specific security technology or products, the incident response tool sets used in various organizations will vary and they're likely to ask about the tools they're actually using in their environment. We've also tried to order them from easiest to hardest -- you'll notice, though, that where something falls on this spectrum is open to interpretation. A straight-forward, fact-based question will of course be hard to answer if you don't know it … but a question like that shows up earlier on this list for two reasons: It has single, definite answer and it's unambiguous what the interviewer is looking for.
Question 1: How does [some aspect of] TCP/IP work?
From an incident-response point of view, one of the most important things that you'll need to do is examine components in the technology ecosystem and how they interact, and look at traffic patterns to monitor for -- or resolve -- potential security-relevant events. Understanding of networking is foundational to this exercise. If your interviewer asks technical questions at all, it is almost a given that at least one of them will be an in-depth question about the operation of some network protocol.
The question might be focused at a higher level of the stack (e.g., "How does the TLS handshake work in TLS <1.3?"), it might be in the middle ("How does the TCP three-way handshake work?") or maybe lower down ("What are the elements of an Ethernet frame?"). Unfortunately, the only way to really prepare for this one is to know it -- cold. If you don't, now's a good time to bone up. You might want to look at some packet-capture data (for example, using a tool like Wireshark) to help you refresh or do a quick review of a book like TCP/IP First-Step that explains the topic in depth. As you prepare, quiz yourself and practice walking through how you'd explain how these elements work to someone else.
Question 2: How do you accomplish <task> using <tool>?
The second thing they might ask about is how to perform some task that you will likely need to do often using a given toolset. For example, how would you export syslog data to another system, how would you generate a list of running Docker containers or how would you view an endpoint's software inventory in SpiceWorks? Again, this falls in the easier category because it's binary -- either you know the tool (and have the answer at your fingertips) or you don't. The truth is, you're not going to know every tool that exists: It's likely that the toolset you're using in your current job will differ from the one being used at the potential employer. Therefore, a useful strategy here is to explain that you use a different tool in your current role for the same purpose and offer to explain how to accomplish the same thing in the tool you do know. Savvy interviewers know that learning the concepts involved is hard while learning what button to push is comparatively easy: You'll pick up the minutiae of security product X versus product Y in very little time so long as you understand the goals and purpose behind them.
Question 3: Write a script [or execute commands] to do <task> on <platform>.
You'll notice that this is similar to the last question, except it asks you to author commands or write a script to accomplish some task instead of asking you for detailed knowledge of a particular product. The difference is subtle, but it actually makes the question a little more challenging because there are almost always multiple paths to accomplish the goal. The task here is usually on a given platform -- for example, PowerShell on Windows or Bash on Linux (though other platforms are possible). What questions like this are designed to test is your ability to use tools at your disposal (i.e., the native tools built into the platforms in their environment) to gather data or effect remediation and recovery. Leverage your strengths on this one -- for example, maybe you're not much of a whiz with Bash, sed or AWK, but you're a cool hand with Python or Perl. Play to your strengths, and don't be shy to ask for clarifying detail and additional data.
Question 4: Write a regular expression to find/do <something>.
Everyone hates sorting through log data. It is, however, a part of the job. This means that the ability to use shortcuts to help you find what you're looking for is a must. Regular expressions are used so often in doing this that creating them (sometimes reading and unpacking them) comes up frequently during the technical vetting portion of job interviews. It's useful, therefore, to have at least a passing familiarity with how they work and how to write one. You probably won't be expected to demonstrate mastery of advanced constructions, but you should at least be able to search through log information looking for specific patterns (both case-insensitive and case-sensitive), ranges of possible values, work with positions using anchors (e.g., start of line, end of line), account for whitespace, escape characters, and so on. It's not a given that you'll get this question, though, so don't over-prepare if this isn't your strongest area. (Instead, maybe be ready to explain how you'd use some other tool to accomplish the same goal.)
Question 5: How do you resolve <ethical quandary>?
Counterintuitively, one of the hardest types of questions are ethically based. You might think that "don't be a crook" would suffice as an answer, but questions along these lines can be nuanced and difficult. For example, the interviewer at a managed security service provider (MSSP) might ask you what you'd do if you discover that your company accidentally put a client at risk (e.g., due to a failure or oversight relating to a service or tool the MSSP supplies). Do you tell the customer? If so, how do you do it? If not, how do you handle it? A question like that directly pits the business interests of the organization (and potential profitability) against the ethically appropriate path. Another example might be an internal team or your manager telling you to do something that undermines the security of a customer or the organization -- how do you respond?
There's no easy way to prepare for these, as each situation and incident response interview question will be different. The trick is to fully flesh out the parameters of the question by asking for additional data about the incident and responding honestly about how you would actually approach it. Likewise, the culture of the organization matters as well as your own worldview; for example, when I worked for a large MSSP (where we asked a similar question during interviews), the "right" answer to the service-failure question was along the lines of "alert your manager and inform the customer." I'm sure there are organizations where failure to inform is the right answer -- though, frankly, I wouldn't want to work there.
Bonus Question: Are you the type of person who <xyz>?
I'd like to close with one type of question that you might get, but that's a little different from the ones above. This type of question is designed to solicit who you are as a person -- to see if you fit in culturally with the organization. It's hard to be overly specific about what these might be in advance (which is why it's a bonus rather than in the top five), since organizational culture varies so much from organization to organization.
However, I did want to point out that, intimidating as these types of questions might be, keep in mind that we're in a buyer's market for incident-responder positions. Because of the skills gap and the challenge that organizations have in finding talented incident responders, this means that candidates can afford to be a little bit choosy when it comes to the positions they accept. As a consequence, the interview process is every bit as much the potential employer auditioning for the candidate as it is vice versa. So pay careful attention to what cultural questions are being asked -- these tell you about the organization and what it's like to work there. Be critical, objective and remember that finding out beforehand if an organization isn't a good fit is a huge win compared to finding the same thing out afterward.