SOC Analyst Interview Questions: 30 Questions Real Hiring Managers Ask in 2026

I've interviewed 200+ SOC candidates and sat on the other side of the table 50+ times myself. Here's the uncomfortable truth: 90% of candidates fail the same 5 questions, and it's never because they lack technical knowledge.

They fail because they answer like a textbook instead of like a colleague. "What is phishing?" gets you rejected. "Here's how I triaged a phishing campaign at my last job" gets you hired.

This guide covers the 30 questions that actually decide SOC interviews in 2026, organized by tier, with answer frameworks that show you think like a practitioner.

Tier 1 Interview Questions (Entry-Level, 0-2 years)

Tier 1 interviews test triage instinct, not deep expertise. They want to know: can you separate real threats from noise in under 60 seconds?

1. "Walk me through how you'd triage this alert."

The setup: They show you a SIEM alert (usually something like "Multiple failed logins from external IP").

The framework:

1. Context first: What asset? What user? What time? Is this business hours?
2. Baseline check: Does this user normally log in from this geo? Is the volume anomalous?
3. Enrichment: Check the IP in VirusTotal, AbuseIPDB. Check the user in AD.
4. Verdict: Benign (close with reason), suspicious (escalate to T2), or confirmed (trigger playbook).

Good answer: "First I'd check if this user normally logs in from that geography. If they're in Bangalore and the IP is from Nigeria at 3am IST, that's a red flag. I'd enrich the IP in VirusTotal, check if the account has recent failed logins suggesting brute force, then either close as false positive or escalate to Tier 2 with my reasoning documented."

2. "What's the difference between a false positive and a true positive?"

Trap answer: "False positive is wrong, true positive is right."

Good answer: "A false positive is when the detection fires on benign activity - like a pentest we forgot to whitelist, or an admin running nmap legitimately. A true positive means the detection correctly identified malicious or policy-violating activity. A false negative is what keeps me up at night - that's when bad stuff happens and the SIEM doesn't catch it."

3. "Explain the MITRE ATT&CK framework to someone who's never heard of it."

Good answer: "It's a knowledge base of how real attackers behave, organized into tactics (their goals like Initial Access, Persistence, Exfiltration) and techniques (how they achieve them like Phishing, Timestomping). We use it to map our detections - so we know which attack paths we can see and which are blind spots."

4. "A user reports their computer is acting weird. What do you do?"

This tests process discipline.

Good answer: "I'd ask three questions: what changed recently (new software, downloads, emails opened)? When did it start? What exactly is 'weird' (slow, popups, reboots, network activity)? Then I'd pull the endpoint logs in our EDR, check for suspicious processes, unusual network connections, and file modifications in the timeframe. If I see indicators of compromise, I isolate the host from the network and escalate to incident response."

5. "What's the difference between TCP and UDP?"

The classic. They're testing whether you actually understand or just memorized.

Good answer: "TCP is connection-oriented - it establishes a three-way handshake (SYN, SYN-ACK, ACK) and guarantees delivery. UDP is connectionless - fire and forget, no guarantee it arrives. In a SOC context, most malware C2 uses TCP because they need reliability, but DNS tunneling uses UDP. NTP amplification attacks abuse UDP because there's no handshake to verify the source."

Tier 2 Interview Questions (3-5 years, investigation focus)

Tier 2 is where interviews get interesting. They want to see you think like an investigator, not just an alert closer.

6. "You see PowerShell downloading and executing from a temp directory. Walk me through your investigation."

Good answer: "That's almost certainly malicious. My steps:

1. Isolate the host from the network immediately.
2. Pull the PowerShell command line - what URL did it hit? What was downloaded?
3. Hash the downloaded file, check in VirusTotal.
4. Check parent process - was it winword.exe (phishing), explorer.exe (user ran it), or something else?
5. Query the SIEM for other hosts that ran the same command or hit the same URL.
6. Check if the user account was used elsewhere (lateral movement).
7. Document timeline and hand off to IR team."

Key insight: I'm thinking about scope the whole time. Is this one host or an enterprise-wide incident?"

7. "How do you detect lateral movement?"

Good answer: "Lateral movement shows up as:

• One source IP authenticating to many destinations in a short window
• Admin accounts logging in from unusual workstations
• PSEXEC, WMI, or RDP usage between workstations (not just servers)
• Pass-the-hash patterns: NTLM auth without a password entry event
• New scheduled tasks or services created remotely"

"I'd build detections for these patterns, tuned to exclude legitimate admin activity from our jump hosts."

8. "Describe a time you missed something in an investigation. What did you learn?"

This is a trap question - they want to see self-awareness.

Good answer: "Early in my career I closed an alert for suspicious PowerShell as a false positive because the command looked like admin scripting. I didn't check the parent process - it was actually a weaponized Excel attachment. The user got compromised, but my teammate caught it 4 hours later when C2 traffic showed up.

What I learned: context beats content. The command itself can look legitimate; what matters is how it got invoked. I now always trace the parent process chain before closing anything."

