DEV Community: Ahmed Abdelgawad

The Biggest Red Flag I Ever Heard in a Technical Interview

Ahmed Abdelgawad — Fri, 17 Jul 2026 16:39:56 +0000

A few years ago, I interviewed with a CTO

Everything was going well until we started talking about automated testing.

I explained how useful tests had been in some of the systems I worked on, especially when we had to change existing behaviour without breaking something completely unrelated.

Then he interrupted me.

"We don’t write tests because our business logic changes too quickly."

For a moment, I understood what he meant.

They were a startup. Things changed all the time. Requirements moved fast, features were rewritten, and nothing stayed stable for very long.

So why spend time testing something that might change again next week?

But the more I thought about it, the stranger the statement became.

He was using change as the reason not to write tests, when change was exactly the reason tests mattered.

If your software barely changes, you might survive for a while with weak test coverage and a lot of manual checking.

But if your business logic changes every week, you are constantly touching code that is already running in production.

That is when the risk starts to add up.

Fast-changing software does not need fewer tests.

It needs a safer way to evolve.

Tests Give You Something to Rely On

Tests are usually described as a way to catch bugs.

That is true, but it is not the main reason I value them.

The bigger benefit is that they give you something to rely on when you change existing code.

Imagine you are asked to update a pricing rule that has been in production for more than a year.

The request sounds simple. A discount should no longer apply to a specific customer group.

Writing the new condition is easy.

The real problem is figuring out where else the current behaviour is used.

Maybe the same rule exists in another checkout flow.

Maybe one market has its own override that was added two years ago and never properly documented.

Maybe an old campaign still depends on the current calculation.

Without tests, you can read the code, check a few scenarios manually, and ask someone from product to verify the result.

That may be enough in a small system.

After a few years, it usually is not.

Too much context ends up spread across code, tickets, old decisions, and people who may no longer be on the team. At that point, manual testing becomes less about verification and more about hoping everyone remembered the right things.

Useful tests do not prove that the change is correct.

They do not tell you that nothing can go wrong.

They give you feedback about the behaviour the team already decided was important.

And in a system that keeps changing, that feedback matters.

Change Is the Normal State of Software

Software is never really finished.

Business rules change. Customers use features in ways nobody expected. Performance becomes a problem. Regulations evolve. Decisions that made sense two years ago stop making sense now.

Sometimes the request is genuinely small.

Other times, one small request exposes a design problem that has been sitting there for years.

You add one condition and discover that the same rule is duplicated in four places.

You try to update one workflow and realize that three unrelated modules depend on it.

You fix one edge case and suddenly the change touches far more of the system than it should.

This is where the lack of tests becomes expensive.

Teams compensate with manual checks.

The developer verifies the feature. Someone from product checks the happy path. Maybe a few related screens are tested before the release.

That works until one of the forgotten cases breaks.

Then releases become slower. More people get involved. Everyone becomes a little more careful around the same parts of the codebase.

Eventually, some areas become known as dangerous.

Everyone agrees they should be cleaned up, but nobody wants to be the person who breaks them.

The frustrating part is that the engineers may know exactly what is wrong with the design.

They may even know how to improve it.

They just do not trust what will happen when they touch it.

That is how temporary technical debt slowly becomes the architecture.

Not because nobody noticed it.

Because changing it feels riskier than leaving it alone.

A useful test suite changes that.

It gives the team enough feedback to improve the system gradually instead of waiting for one huge rewrite that may never happen.

This does not mean every test suite is useful.

A slow or flaky suite can create the same uncertainty it was supposed to remove. Tests can also become so tied to the implementation that harmless refactoring breaks them everywhere.

The point is not to write as many tests as possible.

The tests should protect the behaviour the business depends on without breaking every time the internal structure changes.

The Sentence I Still Remember

I do not remember anything about that interview anymore.

I do not remember the architecture they described or any of the technical questions they asked.

But I still remember that sentence.

“We don’t write tests because our business logic changes too quickly.”

What made it such a red flag was not simply that they did not write tests.

It was the reasoning behind it.

