A few months ago, while interviewing for a Cloud Solutions Architect role at Microsoft, one of the interviewers asked me a question that stuck with...
For further actions, you may consider blocking this person and/or reporting abuse
What surprised me when I became a developer was that systems at large, famous companies are not always built with the latest flashy technologies. Large systems tend to be used for a long time, so they often rely on older technologies. However, because of their scale and complexity, they are not easy to replace with cutting-edge technologies, so they often remain unchanged for many years.
I think that's exactly what challenged my assumptions too.
When we're learning, it's easy to think newer automatically means better. But once you see how much of the world runs on systems that have been working reliably for decades, you start looking at "old technology" very differently.
At a certain scale, stability becomes just as important as innovation.
Yes, stability is a high priority for large and famous companies. But for personal projects, I prefer to choose innovative and fun technologies. ๐
Interview questions that make you audit your assumptions after the fact are the good ones. Probably was not testing mainframe knowledge - testing whether you reason well about unfamiliar constraints. Most candidates nail the first, fail the second.
I think you're probably right.
At the time I assumed they were asking about the technology itself, but looking back, it does feel more like a question about how someone approaches unfamiliar systems.
What's funny is that I left the interview thinking about mainframes, and only months later realized I was actually thinking about assumptions.
Which, in hindsight, is probably why the question stuck with me in the first place ๐
the content was the vehicle. what they were testing is how you reason in unfamiliar territory - the mainframe was just the scenery.
Aryan, I enjoyed this one. The idea that the hardest part is not the technology itself but the responsibility that comes with it makes a lot of sense.
I think many of us underestimate older systems until we see how much depends on them every single day.
Thank you Hema ๐
I think that was the biggest shift for me too.
From the outside it's easy to see an old system and immediately think "why hasn't this been replaced yet?"
Then you realize how many people, processes, and businesses depend on it every single day, and the question becomes a lot more complicated.
This landed hard for me.
โThe hardest part isnโt learning the technology. Itโs understanding the responsibility that comes with itโ feels like the real answer.
Iโve been thinking about this a lot from the AI-assisted development side. One thing AI coding agents expose very quickly is that a system does not become safe to change just because code can be generated quickly. In some ways, AI makes even newer codebases start to feel like legacy systems: there are hidden assumptions, ownership boundaries, old decisions, generated artifacts, tests, docs, configs, and runtime behavior all depending on each other.
The dangerous question is not only โcan this be changed?โ
It is: โDo we understand what this change is responsible for preserving?โ
Thatโs actually why I started building Scarab Diagnostic Suite. I kept seeing AI agents make changes that looked locally reasonable, but the harder problem was proving whether the repo still told the truth after the change. Which layer owned the behavior? Which test was protecting the original claim? Which artifact was source truth versus generated output? Which boundary moved without anyone noticing?
Your mainframe example gets at the same deeper discipline: mature systems force humility. They make you slow down long enough to ask why something exists before you assume you can replace it.
That mindset feels increasingly important now, not only for old enterprise systems, but for any codebase being changed by AI faster than humans can fully reason about the consequences.
I really like the way you phrased that:
ยซ"Do we understand what this change is responsible for preserving?"ยป
I think that's much closer to the mindset I was trying to describe.
The technology itself eventually becomes learnable. The difficult part is understanding all the assumptions, constraints, and responsibilities that have accumulated around it over time.
And you're right, AI seems to be making that challenge show up much sooner, even in relatively new codebases.
Thanks for the thoughtful comment. Gave me another angle to think about.
Wow this really changed my perspective towards legacy systems and old technology. With old power comes great responsibility ๐ฃ
Honestly, that's pretty much the entire article summarized in one sentence.
The more I learn about these systems, the more respect I have for the people maintaining them.
This is a great reminder that in real-world systems, the hardest part isnโt the technologyโitโs understanding the responsibility that comes with it. Really thoughtful perspective
Thank you! That's what surprised me too. Going in, I assumed the challenge would be the technology itself. The more exposure I've had to enterprise systems, the more I've realized that understanding the consequences of change is often the harder skill to develop.