DEV Community: Andreas-Christian Hetzl

IT Support Interviews: Explain Your Next Check

Andreas-Christian Hetzl — Tue, 08 Sep 2026 18:28:26 +0000

A practical walkthrough for answering a troubleshooting question without guessing, overclaiming, or reaching for an unsafe fix.

"An employee cannot access a shared folder. What do you do?"

There is a temptation to answer with a tool: check permissions, reset an account, run a command. But the question has not yet told you whether the folder is missing, the connection fails, or the user receives an access error.

A command is not a diagnosis. A confident guess is still a guess.

For a first IT support interview, practise explaining what you would check next and what its result would mean. That gives your technical knowledge a structure without pretending you already know the environment.

First, distinguish recall from investigation
Start with an observation, not a change
Walk through the new evidence
Use a compact decision note
Handle an unfamiliar tool honestly
Keep real experience separate from hypothetical answers
Rehearse with a change of direction
Final thought
Key takeaways

First, distinguish recall from investigation

If the interviewer asks for a definition, give one. If you do not know it, say so precisely. A long troubleshooting speech is not a substitute for knowing a basic concept.

A scenario question is different. It may require you to establish the missing context before a proposed action makes sense. Microsoft explicitly encourages candidates to clarify and explain their thinking in its interview tips. Do not assume every employer uses the same assessment approach.

Practise switching between a short factual answer and a reasoned investigation. Both matter. The goal is not to turn every answer into a five-minute lecture; it is to make each sentence useful to the question you were asked.

Start with an observation, not a change

For the shared-folder scenario, a useful first response is:

I would ask for the exact error and affected folder, whether the task worked before, and whether anyone else is affected. I would clarify the business impact before assigning a priority through the team's process.

That opening leaves several possibilities available. It does not prematurely turn the incident into an account problem.

Microsoft's support-scoping questions distinguish the reported behaviour from speculation about its cause. The article is product-specific; this interview exercise applies that distinction to a fictional support request.

You do not need to ask every conceivable question at once. Start with the questions that separate materially different paths. "What is the exact error?" usually gives the conversation more direction than a recital of everything that could ever fail in a network.

Walk through the new evidence

Suppose the interviewer says: "The error is Access denied. Only this employee is affected, and they changed teams yesterday."

You now have a reasonable avenue to investigate. You still do not have proof that adding permissions is the right action.

Observation: the person reports an access error after a team change.

Hypothesis: their authorised access or relevant group membership may have changed.

Next check: inspect the documented request and access process, using only the tools and information permitted for your role.

Boundary: determine the authorised approver before proposing an access change. Do not copy a colleague's rights simply because their folder opens.

Outcome check: after any approved resolution, ask the employee to retry the original task and record the actual result.

This is a reasoning exercise, not an instruction to inspect a real company's systems without permission. In an interview, state which information you would need and ask whether the scenario allows you to check it.

Use a compact decision note

A useful rehearsal aid is a small note with five prompts:

Observed: What is actually happening?
Unknown: What must I clarify before acting?
Next check: What would this tell me?
Boundary: Who must approve or take over?
Follow-through: How will I verify and communicate?

This is an original practice aid, not a certification methodology. Do not memorise the labels as a performance. Use them to notice missing reasoning when you review your answer.

For example, "I would check the account" is incomplete until you can explain which aspect you mean and how it would affect your next decision. "I would escalate" is incomplete until you explain the information you would pass on and what the affected person should expect next.

The note should become shorter as you get better at the conversation. You are building a habit of connecting evidence to action, not an obligation to say five things before the interviewer can speak again.

Handle an unfamiliar tool honestly

You may understand the issue but have no experience with the employer's ticketing system or administration console. Separate those two facts.

Try: "I have not used that console. I understand the purpose of the access check, but I would need the team's runbook and appropriate access before carrying it out."

That is more accurate than either claiming proficiency or deciding that all your previous learning is irrelevant. It also gives the interviewer something specific to follow up on.

If you cannot remember a value or a command option, do not invent it. Say what you would verify in the documentation for the relevant version. Avoid proposing a search that would expose an internal hostname, customer record, password, or confidential log to a public service.

Being willing to check is useful. Knowing what you need to check is better.

Keep real experience separate from hypothetical answers

"I would" and "I did" are not interchangeable.

For a real example, STAR provides a situation, task, action, and result structure. Describe your own contribution; never turn the practice incident in this article into your employment history.

