Reframe the problem: experience is evidence, not a job title
The single most useful shift you can make when writing your first tech CV is to stop equating "experience" with "a previous job in tech". Employers hiring for entry-level and junior roles already know you may not have held one. What they are really trying to work out is whether you can do the work — and the honest answer to that question lives in the things you have built, not in a job title you do not yet have.
Read that way, "experience" simply means demonstrated, verifiable ability. A working project that a reviewer can open and inspect tells a hiring manager more than a paragraph of adjectives ever could. Your task is not to disguise the absence of a job; it is to make the evidence you do have easy to find and easy to trust.
What counts as real evidence
A surprising amount of what you have already done can sit on a CV as genuine evidence, provided it is real and you can point to it. The strongest candidates for a no-experience tech CV are:
- Personal and side projects — anything you have built for yourself, ideally with a link to the repository or a live demo a reviewer can actually open.
- Open-source contributions — even small, merged pull requests to a public project show you can work within an existing codebase and follow a review process.
- Coursework and capstone projects — a substantial university, college or bootcamp project counts, particularly the capstone you carried from idea to working software.
- Freelance or volunteer technical work — a website for a local charity, a script that saved someone hours, a small tool for a community group. Unpaid does not mean it isn't real.
- Certifications you have applied in practice — a certification is worth listing when you have used what it covers in a real project, not simply because you passed the exam.
The common thread is verifiability. A project with a public repository or a live URL gives a reviewer something concrete to assess. A line that merely asserts you "have experience with X", with nothing behind it, does the opposite — it invites doubt.
A quick test for each item: could a stranger click a link and see the work for themselves? If yes, it belongs on your CV. If the only proof is your say-so, either make it verifiable — publish the repository, deploy the demo — or give it less prominence.
How to write a bullet for a project
Once you have chosen what to include, each project needs describing in a way a hiring manager can quickly grasp. A reliable structure covers four things:
- What you built — a plain description of the thing itself.
- What you used — the languages, frameworks and tools involved.
- What problem it addressed — why it exists, or what it made easier.
- An honest, measurable outcome — but only if a genuine one exists. If it doesn't, describe the work accurately and leave the numbers out.
Compare these two versions of the same bullet:
| Weak | Stronger |
|---|---|
| Built a web app using modern technologies. | Built a recipe-sharing web app in React and Node.js with user accounts and search; deployed publicly, with the code and a live demo linked below. |
| Improved performance significantly. | Reduced page load on the search results view by caching repeated queries, taking it from noticeably sluggish to responsive on my own testing. |
The stronger versions are specific, name the tools, and are honest about the source of any claim. Notice the second one does not invent a percentage — it describes a real improvement in plain terms because no measured figure exists. That reads better than a fabricated "40% faster" that you could not stand behind if asked. For the general method of writing bullets like these — including how to find honest outcomes worth mentioning — see our guide on writing CV bullet points with real evidence.
Not sure whether your CV shows enough evidence? Wallbreak's Analyse CV feature reviews a CV and flags where claims lack supporting detail — the gaps a reviewer would notice first.
Analyse your CVWhat not to do
The whole point of an evidence-led CV is that it holds up under scrutiny. A few tempting shortcuts quietly undermine that, and they are worth naming plainly.
Do not manufacture experience you did not have. In particular:
- Do not invent job titles or dress up a personal project as paid employment at a company that never hired you.
- Do not claim professional scope you did not have — "led a team", "owned the architecture", "shipped to thousands of users" — unless it genuinely happened.
- Do not list tutorials you merely followed as if they were projects you designed and built yourself.
These things get caught. A hiring manager who asks one or two follow-up questions at interview will quickly find the gap between what the CV claims and what you can actually explain — and once credibility is lost on one point, the rest of the CV is read with suspicion. Honest, modest evidence beats an impressive-sounding claim that collapses under a single question.
None of this means underselling yourself. A self-taught developer with three real, well-described projects has a genuinely strong CV. The goal is to present that truthfully and clearly, not to inflate it into something it isn't.
A note on formatting and ATS
This guide is mostly about substance rather than layout, but formatting still matters enough to mention. Many UK employers filter CVs through applicant tracking systems, so a clean, single-column layout with standard headings and real text — not text baked into images — helps ensure your evidence is actually read. Keep it to one or two pages, put your strongest projects near the top, and make links to repositories and demos plainly visible. For the details of what formatting choices genuinely affect how your CV is parsed, see our guide on ATS-friendly CVs for UK jobs.
With the evidence in order and the layout out of the way, the last piece is simply finding roles that are genuinely open to people at your stage — which is often less obvious than it sounds. You can search live UK job listings on Wallbreak to see what entry-level and junior tech roles are actually being advertised right now, and our guide on finding entry-level tech jobs in the UK covers where to look and how to focus your search.
Frequently asked questions
Can I get a tech job with no professional experience?
Yes. Many entry-level and junior roles are aimed at people without a prior job title in tech. What employers look for is demonstrated ability: projects you have built, code they can read, and a clear account of what you did. A CV that shows verifiable work is far stronger than one that simply claims to be a "quick learner".
What can I put on my CV if I have never had a tech job?
Personal and side projects, open-source contributions, coursework or bootcamp capstone projects, freelance or volunteer technical work, and certifications you have actually applied in practice. Each of these counts as evidence when you describe what you built, the tools you used, and the problem it addressed.
Do personal projects really count as experience?
They count when they are real and verifiable. A project with a public repository or a live demo that a reviewer can open gives a hiring manager something concrete to assess. A project mentioned in one vague line, with nothing to look at, carries much less weight.
Should I list every online course and tutorial I have completed?
No. Long lists of courses and tutorials rarely help, and they can crowd out the work that matters. Focus on what you built as a result of learning, not the learning itself. A certification is worth including when you can point to how you have used it in a project.
How do I write CV bullet points for a project?
State what you built, the tools or languages you used, the problem it solved, and an honest, measurable outcome if a genuine one exists. Keep each bullet specific and truthful. Do not invent metrics; a plain, accurate description reads far better than an inflated one that falls apart at interview.