Interview feedback - When Companies Seek Out Pain

TL:DR;

If your framework owns your architecture, you just ain't seasonned enough.

A.K.A When Tools Become the Problem

I recently interviewed with a major bank. Technical directed, during the screening, shared their current (and biggest) pain:

Technical debt (++budget, costly migrations)
That breaks fast features cycles

The cause? Their apps were tightly coupled to specific tools. When those tools change, everything breaks. The irony? Their technical interview focused almost entirely on tool proficiency — Angular, NgRx — rather than engineering fundamentals.

They were litterally looking for a lib operand (like this should help bach code quicker in the times of agents), not an engineer who builds for resilience and maintainability.

Here's my feedback to engineers:

Tools are temporary. Principles are permanent.
Build core code sovereignty. i.e. frameworks on the periphery.
Optimize for adaptability, not just immediate output.

Sometimes what a team wants is exactly what's keeping them in pain.

When Tools Become the Cage: Lessons from an Interview

In many enterprises, engineering teams operate in silos—isolated, inward-looking units that are hard to influence from the outside. Recently, I experienced this firsthand during an interview process with a major bank.

It's striking how quickly you can sense the seasoning of a team. One indicator is their relationship with tooling—particularly the tendency to fixate on the latest library or framework. This tendency is most visible among younger developers, eager to adopt what's fresh without fully considering the long-term implications. With experience, you learn that if you do not control something beyond its version number, you cannot rely on it to make your codebase resilient.

First Screening - The Debt That Drains

During my initial screening the lead, it became clear that technical debt was a central pain point for the team. They were tasked with enduring fast feature development, while simultaneously managing migrations (++ technical debts (as in framework +10 versions behind)), batch processes, etc.

The root cause? A heavy dependence on specific tools—without decoupling their applications from those tools. Every time the tooling evolved, it triggered a cascade of costly, time-consuming updates.

I sympathized with the reality they faced. Yet, with experience, it becomes harder to remain entirely neutral in such discussions. Opinions, even respectfully stated, can make people—both managers and engineers—uneasy. There is a delicate balance between being agreeable enough to collaborate and assertive enough to challenge inefficient practices.

Technical Interview - The Tool Test

The technical stage focused on specific library knowledge, particularly Angular and NgRx. This was essentially a “show and tell” of proficiency with a given tool, rather than an assessment of general engineering understanding and depth of experience.

Enjoyed they progressive enlightment where they encouraged the use of AI assistance. It is to note that, while AI could help meet interview constraints (lowering session stress, batching code), the output would not match the standards of a production application (I mean it's about batching code to meet the constraints and have a chance isn't it? I notified them). In the show and tell 'tell' part, I explained how a resilient, maintainable front-end should be structured (and what the AI (inherently prompt to lower-practice level to meet the timeline) did wrong) — modular, decoupled from specific libraries, layer seggregation and sovereignty, and adaptable to inevitable change.

The Paradox

Here it's fun: the team openly acknowledged their struggles with technical debt, slow feature delivery, and high maintenance costs. Yet, their interview process sought exactly the kind of skill set—deep but narrow tool expertise—that had contributed to those very problems.

It was clear they were looking for a library operator , not an engineer focused on long-term stability and adaptability. In other words, they looked for someone to deepen their pain.

Like adding more shelves to a leaning wall — it hides the problem for a while, but it's unstable, it delays the breakdown, and the higher the costs when it falls.

How much to argue against the cultural status-quo in an interview? As in, the interviewers were supposedly architects. Also they seemed constructive people.

Well they posted their feedback to HR, and I received a negation.

Note to whoever

It's naive to equate proficiency in a tool with engineering excellence. Or the confusion between the state of the arts, and the latest toolkit. Tools matter, but tools evolve independently from your control. Don't focus much on the hammer or it's color. Focus on the bricklaying practice. What endures are principles: solid understanding of separation of concerns, clear boundaries between application and framework, maintainability principles, and resilience in the face of inevitable and paced obsolescence.

Be mindful: chasing the latest framework can lead to brittle systems and escalating maintenance costs. That's litterally what happens to technical dinausors. It's great they can throw money at it, for a while. But eventually it slows down the beast, and impact engineering moral. Here is the market openning for competitive startups.

In interviews, especially at large organizations, you may find that the role is designed around immediate needs rather than sustainable practices. That's their choice — but it's also your opportunity to think critically about the kind of engineer you want to become.

I'd propose further: with the advent of AI, it should be mostly about psychological profiling. Focus on whom/team you want to share your time with, how much energy they have, and egos constructive enough to be butchered and reworked by the machine.

Thanks for reading. Hope that rang a bell, or induced a retrospective.