9. "What's the difference between detection and prevention?"

Good answer: "Prevention blocks the activity (firewall rule, EDR block, email quarantine). Detection alerts on it after the fact. Good security programs need both - prevention stops 80% of commodity attacks, detection catches the 20% that slip through. A SOC's job is detection and response; the engineering team owns prevention."

10. "How would you detect a compromised insider?"

This is a senior-level question often asked of T2 candidates.

Good answer: "Insider threat is hard because they have legitimate access. I'd look for:

• Data exfiltration patterns: large uploads to personal cloud, USB transfers, printing unusual volumes
• Access anomalies: users accessing files they never touched before, especially after a resignation announcement
• Time anomalies: access outside their normal work hours
• Privilege escalation: requests for admin access they don't need
• DLP alerts for sensitive keywords leaving via email"

"I'd also correlate with HR data (resignations, PIPs) to add context - but carefully, because HR data is legally sensitive."

Senior SOC / Team Lead Questions (5+ years)

11. "How do you measure SOC effectiveness?"

Good answer: "I track four categories:

• Detection coverage: What % of MITRE ATT&CK techniques do we have detections for?
• Time metrics: MTTD (mean time to detect) and MTTR (mean time to respond)
• Quality: False positive rate, analyst satisfaction with alerts
• Outcomes: Incidents we caught vs. ones discovered by others (red team, external parties)"

"But I'd push back on metrics used punitively. The goal isn't to close more tickets - it's to catch more real threats faster."

12. "How do you tune a detection that's firing too many false positives?"

Good answer: "First I'd classify the false positives - are they all the same type (e.g., all from one business app)? If so, I'd add an allow-list for that context. If they're diverse, the detection logic is too broad and needs to be rewritten, not just tuned.

I'd also check: what's the cost of a false negative here? If this detection catches ransomware, I'd rather have some noise than miss it. If it's just policy violation, I can be more aggressive about tuning.

Finally I'd loop back with the analysts - what signals would make this alert useful to them? A good detection is one an analyst can action in 60 seconds."

Scenario Questions (The Ones That Actually Decide Interviews)

13. "You're on call Sunday at 2am. Alert fires: 'Possible ransomware on finance server.' What do you do?"

Framework: Contain → Assess → Escalate → Document.

Good answer:

1. Contain: Isolate the server from the network immediately. Don't power it off - we need memory for forensics.
2. Assess scope: Query SIEM for other hosts with same indicators (file extensions, process names, C2 IPs). Is this one server or spreading?
3. Escalate: Page the IR lead and CISO. If scope is >1 host, this is a major incident - wake up the execs.
4. Preserve evidence: Memory dump, disk image, network PCAP if we have it.
5. Communicate: Update the incident channel every 30 min. What we know, what we don't, next steps."

"The key is: don't try to solve it alone at 2am. Contain, assess scope, escalate. That's the job."

14. "Your SIEM shows a user downloading 50GB of data at 11pm on a Friday. What's your response?"

Good answer: "First I'd check context:

• Who is this user? What's their role? Is this normal for them?
• What data? File server? SharePoint? Specific sensitive folders?
• Where to? External drive, cloud upload, email attachment?
• Is the user active or just their credentials?

"If this is a data engineer doing a legitimate backup, close with documentation. If it's an accountant downloading customer PII to Dropbox at midnight, I'm escalating to IR and HR immediately. The key question is: does this match their job function and work patterns?"

15. "A phishing email got through. What do you do?"

Good answer: "Three phases:

1. Scope the campaign: Pull the email from our gateway. Who else got it? Who clicked? Who entered credentials? Who ran attachments?
2. Contain the damage: Reset passwords for clickers, revoke sessions. Reimage anyone who ran the attachment. Block the sender/URL/IP at the gateway.
3. Prevent recurrence: Update email filters, add the IOCs to SIEM detections, run a phishing simulation based on this template to train users."

"The lesson is: assume breach. The email got through. My job is to limit the blast radius and learn from it."

Red Flags That Get Candidates Rejected

After 200+ interviews, here are the patterns that make me pass:

• "I don't know" without curiosity: Not knowing is fine. Saying "I don't know, but I'd check [specific resource] and come back to you" shows how you learn.
• Textbook answers: If your answer sounds copied from a Wikipedia article, you haven't actually done the work.
• Blaming others: "The previous team's detections were garbage." Okay, but what did you do about it?
• No questions at the end: If you don't ask about their detection stack, alert volume, or on-call expectations, you're not actually interested.
• Over-claiming: "I've seen every type of attack." You haven't. Nobody has.

The Bottom Line

SOC interviews reward practitioners over memorizers. The best candidates:

• Think in timelines and scope
• Admit what they don't know and say how they'd learn it
• Tell specific stories from real investigations
• Ask smart questions about the SOC's actual workflow

If you can do those four things, you'll stand out from 90% of candidates who recite definitions and hope for the best.