Why pre-screen SOC analysts before the live triage exercise
Pre-screening SOC analysts protects the time of the people who run your live triage exercise. Applicants arrive from help desk and NOC teams, bootcamps, MSSP tier 1 pools, and military signals roles, and every resume lists Splunk, Sentinel, CrowdStrike, and Security+. What it cannot show is whether they wrote their own searches or only clicked through playbooks. Ten minutes of them narrating one alert exposes the difference: log sources named, queries described, the field that triggered escalation.
What actually matters when screening Security Operations Center (SOC) Analyst candidates
- 01
Technical depth
Probe log sources, host and network fundamentals, and whether they can investigate beyond the alert's own summary.
- 02
Real incidents and findings
Look for incidents they personally worked through to containment, and what the post-incident review changed.
- 03
Risk judgement
Test triage judgement: how they decide what is a real incident when the queue is long and most alerts are noise.
- 04
Getting things fixed
Assess escalation and handover quality on a live incident crossing a shift boundary.
Pre-screening questions to ask Security Operations Center (SOC) Analyst candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Tooling and fundamentals
Which SIEM have you used hands-on, and what did a normal shift in that console look like for you?
Names a specific platform (Splunk, Microsoft Sentinel, QRadar, Elastic) plus daily volume, the dashboards they lived in, and log sources feeding it.
Lists SIEM products from a job description but cannot describe a single search, dashboard, or alert queue they used.
How proficient are you with firewalls, IDS/IPS, EDR, and antivirus consoles day to day?
Distinguishes what each tool tells them, for example EDR process trees versus firewall deny logs, and names vendors they used in production.
Treats all security tools as interchangeable dashboards and cannot say which one they would check first for a suspicious process.
Have you created your own detection rules, searches, or reports to catch intrusion attempts?
Describes a rule or query they authored (SPL, KQL, Sigma, correlation rule), why they built it, and how they tuned out false positives afterwards.
Only ever consumed vendor default rules and has never adjusted a threshold or exclusion themselves.
What scripting or programming do you use in your analysis work, and on what?
Concrete use case: Python or PowerShell for log parsing, IOC enrichment, API pulls from the SIEM, or bulk hash lookups.
Claims scripting ability but cannot name a script they wrote or what problem it solved.
How familiar are you with investigating alerts in cloud environments like AWS, Azure, or Google Cloud?
References real cloud log sources such as CloudTrail, Azure AD sign-in logs, or GuardDuty findings, and a cloud-specific detection they handled.
Assumes cloud investigation is identical to on-premises and cannot name a single cloud audit log.
Incidents and investigation
Walk us through one incident you worked from first alert to containment: what fired, what you checked, and what you did.
First person sequence with timestamps, the pivot that confirmed it was real, the containment action taken, and what the post-incident review changed.
Describes incident response as a generic lifecycle diagram with no incident they personally drove to containment.
What is your hands-on experience with digital forensics and malware analysis?
Names artefacts and tooling they actually touched: memory capture, disk image triage, Autopsy or Volatility, sandbox submissions, hash and string analysis.
Confuses uploading a file to VirusTotal with analysis, or overstates reverse engineering they cannot describe.
Triage and escalation
Your queue has hundreds of alerts and most are noise. How do you decide what is a real incident?
A repeatable prioritisation method: asset criticality, alert fidelity history, clustering related alerts, and one evidence check they never skip before closing.
Works purely in first-in-first-out order or closes alerts as benign without naming any verification step.
You need to escalate a live incident at the end of your shift. What goes into the handover, and how do you brief a non-technical stakeholder?
Structured handover: current status, actions already taken, open questions, next steps, plus plain-language business impact without jargon.
Hands over a ticket number and nothing else, or explains impact only in tool and CVE terminology.
How do you keep up with the current threat landscape, and what technique or campaign has your attention right now?
Names specific sources (vendor threat reports, CISA advisories, MITRE ATT&CK updates) and one current technique they can explain in detection terms.
Says they read the news but cannot name one threat actor technique or advisory from recent months.
Credentials and shift cover
Do you hold any security certifications, and which one taught you the most on the job?
Names live certifications (Security+, CySA+, GCIA, GCIH, BTL1, Azure or AWS security) and connects one to a task they now do differently.
Lists expired or in-progress certifications as current, or cannot connect any of them to actual analysis work.
Can you work on-call, night shifts, or weekend rotations as part of a 24/7 operation?
A clear yes with specifics: shift patterns they have already worked, rotation length, and any constraints stated up front.
Vague willingness that later collapses into weekday-only availability, or no experience of shift work in a 24/7 environment.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
| Criterion | What a 5 looks like | Scale |
|---|---|---|
| Technical depth | Investigates from raw logs and host artefacts rather than trusting the alert summary, with real technical grounding. | 1 · 2 · 3 · 4 · 5 |
| Real incidents and findings | Names incidents they worked to containment, with the detection or process change that came out of the review. | 1 · 2 · 3 · 4 · 5 |
| Risk judgement | Triages accurately under queue pressure, and can name an alert they wrongly closed and what they changed after. | 1 · 2 · 3 · 4 · 5 |
| Getting things fixed | Escalates with calibrated urgency and hands over live incidents completely, including what is still unknown. | 1 · 2 · 3 · 4 · 5 |
Async video lets you hear an analyst narrate an investigation out loud, which is exactly what a 3am escalation call sounds like. You can judge whether they sequence evidence clearly or bury the finding in tool names.
Try it on HirevireScreening FAQ
Process basics
What should you ask a SOC analyst in a ten minute pre-screen?
Cover four areas: which SIEM and EDR they used daily, one incident they personally took to containment, how they clear a noisy queue on a busy shift, and their on-call or shift availability. Ask them to name log sources (proxy, EDR telemetry, Windows event IDs, authentication logs) rather than describing tools generically.
Should you screen tier 1 SOC analysts differently from tier 2 and tier 3?
Yes. For tier 1, weight shift reliability, playbook discipline, and whether they escalate with enough context. For tier 2 and tier 3, expect self written detection content (Sigma rules, KQL or SPL searches), forensic triage, malware artefact handling, and a post-incident review that changed a detection or a control.
Evaluating answers
How do you tell whether a SOC analyst really worked incidents or just watched the queue?
Listen for first person detail with timestamps and decisions: which alert fired, what they queried next, who they woke up, when the host was isolated. Analysts who only monitored describe process in passive terms and cannot say what containment action was taken or what the post-incident review changed.
What is a red flag when a SOC analyst talks about false positives?
Closing alerts as benign by pattern or gut feel with no supporting evidence is the red flag. Strong answers describe a check they always run before closing (parent process, destination reputation, whether the user travelled) and name a tuning change or exclusion they proposed so the same noise stopped recurring.
























