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.
Top comments (0)