I Have Projects. Why Do I Still Look Inexperienced?
This is the question I hear most often, and it is almost never asked by someone who hasn't tried. It's asked by people who did everything they were told — the courses, the projects, the certifications — and still read as a beginner to anyone who opens their GitHub. The answer is not that you need more. It's that the part of you worth hiring is currently invisible. This essay is about making it visible, and the exercises save in your browser as you go.
You can't even tell what's wrong. A rejection for missing a certification is at least actionable. Silence from a portfolio you worked months on tells you nothing — so you assume the problem is volume, and you start another project. Which is how people end up with eight repositories and the same feeling.
Let me start with my own route, because it matters for what follows. I was a geologist. Then a data analyst. Then an AWS student in a training programme in Dorset. Then a mentor. Roughly five years, end to end. People hire me now — not because I finished tutorials, and not because I can list tools. They hire me because they have seen me make a call, explain why, and be right often enough to be trusted with the next one.
That is the whole difference, and in 2026 it has become sharper than it was when I started. A working application is no longer scarce. Across more than 17,000 developers in Stack Overflow's 2026 survey, 83% use at least one AI tool at work [1]; in Google's DORA study of nearly 5,000 technology professionals, 90% use AI as part of their work [2]. The artefact is cheap now. What remains expensive is the person who can tell whether the artefact is any good.
Read those four numbers together and the hiring problem writes itself. Nearly everyone is using the same tools. Engineering leaders say this has made technical skill harder to assess — 71% of 400 of them, surveyed across the US, India and China [3]. Developers agree the assessments are easier to game [4]. And the single largest group of developers says it trusts AI output only when it can easily verify it [1]. That last one is not a complaint about AI. It is a description of the job.
Experience is not what you built. It is what you noticed, what you changed, and what you can explain. A portfolio that shows only the built thing is showing the one part of the work that is now commodity.
Why “I used Lambda” doesn't read as experience
Most portfolios are organised around tools. They say: I used Lambda. I used Terraform. I used Docker. I used GitHub Actions. I used Kubernetes. That sounds technical, and it is — but technical is not the same as experienced, and the difference is one word that appears in a reviewer's head every single time:
Yes, but why?
Why this architecture? Why that service and not the obvious cheaper one? Why this much complexity for this much traffic? A tool list cannot answer any of those, because a tool list is a record of what was available, not what was chosen. And a reviewer who can't find a choice has no way to distinguish you from the tutorial you followed.
“Built a serverless API with Lambda and API Gateway.”
“Used Terraform for infrastructure as code.”
“Implemented CI/CD with GitHub Actions.”
“Deployed to AWS.”
Notice what the stronger versions have in common. Not better technology — the same technology, with the thinking attached. Every one of them contains an alternative, a reason, and a cost. That is the grammar of experience, and it is learnable in an afternoon on projects you have already built.
Open your best project's README. What does the first paragraph actually lead with?
Start from a problem, not a service
“I want to use Lambda” is not a project idea. It's a shopping decision. Compare it with these:
- A small clinic loses bookings every time its website goes down.
- A founder needs to publish content faster than her agency can turn it around.
- A growing app is spending more on its staging environment than on production.
Each one forces decisions, because each one has a constraint attached — availability, speed, money. That is the moment a project stops being a tutorial and starts being evidence. And the easiest place to find real constraints is the job adverts for the role you want: they are companies describing their problems in public. I've written the long version of how to read them in Read Between the Lines — the five signals, and two exercises for extracting the problem behind the tools list.
One caution, because this is where people over-correct. If you already have projects, you very probably do not need a new one. Everything in the rest of this essay can be applied to a repository you finished months ago, in evenings, without writing a feature. If you do want the full arc of taking one system through six honest versions, that's Build One Project That Grows Up. This essay is the other half: making the judgement inside what you already have legible to someone else.
Where you overruled the AI
This is the section I would most like you to act on, because it is the newest and almost nobody is doing it yet.
In 2026, pretending you don't use AI is pointless and slightly suspicious. Use it. Let it scaffold, let it suggest, let it save you the boilerplate. But understand what that means for your portfolio: the generated artefact proves nothing about you, because the reviewer can generate the same artefact in ninety seconds. The proof moved. It is now in the gap between what the model gave you and what you shipped.
Anyone can show what a model built. Only someone with judgement can show where it was wrong and how they knew. Your override log is the single most defensible artefact you can own in 2026 — and it costs you nothing but the discipline of writing things down as they happen.
This is not a contrarian position; it is roughly what the profession already reports about itself. In Stack Overflow's 2026 survey the largest single answer on trust — 48%, far ahead of anything else — was “I trust it when I can easily verify the output” [1]. DORA found 30% of respondents reporting only “a little” or no trust at all in the quality of AI-generated code [2]. The UK's Skills England assessment describes the same movement at the level of whole roles: a shift “away from routine coding and testing tasks towards oversight, assurance, judgement, and communication” [5]. Verification is the work now. A portfolio that shows none of it is a portfolio of the part that got automated.
Keep an override log
Four lines, written at the moment it happens, because you will not remember it next week. Keep it in the repository — `docs/overrides.md` is fine.
## 2026-10-02 — S3 bucket policy
**Suggested:** a bucket policy with `"Principal": "*"` and a comment saying to
restrict it later.
**Why I rejected it:** “later” is how public buckets happen. The uploader is a
single Lambda, so the principal is knowable today.
**What I shipped:** the execution role's ARN as the principal, `s3:PutObject`
only, scoped to the `incoming/` prefix.
**How I knew:** I'd read the Well-Architected security pillar's least-privilege
guidance, and I checked it with `aws s3api get-bucket-policy-status`
(`IsPublic: false`).Six of those and you have something no certification can give you and no model can write on your behalf: a documented record of you being the safety mechanism. It is also, in my experience, the easiest interview material you will ever carry, because every entry is a story you have already rehearsed by writing it.
Write the decision down while you still remember it
The override log is a special case of a much older habit. In November 2011 Michael Nygard published a short article proposing that teams record architecture decisions as small dated documents kept beside the code [7]. The format has barely changed in fifteen years, which tells you something about how well it works.
For a portfolio, four lines are enough: what I chose, what I rejected, why, and what it cost me. That last line is the one people skip, and it is the one that proves the decision was real — because a choice with no cost was not a choice, it was a default. Cost can be money, speed, complexity, security, flexibility or your own time.
I've written the fuller version of this, including the “what would change my mind” line that makes a decision record interview-proof, in the v3 section of Build One Project That Grows Up. The short instruction: pick the three biggest choices in your existing project and write them up tonight. You still remember the reasoning. In three months you won't, and the decision will have quietly become a default again.
Show the money and the risk
Most junior portfolios stop at “it works”. Reviewers care about two things beyond that, and both are cheap to add to a project you already have.
What it costs. A number, per month, even a rough one. Not “it's on the free tier” — what would it cost at ten times the traffic, and which line item would grow fastest? Put it in the README. I have watched this single sentence change how an interviewer talks to a candidate, because it moves you from someone who builds things to someone who can be trusted with a budget.
What could go wrong. A short, honest risk note. Who can access what. What is logged and what isn't. What you'd tighten before real users touched it. You are not claiming the project is secure — you are demonstrating that you know what questions a secure system has to answer, which is the actual skill.
If you want a structure rather than a blank page, AWS publishes one free and almost nobody in a portfolio uses it. The Well-Architected Framework's six pillars — Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization and Sustainability [8] — make a perfectly good six-heading review of your own project. One honest paragraph per pillar, including the ones where the answer is “not addressed, and here's why that's acceptable for this workload”.
The part that only shows up when it breaks
Building when things go well is table stakes. Responding when they don't is where judgement becomes visible, and it is the single fastest way to make an old project interesting again — because you don't need to write a feature, only to break one and document what happened.
Kill an instance. Revoke a permission the app needs. Feed it malformed input. Point it at a dependency that times out. Then write up five lines: what failed, how you noticed, how you investigated, how you fixed it, and what you changed afterwards so it fails better next time. The last line is the one hiring managers read twice.
Three deliberate failures, with notes, is an afternoon's work and converts a static repository into one with a history. The longer treatment — including what to put on a dashboard and which alert is worth having — is the v5 section of Build One Project That Grows Up.
How judgement actually grows
Judgement isn't a personality trait that some people are issued with. It is a by-product of making decisions and then looking at them honestly. Four habits built mine faster than anything else, and all four are free.
Ask: what am I giving up?
Compare two designs before choosing one
Go back to work you did six months ago
Explain your reasoning to another person
Do not read this and conclude that you need to build more. That instinct is the thing keeping you stuck — it's what turns four shallow projects into eight. You almost certainly have enough built. What you don't have is the record of you thinking, and that is written, not coded.
Your turn: the three questions
Take the last project you built — not a new one — and answer these three. Out loud, then in writing, then in the README.
The goal isn't to show that you built something. It's to show that you can be trusted to build the next thing.
If you have ever thought “I have projects, why do I still look inexperienced?” — this is the shift. Not more building. More visible judgement. And the happy part of that answer is that it is the cheapest work available to you: no new stack to learn, no course to buy, no months of evenings. The evidence is already in your head. It just hasn't been written down where anyone can read it.
Want to know which evidence is missing for your target role?
Which decisions matter, which gaps to close first, and what to write up before you apply — that depends on the role you're aiming at and what your CV already proves. That's the free Orientation Plan: a written, personalised plan, reviewed personally and delivered within 48 hours. No card required.
Sources
Every figure above was checked against its primary source. Where a statistic comes from a narrow or self-selecting sample, the note says so — a number with an unstated scope is not evidence.
- [1]83% of developers use at least one AI tool (n=17,464); on trust, the largest single answer — 48% (n=14,304) — was “I trust it when I can easily verify the output”. Stack Overflow Developer Survey 2026, AI section. 30,903 respondents across 169 countries. survey.stackoverflow.co/2026/aiverified
- [2]90% of respondents use AI as part of their work; 30% report only “a little” (23%) or “no trust at all” (7%) in the quality of AI-generated output. DORA / Google Cloud, State of AI-assisted Software Development 2025. 4,867 technology professionals across 100+ countries. services.google.com/fh/files/misc/2025_state_of_ai_assisted_verified
- [3]71% of engineering leaders say AI is making technical skills harder to assess; 62% of organisations still prohibit AI use in technical interviews. Karat, “Engineering Interviews in 2026”, January 2026. Survey of 400 engineering leaders in the US, India and China; fielding dates not published. karat.com/engineering-interview-trends-2026/verified
- [4]76% of developers say AI makes gaming an assessment easier; 96% say problem-solving should matter more than memorisation. HackerRank 2025 Developer Skills Report. 13,000+ respondents across 102 countries — developer sentiment, not employer practice. hackerrank.com/reports/developer-skills-report-2025verified
- [5]A shift “away from routine coding and testing tasks towards oversight, assurance, judgement, and communication”. Skills England and the Department for Work and Pensions, Sector Skills Needs Assessment — Digital and Technologies, 1 June 2026. A UK desk assessment of existing evidence, not a survey — it carries no sample. gov.uk/government/publications/skills-england-annual-skills-verified
- [6]35% of organisations had at least one hard-to-fill AI vacancy; the report's key finding names lack of work experience (31%) and insufficient technical skills (30%) as the leading reasons. DSIT, AI Labour Market Survey 2025, published January 2026. Small self-selecting sample: 119 UK organisations responded of 3,940 approached (3%), and the reasons sub-sample is 64. gov.uk/government/publications/ai-labour-market-survey-2025-verified — treat the sample as indicative, not representative
- [7]The origin of the Architecture Decision Record. Michael Nygard, “Documenting Architecture Decisions”, 15 November 2011. cognitect.com/blog/2011/11/15/documenting-architecture-decisverified
- [8]The six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization and Sustainability. AWS Well-Architected Framework, current version November 2024. docs.aws.amazon.com/wellarchitected/latest/framework/the-pilverified