I’m often asked by students and those thinking about a move into cyber security: “How do I break into the field?“
My answer hasn’t really changed over the years, but I get asked often enough that I figured it’s worth putting into a quick* blog post. I’ll give you a sense of how I think about hiring, what I look for, and hopefully give you something more useful than some of the generic, unhelpful advice out there.
Just to be super clear – everything here is 100% my personal opinion. This is what I look for when hiring for my own teams, regardless of seniority.
This post is focused on the technical side of cyber security – engineering, architecture, offensive security, defensive security. I think it’s a good foundation, even if you eventually end up specialising in a less technical field like governance, risk, or compliance.
* turns out this wasn’t the “quick post” I thought it would be – it took me three weekends in a coffee shop to get this finished 🙃
The Most Common Question
“I want to get into cyber security but don’t know where to start – what do you recommend?“
The brutal truth is that you’ll be up against hundreds – sometimes thousands – of applicants for roles. The good news is that most of them won’t be qualified, but the question is: how do you stand out amongst the crowd?
Ask yourself – what have you done that actually shows you’re serious?
- Got a portfolio?
- Written anything useful – blogs, walkthroughs, tutorials?
- Are you in the top 1% on platforms like Hack The Box?
- Do you have a bug bounty profile with some published meaningful reports?
- Have you pushed through and earned an OSCP?
- What have you hacked, reverse engineered, patched?
If you want to excel in cyber security, you need deep knowledge across a broad range of technical domains. The broader and deeper your expertise, the more valuable you’ll be – and the more you can command in terms of salary.
To put it in perspective:
A good software engineer knows their codebase, their stack, and how to build reliable systems.
A good cloud engineer knows cloud architecture, networking, and how to secure and scale infrastructure.
A good IT engineer knows networking, endpoints, identity solutions and how to keep the organisation running smoothly and securely.
A good security engineer needs to understand all of this – plus how attackers think, how systems fail, and how to break things before someone else does. That means having working knowledge across many domains: software, cloud, networking, identity, endpoints, authentication, cryptography, and more.
You don’t need to be an expert in all of them, but you need to understand how they fit together and where the risks live. It’s not easy.
Learn the Fundamentals
There’s some foundational knowledge that I think everyone should build up early on in their journey – you may find some of it boring and that’s okay. If you find yourself uninterested in all of it, ask yourself if this is really the right field for you.
Here are some foundations to really get your head into:
- How networks actually work (IP, routing, DNS, ports, etc)
- How operating systems work (especially Linux and Windows internals)
- What happens when you open a browser and type in a URL
- Cloud computing. This is a big one so I will split this into multiple bullet points
- The three main ones I would focus on in order of importance are AWS, GCP and Azure. Get accounts on all of them and start tinkering and playing. They all offer free credit so there’s really no reason you shouldn’t be building, deploying and breaking stuff in these environments
- Learn/play with Kubernetes and containerisation technology
- Learn the basics of Git – create an account on GitHub if you don’t already have one and learn how to use it via an Integrated Development Environment (IDE) like VS Code
- Deploy a basic web application in a container and deploy it via GitOps (it doesn’t need to be in a Kubernetes cluster – that’s probably overkill but if you’re feeling adventurous, fill your boots!)
Get your hands on the community edition of Burp Suite and see how modern web applications work. Learn how the proxy and certificate works, learn how to use the repeater to manipulate the traffic. See what breaks. Then fix it. Get your hands dirty.
A lot of the technical depth you need can be picked up from books. No Starch Press is an excellent resource and they’ve got solid material on so many topics. Pick up a couple that you like the look of. Note down concepts you’re unfamiliar with and research/learn them.
You’ll also find amazing resources on YouTube like IppSec – this will teach you how attacks work and there’s something to learn in every video. Watch, pause, rewind, take notes, and research the stuff you don’t get. By the end of this portion of learning, you should know what a “SQL Injection” attack and “XSS” is and how to protect against them. IppSec has an awesome search feature to help you learn the different categories and types of attack – use it.
It’s not super important which books, videos, courses, etc you choose. What matters is that you actually take the time to learn, build, and test things yourself. Reading is great – but setting up your own development environments and playgrounds, running packet captures, breaking stuff and fixing it – that’s where the real learning comes from.
Learn Some Scripting
Some personal context: I avoided the programming-heavy path in university because I really disliked Java. But later in my career I realised how useful scripting would be, so I picked up Python using the Python Crash Course book from No Starch Press – I know I already mentioned above but they are an excellent publisher!
Not long after, I wrote my first offensive tool, SlackPirate. It’s now got over 700 stars on GitHub and is used by red teams all over the world. It still catches me off guard when someone casually mentions it and I tell them I’m the author.
It doesn’t need to be hardcore programming and you don’t need to come out the other side writing full applications or designing complex systems but something like Python will help you massively in this field – from automating recon, parsing logs, building quick tools and generally just saving a whole bunch of time.
Special note on AI: Yes, AI can help you write code faster – but it’s absolutely critical that you understand the fundamentals yourself. AI tools and LLMs are excellent accelerators, but without a solid foundation, you won’t be able to tell good solutions from bad ones. I don’t need people who can copy-paste from ChatGPT – I can do that myself. I need people who understand how to wield these tools to build excellent solutions faster, not ship clunky garbage.
It’s Okay to Be a Generalist
Don’t stress too much about specialising straight away. Early in your career, it’s totally fine to try different areas – pentesting, red teaming, reverse engineering, malware analysis, cloudsec, appsec, identity, governance, etc.
Eventually, you’ll naturally lean toward an area that suits you. I personally stayed a generalist and still am to this day – and I love it. I get to strategise across all of cyber security and deep-dive into the details when I need to.
What I Look For When Hiring Juniors
You might be surprised, but the bar isn’t as high as you think. The number one thing I look for? Real passion. That raw curiosity.
That passion can show up in all sorts of ways:
- Home/cloud labs and creative setups
- Decent HTB or similar profiles (not the generic “just started” ones)
- GitHub projects with depth – not test repos with one commit
- Technical blogs where you walk through what you’ve learnt
- Tough certs like OSCP – shows you can push through and self-teach something challenging
- Conference talks, even local ones
Do You Need a Degree?
This shouldn’t be controversial in 2025 but the presence of a degree doesn’t play much of a role when I am short listing candidates and I think more and more companies are waking up to that. If you don’t have a degree, I’ll expect to see a bit more effort elsewhere: projects, blogs, a cert or two, speaking gigs, something.
If you give me two candidates: one with a degree but no practical experience and one without a degree but with solid published projects and/or work; all else being equal, I’ll probably lean towards the latter.
Final Thoughts
The vast majority – if I had to guess, probably >90% – will not have the passion, hunger or desire and that’s going to show on their CV’s and interviews. It’s like in most fields – if you don’t have the passion, you’ll probably end up being mediocre in your field. The ones that have the drive are the ones who typically exceed and progress much faster.
If you’re willing to graft, build stuff, learn in public, and show your progress, you’ll get noticed. You don’t need a fancy title or letters after your name – just prove you’re hungry, capable, and willing to learn.
And don’t get caught up in the noise about “AI taking all the junior jobs.” It’s no different to thinking a chef’s knife will prepare and cook the meal. You don’t hire the knife – you hire the chef who knows how to wield it properly. In my opinion, AI is the same: a powerful tool in the hands of those who understand the fundamentals, but useless (or dangerous) in the hands of someone who doesn’t.
I hope this has been helpful. And if you’re early in your journey – keep pushing. You’ve got this.