DEV Community: Andreas-Christian Hetzl

Why Cybersecurity Is Rarely a True First Job

Andreas-Christian Hetzl — Tue, 07 Jul 2026 18:50:22 +0000

Security demand is real, but most roles assume IT fundamentals. Here is the realistic, defensive route in.

The problem

Cybersecurity is marketed as a high-demand field you can jump straight into, so beginners aim there first, then stall when every job posting assumes IT experience they do not have. The demand is real; the 'no fundamentals needed' promise is not.

Why this matters now

Workforce studies like ISC2's keep highlighting a security skills gap, and EU bodies such as ENISA emphasise defensive capability. But the same sources describe roles that assume networking, systems and identity knowledge. Knowing this early prevents months of applying to roles that were never entry-level.

The skills-gap headline is real, but it is widely misread. A shortage of experienced defenders is not the same as a shortage of entry-level seats — most openings are for people who can already be trusted with production systems. That is why so many career changers who aim straight at 'cybersecurity' feel the door is stuck: they are applying for the second rung of a ladder whose first rung is ordinary IT experience.

The practical framework

Think of security as a second floor that needs a ground floor. Build the ground floor first, then climb:

Fundamentals: operating systems, networking, identity, and how systems actually fail.
Bridge roles: IT support, helpdesk, junior sysadmin, or cloud support, where you see real incidents and real users.
Defensive entry: monitoring, logging, patching, identity hygiene, and security awareness, learned defensively and ethically.

A quick word on the 'SOC analyst as a first job' idea: it happens, but even entry SOC roles usually expect you to read a log, understand what a normal network looks like, and explain an alert in plain language — all of which are far easier to learn from a support or systems seat first. This article is strictly defensive: it is about protection, governance and good practice, never attack techniques.

What beginners often get wrong

Skipping fundamentals and chasing exciting offensive-sounding content. Beyond being a weak career strategy, it points learning in an unhelpful direction. Beginner security value comes from awareness, logging, patching, backups, identity and defensive thinking, not from attack tooling.

There is also a credibility cost. An interviewer can tell within minutes whether someone has actually run and restored a backup, watched a patch break something, or reset access for a locked-out user — versus someone who has only watched videos about hacking. The first person is hireable into a defensive role; the second is not yet, no matter how enthusiastic. Real defensive value is unglamorous and that is exactly why it is valued.

A better path

Earn a bridge role, build IT fundamentals, and learn security defensively on top. You will be a far stronger security candidate having seen how systems behave in production than having memorised concepts in isolation.

How to learn security defensively as a beginner, concretely: keep your own devices patched and write down what changed; set up multi-factor authentication and document why it matters; practise taking and restoring backups; read the logs your own machine already produces and try to explain them; and study the basics of identity and access. Foundational, defensive certifications (for example CompTIA Security+) map to exactly this kind of knowledge. Every one of these is legal, ethical, and directly relevant to a first defensive role.

Example roadmap

A realistic, defensive route (a shape, not a promise):

Build fundamentals: OS, networking, identity.
Take a support or sysadmin bridge role.
Learn defensive basics: logs, patching, backups, identity hygiene, awareness.
Add a foundational, defensive certification once its objectives match your target roles.
Move toward a junior defensive security role with real fundamentals behind you.

Realistic bridge roles that lead into security include IT support and helpdesk, junior systems or network administration, and cloud support — each puts you next to real incidents, real users, and real logs. From there, a move into a defensive security seat (monitoring, vulnerability hygiene, identity, GRC-adjacent work) is a credible next step rather than a leap.

What to do this week

Build OS, networking and identity fundamentals first.
Target a bridge role (support, helpdesk, junior sysadmin, cloud).
Learn security defensively: logging, patching, backups, identity.
Avoid framing your learning around attack techniques.
Document defensive labs to show practical understanding.

How to tell it is working

Progress in an IT transition is easy to fake to yourself and hard to fake to an employer, so measure the things employers can see. You are on track when, each week, you can point to one new artefact (a lab note, a troubleshooting write-up, a small script) and explain it in plain language. You are on track when you can name your target role without hesitating and list the skills it asks for. And you are on track when your CV and profile use the same words as the job descriptions you are reading. If a week passes with hours of video but nothing you could show or explain, that is the signal to change the routine, not to push harder at the same thing. Keep a short log of what you produced each week; over a couple of months it doubles as both a portfolio and proof of consistency, which is exactly what a hiring manager wants to see from someone changing fields.

A realistic note on pace

