Introduction: That Banking Website Wasn't an Accident
You know the feeling. You're helping someone navigate a website—maybe a banking site like the one described in that Reddit post—and you're stunned. The interface is confusing. Basic functions are hidden. The whole experience feels like it was designed by someone who's never actually used a website before. The original poster spent five minutes just finding how to transfer money. The button was a hovering icon that only revealed its purpose on hover. It's maddening.
But here's the uncomfortable truth that post tapped into: that awful experience wasn't created in a vacuum. It was built, approved, tested, and deployed by professionals who presumably got paid for their work. And they'll likely get hired to do it again somewhere else. This isn't just about imposter syndrome—the quiet fear that you're not good enough. This is about actual, demonstrable incompetence that somehow keeps passing through hiring filters. Let's unpack why this happens and what it means for our industry in 2026.
The Broken Hiring Pipeline: How Bad Developers Slip Through
Let's start with the obvious question: how do people who build terrible products keep getting jobs? The answer lies in a hiring system that's often optimized for the wrong things. In 2026, many companies still prioritize algorithmic puzzle-solving over practical competency. A candidate can flawlessly reverse a binary tree on a whiteboard yet struggle to build a coherent user flow for something as simple as a money transfer.
Resume inflation is rampant. Two years at a big tech company can be spun into "led mission-critical initiatives" when the reality was maintaining legacy code with clear documentation. References are often just friends or sympathetic former colleagues. And portfolio projects? They're frequently tutorials or bootcamp final projects that look slick but have zero real-world complexity or user testing behind them.
The interview process itself is a major culprit. It's disconnected from the daily work. You're not asked to critique a confusing UI or debug a sluggish API response. You're asked to solve contrived problems that have little bearing on whether you'll create the next hovering-email-icon-transfer-button nightmare.
The UX/Disconnect: When Developers Don't Use What They Build
The banking website example is perfect. The transfer function—the core action of a banking site—was hidden behind a non-descriptive icon. This screams a fundamental disconnect. The developers and designers either never considered the user's mental model, or they were building for themselves—tech-savvy people who enjoy discovering hidden features.
This happens when teams are siloed. Backend developers build powerful APIs but have no say in how they're consumed. Frontend developers implement designs without questioning the user journey. And product managers are focused on feature checkboxes, not holistic experience. No one stops to ask: "Would my 40-year-old neighbor understand this?"
Worse, many developers simply don't dogfood their own products. They test in ideal conditions with perfect data. They don't simulate the elderly user on a slow connection, or the stressed person trying to pay a bill before midnight. This lack of empathy translates directly into the sluggish, confusing interfaces we all curse.
The API Integration Blind Spot
This is where our API & Integration category becomes crucial. That slow, sluggish banking website? Its performance is often a backend issue masquerading as a frontend problem. A poorly designed financial transactions API can make any interface feel awful. Developers might build a beautiful React frontend, but if it's waiting 3 seconds for a simple POST request to complete because the API has unnecessary authentication handshakes or bloated data payloads, the user experience is ruined.
Yet, how many full-stack developers are truly evaluated on their API design skills? They're tested on React hooks or Django models, not on crafting a clean, efficient, well-documented RESTful or GraphQL endpoint that a frontend can consume without latency. This skill gap creates systemic slowness. The frontend dev gets blamed for the "slow app," but the root cause is an integration layer built by someone who understood databases but not network performance.
The Experience Paradox: How Bad Work Begets More Work
Here's the ironic twist: building bad software can actually look good on a resume. That banking website with the terrible UX? It's probably a massive, complex system. The developer who worked on it can legitimately say they "worked on a high-availability financial services platform handling millions in transactions." It sounds impressive. The hiring manager, scanning for keywords, sees "financial services" and "millions of transactions" and moves the resume to the "yes" pile.
The person who built a clean, simple, intuitive website for a local bakery has a harder story to tell. "I made a site that increased online orders by 30%" is meaningful, but it doesn't have the same corporate sheen. The industry overvalues scale and complexity, often at the direct expense of quality and usability. We reward people for working on big, messy systems, not for making small, excellent ones.
Furthermore, bad code creates job security. A clean, well-architected system needs minimal maintenance. A tangled, undocumented mess requires constant firefighting and "domain experts"—the original developers—to keep it running. Those developers become indispensable, not because they're good, but because they're the only ones who can navigate their own catastrophe. They get promoted, or hired away at a premium to "bring their expertise" to a new company, where the cycle repeats.
What You Can Do: Avoiding the Competency Trap
So, you don't want to be the person who builds the next infamous banking UI. How do you ensure your skills remain sharp and your work remains user-centric in 2026's fast-moving landscape?
First, cultivate product empathy. Before you write a line of code, ask: "Who is this for? What are they trying to achieve? What is their worst-case scenario?" Use your own products in suboptimal conditions. Turn on network throttling in Chrome DevTools to simulate a slow connection. Try to complete a task using only a keyboard. These small acts build the muscle memory of user-centric thinking.
Second, master the integration layer. Don't just be a frontend or backend developer. Understand the entire data flow. Learn how to design APIs that are fast, predictable, and well-documented. Tools like Postman or Insomnia aren't just for testing—use them to prototype and think about the consumer's experience. A great API makes a great UI possible; a bad API makes it impossible.
Third, build a portfolio of clarity, not just complexity. Instead of another TODO app, build a small tool that solves a real, specific problem with exceptional UX. Document your thought process: "Here's the problem, here's how a user thinks about it, here's the API I designed to support that, and here's the simple interface I built on top." This shows holistic skill far better than a generic full-stack project.
Fixing the System: Better Hiring and Evaluation
If you're in a position to hire, you have the power to break this cycle. Stop relying solely on algorithmic tests. Introduce practical, take-home assessments that mirror real work. Give candidates a poorly designed API specification and a vague user story (e.g., "User needs to transfer money between accounts") and ask them to critique the API and propose a better solution. You'll learn more in 90 minutes than you would from a day of whiteboarding.
Ask behavioral questions focused on failure and trade-offs. "Tell me about a time you built something users hated. What did you learn?" or "When have you had to argue for a simpler technical solution against pressure to add more features?" The answers reveal a candidate's self-awareness and priorities.
And for the love of all that is good, include design and code reviews in the interview process. Present a piece of intentionally mediocre code or a confusing UI mockup (like a banking site with hidden buttons) and have the candidate review it. Can they spot the issues? Can they articulate why they're problematic and suggest concrete improvements? This tests the exact skill missing in so many shipped products.
FAQs: Navigating the Messy Reality
Q: Is this just bitterness from developers who are actually suffering from imposter syndrome?
A: It's a distinct but related issue. Imposter syndrome is the feeling you don't deserve your success. The problem we're discussing is observable, low-quality work output that exists despite someone having a job title and experience. You can be competent and feel like an imposter. You can also be incompetent and feel perfectly confident. The banking website is objective evidence of a failure in process and skill.
Q: Don't project managers and product owners share the blame for bad UX?
A: Absolutely. This is rarely a single developer's fault. It's a systemic failure. However, a competent developer has a professional responsibility to raise red flags. "This design will confuse users" or "This API pattern will cause performance issues" are critical contributions. The bad developer just implements the ticket without question.
Q: How can I, as a junior developer, avoid learning bad habits in a dysfunctional team?
A: Be a critical consumer of your own codebase. Read books and articles on clean code and good API design (Clean Code by Robert Martin) to build your own internal benchmark. Contribute to open-source projects to see how other teams work. And don't be afraid to ask "why"—though frame it as seeking to understand the trade-offs, not as criticism.
Q: What if I'm stuck maintaining a terrible system like that banking website?
A: See it as a learning laboratory. Document its flaws meticulously. Every time you fix a bug or add a feature, try to isolate and improve one small piece of the architecture or UX. Create a "lessons learned" document for yourself. This terrible system is your masterclass in what not to do, which is incredibly valuable knowledge. You can even offer your services as a consultant to help others refactor similar legacy messes.
Conclusion: Building a Better Web, One Intentional Decision at a Time
That awful banking website will probably get a redesign eventually. It might even be done by the same people who built the last one, now with a few more years of "experience" on their resume. The cycle doesn't have to continue this way.
The fix starts with recognition. We need to acknowledge that experience alone isn't a proxy for quality. Ten years of building confusing interfaces is ten years of perfecting bad habits. We need to value the skills that actually matter: empathy, clarity, and the ability to think critically about the entire system, from the database schema to the user's frustrated click.
In 2026, let's be the developers who ask the annoying questions. Let's be the ones who prototype the user flow before writing the API. Let's champion the simple, obvious solution over the clever, complex one. Our neighbors trying to transfer money are counting on us. And honestly, so are we—because we all have to use this stuff, too.
The next time you're faced with a design decision, think of that hidden transfer button. Then build something better.