They knew the software changed constantly, but instead of giving engineers a safer way to make those changes, they accepted uncertainty as part of the job.

That told me something about the engineering culture.

Engineers were expected to move quickly, but without the feedback needed to know whether their changes were safe. And when that becomes normal, people eventually stop improving the system. They avoid refactoring, work around bad design, and become more careful every time they touch old code.

Since then, I have worked on systems where a tiny change took far longer to verify than to implement because nobody knew what else might break.

I have also worked on systems where much larger changes were possible because the team had enough feedback to move step by step.

That is why the sentence stayed with me.

We do not write tests because the software is stable.

We write them because engineers need the confidence to change it.

Complexity Should Be Earned

Ahmed Abdelgawad — Thu, 02 Jul 2026 06:00:00 +0000

Every engineer eventually reaches a point where they stop asking:

"How do I implement this?"

and start asking:

"What's the right architecture?"

That's a sign of growth.

It's usually when you discover concepts like Domain-Driven Design, CQRS, Event Sourcing, Hexagonal Architecture, and countless other patterns that promise cleaner, more maintainable systems.

The mistake isn't learning those patterns.

The mistake is looking for reasons to use them.

Over the years, I've noticed something interesting: the more experienced engineers become, the more comfortable they are introducing complexity. Sometimes that's exactly what a system needs. But sometimes we're solving tomorrow's problems while today's business is still asking for a simple application.

One of the most valuable engineering skills isn't knowing every architecture pattern.

It's knowing when not to use one.

Every decision has a price

Architecture discussions often focus on what patterns enable.

CQRS separates reads from writes.
Event Sourcing preserves the history of every change.
Microservices allow teams to deploy independently.

Those are all legitimate advantages.

But every architectural decision also introduces long-term costs.

More concepts for new engineers to understand.
More code paths to debug.
More operational overhead.
More infrastructure to maintain.
More failure modes to think about.

Those costs are worth paying only when they're solving a real problem.

If the business isn't getting enough value in return, you've probably introduced complexity too early.

CRUD isn't something to "graduate" from

CRUD isn't an architecture.

It isn't a design pattern either.

It's simply a way of describing applications whose primary behavior revolves around creating, reading, updating, and deleting data.

Yet I often see teams treating CRUD as something temporary—as if every successful system eventually needs CQRS, Event Sourcing, or a fleet of microservices.

I don't think that's the right mindset.

A well-designed CRUD application can have:

clear boundaries
rich domain logic
comprehensive tests
clean abstractions
excellent maintainability

None of those qualities require advanced architectural patterns.

Sometimes CRUD isn't the beginner solution.

Sometimes it's simply the right solution.

Let the business earn the complexity

Imagine you're building an inventory system.

At the beginning, inventory is just a quantity.

Receive stock.

Ship stock.

Update the current value.

A straightforward CRUD application is probably all you need.

Now fast-forward two years.

The business introduces:

multiple warehouses
stock reservations
returns
warehouse transfers
third-party fulfillment
inventory audits

Suddenly, inventory is no longer just a number.

Different parts of the system care about different views of the same data. Historical changes become valuable. Read and write workloads start evolving independently.

At that point, introducing concepts like projections or CQRS might actually make the system simpler, not more complicated.

Notice what happened.

The architecture changed because the business changed.

Not because someone wanted to use a particular pattern.

That's exactly how I believe software should evolve.

Start with the problem, not the pattern

One of the most common architecture questions I hear is:

"Should we use this or that pattern?"

I think there's usually a better question.

"What problem are we trying to solve?"

Sometimes the answer genuinely leads to CQRS.

Sometimes it leads to Event Sourcing.

Sometimes it leads to a modular monolith.

And sometimes it leads to a straightforward CRUD application.

The pattern isn't the goal.

It's the consequence of understanding the problem.

Good architecture isn't about collecting patterns.

It's about making thoughtful trade-offs.

The hardest architectural decision isn't choosing the most sophisticated solution.

It's recognizing when the simplest one is enough.

Good engineers learn patterns.

Great engineers learn when not to use them.