Demystifying the Process: Threat Detection Engineering Interviews

After being affected by a round of layoffs, I was launched head first into interviewing full time for Detection & Response related roles. During my month deep dive I spoke to over 25 companies and completed multiple first round interviews. In the end, I decided to do a handful of on-site interviews with companies that best aligned with what I wanted and then choose my next role from that pool.

This was the first time I interviewed for multiple roles at the same time which gave me perspective on some current trends across related roles & their interview panels.

Let’s dive into what I learned!

Conference table in a futuristic world

Interview Structure

The typical structure is standard for engineering roles and begins a little something like this:

• Recruiter Call
• Hiring Manager Screen
• Technical Code Screen

If you move forward in the process, you’ll be presented with a virtual “on-site,” the name is reminiscent of when interviews used to include flying out to the office in person.

The “on-site” ranges from 3 to 5 additional interviews and can include any of the following topics:

• Detection Engineering
• Incident Response
• Attack & Defense / Threat Modeling
• Security Fundamentals
• Values
• Communication & Conflict Resolution

The security engineering interview processes can be long and daunting, so here’s a small guide on how to approach this process for those in the Detection & Response field.

How & What to Study

Let’s break down the most common interview types and how to study for them effectively.

Technical Code Screen

From my experience in Detection & Response, the coding questions are typically more related to the detection job functions than the typical software engineering leetcode problems. This can include parsing logs, making calls to APIs, writing an automation, and talking about how to scale data ingestion. If there are leetcode-esque problems, they are usually related to string manipulation such as creating a function for a valid palindrome. Occasionally I saw these interviews include a short session on writing SQL queries related to retrieving logs from various tables using types of JOINs.

Prior to coding screens, I typically practice coding related to:

• Working with JSON (ex: JSON loads and dumps in Python)
• Sending messages to webhooks (ex: using requests in Python)
• Interacting with files
• Manipulating data structures (ex: dicts)
• General parsing and sorting of data

Besides checking for code completeness, interviewers may also be interested in your approach on:

• Edge cases
• Handling errors
• Testing
• Deploying a solution at scale

Detection Engineering

For the detection engineering interview, it is often split into a technical example of a detection you wrote followed by your philosophical understanding of the detection process and program. Another potential format is focused on understanding and processing threat intelligence data through the detection lifecycle.

In general there is an expectation for you to be familiar with concepts such as the Detection Development Lifecycle (DDLC), detection as code, MITRE ATT&CK, the Pyramid of Pain and the Cyber Kill Chain.

When explaining previous detections that you built at an organization, provide in depth details about the situation that occurred which spawned the creation, your development, testing, deployment, and monitoring of the detection.

To judge your view and approach to a detection engineering program, I found that interviewers like to dive into risk, metrics, building high fidelity alerts, creation of a detection program, the steps of the detection lifecycle, prioritization of detections and logs, and explain the benefits of building detections around TTPs.

There was also a heavy emphasis on understanding and explaining the nuance of CloudTrail and GuardDuty for AWS environments.

Occasionally this interview touched on threat hunting and how the threat hunting process feeds into detection engineering.

Incident Response

If you interview for a Detection & Response role, there will typically be a standalone interview dedicated to incident response. Similar to the detection interview, often it is focused around an incident you have run or contributed to in the past followed by some additional questions.

There should be several complex incidents you have prepped to talk about that occurred in different environments or were triggered by different circumstances. This way you can fit the scenario you dive into based on the interviewer and the company you are speaking to. For example, if the company only operates in AWS then I would choose an incident that I lead in that cloud environment.

Some teams get a sense of a candidate’s experience and seniority through the incident they choose to speak about and the role that they played which contributes to leveling at the end of the interview. Therefore it’s important to prioritize speaking about complex incidents that require cross-team collaboration and communication in order to show your abilities to handle large impact incidents.

When speaking about an incident, practice talking in great detail about the steps you took and the reasons in which you chose to take those actions.

The interviewers may be looking for:

• How you delegate during an incident.
• What specific actions you took / your role in the incident.
• What types of logs were used to understand the attack (if applicable).
• How communication was managed.
• How you maintain chain of custody (if applicable).
• Understanding the risk of the incident and potentially alerting an active attacker.
• What actions an attacker may take to hide their attack.
• What stakeholders are involved.
• When and how to inform upper management / Legal / HR.
• Utilization of playbooks or prior art.

After walking through an incident, there are often follow up questions that dive into post-incident actions such as writing detections from the scenario or which logs would improve the experience next time.

Occasionally, the interviewer had a set incident response scenario in which they wanted to walk through and understand your thought process for their specific scenario.

This may look something like:

• Receiving a phishing email and analyzing it for suspicious indicators.
• Being alerted to a cloud instance potentially being compromised. (ex: GuardDuty alerts)
• Being alerted to an employee endpoint that exhibits suspicious behavior.
• Notification of a misconfiguration of cloud bucket permissions or ACLs.

