DEV Community: Andreas-Christian Hetzl

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

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

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.