A home exercise can be valuable if you label it accurately. Explain what you controlled and what you could not test. A previous non-IT job can also provide a relevant example of communication or prioritisation without being renamed an IT support role.

Be especially careful about results. "The next shift had a complete handover" may be the truthful outcome. "I improved operational efficiency by 40%" is not an upgrade unless you actually measured that result and can explain it.

Rehearse with a change of direction

Ask a practice partner to change one detail after your opening answer. Perhaps the issue affects everyone, not just one person. Perhaps the error is different from what you first understood.

Then pause and say what changed in your reasoning. Do you need to revisit the initial hypothesis? Does the wider impact affect who you contact? What investigation is now less useful?

Do not treat the first hypothesis like something you must defend. A better answer can begin, "With that additional information, I would change my next check."

Afterwards, review three things: whether you used the new detail, whether you proposed a change before checking authority, and whether you explained how the person would receive an update. This is a practice review, not a prediction of an employer's interview score.

Final thought

Your first support interview does not require you to invent a history of solving enterprise incidents. It does require you to be clear about your actual knowledge and the work still ahead of you.

Make the next check understandable. Make the boundary explicit. Make the handover useful. Those are concrete things you can practise before you know the answer to every question.

Key takeaways

Definitions and troubleshooting scenarios need different kinds of answers.
Separate what was observed from what you think might explain it.
Describe the purpose of a check before naming a tool.
Never imply that you can grant access without the required approval.
Let new evidence change your answer.

Andreas-Christian Hetzl writes SHIFT 2 IT for people building a realistic path into IT. Find the broader roadmap at SHIFT 2 IT. Technical confidence is worth building one explainable decision at a time.

How to Build an IT Study Plan Around a Target Role

Andreas-Christian Hetzl — Tue, 25 Aug 2026 15:34:51 +0000

Turn ten job descriptions into a weekly schedule you can actually follow.

The problem

You have picked a target role. Good. Now what? Most people go straight to a course catalogue and pick whatever looks closest, then study in whatever order the videos happen to be numbered. Three months later they know a lot about some things, nothing about others, and still cannot tell whether they are ready to apply. The missing piece is not motivation or material. It is a plan built from the role itself.

Why this matters now

There has never been more free IT learning material, and that is exactly the problem: with unlimited input, the scarce resource is your attention and the order you spend it in. Workforce research such as the WEF Future of Jobs report keeps stressing specific, demonstrable skills over general study, and community data like Stack Overflow's developer survey shows how normal self-directed learning has become. The people who get hired are rarely the ones who studied the most; they are the ones who studied the right things in an order that produced proof along the way.

The practical framework

A study plan is just a job description, translated. Five steps:

Collect ten real postings for your one target role, in your actual market.
Tally the skills. Every time a skill appears, add a mark. You will end up with a short head (skills in eight or nine postings) and a long tail (skills in one or two).
Cut the tail. The head is your syllabus. The tail is noise for now.
Order by dependency, not by interest. Some skills are prerequisites for others: operating systems and networking usually come before cloud services; identity before security tooling. Learn the ones other things stand on first.
Assign each head skill a week and an artefact. One skill, one week, one small piece of proof. That is the plan.

The output should fit on a single page. If it needs a spreadsheet with tabs, it is a wish list, not a plan.

What beginners often get wrong

Building the plan around courses instead of skills. A course is someone else's ordering of a topic, designed to be complete rather than to match your target role, so following it end to end means studying plenty you do not yet need while missing things the postings actually asked for. Use courses as a resource for a skill on your list, not as the list itself.

The second mistake is planning by hours instead of outputs. 'Two hours of study a day' measures attendance; 'one documented artefact this week' measures progress. Only one of those survives contact with a busy week, and only one of them is visible to an employer.

A better path

Write the plan where you will see it, keep it to one page, and treat each week as a closed loop: learn just enough about the week's skill to attempt something, do the thing, write up what happened in a few sentences, then move on. Do not aim for mastery in week one; aim for a defensible first pass you can deepen later.

Review the plan every two weeks against fresh postings. Job requirements drift, your understanding of the role sharpens, and a skill that looked essential in week one sometimes turns out to be rare. Adjusting the plan with evidence is a sign it is working. Rewriting it from scratch every fortnight because you found a new roadmap graphic is not.

Example roadmap

What the tally looks like in practice for an IT support target (your market will differ):

Appears in nearly every posting: Windows and basic troubleshooting, user account and access handling, ticketing and clear written communication, basic networking.
Appears in about half: a cloud platform's fundamentals, remote support tooling, hardware basics.
Appears once or twice: a specific vendor product, scripting, a niche compliance term.

