How to Assess a Detection Engineer Before You Hire
How to assess a detection engineer: four skills that matter, a task for each, what strong and weak attempts look like, and how to test tuning, not just writing.
6 min read 
To assess a detection engineer, test four things: turning an attack technique into detection logic, knowing the telemetry well enough to write against it, tuning noisy detections without blinding them, and testing whether detections actually work. Give the candidate real logs and real rules, and score both what they write and how they tune it. Writing a rule that fires is easy; writing one the SOC still trusts after a month is the job.
Below, each skill comes with what it looks like on the job, a task that tests it, and what strong and weak attempts look like.
1. Turning a technique into detection logic
On the job: a threat report or red team finding describes an attacker behaviour, and the detection engineer has to express it as a rule that catches it.
A task that tests it: describe a technique, such as PowerShell downloading and running code from the internet, and ask the candidate to write a Sigma rule or a KQL query for it.
| A strong attempt | A weak attempt |
|---|---|
| Targets the behaviour, such as the process relationship and command-line pattern | Targets a single hash, domain or IP address |
| Uses the right log source and fields | Guesses at field names |
| Lists likely false positives and a sensible severity | Treats every match as malicious |
| Notes gaps, such as obfuscated commands or alternative binaries | Assumes the rule is complete |
2. Knowing the telemetry
On the job: a rule is only as good as the data behind it. The engineer has to know which logs exist, which fields they contain, and which events are missing or not collected.
A task that tests it: give the candidate a set of logs, for example sign-in records or process events, and ask them to find a specific attack in the data.
| A strong attempt | A weak attempt |
|---|---|
| Explores the schema before writing a query | Writes a query from memory that fails on real field names |
| Finds the attack and proves it with a query | Gets close but cannot show the evidence |
| Notices what the data cannot show | Assumes everything is logged |
3. Tuning noisy detections
On the job: most of a detection engineer’s time goes on making existing rules better. A rule that fires hundreds of times a day on benign activity gets ignored, and then it misses the real attack.
A task that tests it: give the candidate a noisy rule and a week of its alerts, and ask them to tune it.
| A strong attempt | A weak attempt |
|---|---|
| Groups the alerts and identifies the benign patterns | Looks at a few alerts and guesses |
| Writes narrow exclusions, scoped to specific accounts, hosts or paths | Excludes a whole process or user group |
| Explains what the exclusion could hide | Does not consider what the change might miss |
| Considers lowering severity or combining signals instead | Disables the rule |
4. Testing that detections work
On the job: a detection that has never fired may be quiet because nothing happened, or because it is broken. The engineer has to prove it works, and keep proving it as logs and systems change.
A task that tests it: give the candidate a Sigma rule and five events it matched, and ask which are true positives and which are false positives, and how they would test the rule before production.
| A strong attempt | A weak attempt |
|---|---|
| Reads the rule logic precisely and judges each event in context | Assumes every match is malicious |
| Proposes testing against recorded attack data or a safe simulation | Plans to “see if it fires” in production |
| Mentions monitoring log sources so silent failures are caught | Does not consider broken data feeds |
How to test tuning, not just writing
Most detection assessments only ask candidates to write a rule. That tests the easy half. The skill that protects your SOC is tuning, and it needs a different task: give the candidate an existing rule plus its real output over a period, mostly benign with one or two genuine hits, and ask them to make it better without losing the real ones.
A good tuning task tells you three things at once: whether the candidate can read alert data at volume, whether their exclusions are precise or lazy, and whether they understand that every exclusion is a trade-off. The best candidates explain what their change would miss before you ask.
How to calibrate the assessment by level
| Level | What they own | What to test |
|---|---|---|
| Junior | Writing and maintaining rules under review | Rule logic, reading telemetry, true and false positive triage |
| Mid-level | Owning detections for a set of techniques | Tuning, testing, documentation |
| Senior or lead | The detection programme and its coverage | Coverage against a threat model, prioritisation, detection-as-code practice |
What an assessment cannot tell you
A hands-on assessment shows whether a candidate can write, read and tune detections. It cannot fully show how they prioritise a backlog, how they work with the SOC analysts who receive their alerts, or how they would build a detection programme from scratch. Leave those for the interview and references.
For questions to use in that interview, see these detection engineer interview questions. For the wider method behind task design and scoring, see how to assess cyber security skills of candidates.
Frequently asked questions
What skills does a detection engineer need?
Query languages such as KQL or SPL, rule formats such as Sigma, deep knowledge of the telemetry they write against, an understanding of attacker techniques, and engineering habits such as version control and testing.
Should a detection engineer assessment use your own SIEM?
Use the query language the role will use, but do not test knowledge of your specific setup. Your field names, log sources and tuning history can be learned in the job; the ability to reason about telemetry cannot.
How long should a detection engineering assessment be?
Long enough for one writing task and one tuning task. Tuning takes longer to do properly, so allow time for the candidate to work through alert data rather than rushing a single rule.
How CyberHire assesses detection engineers
CyberHire is cyber technical screening that tests these skills on real telemetry before you book an interview. Pick from the library or paste your job specification and generate an assessment. Candidates work through KQL hunting labs against realistic sign-in and endpoint data, Sigma rule true and false positive triage, Windows event log investigations, and detection rule authoring and tuning.
Every candidate is scored the same way, with integrity signals next to each score, and you see their queries and reasoning. Detection engineers are one of the roles we assess; see all use cases. If you would rather not build the assessment yourself, our team will build it with you.
Hiring a detection engineer?
Test detection skills on real telemetry, free.
Send us the job spec. Within 48 hours we send you a hands-on assessment built around it, in your branding. See who can write a detection that works before you interview anyone.