Broken windows, ownership, and other people's money
Years ago I got interview feedback that I lacked a "fix broken windows" mindset. Here is why that framing breaks down for software that moves other people's money, where real ownership means routing a fix through the framework (code owners, review, staged rollout, audit trail) rather than around it.
A few years ago I applied for a senior front-end role at a neobank for businesses: the kind of platform where a company's accounts, cards, payments and invoicing live, and where a lot of companies run their payroll. Not a two-person startup. A regulated financial platform operating across Europe at real scale. I had wanted to work there for a long time, and I was genuinely excited to be in the process.
Money comes in, money goes out, salaries get paid, tax gets filed, and a business's view of whether it can cover next month depends on the number on that screen being right. This is about as high-stakes as product work gets. A bug in a marketing site is an embarrassment; a bug in a transfer flow or a balance calculation is someone's rent, someone's supplier, someone's audit. The cost of being wrong here is not measured in page views.
The first real conversation was with a recruiter. It was warm and easy. Partway through there was a technical exercise: an interface was shared with me and I was asked to find the bugs in it. I worked through it, called out what I saw, we talked it over, and the call ended on a good note.
A few weeks later the rejection arrived.
The rejection#
The part that matters, lightly redacted:
After reviewing everything with the team, I've decided not to move forward at this time. What we expected to see was stronger signs of ownership and a "fix broken windows" mindset, as well as more experience in coaching or mentoring others with the senior role.
The rest of the note was gracious. It praised my motivation and my product-design background, encouraged me to reapply, wished me well. The tone is not the point. The point is that "we needed to see a fix broken windows mindset" is a specific thing to screen for, and for a company that holds other people's money it is a slightly alarming one.
What "broken windows" actually means#
The phrase comes from The Pragmatic Programmer, which borrowed it from a criminology theory: a building with one unrepaired broken window soon has many, because the visible neglect signals that nobody is watching. Applied to code, it means do not tolerate small rot. Fix the bad name, the dead branch, the flaky test, the stray TODO, the moment you see it, because decay compounds and a codebase that looks uncared-for invites more of the same.
As a personal habit, it is a good one. On my own projects I live by it. The question is not whether tidiness is a virtue. The question is whether "will this person see something broken and immediately fix it" is the trait you select for when the something is part of a payments system.
Why it is the wrong signal at that scale#
An analogy helps. If you see a broken window in your house, you fix it. If you see something that looks broken at an airport, you do not get a screwdriver out. You report it, and someone who understands the systems behind that wall looks into it. That is not a failure of ownership. It is ownership that knows the building is bigger than one person's view of it.
This is a company operating at real scale, and it moves other people's money. That combination is exactly the environment where "I saw it was broken so I fixed it" is not automatically a good sentence.
- The blast radius is somebody's payroll. A well-meant change to a rounding helper, a date boundary, a retry, a currency format, shipped on the strength of one engineer's judgement because it looked broken, is the opening line of a lot of incident write-ups. Around money, the cost of a wrong "fix" is often higher than the cost of the thing being fixed.
- At this size there has to be a framework. Code owners, review, CI, staged rollout, feature flags, change records, an audit trail, sometimes compliance sign-off. That framework is not bureaucracy for its own sake. It is how an organisation that size stops a stream of small changes from compounding into a bad day. If fixing a broken window requires stepping around that framework, the framework is the broken window, and repairing it is the organisation's job, not a mindset to screen candidates for.
- "Ownership" and "route around the process" are not the same thing. Real ownership in that setting means: I notice the problem, I make it visible, I get it an owner and a ticket and a test, I make sure it is prioritised, and I follow it to done. It does not mean I quietly patch something I do not fully understand because leaving it offends my sense of craft.
- A broken-windows culture quietly rewards the wrong reflex. It celebrates the engineer who reaches into an unfamiliar module and changes it, and it can read the engineer who says "this needs an owner, a spec and a rollback plan before anyone touches it" as lacking initiative. Near a ledger, the second engineer is the one you want.
On a side project, "fix it the moment you see it" is discipline. On a regulated payments platform, unreviewed initiative is how the ledger ends up wrong.
The interview was itself a broken window#
There is an irony in being told I lacked process instinct on the strength of a "here is a screen, spot the bugs" exercise. Finding the planted bugs in an interface is a reasonable check of attention to detail. It is not a measure of ownership, of judgement under uncertainty, or of how someone behaves when the right move is to stop and escalate rather than push a change.
It certainly does not measure "coaching and mentoring others," which was the other stated gap. You cannot observe mentoring ability from a bug-spotting task. That signal comes from references, from a structured behavioural interview, from asking for specific stories about people someone has grown. If the rubric included "mentors others" and the loop had no way to test for it, that is a gap in the loop, not in the candidate. It is the same domain mismatch I wrote about in why backend developers should not interview front-end candidates: measuring the wrong dimension, with confidence.
What ownership looks like around money#
| The "broken windows" instinct | What you actually want near a ledger |
|---|---|
| See something broken, fix it now | See something broken, make it visible and get it an owner today |
| Tidy the unfamiliar module while you are in there | Leave a clear report; change only what your task covers and your tests reach |
| Ship the small fix on your own judgement | Small fix, same rules: review, tests, staged rollout, a rollback plan |
| Initiative measured by what you touched | Initiative measured by what you prevented and what you left safer |
| Heroic patching | Improving the framework so the next person does not hit the same window |
None of this argues for learned helplessness or for letting rot sit. It argues that "raise it, own it, route it through the system, see it through" is a more senior behaviour than "fix it yourself before lunch," and that a company built on moving money, of all places, should recognise the difference.
Sometimes the process is the broken window#
Here is where the feedback turns back on the people who wrote it. If a company operating at this scale needs individual engineers to keep reaching outside their boundaries and personally patching things, the engineers are not the problem. Something in the organisation is.
- An issue you raise disappears into a backlog and is never seen again. That is a broken window.
- Nobody can tell you who owns a given part of the platform. That is a broken window.
- Getting an obvious problem fixed means routing around the official process. That is a broken window.
Fixing those is worth far more than coaching people to be heroes who quietly work around the gaps. A company that has to hire for a "broken windows mindset" is telling on itself: it is admitting that doing the right thing there is hard enough to need a personality trait.
The mature version of "no broken windows" is not a workforce that constantly rescues the system. It is a system where the safe path and the easy path are the same path.
"No broken-windows mindset" was probably accurate#
Read plainly, the feedback meant: this person wants a ticket, an owner and a test before touching a money flow. That is true, and I would put it on a CV. In most of software it reads as a mild criticism. In regulated finance it is the job description. A culture that hears "I want a process before I change how customers' money moves" and files it under not enough ownership has its wiring crossed, and it will find out which instinct mattered in an incident review rather than before one.
Afterwards#
I was not discouraged. I kept building, kept shipping, kept working the way I work: fast where it is cheap to be wrong, careful where it is not. Interview feedback tells you what a company values, and this told me plenty. A place that screens for "ownership" with a spot-the-bugs task and then rejects for a missing "mindset" does not have a calibrated view of seniority, whatever the scale.
The reason stuck with me because it named as a weakness the exact instinct you would want in someone working near your money: the reflex to slow down, make the problem visible, and fix it through the system rather than around it. If that instinct disqualifies you from building someone's bank, the problem is not the candidate.