Career-change advice tends to swing between two unhelpful extremes: 'anyone can do this in a few weeks' and 'you need a four-year degree first'. Both are wrong for most people. The honest answer is that it depends on your starting point, the time you can protect each week, the language you are working in, and the roles your local market actually hires for. Be sceptical of anyone promising a fixed timeline, instant placement, or a specific salary on day one; realistic guidance talks in ranges and trade-offs, not promises. What you can control is consistency and visibility: small, steady, documented progress toward one clear role beats sporadic bursts of enthusiasm aimed at everything at once. Protect a few focused hours a week and defend them like any other commitment, because steady beats heroic almost every time.

Turn your non-IT experience into an asset

If you are coming from manufacturing, hospitality, retail, logistics, finance, administration, customer support or the trades, you are not starting from zero. Those jobs build exactly the skills IT teams complain are missing: calm problem-solving under pressure, clear communication with frustrated people, documentation, prioritisation and reliability. The mistake is to hide your old career as if it were an embarrassment. Instead, translate it. 'Handled escalations on a busy shift' becomes evidence you can triage and de-escalate, which is most of helpdesk work. 'Reconciled daily figures' becomes attention to detail and process discipline. Write one or two lines per past role that map a real responsibility onto an IT-relevant strength, and use them in your CV and interviews. Career changers who do this well often interview better than fresh graduates, because they can talk about real situations, real stakes, and real people.

How to read a job description like a map

A job description is not a wish list to feel intimidated by; it is a map of what the employer values, written in their own words. Read several for one target role and mark three things. First, the skills that repeat across postings: those are your priorities, in roughly that order. Second, the 'nice to haves' that appear only occasionally: safe to skip at first. Third, the exact phrasing the employer uses, because mirroring it (honestly) in your CV and profile is what gets you past keyword filters and human skim-reads alike. You do not need to match every line to apply; most postings list an ideal candidate who rarely exists. If you cover the repeated core and can show a little proof, you are a legitimate applicant, not a pretender.

Where SHIFT 2 IT fits

Inside SHIFT 2 IT, I go deeper into turning your current background into a realistic roadmap toward your first target IT role — including how this fits the bigger sequence of learning, proof and positioning.

Final thought

Cybersecurity is a genuinely strong destination. It is just rarely the first stop. Build the ground floor, take a bridge role, and you will reach security as a credible candidate rather than a stalled applicant.

Key takeaways

Security demand is real, but most roles assume IT fundamentals.
Use a bridge role to build real-world experience first.
Beginner security value is defensive: logs, patching, identity.
Avoid building your learning around attack techniques.

If you are planning a move into IT, start by choosing a target role before choosing certifications.

This article is part of my SHIFT 2 IT series for people moving into IT realistically.

AI Will Not Replace Your IT Roadmap But It Changes It

Andreas-Christian Hetzl — Sat, 27 Jun 2026 18:53:02 +0000

A practical way to choose your next step into IT without turning AI into a shortcut around fundamentals.

Why beginners start in the wrong place
The role-first framework
How to build proof
Certification strategy
Weekly checklist

Beginners entering IT need a plan that connects learning to employability. A course can help, but a role-first roadmap is what gives the course a purpose.

Why beginners start in the wrong place

The common mistake is to ask, "Which certification should I take?" before asking, "Which first role am I preparing for?" That order creates scattered learning.

The role-first framework

Choose a first role, identify baseline knowledge, build visible proof, then select certifications that support the path. This keeps the learning plan practical.

How to build proof

Use documented labs, diagrams, troubleshooting notes, cloud screenshots from legitimate practice environments, and ticket-style writeups. Do not create fake experience.

Certification strategy

Certifications can structure learning and help screening, but they do not replace practical skill, communication, documentation, or role clarity.

Weekly checklist

Pick a target role.
Compare job descriptions.
Build one proof artifact.
Write a short reflection.
Review whether a certification supports the role.

This article is part of my SHIFT 2 IT series for people moving into IT realistically.

How to Build a Simple IT Portfolio Without a Job Yet

Andreas-Christian Hetzl — Sun, 21 Jun 2026 15:57:00 +0000

You cannot fake experience, but you can build honest, visible proof — starting today.

The problem

Every job wants experience, and you do not have any yet. The usual workarounds, faking experience or padding a CV, backfire. What you actually need is honest, visible proof that you can do the work, and you can build that before anyone hires you.

Why this matters now