That gives you roughly six to eight head skills. At one skill and one artefact per week, that is a two-month plan with proof attached, and a defensible answer when an interviewer asks why you learned what you learned.

What to do this week

Collect ten real postings for one target role.
Tally how often each skill appears.
Keep the head, cut the long tail.
Order the head skills by dependency, not by interest.
Give each skill one week and one artefact.
Keep the whole plan on a single page.
Re-check it against fresh postings every two weeks.

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.

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

A study plan built from real postings does two things a course catalogue cannot: it tells you what to skip, and it tells you when you are ready to apply. Let the role write your syllabus, and studying stops feeling like an endless queue and starts feeling like progress toward one specific job.

Key takeaways

Build the plan from job postings, not from a course catalogue.
Tally skills; keep the head, cut the long tail.
Order by dependency, not by what looks interesting.
One skill, one week, one artefact — on a single page.
Re-check against fresh postings every two weeks.

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.

Why Beginners Should Not Start With Random Certifications

Andreas-Christian Hetzl — Thu, 06 Aug 2026 18:50:49 +0000

A certificate chosen before a target role is a bet placed before you know the game.

Cross-post: publish on Hashnode first, then set this article's Canonical URL (the canonical_url front matter above, or the Dev.to field) to the Hashnode URL.

The problem

The most common first move for someone entering IT is to buy a certification — usually the one a forum recommended most loudly — and start studying that night. It feels productive and official. But a certificate chosen before a target role is a bet placed before you know the game, and it is one of the most expensive false starts in an IT transition: real money, three months of evenings, and often a badge that no job you actually want asks for.

Why this matters now

Certifications still matter, and providers like CompTIA and Microsoft keep their exam objectives public and current. But the marketing around them is louder than ever, and it pushes beginners to buy first and think later. Workforce research such as the WEF Future of Jobs report keeps pointing to demonstrable, role-specific skills as what employers reward — and a random certificate proves neither a role nor a skill you can show. As AI makes it trivial to grind practice questions, 'passed a popular exam' says less about you than it used to; what you can demonstrate for a specific role says more.

The practical framework

The fix is not 'never get a certification'. It is to move it from first to fourth. The order that works:

Target role. Pick one realistic first role you could reach in 6-12 months.
Baseline skills. Read ten real job descriptions for it; the repeated skills are your syllabus.
Proof. Turn each core skill into a small artefact an employer can see.
Certification. Now choose the exam whose objectives match that role and back it with the proof you already built.
Positioning. Rewrite your CV and profile in the role's language.

A certificate at step four confirms skills you can already partly demonstrate. A certificate at step one is a guess dressed up as progress.

What beginners often get wrong

Choosing the certificate by popularity or marketing instead of by a job. The most-recommended exam on a forum is optimised for forum upvotes, not for your local market or your target role. Two costs follow. First, opportunity cost: the months and money spent on an unaligned exam are months not spent choosing a role and building proof. Second, sunk cost: once you have paid, you keep going even after you realise it does not match any role you want. And because you studied to pass rather than to do, the interview still goes badly — a certificate cannot answer 'what do you want to do here, and can you show me?'.

A better path

Spend the first two weeks not buying anything. Choose one target role, collect ten job descriptions, and build your skill list from the words that repeat. Only then look at certifications, and judge each one by a single test: do its published objectives overlap with that repeated list? If yes, it is worth your money; if no, it is a hobby.

This also makes the famous 'which cert first?' question easy instead of agonising. The answer is never universal — it is whichever exam's objectives match the ten postings you are targeting. For broad support roles that is often a vendor-neutral foundation; for cloud-leaning roles, a cloud-fundamentals exam; for networking, a networking path. The role decides, not the marketing.

Example roadmap

What the first month looks like when you resist buying a cert on day one:

Week 1: choose a target role; read ten real job descriptions; write the repeated-skills list.
Week 2: start learning the most-repeated skill and produce one small artefact (a documented lab, a troubleshooting write-up).
Week 3: shortlist certifications whose objectives match your list; pick one.
Week 4+: study that exam with a lab open, turning each objective into proof as you go, so by exam day you have both the certificate and a portfolio.

Same money, same effort — but now aimed at a role instead of a guess.

What to do this week

