The Cybersecurity Experience Trap

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

SPEAKER_00 0:10

You've found a cybersecurity job you love. There's just one problem: it wants experience you haven't got. Welcome to Hacking Your Cyber Career. Real advice, real experience. Your next move. Here's Steve.

SPEAKER_01 0:26

So you've decided you want to work in cybersecurity. You've studied, maybe earned a degree, perhaps picked up a certification or two. You find a job advertised as entry-level. Brilliant! You open it up. Three years of security operations experience. Experience managing enterprise firewalls. Cloud security, scripting, incident response, penetration testing, risk management, and 17 technologies that apparently everybody but you has used. And preferably a master's degree for an entry-level job. At this point, you're probably wondering whether you were supposed to start working in cybersecurity at the age of 14. Welcome to the Cybersecurity Experience Trap. How do you get the experience employers want if nobody will hire you without it? I'm Steve, and this is Hacking Your Cyber Career. Today we're going to talk about why that trap exists, what employers really mean by experience, and how you can get past it. And I promise you, I'm not going to say just get five certifications and build a home lab, as if that's a magic spell that makes a hiring manager appear. I've spent more than 30 years in IT, and a good part of that leading cybersecurity organizations. I've hired people straight from university, people from the help desk, and even people with very little formal experience. I've also interviewed people with pages of qualifications who couldn't explain what they'd actually done. So I've seen both sides of this. Here's the first thing I want you to remember. You may not have years of cybersecurity employment behind you, but that doesn't mean you have nothing valuable to offer, and you certainly shouldn't be the first person to reject your own application. Let's start with why job advertisements are often so ridiculous. I have a confession to make. Hiring managers, myself included, are partly responsible for this mess. When you're trying to recruit somebody, you start by imagining your ideal candidate. Someone who knows the technology, understands your environment, communicates brilliantly, handles pressure, and can probably fix the office coffee machine while they're at it. Then you put all those things in a job description. Networking, firewalls, cloud, identity, vulnerability management, security monitoring, governance. The list grows and grows. By the time it's finished, you're no longer advertising for a person, you're advertising for a small cybersecurity department in a trench coat. I've done it, most hiring managers have. You want as much capability as you can get, so you write down everything you'd like. The important distinction is between a requirement and a wish. Sometimes a job really does require a specific certification, security clearance, legal eligibility, or experience with a particular technology. Those things matter, but a surprising number of other items are preferences. The perfect person who ticks every box is what I call a unicorn. They might exist, but you shouldn't build your entire hiring strategy around finding one. Often I'm hoping to find someone strong in two or three important areas, with the attitude and foundation to learn the rest. So when you see a long list of requirements, don't immediately close the browser. Look at the actual responsibilities. Which skills are genuinely essential to do the job safely? Which could be learned? Can you demonstrate related experience? If you meet the core requirements and could credibly grow into the role, consider applying. Don't lie, don't claim experience you haven't got, but don't assume every bullet point is a legal contract either. One caveat. Some positions genuinely aren't entry-level, even if the title suggests otherwise. If the job requires you to lead major incidents independently from day one, that isn't a sensible first security role. The trick is learning to tell the difference between an ambitious wish list and a job where experience is truly necessary. And that's where understanding what employers mean by experience helps. Here's something I really want younger listeners to hear. I've hired people with almost no direct cybersecurity experience. Some were straight out of college, some were very early in their working lives. Why? Energy, curiosity, eagerness. They wanted to learn, wanted to contribute, and weren't afraid to ask why things were done a certain way. Now, I'm not suggesting every experienced employee is jaded. Far from it. Some of the best people I've worked with had decades of experience and the enthusiasm of someone on their first day. But in established organizations, people can become accustomed to doing things a particular way. They've heard all the reasons something supposedly can't change. They know the politics. Sometimes they stop asking whether the process makes sense. A new person comes in and says, why do we do it like that? And suddenly everyone looks slightly uncomfortable. Because the answer might be, well, we've always done it that way. Which isn't really an answer, is it? Fresh perspectives can be incredibly valuable. People who've learned different tools, worked on different projects, or simply haven't absorbed the organization's assumptions can challenge the status quo. That is not a substitute for judgment or experience. New ideas still need testing, but the combination of experienced professionals and curious newcomers is often much stronger than either group alone. When I was hiring, I wasn't expecting a junior candidate to know everything. I wanted to see that they cared, that they could learn, that they would communicate, and that they could work constructively with the team. Cultural fit, to me, wasn't about hiring people who looked or thought alike. A team needs different perspectives. It was about attitude, respect, honesty, and willingness to contribute. So please don't underestimate the value of you. Your curiosity, energy, and fresh thinking are assets. They're not a consolation prize for having less experience. Your task is to demonstrate them in a way an employer can recognize. And that brings us to the question of what actually counts as experience. Let's say you've never been employed as a security analyst. Does that mean you've never done anything relevant to cybersecurity? Of course not. Think about what cybersecurity actually involves systems, networks, identity, applications, people, business processes. If you've worked on a help desk, you've probably dealt with user accounts, permissions, devices, troubleshooting, and frustrated people. That last one is a skill in its own right. A good help desk employee learns to ask questions, listen carefully, and solve problems while somebody is waiting for an answer. Those skills transfer beautifully into cybersecurity. I know because I've brought people from help desk teams into security roles. Particularly in the earlier years, cybersecurity wasn't the large separate discipline it is now. We needed people who knew the environment. Help desk staff knew how the business actually used its systems. Infrastructure and networking staff knew how those systems connected. They understood firewalls, routing, servers, operating systems, and access controls, all incredibly relevant to technical security. Now, someone moving into governance, risk, or awareness might need a different set of skills. Cybersecurity is broad, but there's a lot of overlap. A network engineer who understands traffic flows is already partway toward network security. A system administrator who understands authentication is building useful identity security knowledge. A software developer who understands code quality can learn secure development practices. And a help desk analyst who handles access requests and user problems has a foundation for identity, security operations, and awareness work. Even outside paid employment, university projects, internships, supervised volunteer work, student competitions, and home labs can give you something meaningful to discuss. But here's the important bit. Describe them honestly. A home lab is a home lab. Don't describe it as implementing enterprise security architecture for a multinational organization. Explain what you built, why you built it, how you tested it, what broke, and what you learned. A small project explained clearly is far more credible than a grand claim that falls apart under one follow-up question. And believe me, hiring managers ask follow-up questions. Welcome to From the Hiring Desk, where we talk about what really happens when you're sitting on the other side of the interview table. I've interviewed candidates with absolutely spectacular resumes. Pages and pages of experience. Degrees, master's degrees, certifications, technologies, projects. The sort of resume that makes you wonder whether the person has had time to sleep. On paper, brilliant. Then we sit down and start talking. I see a project on the resume. Perhaps a technology they say they implemented. So I ask a straightforward question. Tell me about your role in that. What did you design? Which decisions were yours? What went wrong? How did you solve it? And sometimes you can almost see the cracks appearing. The answers become vague. They talk about what the team did, but can't explain what they personally contributed. Or the story changes as you ask more questions. It becomes clear that they've embellished the experience, or in some cases, simply invented it. And that is an enormous turnoff for me. Not because I expect everyone to have led every project. I don't. In fact, I'd be delighted if someone said, I was the junior person on that project. My role was to configure these components, document the changes, and test the results. I didn't design the whole solution, but here's what I learned. That's a credible answer. That's someone I can work with. The problem isn't limited experience. It's dishonesty. Cybersecurity depends on trust. When something goes wrong, I need people to tell me what actually happened, not what they think I want to hear. And here's another thing. Lots of short jobs on a resume can prompt questions, but they don't automatically make someone a bad candidate. People change jobs for good reasons. Just be prepared to explain your choices clearly. So, if you're applying for your first role, don't try to sound like you've been running a security department for 10 years. Be specific, be accurate. Say what you know and what you don't. If you don't know an answer in an interview, talk through how you'd investigate. Show your reasoning, show your curiosity. And please, don't make things up. The person interviewing you may have spent 20 years working with the very technology you're claiming to have invented. That can become awkward rather quickly. One of the best ways into cybersecurity is to start creating opportunities before there's a job opening. I remember someone working on a help desk several years ago who recognized where cybersecurity was heading. They could see the discipline growing. More investment, more attention from leadership, more specialist work. And instead of waiting for someone to offer them a security job, they started getting involved. They showed interest, they asked questions, they looked for ways to help. They wanted training, wanted exposure, wanted to understand the technologies and the problems. That's exactly the sort of behavior that gets my attention. It doesn't guarantee a transfer or a promotion. Teams have budgets, vacancies, and business constraints. But when an opportunity does appear, the person who's already been learning and contributing has a much stronger story to tell. This was something I tried to do throughout my own career. Don't look only at what you're doing today. Look at what the industry will need tomorrow. When networking was changing, I learned networking. When security became a bigger discipline, I got more involved. Today you might be looking at cloud identity, automation, AI security, or something we haven't even named yet. The point isn't to jump on every fashionable bandwagon. There are enough of those already, thank you very much. The point is to identify real problems organizations will need people to solve. Then begin learning how to solve them. If you're at university, ask about internships, research projects, and practical assignments. If you're already in IT, talk to your security team. Ask whether you can observe a review, assist with documentation, help test a control, or join an approved project. Respect boundaries. Don't go poking at production systems to prove your enthusiasm. That tends to create a rather different sort of career opportunity, usually involving a meeting with HR. If you don't have access to a workplace, build a modest lab or complete a legitimate training exercise. Document it. Take notes. Explain what you tried and what you discovered. Over time, those small experiences become evidence. Not pretend experience, real evidence that you can learn, think, and contribute. Now, after spending a good portion of this episode explaining what candidates get wrong, it's only fair I tell you about an interview I got wrong myself. When I was younger, I applied for a job at another company. I was technically capable, enthusiastic, and looking back, probably a little too cocky. I went into the interview feeling pretty good about my skills. And then they asked a very simple question. So, Steve, what do you know about our company? Ah, yes, that. I'd done very little research. I had a vague idea what the business did, but I hadn't properly looked into it. I took a stab at answering. It wasn't a particularly good stab. I could see from their faces that I was missing the mark, and the more I talked, the worse it got. I didn't get the job. And looking back, I think that's why. It wasn't a technical failure, it was a preparation failure. I assumed my technical skills and enthusiasm would be enough. They weren't. And while I might have wondered at the time why they cared so much whether a junior candidate understood the business, I understand it much better now. Cybersecurity exists to protect an organization. If you don't know what the organization actually does, it's difficult to explain why its systems, data, and customers matter. So here's my advice. Before any interview, research the employer. Not just the first paragraph of the website. Find out what they sell or provide, who their customers are, how they make money or deliver their mission, which industries they operate in, what technology and security challenges they might face. If they're a public company, look at their annual report and recent news. You don't need to become an expert overnight, but you should be able to explain, in plain language, what the company does and why cybersecurity matters to it. Prepare a couple of thoughtful questions too. What does success look like in this role? How does the team support junior staff? What are the biggest challenges the team is working on? Those questions show your thinking beyond the job title. I can still remember the feeling of stumbling through that interview. Not my finest moment. But it taught me something I never forgot. Technical ability gets you considered. Preparation, honesty, and understanding the business help you get hired. Right, let's finish with your next move. This week I want you to do something that produces actual evidence of your capability. Pick one cybersecurity job that interests you. Read the description and identify one skill you don't yet have. Just one. Then give yourself seven days to learn something practical about it. Perhaps configure a small network in a lab. Explore access controls in a test environment. Complete an authorized security exercise. Or research how a particular control protects a business. Write down what you did, what went wrong, and what you learned. Then turn it into three or four clear sentences you could use in an interview. I wanted to understand this. I tried that. I ran into this problem. Here's how I solved it, or what I'd do next. That's much more useful than saying, I'm passionate about cybersecurity and hoping everyone believes you. While you're at it, choose one employer you genuinely like to work for and research what the business actually does. Consider that a small favor to your future self, courtesy of one of my less impressive interviews. Here's what I want you to remember from today. A job description is often a wish list, not a description of a mythical perfect human. Experience can come from support, networking, development, university projects, and practical learning. Fresh thinking and enthusiasm have value, and honesty matters far more than an inflated resume. Don't reject yourself before the employer has even met you. But don't expect enthusiasm alone to do the work either. Build skills, gather evidence, learn about the business, and make it easy for someone to see what you could contribute. Next time, we're going to ask another question that causes a lot of debate. Do you really need a degree to work in cybersecurity? I've got some fairly strong views about education, as you might imagine, but there are more routes into this profession than you may think. I'm Steve. Thanks for listening to Hacking Your Cyber Career. And remember, getting in is just the beginning.