There is a piece of advice that circulates endlessly through mentoring conversations, coding bootcamps, and LinkedIn posts aimed at people trying to break into the tech industry. Get certified. Build something for your GitHub. Put together a portfolio. Contribute to open source. Let’s call this “the checklist”.
It’s not bad advice, and it wasn’t bad advice when people started giving it. The problem is that enough people have followed it that it has stopped being advice and started being a floor. The rise of LLMs has only sharpened this, making it far easier to write a polished, tailored CV that hits every mark on a job description, or to spin up a portfolio project. The checklist looks less distinctive than ever. It’s the minimum, not the differentiator.
I see this clearly through my work with CodeYourFuture, a charity that provides free technical training and career support to people from underrepresented backgrounds. The people I mentor there have worked hard to get where they are; some are still learning and trying to land their first role, others are already in the industry and trying to figure out how to progress. What I notice, talking to them, is that the checklist items are rarely what’s holding them back. They have the certifications. They have the GitHub repos. They are doing everything they were told to do, and they are still finding it difficult to stand out. Standing out requires something else, and that thing is not to add another certification to their LinkedIn.
At London Tech Week this year, I listened to speakers from some of the biggest names in the industry. The same hiring wishlist kept coming up: curiosity, adaptability, and the ability to learn. They want evidence that someone can pick up an unfamiliar codebase, work in a different context, shift between problem domains without falling apart. These qualities matter more to them than any specific technical credential.
The difficulty — and every speaker acknowledged it — is that these qualities are genuinely hard to assess from a CV, cover letter, or even a technical interview. A list of certifications tells you what someone has been taught. It does not tell you how they think, how they respond when things are unfamiliar, whether they show any intellectual curiosity outside of their day-to-day work. That gap between what hiring managers want and what traditional methods can surface is the real problem. The checklist was never designed to solve it.
Work on code you didn’t write
Closing that gap starts with contributing to an open source project you did not build. Not a project you started yourself or one where you know all the context. Find something unfamiliar, read the code, understand how decisions were made without being there when they were made, and then do something useful. This matters because it puts you in a situation that is much closer to what actual employment looks like: navigating someone else’s architecture, working under review from people who do not know you, working in legacy codebases with contradictory coding styles and patterns. It is a concrete demonstration that you can learn a system you did not design, which is most of the job.
Write from confusion
The next thing is to develop a point of view and put it somewhere public. This does not mean writing tutorials. Tutorials are another form of the checklist; plenty of people write them and they tend to blur together. What is rarer, and more useful, is writing honestly about confusion. Not the resolved version of a problem, but the experience of being confused, the specific thing that did not make sense, and then exactly what clicked and why. That specificity is what gets remembered. There is also a practical reason to write while you are still close to the confusion: some senior engineers may have forgotten what it genuinely felt like not to understand something. That memory is an asset. Use it before it fades.
Speak so non-engineers can follow
The third thing is the hardest to fake and the easiest to neglect: learn how to translate technical decisions for people who didn’t make them and don’t share your frame of reference. Not dumbing things down; that framing is condescending and also inaccurate. Translation is a different skill, one that requires you to understand what you are trying to communicate well enough to find a different path to it. Many early-career engineers treat this as something to develop later, once they have more experience, once the technical foundations are solid. It is not a later skill. It is a foundational skill, and building it early, before you are comfortable, is considerably easier than retrofitting it later. Junior engineers naturally default to speaking in technical terms when they are around other technical people, and the longer that default goes unchallenged, the harder it becomes to break.
Find work with real stakes
There is one more route, and it is among the most underrated for early-career engineers: find technical work to do for free. Volunteering. In the UK there are platforms built precisely for this, such as reachvolunteering.org.uk, doit.life, and CodeYourFuture (codeyourfuture.io). I am sure similar platforms and organisations exist in other parts of the world, and many charities would be willing to accept help from people working remotely. What makes this different from a side project is not the technical challenge — it’s that the stakes belong to someone other than you. The constraints are real, the consequences of poor work land somewhere outside your GitHub profile, and the decision to do it at all is entirely yours. It does something good for society at the same time, which is reason enough on its own. Hiring managers tend to look favourably on volunteering work; choosing to take on work like this when nobody asked you to signals exactly the curiosity and initiative they are looking for, in a way the checklist cannot.
None of this replaces the checklist. The checklist gets you in the room, and it was never meant to do more than that. Everything else here is a behaviour, not a credential — something you demonstrate rather than something you claim. Credentials can be generated now. Behaviour has to be lived. That is the thing AI can’t fake, and it is the thing that makes someone worth keeping around.
Top comments (2)
The collapse of the traditional checklist is a straightforward consequence of credential depreciation. When the marginal cost of producing a tailored CV, a polished repository, or a CRUD side project falls to zero, the signaling value of those artifacts drops with it. Hiring managers are not being unreasonable; they are reacting to an information environment flooded with synthetic competence.
What makes navigating unfamiliar legacy code a durable differentiator is that it cannot be faked through isolated prompt loops. Real codebases contain contradictory historical decisions, undocumented operational constraints, and fragile boundary contracts. Demonstrating that you can audit someone else's architecture, identify where assumptions break, and ship a targeted fix without expanding the blast radius provides proof of systemic reasoning.
The same dynamic applies to volunteering on projects with external stakes. The moment consequences land on real users rather than a private sandbox, the problem stops being syntax generation and becomes risk management. In an era where code generation is commoditized, the ability to manage uncertainty and own downside risk is the only asset that continues to command an economic premium.
The checklist angle is right, and it maps onto something I keep seeing from the other side: I run AI agents over codebases all day on a VPS, and an afternoon of agent time can now produce the entire checklist — polished repo, tests, README with badges. None of it guarantees the person behind it understands anything. So the floor you describe keeps sinking, and portfolios stop carrying signal faster than most advice expects.
What still carries signal for me is your "work on code you didn't write" section, but in reverse: when I review code someone (or some agent) produced, the tell isn't the code, it's whether they can defend the decisions in it. Why this approach over the obvious alternative. What they'd rip out first under load. That's hard to fake without actually having wrestled with something unfamiliar.
Which makes me wonder about the assessment side: do you think the evidence format itself needs to change too? A recorded debugging session or a substantive issue thread shows the thinking process in a way a finished repo never will, but I rarely see either requested in hiring processes. Curious what you've seen move the needle with the CodeYourFuture folks — did any evidence format work better than the repo?