| What the role is in 2026-27 | Authoring, testing, tuning and retiring the logic that turns telemetry into alerts, plus owning what that logic depends on: the log sources, the field schema, the validation tests, the runbook attached to each alert, and the review cycle that kills rules that stopped earning their volume. The output is production content with a lifecycle, not a clever query. |
|---|---|
| Posting titles that mean this job | Detection Engineer, Threat Detection Engineer, Detection and Response Engineer, Security Content Engineer or Content Developer, Security Analytics Engineer, Threat Researcher (at vendors and managed detection providers), and Security Engineer with detection in the responsibilities. Searching only the exact phrase 'detection engineer' hides a large share of the market. |
| Closest confusions | A SOC analyst triages what the rules produce. A threat hunter looks for what no rule covers and hands findings over to be turned into content. An incident responder works the confirmed compromise. A security engineer builds and operates controls. A security data or platform engineer owns the pipeline and the SIEM bill. A detection engineer owns the logic itself and everything required to trust it. |
| Typical hiring loop | Recruiter or sourcer screen, hiring manager call, one or two practical rounds (live rule writing, or a take-home with a log sample), often a telemetry and architecture round, sometimes a Python round at platform-heavy employers, and a team or on-call conversation. Two to five weeks at most employers, faster at a managed detection provider, months where a security clearance has to be processed. |
| Credential gate | No licence anywhere, and no mandatory certification. A US security clearance is the only hard gate, and only for defence, government and intelligence work (with a polygraph in parts of the intelligence community). GIAC GCDA, GCIA, GCFA and GCTI, Microsoft SC-200, and platform certifications from Splunk, Elastic, CrowdStrike or Google SecOps read as credible to practitioners; Security+ and CySA+ mainly clear HR and government filters. A degree is common and not required. |
| Pay, and where to read it | There is no US Bureau of Labor Statistics occupation code for 'detection engineer'. Bracket it with OES 15-1212 (Information Security Analysts) and read the metropolitan-area tables rather than the national median, then read the ranges employers must publish under state pay-transparency laws in Colorado, California, Washington, New York, Illinois and a growing list of others, and levels.fyi for the large technology and fintech security ladders. For US federal work read the GS scale and the 2210 series. In the EU, the pay transparency directive (2023/970) has to be in national law by June 2026, which is putting ranges into more European postings. Naming those sources beats quoting a band. |
| Portfolio minimum that works | Six to ten technique write-ups in one public repository, each with the hypothesis, the telemetry and exact fields, the rule, the attack test you ran, the firings it produced, the false positives you found and what you did about them, and the variant you could not cover. That beats a hundred untested rules, and one merged public rule is worth more in a screen than any certificate. |
| What changed by 2026-27 | Identity and SaaS became the primary intrusion surface, so the centre of gravity moved off the endpoint and onto sign-in, token, consent and control-plane telemetry. Detection-as-code (git, peer review, CI tests) became the default expectation rather than a maturity badge. Ingest cost became an explicit design constraint, and interviews ask about it. Automated and AI-assisted triage now consumes alerts first at a growing minority of employers, concentrated where alert volume is high, which raised the bar on alert context and runbook quality instead of removing the work. |
What a detection engineer actually does, and which postings are really this job
A detection engineer owns the logic that decides what a security team gets woken up for. That means writing the rule, knowing exactly which log source and which fields it depends on, running the attack to prove it fires, measuring how often it fires on benign activity before anyone is paged, writing the steps the receiver follows, and coming back three months later to decide whether it still deserves to exist. The deliverable is production content with a lifecycle, and the quality bar is set by the people downstream rather than by the elegance of the query.
Describing it as 'writing rules all day' sets the wrong expectation and candidates get caught by it in interviews. A realistic week includes a meaningful share of data work: finding out that a log source silently stopped shipping, discovering that the field a rule depends on is only populated on part of the fleet because an agent version lagged, normalising an event into the schema the rest of the content uses, arguing about whether a verbose source is worth its ingest cost, and reading an intrusion report to work out which of its steps are visible in your environment at all. Then there is the content itself, the tests around it, and the tuning queue.
Three activities sit at the centre and interviewers probe all three. First, abstraction: turning a specific observed intrusion into logic that catches the class of behaviour rather than the one sample. Second, validation: proving the rule fires on the behaviour and knowing which variants slip past. Third, cost: knowing what the alert does to the humans or the automation that receive it, because a technically correct detection that produces hundreds of benign alerts a day is a net negative, and a senior candidate says so out loud.
Before you tailor anything, work out which adjacent role the posting actually describes. The titles overlap in the market and the responsibilities do not.
- SOC analyst (tier one and two) triages the output of detections, enriches, dispositions and escalates. Measured on queue handling and accurate dispositions. This is where most detection engineers come from.
- Threat hunter looks for activity nothing currently alerts on, works from hypotheses rather than a queue, and the output of a good hunt is a new detection or a documented telemetry gap. Many teams merge hunting and detection engineering into one role, and the posting will say so in the responsibilities.
- Incident responder works confirmed compromises: scope, contain, eradicate, write the report. Detection engineers consume IR output, and your own organisation's post-incident reports are the best source of detection gaps you already have access to.
- Security engineer builds and runs controls: EDR deployment, hardening, email security, network segmentation. Overlaps on tooling, differs on deliverable. A posting that is mostly 'deploy and operate the EDR' is this job, not detection engineering.
- Security data or platform engineer owns the pipeline: collection, parsing, routing, retention, the data lake, the bill. Increasingly a separate title at larger employers, and increasingly the person a detection engineer negotiates with.
- Threat researcher at a vendor or managed detection provider studies adversary behaviour and ships content to many customers, often with public writing attached. Closest cousin to detection engineering, with more emphasis on malware or campaign analysis and on writing that leaves the company.
- Detection engineer owns the logic and its lifecycle. If the posting lists a query language, a log source inventory, false-positive rate, ATT&CK mapping, detection-as-code or alert tuning, it is this job whatever the title says.
The move from triage to detections, which is how nearly everyone gets in
Detection engineering is not an entry-level job at most employers. Postings commonly ask for a few years in a SOC, in incident response, or in systems and cloud operations, and the reason is not gatekeeping: you cannot judge whether an alert is worth sending until you have been on the receiving end of a few thousand of them. If you are in tier-one triage now, you are in the best possible position, and the work of getting the title is mostly the work of being seen doing the job before you have it.
Be clear-eyed about why this move is worth making now. The repetitive front of triage is where automation and outsourcing landed hardest: managed detection providers absorbed a large share of first-line monitoring, and the current wave of AI triage tooling is aimed squarely at the enrich-and-disposition loop. Detection engineering sits one step upstream of that, deciding what gets sent at all, which is a harder thing to automate away and a better place to be standing. That is an argument about where the durable work is, not a promise, and anyone who tells you a security job is automation-proof is selling something.
The internal play is specific, and it is the same play whether you want the title where you are or somewhere else. Everything in it produces a written artefact with your name on it, because that record is the portfolio when you apply.
- Mine your own queue. Pull the last 90 days of your tickets, rank the rules by volume, and for the worst one work out what share closed benign and what the benign cause actually was. That analysis is the single most valuable thing a triage analyst can hand a detection team, because they rarely have time for it.
- Bring a tuning proposal, not a complaint. The query change, the expected volume reduction, the coverage you would lose, and how you would confirm you did not break the true positive. Written, one page. This is the audition.
- After every incident you touch, write the detection that would have caught it earlier, test it, and open a pull request or a ticket. Keep the link. Two or three of these are worth more in an interview than a certificate.
- Own one thing end to end: a single ATT&CK technique, a single log source, or one alert use case. Ask explicitly for it. 'I own our identity detections' is a sentence that gets interviews.
- Volunteer for every purple team exercise, breach-and-attack-simulation run or tabletop, and own the gap list afterwards. If your employer runs none, run Atomic Red Team tests in a lab and bring the results.
- Learn the platform's query language properly rather than clicking the console: SPL for Splunk, KQL for Microsoft Sentinel and Defender advanced hunting, ES|QL and EQL for Elastic (note that Elastic's own KQL is a different, simpler language from Microsoft's Kusto, and interviewers do check you know the difference), YARA-L for Google SecOps, XQL for Cortex XSIAM, Python for Panther, SQL for anything data-lake backed. Depth in one plus reading fluency in a second is the right shape.
- Write the runbooks nobody else wants to write. Runbook authorship is detection engineering work and it is usually unclaimed.
- Ask to be added as a reviewer on the detection team's pull requests before you are on the team. Reading other people's rules and their review comments is the fastest available education in the bar, and it makes you a known quantity when a role opens.
- Take the receipts with you: pull request links, before-and-after volumes, sanitised incident references, the names of the tests you ran. Numbers from your own work are the one place numbers belong on this resume.
How hiring works, and how differently it works by employer type
Who screens you first depends on the employer, and it changes what the first conversation is for. At most companies it is a security recruiter or sourcer working a keyword list drawn from the posting: platform, query language, cloud, sometimes a certification. At managed detection providers it is often a dedicated technical recruiter who has screened hundreds of these and will ask you one or two real questions. At small teams the hiring manager is also the detection lead and screens you personally, which is the best case because the conversation is immediately about work.
The stages are fairly stable: screen, hiring manager, one or two practical rounds, sometimes a telemetry and architecture round, sometimes a coding round, and a team or on-call conversation. Two to five weeks is normal. What varies enormously is the weighting, and getting that wrong is how strong candidates fail. Read the employer type before you prepare.
- Managed detection and response providers, and the detection teams inside endpoint and SIEM vendors. Your content ships to thousands of customers you will never see, on telemetry you do not control. They weight false-positive behaviour at scale, whether a rule survives environments that look nothing like each other, and whether your written runbook can be executed by an analyst with no context. Hiring volume is highest here and the process is fastest, which makes it the best-odds door into the discipline. Watch the careers pages directly rather than waiting for a job board: Expel, Red Canary, Huntress, Arctic Wolf, Rapid7, Sophos, Binary Defense, Mandiant and the vendor content teams at CrowdStrike, Microsoft, Elastic, Splunk and Palo Alto all hire for this repeatedly.
- In-house enterprise teams: banks, insurers, health systems, retailers, manufacturers, universities. Often a team of one to ten. They weight depth in their platform (most commonly Microsoft Sentinel and Defender, or Splunk), understanding of change control and of stakeholders who will push back on your tuning, and whether you grasp that ingest has a budget. Expect questions about operating inside constraints rather than greenfield design.
- Large technology, fintech and crypto companies. Detection engineering here looks like software engineering: detections as code in a repository, CI tests, a data lake or streaming pipeline, custom tooling. Expect a genuine Python round, expect to discuss testing and deployment practice, and expect them to care more about engineering rigour than about how many SIEM products you have used.
- Vendor content, research and threat intelligence teams. They weight public output: a blog, a conference talk, published rules, malware or campaign analysis. The practical exercise may be analysing a sample or a campaign write-up rather than writing a SIEM rule. If you want this path, write publicly starting now.
- Government, defence contractors and anything cleared. The clearance is the gate and it dominates the timeline, sometimes for months. Tooling can be older than you expect and process heavier. Cleared detection engineers are scarce, which is reflected in pay and in how long these roles stay open.
- Consultancies and SIEM implementation partners. They weight breadth across platforms, client-facing communication and migration work (very commonly Splunk to Sentinel or the reverse). Good place to accumulate platform range quickly, less good for depth in one environment's baselines.
The detection exercise: the forms it takes, and how it is graded
This is the round that decides the job, and it is a practical exercise far more often than a quiz. Five forms cover almost everything you will meet, plus a sixth if the employer has a live range. Ask the recruiter which form it is, in which query language, and whether documentation or an AI assistant is permitted. All three are legitimate questions and none of them is held against you.
Across every form the grading is roughly the same, and it is not syntax. Interviewers are looking for whether you start from the behaviour rather than the tool, whether you know which telemetry would actually carry the evidence, whether you volunteer the false-positive surface before being asked, whether you have any way of proving the rule works, and whether you consider the person or process receiving the alert. Candidates who narrate that reasoning while getting a field name slightly wrong routinely outscore candidates who produce clean syntax and no reasoning. Say your assumptions out loud, including 'I would check that field name against our schema', because silence is scored as not knowing.
- Live rule writing. 'Write a detection for credential dumping from LSASS', or for persistence via a scheduled task, or for a suspicious OAuth consent grant. In their language, in a shared document, sometimes on a whiteboard. Pseudocode is usually accepted if you say which field you mean and why.
- Take-home with a log sample. You get Sysmon JSON, EVTX exports, CloudTrail or Entra sign-in logs, Zeek logs or a packet capture, and a loose brief: find the suspicious activity and write detections for it. The write-up is graded more heavily than the rules. Ask the time cap and respect it visibly. If an unpaid take-home is open-ended and large, it is reasonable to ask for a scoped version or a live session instead.
- Tune a noisy rule. You get an existing detection and a sample of its firings, nearly all benign, and are asked to fix it. The trap is answering immediately. The strong move is to ask what the rule is for, what the analyst does when it fires, and whether this should be an alert at all, before touching the logic.
- Threat report to detection strategy. You are handed a public intrusion write-up, commonly from The DFIR Report or a vendor blog, and asked what you would build. They are testing layered thinking (what is prevented, what is alerted, what is only huntable), telemetry realism, and whether you will say out loud which steps you could not see.
- Critique an AI-written detection. Increasingly common: a rule drafted by a model, syntactically plausible, with a field that does not exist in that schema, an operator that does not mean what it looks like, or a match on a tool string rather than a behaviour. Say what is wrong, say how you would verify it against the real schema and real data, and say what the rule would cost in volume.
- A hands-on environment: a live Splunk, Sentinel or Elastic instance with seeded activity and an hour to find it. This is closer to a hunting exercise, and the same narration rules apply. Practise by loading a public dataset into your own stack, because the first time you fight a search bar should not be in an interview.
A worked answer: the seven steps, with credential dumping as the example
Use the same seven-step structure for every detection question, out loud, in this order. It is close to the Alerting and Detection Strategy framework Palantir published and many teams adapted internally, and interviewers recognise the shape. Having a structure is most of the advantage, because it stops you doing the thing that loses the round, which is starting with a query.
Step one, the goal, stated as behaviour. 'Detect an attacker reading credential material out of the LSASS process memory.' Not 'detect Mimikatz'. Step two, categorise it: the ATT&CK technique (OS credential dumping, the LSASS memory sub-technique) and, more usefully, the functional chain. An actor must obtain a handle to the process with read rights, read its memory, and get the result somewhere usable. Tools differ enormously at the surface and converge on that chain, which is exactly why you abstract to it.
Step three, technical context: which telemetry carries the evidence. Sysmon event ID 10 records process access with the granted access mask, and the masks associated with memory reads are the classic predicate, though a mask alone is a weak one. An EDR gives richer process-access and handle telemetry, often with the call stack, which is what lets you separate a direct API call from a handle duplicated out of another process. Windows Security events 4656 and 4663 can cover object access but require a SACL on the object and the matching audit policy, which most environments do not have. Say which of these your employer actually has, and say if you do not know.
Step four, blind spots, before anyone asks. Dumping the SAM and SYSTEM registry hives avoids LSASS entirely. The MiniDump export in comsvcs.dll invoked through rundll32 produces the same outcome through a signed Microsoft binary. Tools that issue syscalls directly, or duplicate an existing handle, or use the silent-process-exit and debugger-based paths, change the surface your rule matches on. Where LSA protection or Credential Guard is enabled the attack shifts rather than disappears. Naming two or three of these, and saying which ones your rule does not cover, is the clearest senior signal available in this round.
Step five, false positives, with specifics. Endpoint protection products legitimately open LSASS, as do backup agents, some vulnerability scanners, Windows Error Reporting, and an administrator who opened Task Manager and clicked 'create dump file'. The right handling is a named allowance for a signed binary from a specific path with the publisher checked, not a wildcard on a process name, because the process name is trivially chosen by an attacker. Step six, validation: run the Atomic Red Team tests for the technique and the variants above, confirm which fire and which explicitly do not, then run the rule in production in log-only mode for a week or two to get the real volume before anyone is paged.
Step seven, deployment and lifecycle. Is it an alert, an enrichment, or a hunt-only query? What severity, and why? What does the runbook ask the receiver to check, in order, and what is the escalation condition? Who owns it, when is it reviewed, and what tells you it has gone silent because a log source broke rather than because nobody is attacking you? That last question, detection health monitoring, comes up constantly and very few candidates raise it unprompted.
Then prepare the same structure for two non-endpoint examples, because in 2026 these come up at least as often. For identity: session-token replay after adversary-in-the-middle phishing, where the sign-in succeeds with a correct password and a satisfied MFA claim but the session appears from a new network and device, alongside the behaviours that usually accompany it, a new MFA method registered, a mailbox rule created, an OAuth consent granted to an unfamiliar application, or a help-desk credential reset followed immediately by enrolment from a new device. For cloud: a long-dormant identity creating a new access key, immediately followed by identity and inventory enumeration from an address range that principal has never used, validated with Stratus Red Team rather than hand-waved.
The questions that decide the interview, and what a strong answer contains
Beyond the exercise, a predictable set of questions separates people who have operated detections from people who have only written them. None of these have trick answers. All of them reward a specific story with an artefact or a number attached, and all of them punish generalities.
Prepare two detections you built end to end to the depth of the structure above, one incident where your detection missed and what you changed, and one rule you deliberately deleted. That last one is the quiet favourite of experienced interviewers.
- 'How do you know a detection works?' Weak answer: 'I tested it.' Strong answer: the attack tests you ran by name, the variant matrix including the ones that did not fire, the log-only baseline period and the volume it produced, and the health check that alerts you when the rule stops firing at all.
- 'Tell me about a detection you retired.' Shows you understand that content has a cost and a lifecycle. Say why it existed, what changed, what evidence you used to kill it, and what you put in its place, if anything.
- 'This rule fires hundreds of times a day and everything closes benign. What do you do?' Do not reach for the threshold. Find the benign cause class, then choose deliberately between suppressing a specific precise condition, enriching so the disposition is automatic, narrowing to the behaviour that actually matters, demoting it to a hunt query, or deleting it. Then record the decision where the next person will find it.
- 'What is wrong with alerting on this list of indicators?' Hashes and addresses are cheap for an attacker to change and expensive for you to maintain, which is the point of David Bianco's Pyramid of Pain. Indicator matching has a place, with an expiry date and a volume ceiling, and it is not a detection strategy.
- 'What log sources would you need to detect this, and what do we probably not have?' Coverage honesty. Good candidates reason about collection, retention, field population and the difference between a source existing and a source being complete. Knowing how to express that as a coverage assessment, the way DeTT&CT does, is a plus.
- 'We are told our ATT&CK coverage is eighty percent. Why might that be misleading?' Because coverage is procedure-dependent: one rule catching one procedure colours a technique green on the heat map while five other procedures walk past. Offer a per-procedure variant matrix as the honest version. SpecterOps has published the clearest public material on this, under capability abstraction and the funnel of fidelity.
- 'How would you cut SIEM ingest by a third without losing detection coverage?' A 2026 staple, and many candidates have never thought about it. Work out which sources any production rule actually queries, prune fields rather than whole sources where you can, route the verbose low-value sources to cheaper storage with federated or scheduled search, use the platform's cheaper ingest tiers for data you only need during an investigation, and re-measure detection coverage afterwards rather than assuming it held.
- 'Who reads your alert, and what do they do with it?' Say the runbook is part of the detection, not documentation written afterwards. Severity, enrichment, the ordered disposition questions, the escalation condition, and whether an automation or an AI triage layer is the first consumer, which changes what context the alert must carry.
- Depth probes on the surface the team actually defends. For Windows: process creation and command-line logging, parent-child relationships and the ones attackers forge, service creation, scheduled tasks, WMI, named pipes, AMSI and ETW and what their absence means. For identity: tokens, conditional access, consent, device registration, federation. For cloud: control plane versus data plane, role assumption, key material. For containers: the audit log and runtime visibility. Prepare the one in the posting, and say honestly which of the others you have only read about.
- On-call and change management. How content gets reviewed and promoted, what your rollback looks like, how you handle a tuning request from a team that does not want to be alerted on, and whether you have ever pushed a rule that caused a page storm. Having an answer for the last one reads as experience rather than carelessness.
- Your own questions, which are scored. Ask how many production detections they run and who owns them, what their false-positive or auto-close rate looks like, whether content lives in git with tests, who owns the pipeline and the ingest budget, what the on-call rotation actually pages for, and what happened after their last significant incident. The answers tell you whether you are joining a detection practice or becoming its first member.
The portfolio, the lab, and the one public artefact worth more than a certificate
This role has the most legible portfolio in security, and most candidates still do not build one. A detection is small, self-contained, testable and shareable, which means your claim to be able to write detections is verifiable in public. Hiring managers for this role routinely read a candidate's repository before the first call, and a good one changes the conversation from whether you can do the work to how you did it.
Scale the ambition correctly. Six to ten deep write-ups beats a hundred rules, every time, and a large pile of untested or model-generated Sigma files reads as a negative because it says you do not know what validation is for. Quality is demonstrated by the parts that are inconvenient to write: the variant you could not catch, the false positive you only found in week three, the rule you abandoned.
Build a lab you can actually run, keep it small, and keep notes as you go. If you cannot run a lab at all, public datasets are a legitimate substitute for the first few write-ups, as long as you say that is what you used.
- A minimum useful lab: a Windows domain controller and one or two workstations, evaluation licences or cloud credits, Sysmon with a published configuration (Olaf Hartong's sysmon-modular or the SwiftOnSecurity config) so your telemetry matches what reviewers expect, and a destination to search: Elastic, a Microsoft Sentinel or Defender trial, or Splunk's free tier. Splunk Attack Range and Ludus are maintained ways to automate the build. Note that the older DetectionLab project is archived and no longer maintained.
- Attack tooling for validation, not for showing off: Atomic Red Team for endpoint technique tests, Stratus Red Team for cloud control-plane behaviour, CALDERA for chained activity, and a commercial breach-and-attack-simulation tool if your employer has one. The point is to generate real telemetry for the behaviour you are detecting.
- Public telemetry you can work on without a lab: the Open Threat Research Security-Datasets project, sbousseaden's EVTX-ATTACK-SAMPLES, splunk/attack_data, and the PCAPs and log bundles attached to published intrusion reports. Loading one of these into your own stack and writing detections against it is a real write-up, and it is how you practise the hands-on round.
- Add the surfaces that matter in 2026, because an endpoint-only portfolio now looks dated: a Microsoft Entra or Okta developer tenant for identity detections, a sandbox cloud account with the audit log enabled for control-plane detections, and if you work with containers, Kubernetes audit logs plus Falco rules.
- Use one write-up template every time and publish it as markdown next to the rule. Goal stated as behaviour. ATT&CK mapping and the functional chain. Telemetry and exact fields, with how they are generated. The rule. Blind spots and assumptions. False positives observed and how each is handled. Validation: tests run, which fired, which did not. Response plan and severity. Review date.
- Contribute one rule upstream and keep the link. SigmaHQ, elastic/detection-rules, splunk/security_content, panther-labs/panther-analysis, falcosecurity/rules and sublime-security/sublime-rules all take outside contributions, and the review you get on a pull request is an education in the actual bar. A merged rule is a verifiable public artefact with your name on it, which is a different category of evidence from a certificate.
- Write. Six focused posts on your own site, each one a detection problem and how you solved it, outperform a long list of courses taken. A BSides, Blue Team Con or SANS Summit talk puts you in front of the people who hire for this directly, and the call-for-papers bar at regional BSides events is lower than people assume.
- Be honest with yourself about blue-team ranges. TryHackMe's SOC and detection paths, LetsDefend, Blue Team Labs Online, CyberDefenders and Splunk's Boss of the SOC are useful for building skill and getting query reps in, and they are weak differentiators on their own, because they demonstrate triage under guided conditions rather than authorship and maintenance. Use them to learn, then build the repository.
- On Sigma specifically, get the framing right: it is excellent for sharing, for portfolios, and for multi-platform shops that convert to native rules, and most teams run native content in their own platform's language. Claiming Sigma as your primary production experience when you have only written Sigma locally will not survive a follow-up question.
The resume, the credentials worth buying, where the postings are, and a 12-week plan
One page under roughly eight years of experience, two beyond that. The biggest single improvement available to most candidates moving from triage is replacing responsibility language with authorship language. 'Monitored and triaged SIEM alerts' describes the job you are leaving. It tells a detection lead nothing, and it is the line that gets resumes filtered out for this title.
Use a repeatable formula per bullet: the behaviour detected, the platform and language it was written in, the telemetry it ran on, how it was validated, and what happened to volume or to the catch. If a number is confidential, keep the unit and give the shape rather than dropping the outcome: 'cut alert volume on our identity use case by roughly two thirds with no loss of true positives over the following quarter' is sayable without exposing anything, and it is far stronger than listing a tool.
Give the screen the keywords it reads for, in a skills block that is specific rather than exhaustive, and do not hide a platform mismatch. If your experience is Splunk and the posting is Sentinel, say so in the summary line and name the mapping: SPL to KQL, the equivalent telemetry, the fact that the behaviour and the tuning judgement transfer while the syntax takes a fortnight. Recruiters screen on platform, and a candidate who addresses the gap directly gets through more often than one who leaves it to be discovered.
Finding the postings is its own task, because job boards index the exact title badly. Search the synonyms, then go direct: the careers pages of the managed detection providers and endpoint vendors, the security pages of large technology and fintech employers, and government job systems if you are cleared or clearable. Set alerts on the synonyms rather than checking manually. The other half of sourcing is inbound, and it is why the upstream pull request and the public write-ups pay twice: maintainers, newsletter authors and conference organisers in this field are often the same people doing the hiring, and 'I reviewed your Sigma PR' is a warmer introduction than any cover letter.
Outside the US the structure differs in two specific ways. There is no BLS, so posting ranges and recruiter conversations are your pay evidence, and in the EU more postings will carry ranges as the pay transparency directive lands in national law through 2026. The clearance equivalent in the UK is SC or DV vetting, sponsored by an employer and not something you can obtain yourself, and in Canada it is Reliability Status and the Secret or Top Secret levels above it. Detection hiring outside the US concentrates in financial services, government suppliers, and the MDR providers.
- Skills blocks worth having, with real contents: query languages named by dialect (SPL, Microsoft KQL, Elastic ES|QL and EQL, YARA-L, XQL, SQL, Python for Panther); platforms (Splunk Enterprise Security, Microsoft Sentinel and Defender XDR, Elastic Security, CrowdStrike, Google SecOps, Panther, Cortex XSIAM); log sources you have genuinely worked with (Sysmon, Windows Security and System event logs, EDR process telemetry, Entra ID sign-in and audit logs, Okta system log, AWS CloudTrail, Azure activity logs, GCP audit logs, Kubernetes audit, Zeek, proxy, DNS, email gateway); detection-as-code toolchain (git, pull-request review, CI tests, Sigma conversion, rule metadata); validation tooling (Atomic Red Team, Stratus Red Team, CALDERA, a named BAS product); frameworks (MITRE ATT&CK, Sigma, the Pyramid of Pain, an ADS-style write-up standard, DeTT&CT for coverage).
- Lines that land: a detection you authored with its telemetry and its measured outcome; a tuning result with before-and-after volume; a telemetry gap you found and closed; an incident where your content caught the activity, described without exaggeration; a detection-as-code pipeline you built or improved, including the tests; a runbook set you wrote and the handling-time effect; a public rule merged upstream, with the link.
- Lines that get ignored: 'monitored SIEM dashboards'; a list of every security product you have ever opened; 'knowledge of MITRE ATT&CK' with no technique named; certification strings stacked after your name in the header; soft-skill adjectives; CTF placements, which carry much less weight here than in a pentest application.
- Certifications, ranked honestly by what they do for you. Real experience and a public portfolio outrank all of them. Next, the practitioner-respected ones: GIAC GCDA (detection analytics), GCIA (intrusion analysis), GCFA (forensics, which is what teaches you where evidence lives), GCTI (intelligence), and Microsoft SC-200 if you are going anywhere near Sentinel and Defender. Platform certifications from Splunk, Elastic, CrowdStrike or Google SecOps are worth it when the posting names that platform. Security+ and CySA+ mainly exist to clear HR and government filters. An offensive certification such as OSCP, CRTO or CRTP is not required and reads surprisingly well, because it is evidence you understand what you are detecting.
- Training worth the money if an employer is paying: SANS SEC541 for cloud attack detection, SEC450 for security operations fundamentals, FOR508 for enterprise forensics and incident response. Check the current catalogue before you budget, because SANS retires and renumbers courses. Worth the money if you are paying yourself: usually not, compared with a lab plus the free material. The one book to read first is Practical Threat Detection Engineering by Megan Roddie, Jason Deyalsingh and Gary Katz. Follow the detection engineering newsletters and the vendor research blogs for current tradecraft rather than courses.
- Clearance is the exception to everything above. If you want defence, government or intelligence detection work in the US, the clearance is the qualification, and the realistic route is an employer that sponsors one. Budget months, not weeks, and keep a second non-cleared pipeline running while you wait.
- Weeks one to four of a 12-week plan: pick one platform and learn its query language properly, stand up the lab or load a public dataset, and publish two full write-ups from Atomic Red Team tests you ran yourself. At work, pull your 90-day ticket analysis and write the one-page tuning proposal.
- Weeks five to eight: add two identity detections in a developer tenant and one cloud control-plane detection validated with Stratus Red Team, then open your first upstream pull request and take the review seriously. Rewrite the resume in authorship language against two real postings.
- Weeks nine to twelve: finish at the six to ten write-up mark, add the detection-health and runbook sections that most portfolios lack, and start applying, MDR providers first because the volume and the speed are there. Rehearse the seven-step structure out loud against three behaviours until it is automatic, and rehearse the tuning question, because that is the one candidates answer too fast.
- Negotiation specifics for this role: on-call rotation and its compensation, whether the role is content-only or content plus response, whether you own the pipeline or negotiate with someone who does, headcount on the detection team, and an active clearance, which is the single largest legitimate premium in this market.
What a detection engineer must know about AI in 2026-27
Start with the honest version, because overclaiming here will lose you an interview with an experienced detection lead. AI has not replaced the core of this job and is not close to it. Writing a detection that holds up still requires knowing what your telemetry actually contains, what is normal in your specific environment, which fields are populated on which fleet, and what the alert will cost the people who receive it. No model knows your environment's baseline, and saying that plainly in an interview reads as competence rather than scepticism.
What did change is real, and it is in three places. First, drafting and translating rules got genuinely faster, which moved the bottleneck from writing to validating. Second, the triage layer below you is being automated at a growing number of employers, which changes what a good alert has to contain. Third, there is a new attack surface made of AI systems themselves, and someone has to build the first detections for it. None of those three removes work from this role. All three change what the work looks like, and the second one changes what interviewers ask you. Be aware that vendor marketing about the autonomous SOC is well ahead of what is actually deployed, and that practitioners in the room know it.
There is also a change on the adversary side that is routinely overstated. Phishing got cheaper, better written and more voluminous; disclosed vulnerabilities get weaponised faster; voice cloning has been reported in help-desk social engineering, with intrusions following. What did not change is the post-compromise behaviour, which remains identity abuse, token and session theft, living off the land, legitimate remote access tooling and cloud control-plane manipulation. The practical consequence for a candidate is that identity-centric detections, not novel AI detections, are where the hiring demand actually sits.
The underlying thing interviewers are testing is whether you use these tools the way a practitioner does: to reach a draft and a hypothesis faster, while keeping the validation, the schema knowledge and the environmental judgement firmly on your side of the line. Tool familiarity is assumed and cheap. What gets graded is whether you caught what the tool got wrong.
Writing detections that an automated or AI triage layer can actually resolve
At a growing number of employers the first consumer of your alert is not a person. It is an automation or an AI triage agent that enriches, forms a verdict and either closes or escalates. That layer amplifies whatever you give it: a detection with clear context and an explicit disposition path gets handled well at volume, and a vague one produces confident wrong closures, which is worse than a noisy queue because nobody sees it happen.
Show it: Describe a detection as a contract rather than a query. Name the fields you emit so the receiver never has to pivot manually, the ordered disposition questions, the known benign classes written down as a taxonomy rather than living in an analyst's head, the escalation condition, and the severity reasoning. Then say how you verified the automation's closures were correct: a sampled audit of auto-closed alerts, and what you found in it.
Drafting and translating rules with a model, then validating what it produced
Converting a Sigma rule to KQL, turning a published report into candidate logic, or scaffolding a query is now fast, and the failure modes are specific and consistent: a field that does not exist in your schema, an operator whose semantics differ from how it reads, a log source that is not actually collected, a match on a tool string instead of a behaviour, and no false-positive surface considered at all. Interviews increasingly hand you a model-written rule and ask what is wrong with it.
Show it: Bring a concrete before-and-after: a draft you corrected, what specifically was wrong, and how you confirmed the fix against the real schema and real data rather than against plausibility. Say explicitly that you never ship a rule you have not run against live telemetry and an attack test, regardless of who or what wrote it.
Identity-first detection, because that is where AI-accelerated intrusions land
Better phishing and voice-cloned help-desk pretexting change the front door, not the house. The detections that catch what follows are identity detections: a session appearing from a new network and device with MFA already satisfied, a new authentication method registered, a device-code or illicit-consent flow, a help-desk reset followed immediately by enrolment from somewhere new, a mailbox rule created minutes after a sign-in. These are the detections employers are short of and the ones they ask about.
Show it: Show two or three identity detections at full depth, with the specific audit or sign-in events they use in Entra ID, Okta or your platform of choice, the benign causes you had to accommodate (travelling staff, VPN egress, legitimate device replacement, a genuine help-desk reset), and how you validated them in a developer tenant. Pair them with the response question: what gets contained automatically, and what needs a human.
Detecting attacks on and through the company's own AI systems
This is a real and growing surface, and it is honest to say it is still a minority of postings, concentrated at employers who ship AI features or who have deployed agents internally. The concerns are concrete: stolen model API keys used from unfamiliar infrastructure, agent and service identities with standing permissions, tool and connector consent granted to something nobody reviewed, prompt injection reaching an agent that can act, data or model exfiltration through an inference path, and staff pasting sensitive material into unsanctioned services. Telemetry for most of this is immature, which is precisely the opportunity.
Show it: Being the person who wrote your organisation's first three detections for its own AI stack is a strong differentiator, because almost nobody has. Describe them the way you would any other detection: the behaviour, the log source (the AI gateway or proxy, the provider's own audit and admin logs, the identity platform's record of application and agent consent, egress telemetry), the validation, and the blind spot you could not close yet. If you have not done it, say so, and say what you would instrument first.
Knowing the response automation layer you hand off to
Detection and automated response are now one pipeline at most employers, and the interface between them is a design decision a detection engineer owns half of. Which alerts may trigger automatic containment, what the blast radius of a wrong containment is, and what evidence must be present before an action fires are questions you will be asked to answer, because you are the person who knows how reliable the signal is.
Show it: Name the tooling you have worked with, whether that is the SOAR built into your SIEM, Tines, Torq or in-house code, and describe one automated action you gated: the detection, the precondition you insisted on, the reversal path, and the incident or near-miss that taught you to add it.
Evaluating AI security tooling the team is about to buy
Detection engineers are increasingly pulled into evaluating AI triage and autonomous SOC products, because they are the ones who will own the output quality afterwards. The useful skill is designing an evaluation rather than reacting to a demo: a labelled set of your own historical alerts, agreement measured against the dispositions your analysts actually made, and attention to the false-negative side, which vendor demos never show.
Show it: Describe an evaluation you ran or would run: the sample of real alerts, how you labelled ground truth, what agreement you measured, what the tool got confidently wrong, and the conditions under which you would let it close an alert unattended. This question appears at employers midway through such a purchase, and a structured answer stands out immediately.
What a screen is looking for
These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.
- Detection engineering
- Threat detection engineering
- Detection-as-code
- SIEM
- Splunk Enterprise Security
- SPL
- Microsoft Sentinel
- KQL
- Microsoft Defender XDR
- Advanced hunting
- Elastic Security
- ES|QL
- EQL
- Google SecOps
- YARA-L
- Cortex XSIAM
- XQL
- CrowdStrike Falcon
- Panther
- Sigma rules
- YARA
- Suricata
- Zeek
- Falco
- osquery
- MITRE ATT&CK
- ATT&CK mapping
- Threat hunting
- Alert triage
- Alert tuning
- Alert enrichment
- False positive reduction
- Use case development
- Security content development
- Detection content lifecycle
- Runbook authoring
- Detection validation
- Atomic Red Team
- Stratus Red Team
- CALDERA
- Breach and attack simulation
- Purple team
- Sysmon
- Windows event logs
- Process creation logging
- Credential dumping detection
- LSASS
- Living off the land
- LOLBins
- Persistence detection
- Lateral movement detection
- Command and control detection
- Entra ID
- Okta
- Sign-in logs
- Conditional access
- OAuth consent abuse
- Session token theft
- Adversary-in-the-middle phishing
- MFA abuse
- AWS CloudTrail
- Azure activity logs
- GCP audit logs
- Kubernetes audit logs
- Cloud detection
- Log source onboarding
- Telemetry coverage
- DeTT&CT
- Field normalisation
- OCSF
- Elastic Common Schema
- ASIM
- Cribl
- Log pipeline
- Ingest cost optimisation
- Security data lake
- Python
- Git
- CI/CD
- Pull request review
- Incident response
- Digital forensics
- Threat intelligence
- SOAR
- Security automation
- Detection health monitoring
- Security clearance
- GCDA
- GCIA
- GCFA
- SC-200
Mistakes that cost people this job
Writing detections that match a tool rather than a behaviour: 'mimikatz' in a command line, a hash list, a user-agent string.
Abstract to the functional chain the behaviour requires, then detect that. For credential access from LSASS: a handle with read rights, a memory read, the result landing somewhere. Name the variants that defeat your rule, including the signed-binary and registry-hive routes, and state which ones you do not cover. Indicator matching has a place with an expiry date, not as a strategy.
Shipping a rule without ever running the attack that should trigger it.
Validate before deployment and say so with specifics: the Atomic Red Team or Stratus Red Team tests you ran, which variants fired and which did not, and a log-only baseline period in production that gave you real volume before anyone was paged. 'I tested it' is not an answer in this interview.
A portfolio of two hundred rules copied from public repositories or generated by a model, none of them tested.
Six to ten write-ups at full depth, each with telemetry and exact fields, the test you ran, the firings you observed, the false positives you found, the blind spot you could not close, and a review date. The inconvenient sections are what prove the work is yours.
A resume for a detection role written in triage language: 'monitored and triaged alerts in the SIEM'.
Lead with authorship. The behaviour detected, the platform and language, the telemetry, the validation, and the measured effect on volume or on the catch. Shape rather than a precise number is fine where the number is confidential; dropping the outcome is not.
Treating the live exercise as a syntax exam and freezing because you cannot remember an exact field name.
Narrate the structure out loud: goal as behaviour, ATT&CK and functional chain, telemetry and fields, blind spots, false positives, validation, deployment and lifecycle. Say 'in Sysmon this is the granted access field on event ID 10, and I would confirm the exact name against our schema'. Reasoning is what is graded; syntax is checked against documentation on the job.
Tuning a noisy detection by raising the threshold until the noise stops.
Find the benign cause class first, then choose deliberately: suppress one precise condition, enrich so the disposition is automatic, narrow to the behaviour that matters, demote to a hunt query, or delete the rule. Allow on a signed publisher and path rather than a process name, because a process name is whatever the attacker types. Record the decision where the next engineer will find it.
Presenting an ATT&CK Navigator heat map as coverage.
Say plainly that coverage is procedure-dependent: one rule catching one procedure turns a technique green while other procedures walk past untouched. Offer a per-procedure variant matrix for the techniques that matter most to your threat model, and name the gaps. Volunteering a gap list is a senior signal; a green heat map is not.
Ignoring what the alert costs the receiver, and ignoring who the receiver now is.
Treat the runbook, the severity reasoning and the enrichment fields as part of the detection. Know the daily volume you are adding and the handling time per alert. Where an automation or AI triage layer consumes the alert first, make sure it carries enough structured context to be resolved without a manual pivot, and audit a sample of what it auto-closed.
Searching only for the exact title 'detection engineer', and applying only through job boards.
Search the synonyms: threat detection engineer, detection and response engineer, security content engineer or developer, security analytics engineer, threat researcher, and senior security engineer postings whose responsibilities are detection. Then go direct to the careers pages of the managed detection providers and endpoint vendors, which hire in the largest volume and are the best-odds door into the discipline.
Hiding a platform mismatch and hoping it does not come up.
Name it in the summary line and map it: SPL to KQL, the equivalent telemetry, the fact that abstraction and tuning judgement transfer while syntax takes a fortnight. Recruiters screen on platform keywords, and candidates who address the gap directly get through more often than candidates who leave it to be discovered in round two.
Claiming AI tooling wrote or validated your detections, or claiming the opposite, that you refuse to use it.
Describe the division of labour a practitioner actually uses: the model drafts and translates, you validate against the real schema, real telemetry and an attack test before anything ships. Bring one example of a model-written rule you corrected and say exactly what was wrong with it. Both overclaiming and refusing read as inexperience to an interviewer who uses these tools daily.
Questions people ask
What does a detection engineer actually do?
A detection engineer writes, tests, tunes and retires the logic that turns security telemetry into alerts, and owns everything that logic depends on: the log sources, the field schema, the attack tests that prove a rule fires, the runbook attached to the alert, and the review cycle that removes rules no longer worth their volume. In practice the week splits between authoring content, validating it against real attack behaviour, tuning what is already in production, and data work such as fixing a log source that stopped shipping or normalising an event into the team's schema. The deliverable is production content with a lifecycle, not a clever query.
What is the difference between a detection engineer and a SOC analyst?
A SOC analyst triages the output of detections: enriching, dispositioning and escalating what fires. A detection engineer decides what fires in the first place and is accountable for whether that was a good decision, including the false-positive rate, the runbook, the telemetry it depends on and the test that proves it works. The analyst is measured on queue handling and accurate dispositions; the detection engineer is measured on the quality and maintainability of the content. Most detection engineers come from triage, which is why having been on the receiving end of thousands of alerts is treated as a genuine qualification.
How do I move from alert triage to detection engineering?
Do the job visibly before you have the title. Pull 90 days of your own tickets, rank the rules by volume, work out what share of the worst one closed benign and why, then bring a one-page tuning proposal with the query change, the expected volume reduction and the coverage you would lose. After every incident you touch, write and test the detection that would have caught it earlier and open a pull request. Ask explicitly to own one ATT&CK technique or one log source end to end, learn the platform's query language properly rather than clicking the console, and keep every artefact: pull request links, before-and-after volumes, sanitised incident references. If you have no SOC history at all, the same portfolio carries more of the weight, and the two routes that work are a strong software or platform engineer joining a detection team that needs pipeline and tooling work, or a systems and cloud operations engineer who knows the defended surface deeply.
What does the detection engineering interview test?
Almost always a practical exercise rather than a quiz, in one of five forms: write a rule live for a named behaviour in the platform's query language, a take-home with a log sample and a loose brief to find and detect the activity, tune a noisy rule given a sample of its real firings, turn a published intrusion report into a detection strategy, or critique a model-written rule and say what is wrong with it. Some employers add a hands-on range with seeded activity. The grading is consistent across forms: do you start from behaviour rather than a tool name, do you know which telemetry would carry the evidence, do you volunteer the false-positive surface before being asked, can you prove the rule works, and do you consider the analyst or automation receiving the alert. Candidates who narrate that reasoning and get a field name slightly wrong routinely beat candidates with clean syntax and no reasoning.
What should be in a detection engineering portfolio?
One public repository with six to ten technique write-ups, each containing the goal stated as a behaviour, the ATT&CK mapping and the functional chain, the telemetry and exact fields with how they are generated, the rule itself, blind spots and assumptions, the false positives you observed and how each is handled, the validation you ran including which variants did not fire, a response plan and severity, and a review date. Six deep write-ups beat a hundred untested rules, which read as a negative. Add one rule merged upstream into SigmaHQ, elastic/detection-rules, splunk/security_content, panther-analysis or a similar public repository, because the review you get there teaches the real bar and a merged pull request is a verifiable artefact with your name on it.
Do I need to know how to code to be a detection engineer?
You need fluency in at least one detection query language and that is non-negotiable: SPL, Microsoft KQL, Elastic ES|QL or EQL, YARA-L, XQL, or SQL depending on the platform. Beyond that, Python is strongly expected at employers that run detections as code with CI tests, build their own tooling, or sit on a data lake or streaming pipeline, and it is effectively required at large technology, fintech and vendor content teams, where you should expect a real coding round. At many in-house enterprise teams a working level of scripting is enough. Read the posting: if it mentions a repository, tests, pipelines or automation, prepare to write Python in the loop.
Which query language or platform should a detection engineer learn first?
Learn the one your target employers run, and the two largest footprints are Splunk with SPL and the Microsoft stack with KQL across Sentinel and Defender advanced hunting. Pick one for depth and get reading fluency in a second; Elastic's ES|QL and EQL, Google SecOps YARA-L, Cortex XSIAM's XQL and Python-based detections in Panther cover most of the rest. Note that Elastic also has its own KQL, the Kibana Query Language, which is a different and simpler thing from Microsoft's Kusto, and knowing the difference is a small credibility marker. Learn Sigma as well, but frame it correctly: it is excellent for sharing, portfolios and multi-platform shops that convert to native rules, while most teams run native content in their own platform's language, so claiming Sigma as your primary production experience will not survive a follow-up question.
What certifications do detection engineers need?
None are required. There is no licence and no mandatory certification for detection engineering anywhere. The ones practitioners respect are GIAC GCDA for detection analytics, GCIA for intrusion analysis, GCFA for forensics, GCTI for threat intelligence, and Microsoft SC-200 if you are working with Sentinel and Defender; platform certifications from Splunk, Elastic, CrowdStrike or Google SecOps are worth it when the posting names that platform. Security+ and CySA+ mainly clear HR and government filters. An offensive certification such as OSCP or CRTO reads well because it evidences understanding of what you are detecting. All of them rank below demonstrable experience and a tested public portfolio, and a US security clearance is the only credential that functions as a hard gate, in defence, government and intelligence work.
Is AI replacing detection engineers?
No, and the honest picture is more specific than that. Automation and AI tooling landed hardest on first-line triage, the enrich-and-disposition loop, which is one step downstream of detection engineering and is the part of security operations shrinking fastest at entry level. Drafting and translating rules got genuinely faster, which moved the bottleneck from writing to validating, because a model does not know your schema, your log coverage or your environment's baseline and will confidently produce a rule that matches a tool string and references a field that does not exist. What a model cannot do is decide what deserves an alert in your specific environment or prove that it fires. The practical effect on hiring is that alert quality, context and runbook rigour matter more than they did, because an automated consumer amplifies both good and bad detections, and that vendor claims about the autonomous SOC are well ahead of what is actually running in production.
How much do detection engineers earn?
There is no reliable single band to quote, because the US Bureau of Labor Statistics has no occupation code for 'detection engineer'. Bracket it with OES 15-1212, Information Security Analysts, and read the metropolitan-area tables rather than the national median, then read the ranges employers are required to publish under state pay-transparency laws in Colorado, California, Washington, New York, Illinois and a growing list of other states, which are the most honest numbers available for a specific market. Use levels.fyi for the large technology and fintech security ladders, and the GS scale with the 2210 series for US federal roles. In Europe, more postings will carry ranges as the EU pay transparency directive lands in national law through 2026. The factors that move pay most are employer type (large technology and fintech above enterprise, enterprise above consultancy), an active security clearance, on-call responsibility, and whether you can write production code rather than only queries.
Put this on a resume in about a minute
Paste your history once and point it at the Detection Engineer posting you are looking at. No account, no card.
Build my resume free More roles