Sooner or later you inherit a codebase that makes you wonder if the previous developer lost a bet. I gave candidates exactly that kind of application; circular dependencies, no separation of concerns, a structural mess and asked them to extend it. Their reactions exposed a deeper cultural divide in how developers think about their work.
The initial app was a deliberate train wreck: violations of separation of concerns, circular dependencies, and no real interfaces. It exposed multiple endpoints such as HTTP and SMTP. The task was to add a new JMS endpoint.
The idea was simple. Applicants received instructions written in the voice of a business owner. It wasn’t a trick question or a strict feature-delivery test. Yes, they had to add the endpoint, but the real question was whether they’d confront the underlying mess. The framing made it clear they had full authority; the previous developer had vanished with his girlfriend, and nobody else was touching this code. They were inheriting the whole thing.
Feedback
I ran this exercise inside a Fortune 500 team. One pattern I saw immediately was defensiveness. Some felt judged. That was never the point. The goal was to understand how each developer thinks when they inherit a broken system.
The real question is simple:
Do you recognize the problems? And do you feel empowered to fix them?
Do you feel ownership of the whole application, or do you only feel responsible for the wording of the ticket?
The sharpest feedback came from capable developers who had spent years in cultures where they were actively discouraged from taking broader responsibility. They were rewarded for clearing tickets, not for improving architecture. They weren’t wrong. Many companies punish initiative unless management explicitly orders it, and as you know, management never does.
The lesson for me was that the reluctance wasn’t a lack of skill or values. It was learned behaviour. People internalize the norms of their past workplaces.
So the test works, just not in the way some expected. It reveals how a developer believes software development should operate. Do they wait for perfect requirements? Or do they roll up their sleeves and improve the area they’re working in?
Refactoring Nightmares
Since I’ve made such a strong case for taking ownership, it’s worth admitting the danger. Sometimes you spot a pattern in one class and realize the entire codebase is built on the same mistake. Fixing it “properly” means touching half the system.
This is where discipline matters. Pride in craftsmanship is good. Accidentally triggering a month-long refactor because you changed one function is not.
Developers can fall into this trap easily. I’ve seen people disappear for weeks, only to emerge with one enormous commit and a merge conflict from hell. Feature branches have the same risk; leave them running too long, and you’re basically refactoring in the dark. Merging daily avoids this, but I digress.
The point is that architectural improvements must be balanced with delivering value. Nobody is suggesting you go rogue and rebuild the world. But when you’re working in a part of the codebase, keep it clean. Use simple patterns. Avoid piling on more chaos. That’s the level of stewardship that matters.
Be a Senior
For me, seniority isn’t about wizard-level coding skills. It’s about responsibility.
A junior has little responsibility. They get clear tickets and follow the patterns they see. Intermediates work independently and start taking responsibility for local quality. Seniors go wider. They feel accountable for the entire system and the people working on it. They mentor. They think about longevity. They make the call when something needs refactoring and when it doesn’t.
This picture matters because the best indicator of senior-level thinking is the willingness to take broad responsibility. That’s what I’m actually testing for. Technical skill matters, but mindset matters more.
Seek broad experience. It shapes not only what you know, but how you carry the responsibility that comes with being a senior.
Top comments (0)