Introduction
I’ve been building frontend applications professionally for over a decade. Enterprise-grade platforms, applications used by thousands of people managing fleets, tracking terminals, running loyalty programs. I’ve led teams, mentored juniors, architected systems, written the kind of code that gets studied in code reviews rather than just passing through them.
And yet, sitting here in present, I am being quietly nudged — sometimes less than quietly — toward spending six to eight months and a non-trivial amount of money acquiring certificates for technologies I have been using professionally for years.
I want to write about this honestly. Not as a rant, because I don’t think the people who created certification programmes are villains. But as an observation about something that has shifted in the industry, that is having a real cost on experienced developers, and that is worth examining before it becomes even more entrenched than it already is.
How It Used to Work
Cast your mind back ten, maybe fifteen years. The interview process for a frontend developer looked something like this: you’d have a technical conversation, maybe a coding exercise, you’d show some work you’d done, and someone who knew the technology would assess whether you understood it. The conversation would naturally reveal depth or its absence. A developer who had actually built things with Angular or React for three years would demonstrate that in thirty minutes of conversation with someone who had also built things with Angular or React.
Nobody asked for a certificate. The idea would have seemed odd. You either knew the technology or you didn’t, and the interview process was designed to find out which.
I went through multiple hiring cycles in that era. My resume listed the projects I’d worked on, the technologies I’d used, the scope of the work. A portfolio site or a GitHub profile was considered a strong addition. Interviewers asked about architectural decisions I’d made, problems I’d debugged, trade-offs I’d navigated. The assessment was fundamentally about what I’d actually done.
That era is not completely gone. But it is eroding, and the erosion is being driven by a cultural shift that has real consequences for real people.
When Certificates Started Appearing
The rise of online learning platforms — Coursera, Udemy, LinkedIn Learning, Google Career Certificates, AWS certifications, and a dozen others — was genuinely valuable. It democratised access to technical education in a meaningful way. Someone in a city without strong tech infrastructure, or in a country where formal computer science education was expensive or unavailable, could learn to code through structured online content. That is a good thing. I want to be clear about that before I get to the part that troubles me.
But somewhere along the way, the certificate that was designed to help newcomers prove competence they couldn’t otherwise demonstrate started being used as a screening filter for everyone — including people who already had years of demonstrated competence.
It crept in gradually. First it was a “nice to have” on job descriptions. Then it became a checkbox on applicant tracking systems. Then it started appearing in recruiter emails: “the client prefers candidates with AWS certification” or “they’re looking for someone with a Google Cloud certification.” And now, in some organisations, it has become a hard requirement — an automated filter that a resume doesn’t get past without the relevant credential, regardless of what that resume actually contains.
The Specific Absurdity for Experienced Developers
Here is what this looks like in practice for someone with my background.
I have spent years building Angular applications. I have migrated a legacy Angular codebase to latest. I have led teams of developers through complex Angular projects. I understand Angular’s change detection, its dependency injection system, its compiler, its forms API, its router, its approach to state management — not because I read about them, but because I have debugged them at midnight when a client’s B2B platform was misbehaving.
Now imagine I encounter a role where the screening criteria include a specific Angular or JavaScript certification from a particular provider. To obtain that certificate, I would need to enrol in a course. The course would begin by explaining what a component is. What ngOnInit does. How to bind a variable to a template. Content that, for me, is as foundational as knowing what a for loop is.
I would spend weeks watching videos that cover material I have been applying in complex enterprise contexts for years. I would complete assignments designed for beginners. I would pay for the privilege of doing this. And at the end, I would have a PDF that a recruiter’s applicant tracking system could process — which is, honestly, what the whole exercise is for.
This is not learning. It is bureaucratic compliance. And it takes real time, real money, and a particular kind of patience that frankly wears thin when you are also doing an actual job.
The Inconsistency Makes It Worse
If at least there were a standardised set of certificates that the whole industry agreed on, the cost would be fixed and predictable. You would know exactly what you needed, acquire it once, and move on.
But that is not how it works.
Different organisations have preferences for different providers. One company wants AWS certification. Another wants Google Cloud. A third has a contract with a specific learning platform and prefers candidates who have completed their courses. Some prefer Coursera-issued certificates. Some respect Udemy certificates, others don’t. Some want vendor-specific certifications that are only available through expensive proctored exams. Some ask for Microsoft Azure credentials. Some want Kubernetes certificates, some want Docker, some want both.
There is no universal currency. The certificate that gets you through one organisation’s filters means nothing to another. Which means that if you are actively job searching across multiple companies simultaneously — as most people in the market are — you are not looking at acquiring one certificate. You are looking at a fragmented landscape of credentials, each with its own cost, time commitment, and renewal schedule, that have limited transferability between contexts.
It is genuinely possible to spend a year acquiring certificates that collectively improve your employability by less than six months of actual project work would have.
What It Actually Costs
Let me be concrete about the cost, because I think it is underestimated.
Time. A serious certification course takes six to eight months if you are doing it while working full time. That is six to eight months of evenings and weekends. That is the time you could have spent building a personal project that demonstrates actual skill. It is the time you could have spent contributing to open source. It is the time you could have spent reading deeply about a technology you want to understand better. Those activities also produce results — arguably better results for your actual development as an engineer — but they don’t produce the specific PDF that the applicant tracking system is looking for.
Money. Platform subscriptions, exam fees, proctoring fees, renewal fees. Some vendor certifications cost several hundred dollars per exam, and some require renewal every two or three years. For a developer who is between roles or in a lower-cost geography, these numbers are not trivial.
Energy. This is the cost nobody talks about. Sitting through beginner content when you are not a beginner requires a specific kind of patience that is separate from the patience required to learn something new. Learning something new is energising, even when it is hard. Being assessed on things you have known for years, in a format designed for people who don’t yet know them, is quietly demoralising in a way that compounds over time.
Opportunity cost. The time spent on certification courses is time not spent on the things that actually make developers better: building things, debugging hard problems, reading thoughtful technical writing, mentoring others, contributing to the broader community. The certificate is a proxy for competence. Pursuing the proxy crowds out time that would have been spent developing the actual competence.
I Understand Why It Happened
I want to be fair to the other side of this, because I don’t think the companies asking for certificates are acting in bad faith.
Hiring is genuinely hard. Evaluating technical competence at scale is genuinely hard. When you receive hundreds of applications for a role and have limited time to screen them, you need some kind of signal that allows you to sort. Certificates are legible signals — they are issued by recognisable institutions, they have a standardised format, and they can be processed automatically. For an organisation that cannot invest hours of senior engineer time into every applicant who makes it past the initial filter, the certificate is a practical tool.
For newcomers to the industry, certificates are genuinely valuable. A developer who is transitioning from a different career, or who learned independently without a formal degree, benefits enormously from a credential that says “this person has covered this material to an assessed standard.” The certificate levels the playing field in a meaningful way when the alternative is having no signal at all. I have no issue with this use case. It is legitimate and the credential serves a real purpose.
The problem is that the same mechanism that helps newcomers prove competence is being applied universally, without adjustment for context. A system designed to say “this person has learned this material” is being used to evaluate people for whom the question is not whether they have learned the material but whether they have demonstrated it at scale over years. Those are different questions, and the same instrument cannot answer both well.
What It Feels Like From the Inside
I want to describe this experience accurately, because I think the people who design hiring processes sometimes do not have a clear picture of what it is like to be on the receiving end.
Imagine you have spent ten years developing a skill. You have applied it across dozens of real projects. You have solved problems with it that the people who wrote the course content have never encountered in a classroom context. You understand its edge cases, its performance characteristics, its failure modes — not abstractly, but because you have lived through them in production environments.
Now you are told that to be considered for a role that uses this skill, you need to demonstrate that you have watched a series of videos and completed a series of exercises designed for people who have never used it before. The implicit message — even if it is not intended — is that your decade of experience is not a sufficient signal of competence. That the credential, which measures beginner-to-intermediate familiarity with the technology, is a more reliable indicator than the career you actually built.
That message is hard to sit with. Not because it produces outrage — it doesn’t, exactly — but because it produces a particular kind of quiet frustration that comes from being measured by the wrong instrument and knowing it.
The Newcomer vs. The Veteran
This is the tension I keep returning to, because I don’t want to be the person who pulls up the ladder after climbing it.
Certificates genuinely help newcomers. They provide a structured path through a technology, they offer external validation that is otherwise unavailable for someone without a portfolio or professional history, and they give hiring teams a legible signal when there is no other signal to read. All of that is real and good.
But the same policy that serves a newcomer well creates friction for a veteran that is disproportionate to any benefit it provides. The veteran is not learning from the certificate course — they are complying with a bureaucratic requirement. The newcomer is building a foundation — the veteran is re-carpeting a house that has been standing for a decade.
A hiring system that cannot distinguish between these two cases — that applies the same credential requirement to the first-year developer and the tenth-year lead — is not a sophisticated system. It is an efficient one. Efficiency and sophistication are not the same thing, and in hiring, the difference matters.
What I Think Would Be Better
I am not arguing that credentials are bad or that structured learning programmes have no value. I am arguing that the way they are being used as universal screening filters is producing bad outcomes for a significant class of people, and that the industry could do better.
Interview for competence, not credentials. A thirty-minute technical conversation with someone who knows the technology well is a more accurate signal of a candidate’s competence than any certificate. It is more expensive, but the cost is worth it. The certificate tells you someone watched the videos. The conversation tells you whether they understand the material.
Treat experience as a credential. A developer who has shipped production Angular applications for eight years has demonstrated competence in a way that a certificate cannot. Applicant tracking systems that filter on credentials rather than demonstrated experience are discarding a significant portion of the most qualified candidates.
If certificates are required, be specific and proportionate. If a role requires cloud infrastructure knowledge and the team is on AWS, an AWS certification is a reasonable requirement because it covers vendor-specific knowledge that experience alone may not address. That is different from requiring a generic JavaScript or Angular certificate from someone with ten years of those in production.
Acknowledge that different providers mean different things. If your organisation has a genuine preference for a specific provider’s certificates, say so explicitly and explain why — rather than maintaining a vague “certification preferred” requirement that sends candidates chasing multiple credentials in different directions.
Where I’ve Landed
I am acquiring some certificates. Not because I believe they will make me a better engineer — I don’t — but because the market has shifted in a direction where they are occasionally required to get through the first filter. That is a pragmatic decision, not a principled one.
But I want to be honest about what the experience is like. Watching introductory content on technologies I have been using in production for years is not stimulating. Paying for that experience adds a particular edge to it. Doing it while also doing an actual job, maintaining a career, and investing in the deeper technical learning that actually matters takes a kind of discipline that starts to feel like it is being spent in the wrong direction.
I think about the juniors I have mentored and the time and energy they are putting into certificates as they build their careers. For them, it makes sense. The certificate is doing real work. But I also think about the experienced developers I know — people who have shipped remarkable things — who are going through the same process not because they need to learn the material but because the form of the credential has become more legible than the substance of the work.
That is a waste of some of the best engineering minds in the industry. And the industry, which is perpetually short of experienced talent, might want to think more carefully about whether the filtering mechanisms it has built are actually selecting for the people it says it wants.
Conclusion
Ten years ago, the work was the credential. The projects you had shipped, the problems you had solved, the code you had written — these were what hiring teams evaluated. That system was imperfect, because imperfect humans ran it. But it measured the thing it was supposed to measure.
Today, the credential is increasingly the credential. The certificate has become the first line of evaluation for many roles, and the work — all those years of actual engineering — has to fight its way into consideration past a filter that was not designed with it in mind.
I understand why this happened. I understand that it serves a real purpose for a real group of people. And I am going to keep acquiring certificates because the pragmatic reality is what it is.
But I think we should be honest about the cost. About the time, the money, the energy, the quiet demoralisation of being asked to prove you can walk by someone who has watched you run for a decade. That cost is being paid, largely in silence, by a lot of experienced developers who are too busy building things to complain about it publicly.
Consider this my small contribution to the noise.