Hiring a detection engineer: profile and assessment

Your SOC drowns in useless alerts yet still misses behaviour it should catch? The problem often lies less with the analysts than with the detection rules themselves. The detection engineer is the person who designs, tests and maintains those rules. This guide helps you define the role, recognise the right skills and assess candidates on concrete cases.

What a detection engineer does

Detection engineering treats detection like a software product: each rule answers an identified need, and it is written, tested, documented, versioned, then measured and improved over time. The detection engineer owns that lifecycle.

Typical responsibilities:

• Prioritise the behaviours to detect, based on the threats relevant to your organisation, past incidents and findings from threat hunting.
• Check collection: do the required logs exist, are they parsed correctly, are they retained long enough?
• Write rules in the language of your SIEM or EDR, often starting from generic formats such as Sigma.
• Test each rule against simulated malicious activity and against normal activity, to gauge how well it detects and how much noise it makes.
• Document: what the rule detects, its known limits, and what the analyst receiving the alert should do.
• Maintain: tune noisy rules, retire those that no longer serve, and track coverage against a framework such as MITRE ATT&CK.

The role sits where the SOC, engineering and knowledge of attackers meet. That is what makes it valuable, and hard to hire for.

Detection engineer, SOC analyst, threat hunter: telling them apart

These three roles work together and partly overlap. Mixing them up in a job description attracts candidates who do not match your need.

The threat hunter discovers, the detection engineer industrialises. If you are torn between the two, our guide to hiring a threat hunter covers the prerequisites for hunting. In a small team, an L3 analyst often handles part of detection engineering: that is a normal step before a dedicated role.

When to open the role

A detection engineer adds the most value in these situations:

1. Your analysts complain about noise. A large share of alerts is closed as false positives, always from the same rules.
2. You deployed a SIEM or EDR with nobody to make it work for you. Vendor rules run as shipped, never adapted to your environment.
3. Your incidents reveal blind spots. After each incident you find that no alert fired even though the traces were there.
4. You rely on a managed SOC and want to keep control in-house over what gets detected, especially for your business applications.
5. Regulation pushes you to demonstrate detection capability. This applies to many entities in scope of NIS2, as explained in our article on the profiles to hire first for NIS2.

On the other hand, if log collection is still patchy and no alert handling process exists, start by hiring a SOC analyst or a SIEM engineer to own collection. A detection engineer with no data and no analysts to use their rules will burn out on work that is not theirs.

Skills to check

Knowledge of attack techniques

You only detect well what you understand. Candidates should be able to describe concretely what a technique leaves behind: which log, which event, which fields. A good sign: they bring up, unprompted, the variants an attacker would use to slip past a rule that is too narrow.

Data and query languages

• Close reading of Windows and Linux logs and, depending on your scope, cloud and identity logs.
• Fluency in at least one SIEM or EDR query language, and the ability to pick up another quickly.
• An understanding of data normalisation: a badly parsed field makes a rule blind.

Engineering practices

This is what sets a detection engineer apart from a good analyst. Check for:

• version control (Git) for rules;
• the habit of code review and testing before production;
• scripting (most often Python) to automate tests, deployments or enrichment;
• interest in a "detection as code" approach, without turning it into dogma if your tooling does not suit it.

A sense of trade-offs

Every rule balances coverage against noise. Candidates should be able to explain why they accept a few false positives on a critical behaviour, and why they would rather retire a rule that fires a hundred times a day without ever finding anything. They should also think about the analyst on the receiving end: a detection with no context or playbook wastes time.

Profiles that succeed

Detection engineers most often come from:

• L2 or L3 SOC analysis, with a taste for automation and rule writing;
• SIEM engineering or systems security, strong on data and tooling, needing to add offensive knowledge;
• pentesting or red teaming, for people who want to move to defence and know the techniques from the inside;
• software development or DevOps, more rarely, bringing engineering practices and needing to learn how attacks work.

Choose based on what your team lacks. A team of experienced analysts will benefit from a more engineering-minded profile; a well-tooled but defence-only team will benefit from a former pentester.

How to assess a candidate

The practical exercise

A theoretical interview cannot tell you how good someone's rules are. A short exercise in a lab environment or on a realistic log set says far more. We explain this approach in our article on assessing skills beyond the CV.

A format that works:

1. Describe a specific attack technique and provide logs of one execution of it, mixed with normal activity.
2. Ask for a detection rule in the language of their choice, or in pseudo-code if they do not know your tool.
3. Then ask how they would test it, which false positives they expect and how an attacker could evade it.
4. Finish with a short note for the analyst: what should be checked when the alert fires?

Score the reasoning more than the syntax. An imperfect rule with a clear-eyed analysis of its limits beats an elegant rule whose author cannot see its blind spots.

Interview questions

• "How do you decide which detections to write first?" Look for prioritisation tied to threats, critical assets and past incidents, not exhaustive coverage of a framework.
• "A rule generates lots of false positives. What do you do?" A good answer covers analysing the cases, targeted and documented exclusions, and checking that the tuning does not open a blind spot.
• "How do you know a rule still works six months later?" Expect regular testing, monitoring of collection and tracking of alerts.
• "Tell me about a detection you are proud of." Look for a clear need, a testing method, a concrete result and feedback from analysts.
• "What do you think of vendor-supplied rules?" A mature candidate sees a useful baseline to adapt, neither a complete solution nor something to ignore.

To keep scoring consistent across several interviewers, use our guide to structuring a technical cyber interview.

Mistakes to avoid

• Posting a renamed SOC analyst job description. If the role is mostly alert handling, detection engineers will notice and will not apply.
• Requiring mastery of one specific tool. Query languages can be learned. Understanding attacks and engineering discipline take much longer.
• Counting rules. A hundred noisy rules are worth less than twenty reliable ones. Set expectations on quality, coverage of priority behaviours and analyst satisfaction.
• Isolating the role. A detection engineer needs feedback from analysts, threat hunters and the incident response team. Build those exchanges into onboarding.
• Letting the process drag. These profiles are scarce and in demand. A tight interview schedule is part of your appeal.

In short

A detection engineer turns a pile of inherited rules into a detection capability you actually control. Hire one when your data is available and your analysts need more reliable alerts. Assess them on their understanding of attacks, their engineering discipline and their ability to balance coverage and noise, ideally through a practical exercise.

Looking for a detection engineer? At Cyber Recrut, a recruiter and a security practitioner scope the role with you and run the search together. Our shortlisted candidates prove their skills on hands-on labs, and you only pay when a hire is made. See how we work or share your hiring need.