As more people enter IT through self-study, employers increasingly look for evidence beyond a CV line. Public learning data (for example Stack Overflow's developer survey) shows how common self-directed learning has become, which means a small, credible portfolio is one of the cleanest ways to stand out from identical-looking beginners.

AI sharpens this further. When anyone can generate a polished-sounding CV in seconds, a tidy CV proves less than it used to. What it cannot fake is a trail of real work: the messy middle of a problem you hit, what you tried, and how you fixed it. That trail is exactly what a portfolio captures, and it is becoming the thing that separates a believable beginner from a generated one.

The practical framework

A beginner IT portfolio is a small collection of honest artefacts, each showing a problem, an attempt, and an outcome. Aim for five that do not look fake:

A documented home lab (what you built, why, and the steps).
Two troubleshooting write-ups in a ticket style: symptom, investigation, fix, lesson.
A small script or automation with comments explaining the intent.
Cloud free-tier screenshots with captions on what each resource does.
A 'what I learned' log that shows direction and reflection over time.

Why these five look real when a 'project' often does not: each one shows judgement, not just completion. A home lab shows you can set up and break and fix an environment; a ticket write-up shows how you think under a real problem; a commented script shows you understand what the code does and why; captioned cloud screenshots show you can navigate a platform; and the learning log shows direction over time. Reviewers are not looking for polish — they are looking for signs that a real person solved a real problem.

What beginners often get wrong

Turning a tutorial into a 'project' and presenting copied steps as original work. Reviewers can tell. The fix is not to avoid tutorials but to add your own problem, your own mistakes, and your own explanation on top of them. The second mistake is hiding the struggle: people delete the dead ends and show only the clean final result, which reads as either copied or shallow. The dead ends are the proof — 'I assumed it was DNS, it was not, here is how I found the real cause' is far more convincing than a flawless screenshot.

A better path

Document as you learn, not afterwards. Every time you fix something or build something, write three short paragraphs: what you were trying to do, what went wrong, and how you solved it. Put these in a simple public place and link to it from your CV and LinkedIn.

Where to host it, simplest first: a free GitHub account works even if you are not a developer — a repository is just a folder, and a single README file (plain text with headings) can hold your write-ups, screenshots and notes. A free blog (Hashnode, dev.to) or even a tidy shared document works too. What to put on GitHub if you are not a developer: your home-lab notes, your troubleshooting tickets, small scripts, and configuration files with comments. The point is a single link you can put on your CV that says 'here is proof', not a polished website.

Example roadmap

A four-week shape to a first portfolio (adapt to your pace):

Week 1: stand up a home lab (a couple of virtual machines, or a spare PC) and document the setup, including what went wrong.
Week 2: write two troubleshooting tickets from real problems you hit — symptom, what you checked, the fix, the lesson.
Week 3: build a small script (even a five-line one) and a cloud free-tier example with captioned screenshots.
Week 4: write your learning log, tidy the README, and link everything from your CV and LinkedIn.

Five beginner projects that do not look fake, if you want concrete ideas: set up and document a home network or lab; write a 'how I fixed it' ticket for a real device problem; automate one boring task with a short script; deploy a free-tier resource on Azure or AWS and explain it; and keep a dated learning log. None require a job, money, or permission — only honesty about what you actually did.

What to do this week

Pick one place to host proof (site, GitHub, or a tidy doc).
Document your home lab setup as you build it.
Write two ticket-style troubleshooting notes.
Add one commented script or small automation.
Caption your cloud free-tier screenshots with what they do.
Link the portfolio from your CV and LinkedIn.

How to tell it is working

A realistic note on pace

Turn your non-IT experience into an asset

Where SHIFT 2 IT fits

Final thought

You cannot manufacture years of experience, but you can manufacture proof of ability, honestly and starting today. A small, real portfolio answers the question every employer is silently asking: can this person actually do the work?

Key takeaways

You need honest proof, not fake experience.
Document problems, attempts and outcomes as you learn.
Five small real artefacts beat one inflated 'project'.
Link your proof from your CV and LinkedIn.

If you are planning a move into IT, start by choosing a target role before choosing certifications.

This article is part of my SHIFT 2 IT series for people moving into IT realistically.

What Beginners Get Wrong About IT Certifications

Andreas-Christian Hetzl — Wed, 17 Jun 2026 21:33:22 +0000

Certifications help when they match a role and are backed by proof — not as a scoreboard.

The problem

Beginners are told certifications are the key to IT, so they buy the most popular one, pass it, and are surprised when interviews still go badly. A certificate proves you can pass an exam; it does not, on its own, prove you can do the job.

Why this matters now

Certifications remain useful signals, and official providers like CompTIA, Microsoft, AWS, Cisco and Google keep their exam objectives public and current. But as AI makes it easier to grind practice questions, employers lean harder on whether you can actually apply the knowledge. The value of a certificate is increasingly in what you can demonstrate alongside it.

There is also a cost reality. Exams, courses and retakes add up in money and time, and career changers usually have limited amounts of both. Spending three months and a chunk of savings on a certificate that no target role actually asks for is one of the most common and most avoidable mistakes in an IT transition — which is exactly why the order you choose them in matters.

The practical framework

Use certifications as targeted evidence, not as a scoreboard. Three rules:

Match objectives to a job. Open the certification's published objectives next to a real job description. Overlap means it is relevant; no overlap means it is a hobby.
Prove the same skills in practice. For each major objective, build one small artefact that shows you can do it, not just recall it.
Stop at enough. One well-chosen, well-demonstrated certification beats three unrelated ones. Sequence them to roles, not to availability.

Which one first? Let the target role decide, not the brand with the loudest marketing. As a rough guide: a vendor-neutral foundation (such as CompTIA A+ for general IT support, or Network+/Security+ as you specialise) suits broad support roles; a cloud-fundamentals exam (Microsoft Azure or AWS) suits cloud-leaning roles; Cisco-flavoured paths suit networking-heavy roles. None of these is universally 'best' — the best first certificate is simply the one whose objectives overlap most with the ten job descriptions you are actually targeting.

What beginners often get wrong

Believing a certification is a substitute for role clarity, hands-on ability, communication and troubleshooting. It is a complement to those, not a replacement. The related trap is 'certification collector syndrome': stacking badges to feel progress while avoiding the harder work of building visible proof.

Interviewers have a name for the result: the 'paper' candidate — someone whose CV lists certificates but who cannot walk through how they would actually diagnose a slow laptop or reset a locked account. The moment a practical question lands, the gap between passing an exam and doing the work shows. The fix is never another exam; it is pairing the certificate you have with evidence that you can apply it.

A better path

Choose the certification a specific role asks for, study its objectives, and as you study, turn each objective into a small piece of evidence. By exam day you have both the certificate and a portfolio that backs it up, which is exactly what survives an interview.

Concretely, study with a lab open, not just a video playing. When the objectives mention user accounts, create and reset some; when they mention networking, capture what you configured; when they mention backups, actually run and restore one. Each of those becomes a short write-up. You end up studying once and producing proof at the same time, instead of treating learning and portfolio-building as two separate chores.

Example roadmap

A sane certification sequence (depends on your target role and market):

Confirm the role and read ten of its job descriptions.
Pick one foundational certificate whose objectives match (often a vendor-neutral or fundamentals exam).
Build one artefact per objective while studying.
Sit the exam; update CV and LinkedIn with both the cert and the proof.
Add a second certificate only when a target role specifically asks for it.

What this is not: it is not 'collect A+, then Network+, then Security+, then a cloud exam' on autopilot because a roadmap graphic said so. Each step should be justified by a real posting you want to apply to. If two certificates cover the same ground for your target role, you only need one. The goal is the job, not the badge collection.

What to do this week

Pick a target role before any certification.
Compare the certificate's objectives to a real job description.
Turn each major objective into one small proof artefact.
Avoid buying a second certification 'just in case'.
Put the proof, not just the badge, on your CV and LinkedIn.

How to tell it is working

A realistic note on pace

Turn your non-IT experience into an asset

Where SHIFT 2 IT fits

Final thought

Certifications open doors when they match a role and are backed by visible ability. On their own, they are a receipt for studying. Aim them, demonstrate them, and stop collecting them for their own sake.

Key takeaways

A certification proves you passed an exam, not that you can do the job.
Match certification objectives to a real job description.
Build proof for each objective as you study.
One well-chosen, demonstrated certificate beats a stack of unrelated ones.

If you are planning a move into IT, start by choosing a target role before choosing certifications.

This article is part of my SHIFT 2 IT series for people moving into IT realistically.

DEV Community: Andreas-Christian Hetzl

Why Cybersecurity Is Rarely a True First Job

The problem

Why this matters now

The practical framework

What beginners often get wrong

A better path

Example roadmap

What to do this week

How to tell it is working

A realistic note on pace

Turn your non-IT experience into an asset

How to read a job description like a map

Where SHIFT 2 IT fits

Final thought

Key takeaways

AI Will Not Replace Your IT Roadmap But It Changes It

Table of contents

Why beginners start in the wrong place

The role-first framework

How to build proof

Certification strategy

Weekly checklist

How to Build a Simple IT Portfolio Without a Job Yet

The problem

Why this matters now

The practical framework

What beginners often get wrong

A better path

Example roadmap

What to do this week

How to tell it is working

A realistic note on pace

Turn your non-IT experience into an asset

Where SHIFT 2 IT fits

Final thought

Key takeaways

What Beginners Get Wrong About IT Certifications

The problem

Why this matters now

The practical framework

What beginners often get wrong

A better path

Example roadmap

What to do this week

How to tell it is working

A realistic note on pace

Turn your non-IT experience into an asset

Where SHIFT 2 IT fits

Final thought

Key takeaways