Do not buy a certification in your first week.
Choose one target role first.
Build a skill list from ten real job descriptions.
Shortlist certifications only by objective-to-job overlap.
Study with a lab open, turning objectives into proof.
Skip any exam no target job actually asks for.

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 are a good fourth step and a poor first one. Choose the role, learn what it needs, build a little proof, and the right certificate becomes obvious — and worth every euro. Start with a random exam and you are paying to postpone the decision that actually matters.

Key takeaways

A certificate before a target role is a guess, not progress.
Move certifications from the first step to the fourth.
Pick a cert only by objective-to-job overlap for your target role.
The right first cert is decided by the role, not by marketing.

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.

The First 90 Days of Learning IT

Andreas-Christian Hetzl — Sun, 26 Jul 2026 18:47:27 +0000

A realistic 12-week structure that turns enthusiasm into visible proof.

The problem

You are motivated now, but motivation fades, and without a structure the first three months of learning IT dissolve into random videos. A realistic 12-week shape keeps you moving and produces proof along the way.

Why this matters now

With more people self-teaching IT, the people who succeed tend to be the ones with a plan, not the ones with the most enthusiasm. A clear 90-day structure, anchored to a target role, turns scattered effort into visible progress you can show employers.

Three months is also about the honest minimum to go from zero to a credible first application, and about the maximum you can run on motivation alone before it fades. So the plan has two jobs: cover the fundamentals a first role actually needs, and leave a visible trail of proof behind you, so that by day 90 you have something to show and not just a browser full of half-watched tutorials.

The practical framework

Twelve weeks, four phases, proof at every step (adjust to your target role):

Phase 1 (weeks 1-3): foundations. Computer and operating-system basics, plus your first documented home lab.
Phase 2 (weeks 4-6): connectivity and identity. Networking and identity basics; two troubleshooting write-ups.
Phase 3 (weeks 7-9): cloud and security hygiene. A cloud fundamentals path plus basic defensive hygiene; annotated screenshots.
Phase 4 (weeks 10-12): proof and positioning. A small script, a learning log, and a CV and LinkedIn rewrite around your target role.

Two rules hold the whole thing together. First, spend roughly 70% of your time doing and only 30% watching or reading: the doing is what sticks and what becomes proof. Second, each phase has one concrete output you finish before moving on, so you are never tempted to restart Phase 1 for the third time because it felt safe. If you can only protect a few hours a week, stretch the calendar rather than skipping the outputs; the order matters more than the dates.

What beginners often get wrong

Consuming content without producing anything, and switching topics whenever the next shiny tutorial appears. Input without output feels like progress but leaves you with nothing to show.

The other classic failure is the 'week 1 forever' loop: restarting the basics again and again because starting is comfortable and finishing is not. Related is tutorial-hopping across three courses at once, which spreads you thin and produces no single completed artefact. The cure for both is the same: pick one path, finish this phase's one output, then move on, even if the output is rough.

A better path

End every week with one small artefact and one sentence of reflection. The artefacts become your portfolio; the reflections become your learning log; together they prove direction and consistency.

A weekly rhythm that fits around a job or family: one short session to learn the week's topic, one longer session to actually build or break something, and fifteen minutes at the end to write up what you did and what confused you. Miss a week? Do not restart, just continue; a plan you can return to beats a perfect plan you abandon. Track it somewhere visible, even a single checklist, so the progress is real rather than remembered.

Example roadmap

Use the four phases above as your 90-day skeleton, and attach each week to the skills your ten target job descriptions repeat. The plan is a shape, not a guarantee; your background and target role will move the emphasis around.

Made concrete for an IT-support target: weeks 1-3 you install an operating system in a virtual machine and write down every step and error; weeks 4-6 you set up basic networking and user accounts and turn two real problems into ticket-style write-ups; weeks 7-9 you open a cloud free-tier account, deploy one small thing, and practise patching and backups; weeks 10-12 you write a short script, tidy your notes into a learning log, and rewrite your CV and LinkedIn around the role. Twelve weeks, one artefact each, and a portfolio that did not exist in January.

What to do this week

Pick a target role before week 1.
End each week with one small artefact.
Write one sentence of reflection per week.
Do not switch topics mid-phase chasing novelty.
Rewrite your CV and LinkedIn in the final phase.

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

Ninety days is enough to build real foundations and visible proof if you trade enthusiasm for structure. The goal is not to finish IT; it is to become a credible applicant for one role.

Key takeaways

Structure beats enthusiasm over 90 days.
Four phases: foundations, connectivity, cloud/security, positioning.
Produce one artefact and one reflection every week.
Anchor every week to your target role's repeated skills.

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 to Put on LinkedIn When You Have No IT Job Yet

