What do cyber security analyst interviews actually test?

Who is actually in the room

For a cyber security analyst role, the first interview is rarely with HR alone. Expect the SOC manager or a senior analyst on the call from the start, because the questions that matter can't be asked by someone who hasn't triaged an alert themselves. In smaller companies you might get the CISO directly. In larger ones there's often a technical screen first (a senior analyst or team lead, 30-45 minutes, heavy on scenarios) followed by a panel that includes the hiring manager and sometimes someone from IT operations or a platform team you'd work with — because a lot of the job is escalating and handing off, not just detecting.

If the company runs a mature SOC, you may also meet whoever owns the SIEM (Splunk, Microsoft Sentinel, QRadar, Elastic) and whoever owns the EDR (CrowdStrike, Defender for Endpoint, SentinelOne). They ask different questions because they care about different failure modes: the SIEM owner wants to know if you can write a search that isn't garbage; the EDR owner wants to know if you'll chase a benign PowerShell script for two hours because you didn't check the parent process first.

The technical exercise: what it looks like

Most technical assessments for this role are not coding tests. They're triage exercises, because triage is the job. Common formats:

• Alert triage in a sandboxed SIEM or a screenshot pack. You're given a handful of alerts — a login from an unusual geography, a spike in outbound DNS queries, an EDR detection flagged as "suspicious" rather than "malicious" — and asked to say which you'd escalate, which you'd close, and why. The interviewer is watching your reasoning order, not your final answer.
• A pcap or log excerpt. You might be handed Wireshark output or raw firewall logs and asked to reconstruct what happened: is this a port scan, a failed brute force, C2 beaconing on an odd interval. Some places substitute a phishing email with headers and ask you to read the Received chain and judge SPF/DKIM/DMARC results.
• A tabletop incident scenario. "Ransomware note appears on a finance laptop at 4pm on a Friday. Walk me through the next hour." This is testing whether you know the shape of NIST 800-61's incident lifecycle — identification, containment, eradication, recovery, lessons learned — without reciting it as a list. Good candidates isolate the host before they start asking who's responsible.
• A take-home, less often now than a few years ago. Usually a written incident report from a given set of logs, or a short threat model for a hypothetical system. If you get one, the interviewers are checking whether you can write for someone who wasn't in the room — because incident reports get read by people who weren't on the call.

What's rarely tested, despite what generic interview guides imply, is whether you can recite the OSI model or define "zero trust" from memory. Those come up as warm-up questions at most. The exercise exists to see what you do when the alert is ambiguous, because most alerts are ambiguous.

The questions that are actually probing competence

Some questions sound like small talk but aren't. Here's what they're really checking:

"Walk me through the last false positive you closed." This is not a memory test. It's checking whether you understand why it was a false positive — the mechanism, not just the label — and whether you tuned anything afterwards, or just clicked close. An analyst who can't describe tuning a detection rule or suppressing a noisy source hasn't done the job long enough to reduce the noise they generate.

"What's your process when you get an alert you don't understand?" They're listening for a sequence: check the asset (is it a domain controller or someone's laptop), check the account's normal behaviour, pull related events in a window either side of the alert, check whether the IOC appears anywhere else, then decide. If the answer jumps straight to "I'd escalate it," that's a red flag to an experienced interviewer, because escalating everything is what someone does when they don't know how to investigate.

"Tell me about a time you were wrong about an incident." This is deliberately awkward. Analysts who've only worked tickets, not real incidents, often don't have an answer, because being wrong requires having made a call under uncertainty. Interviewers use this to separate people who followed a runbook from people who've had to make a judgement call at 2am with incomplete information.

"How do you keep threat intel current, and how does it change what you look at?" Not "do you read blogs." They want to know if you can name a specific feed or source (a vendor's threat research, an ISAC, an internal IOC list from a previous incident) and, more importantly, give an example of a detection or hunt you built because of something you read — not just that you subscribed to a mailing list.

Questions about MITRE ATT&CK usually aren't asking you to recite tactic IDs. They're checking whether you use it as a working tool: can you map an observed technique (say, T1053 for scheduled task abuse) to what you'd expect to see next in the chain, and whether you'd know it if you saw it.

What a shallow answer sounds like

To someone who actually runs a SOC, these are the tells:

• Describing detection entirely in terms of tools ("we used Splunk and CrowdStrike") with no mention of what you were looking for or what the query logic was. Naming the SIEM is not the same as showing you can use it.
• Answering "what's the incident response process" by listing the NIST phases in order with no example attached. Anyone can memorise six words. The interviewer wants one incident where containment was harder than the textbook makes it sound — because a production system you can't just unplug, or a compromised account that's also the account running a critical service, is where the real judgement is.
• Treating every scenario as if the answer is "escalate to the incident response team," without demonstrating you know what that team would want handed to them first: scope, affected hosts, time of first indicator, whether containment has already started.
• Confusing vulnerability management with detection. Being asked about a CVE and only being able to say "we'd patch it" without mentioning compensating controls, exposure, or exploitability in your environment suggests you haven't sat in a patch prioritisation meeting.
• Talking about certifications (Security+, CySA+, GCIH, OSCP) as achievements rather than as evidence of specific capability. An interviewer who holds GCIH themselves will ask what you did in the labs, not whether you passed.

What to do before your next interview

Pick two incidents or investigations from your own work — real ones, even small ones — and be ready to describe them in enough technical detail that another analyst could follow the reasoning: what triggered the alert, what you ruled out and how, what you'd do differently. That's more useful preparation than any list of generic questions, because it's what the interviewer is actually trying to get you to produce.

If you're applying to several SOC or analyst roles at once and the adverts all ask for slightly different tooling combinations (Sentinel here, QRadar there, a SOAR platform you've only touched once), jobmarket.pro reads each advert in full and prepares an application from your actual experience, without inventing familiarity with tools you haven't used.