The Skills That Got Me Hired vs. The Skills I Use Every Day. Big Difference.

The Resume That Got Me In The Room

When I was job hunting, my resume had a skills section that looked like this:

Burp Suite Pro. Nmap. Metasploit. Nikto. SQLmap. Python scripting. OSCP certified. 500+ PortSwigger labs completed. Active Directory attacks. Privilege escalation. Buffer overflow.

Every single item on that list was real. I had genuinely done the work. I could demonstrate each one in a technical interview.

That resume got me hired.

Here is what my actual workday looks like eighteen months into the job.

The Skills I Actually Use — Ranked by Daily Frequency

1. Writing.

Not scripting. Not coding. Writing.

Every engagement produces a report. Every report has an executive summary that a CISO will read, a technical findings section that a developer will act on, and a risk narrative that justifies the prioritization. The writing has to work for both audiences simultaneously — technical enough to be credible, clear enough to be actionable.

I write for roughly three hours of every eight-hour workday. That is the single most-used skill in my professional life. It was not on my resume. It was not in any certification curriculum. It was never mentioned in any cybersecurity career advice I consumed before entering the field.

2. Asking the right question before starting.

In labs, the scope is defined. The target is defined. The objective is implicit — root the machine, capture the flag, move on.

In professional engagements, the most important technical decision happens before you touch anything. What is the realistic threat model here? What would a real adversary actually want from this organization? Which surface is most likely to be exploitable given what we know about the environment?

Getting this wrong means spending five days looking in the wrong direction. Getting it right means finding the thing that matters instead of the things that fill a report.

This is a thinking skill. It requires understanding attacker motivation, business context, and technical architecture simultaneously. No lab I did in two years of preparation built this skill. I built it slowly, watching senior testers make decisions I didn't understand at first and asking why afterward.

3. Knowing when to stop.

Rabbit holes are the productivity killer of offensive security. The ability to recognize — at the 40-minute mark, not the 4-hour mark — that a particular attack path has a low probability of yielding results and that moving on is the correct professional decision: this is a skill I use multiple times per week.

It sounds simple. It is not simple. It runs against the psychological grain of someone who got into this field by being obsessive about problems. The lab mindset rewards persistence. The engagement mindset requires knowing when persistence becomes waste.

4. Reading people in a room.

Kickoff calls. Debrief sessions. Client conversations when a critical finding lands and the room goes quiet.

I need to read whether the CISO is defensive or receptive. I need to calibrate how technically I should explain a finding based on who's actually listening. I need to know when the client is minimizing a critical finding for political reasons versus when they have legitimate operational context that changes the severity assessment.

This is emotional intelligence applied in a technical context. It determines whether your findings get acted on or get filed. A finding that doesn't get fixed is a finding that didn't matter.

5. Explaining the "so what."

Any competent tester can find a misconfiguration. The skill that separates useful testers from noise generators is the ability to answer — clearly, quickly, without jargon — "so what does this mean for this business?"

An exposed internal API endpoint is a technical finding. The business consequence — that an attacker can enumerate customer records, pivot to the payment processing environment, and trigger a breach that costs significantly more than this engagement cost — is the "so what." Translating between these two registers, live, in a conversation with a room full of non-technical stakeholders, is a skill I use multiple times per week.

The Skills I Was Hired For — Where They Actually Show Up

This is not to say the technical skills are irrelevant. They are the foundation. Without them, none of the above is possible. But here is where they actually appear in my week:

Burp Suite: Active use during application testing phases. Maybe 30% of engagement time when working web targets. Not every day.

Nmap / recon tooling: First two days of an external engagement, then referenced occasionally. Not a daily activity.

Metasploit: Rarely. Most professional environments have EDR that makes Metasploit noisy. Custom tooling, living-off-the-land techniques, and manual exploitation are the actual daily practice when post-exploitation is in scope.

Python scripting: Yes, regularly — but for automating report data extraction, building quick parsers for tool output, and occasionally for custom payload generation. Not for the dramatic exploit scripting I imagined.

Active Directory attacks: When it's in scope. Not every engagement. When it appears, it's intense and the skills matter significantly. But it is not the daily texture of the work.

Buffer overflow: I have not needed this skill professionally since being hired. Modern targets don't present this attack surface in ways that require manual buffer overflow exploitation. The OSCP prepared me for it. The job has not required it.

What This Actually Means If You're Still Preparing

The certifications and the labs are not wasted. They build the technical vocabulary that makes everything else possible. Without the foundation, you cannot do the job.

But if you're building toward a career in professional security and you are spending zero time on writing, zero time on communication, and zero time on developing judgment about when to pursue and when to move on — you are underprepared for the job in ways that your OSCP score will not reveal until you're in it.

The things that will make you exceptional at this job are not in any syllabus. They accumulate from doing the work, making the mistakes, watching people who are better than you operate, and being honest about the gaps that emerge.

The resume gets you hired. The skills you build in the first two years determine whether you stay.

The One Thing Nobody Said Out Loud

Every cybersecurity content creator — including me, in my earlier writing — spends the majority of their content on technical skills. Tool tutorials. Vulnerability breakdowns. Exploitation methodology. Certification guides.

This content is useful. I consumed thousands of hours of it.

But there is a version of this career that nobody films: the version where you spend Tuesday afternoon rewriting an executive summary because the first version confused the CISO. The version where you spend an hour on a phone call managing a client's reaction to a critical finding rather than exploiting anything. The version where the most important thing you do all week is convince a development team that a finding they've dismissed is actually worth fixing.

That version of the job is the majority of the job.

Build for it.

Key Takeaways

• Writing is the most-used skill in professional security work — it is absent from almost every preparation curriculum
• Threat modeling before touching a target matters more than any individual technique
• Knowing when to stop chasing an attack path is a professional skill — labs reward persistence, engagements require judgment
• The "so what" translation — from technical finding to business consequence — determines whether findings get acted on
• Technical skills from certification are real and necessary — they just represent a smaller fraction of daily work than expected
• The resume gets you hired. The soft skills — communication, judgment, client management — determine your ceiling
• The job that isn't filmed is the majority of the job