Attack & Defense / Threat Modeling

Some organizations adopt a threat modeling interview in which they want to understand how you’d both attack and defend a system, such as how you’d approach a simplified version of their product infrastructure or their corporate environment.

These interviews are fun and open ended, there’s often no wrong area to focus on as they are trying to understand how you approach security problems. Interviewers also appreciate when you ask questions to clarify scenarios and details along the way.

Prior to these interviews I like to review threat modeling resources such as the STRIDE model and think about what target assets I want to focus on first such as admin panel access, user PII, or authentication in the environment.

Part of this interview often includes making recommendations on what to do to detect and/or fix the identified security vulnerabilities.

Security Fundamentals

Depending on your leveling, companies may include a security fundamentals interview that covers topics across various areas of security. Typically it touches on security basics, application security, infrastructure security, and corporate security.

You may want to brush up on the following areas:

• OWASP Top 10
• Encryption vs. Hashing vs. Encoding
• TLS handshake
• Explaining how the Internet works (DNS, TCP, routing, retrieving content, etc.)
• Asymmetric vs. Symmetric cryptography
• AWS CloudTrail logging & GuardDuty alerts
• How Kubernetes works and its logging
• WebAuthn
• Endpoint configuration hardening
• SSO
• Zero Trust

Values

The Values interview is a critical interview in which the team determines if you are going to be a good fit for the team by evaluating your soft skills and interests. To study for this interview, you want to learn about the company, their values, where they invest their time into, and the ways in which you’d benefit from being a part of their mission.

These questions are often asking about how you relate to their values, your strengths or passions, and your weakness areas. They might also touch on how you interact with the security community such as where you get your news, events you attend, volunteering you may be involved in. The most vital part of this interview is having a good answer for why you want to work for the company.

They may also approach this interview where they ask for the candidate to do a project retro or ask about projects in the past that demonstrated examples of the company’s values. Prepare a couple projects that include aspects of the company’s values in case they ask for you to dive into it.

Communication & Conflict Resolution

Another common interview is often led by a cross functional partner and covers how you approach working with others, communicating in general, and handling feedback & growth opportunities.

They can include questions such as:

Tell me about a time…

• when you had a conflict with a co-worker, team, or other department.
• in which you had a conflict and needed to influence somebody else.
• when you needed to overcome external obstacles to complete a task or project.
• you faced pushback/resistance to your approach on a project.
• you had a disagreement with a stakeholder.
• you received constructive feedback or worked on a growth area.

How do you approach…

• tackling a challenge and learning from it.
• difficult working relationships.
• working with distributed teams.
• learning from mistakes.

Interviewing the Interviewer

While the team is interviewing you, it’s also important to remember you’re interviewing them. This is your chance to build an accurate view of the workplace, team dynamics, tech stack, and other key aspects of the role.

As you interview make sure you take notes after the call on the details of what you learned in the conversation and any potential concerns to follow up on. These are crucial when you’re making your decision on where to join.

Well tailored questions also demonstrate genuine interest in the role and create a good impression on the interviewers.

Here are some examples of detection engineering related questions:

• What does the detection tech stack look like?
• How do detections get deployed?
• What is your coverage of systems logged in your SIEM like?
• How often are you performing detection & response on production vs. corporate related systems?
• How is the security engineering team perceived by other engineering teams?
• How do you view Threat Detection’s role in collaborating with other teams?
• What has the evolution of the Detection team looked like?
• What does the roadmap for the next 3–6 months look like? How will this role contribute to it?

Here are some general other areas I like to ask questions on:

• Are there opportunities for external engagement for the team? What does that look like?
• How is performance evaluated for this position?
• What annual opportunities are there for personal career development like training?
• What is a project coming up that you are excited about?
• Is there an on-call? What does that look like?
• What does a typical week look like for you? Do you work async or spend time working together or in meetings?
• How would you describe the team culture in three words?

Making the Decision

As mentioned above, there are many factors that come into play when deciding where you want to take your career next and this is where those notes during your interview process can be crucial.

The following are some of the areas I divided into pros and cons before signing for my next role.

• Salary & Benefits
• Team Culture & Collaboration
• Career Growth Opportunities
• Upcoming Team Projects
• Company Growth
• Work / Life Balance
• Travel Requirements
• In-Office or Remote Environment

Ultimately, this guide is just the beginning of all the things you could read in your journey for your next role. There are some additional great resources about general tech interviewing from those at Tech Interview Handbook and security specific topics to study provided by Grace Nolan.

Thanks for reading! If you’re also in Detection and Response and have ideas on how to improve this list, let’s collaborate. You can reach me at @julieasparks on Twitter or in the comments below.