Andreas-Christian Hetzl — Thu, 16 Jul 2026 20:40:32 +0000

An honest middle path between hiding your career change and faking experience you do not have.

The problem

Your LinkedIn still describes your old career, and you feel you have nothing 'IT' to put there yet. So you leave it blank or, worse, pretend to be experienced. Both hurt you. There is an honest middle path that shows learning and direction.

Why this matters now

LinkedIn is where a lot of early IT hiring and networking happens, and recruiters search by role and skill. A profile that clearly states your target role and shows real learning makes you findable and credible without pretending to be something you are not.

The mechanics matter: recruiters and hiring tools search by keywords, and those keywords come mostly from your headline, your About section, and your skills. If those say 'experienced barista' and nothing about IT, you are invisible to every search for the role you actually want. And as AI makes generic, inflated profiles cheap to produce, a profile that shows a real learning trail stands out precisely because it is verifiable.

The practical framework

Position for the role you are moving toward while being honest about where you are:

Headline: name your target role plus your honest status. A simple formula is '[target role] in progress | [what you are building] | ex-[old field]', for example 'Aspiring IT Support Specialist | building hands-on proof | ex-hospitality'.
About: two short paragraphs — your transferable background, then what you are learning now — ending with a link to your portfolio. Write it in the first person and keep it human.
Featured: pin your strongest proof — home-lab notes, a troubleshooting write-up, your learning log — so a visitor sees evidence in one click.
Skills: add the skills that repeat across your target role's job descriptions; these are the exact terms recruiters search for.
Activity: post short, honest learning updates, not motivational filler.

What beginners often get wrong

Either hiding (a blank, old-career profile) or faking (implying experience you do not have). Both fail: one makes you invisible, the other unravels in interviews. A third trap is chasing reach with bait — asking people to comment a keyword, or posting hollow motivational quotes — which damages credibility with the exact recruiters and practitioners you want to reach. A career changer's advantage is being real; bait throws that away.

A better path

Show direction and proof. Recruiters do not expect a career changer to have ten years of IT; they want to see that you know your target role and are visibly building toward it. Honesty plus evidence beats inflation every time.

For the Activity feed, a simple rhythm works: once a week, share one thing you learned or built, in two or three plain sentences — what you tried, what surprised you, what you would do next. Comment thoughtfully on posts from people already in your target role; genuine questions open more doors than connection-request spam. Over a couple of months this quietly builds both a record of progress and a small, relevant network.

Example roadmap

A one-evening profile refresh:

Rewrite the headline around your target role and honest status.
Rewrite the About section: background + current learning + portfolio link.
Add three pieces of proof to Featured.
Add the target role's repeated skills.
Schedule one honest learning post for the week.

A quick before-and-after shows the shift. Before: headline reads 'Customer Service Representative', About talks only about the old job, no proof, no target. After: headline reads 'Aspiring IT Support Specialist | building hands-on proof | ex-customer service', About maps that customer-service experience onto IT-relevant strengths and links a portfolio, and Featured shows two real write-ups. Same person, same week — but now findable and believable for the role they actually want.

What to do this week

Rewrite your headline around your target role and honest status.
Add a short About: background, current learning, portfolio link.
Feature three real proof artefacts.
List the repeated skills from your target role.
Post honest learning updates, not engagement bait.

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

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

Final thought

You do not need an IT job to have a credible IT LinkedIn. You need a clear target, honest framing, and visible proof. That combination is what makes a career changer findable and believable.

Key takeaways

Don't hide and don't fake; show direction and proof.
Put your target role and honest status in the headline.
Feature real artefacts, not inflated claims.
Avoid engagement bait; post honest learning updates.

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.

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

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

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

IT Support Interviews: Explain Your Next Check

A practical walkthrough for answering a troubleshooting question without guessing, overclaiming, or reaching for an unsafe fix.

Table of contents

First, distinguish recall from investigation

Start with an observation, not a change

Walk through the new evidence

Use a compact decision note

Handle an unfamiliar tool honestly

Keep real experience separate from hypothetical answers

Rehearse with a change of direction

Final thought

Key takeaways

How to Build an IT Study Plan Around a Target Role

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

Why Beginners Should Not Start With Random 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

The First 90 Days of Learning IT

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 to Put on LinkedIn When You Have No IT 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

How to read a job description like a map

Where SHIFT 2 IT fits

Final thought

Key takeaways

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