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 me long after the interview ended.
Not because I couldn't answer it.
But because I kept thinking about whether I had answered it well.
The question was:
"What's the hardest part about working on mainframe technology?"
At the time, I was still relatively new to the world of mainframes.
And by "relatively new," I mean embarrassingly new.
Before joining my current company, I didn't even know something called a "mainframe" still existed. If you'd asked me what COBOL was, I probably would've guessed it was a Pokémon. Okay that is an exaggeration but you get what I mean.
I still remember early on hearing terms like KT (Knowledge Transfer) being thrown around and quietly wondering if everyone had received some secret corporate dictionary except me.
The good news is that I've never been particularly afraid of looking stupid.
So my strategy is simple:
Ask the question.
Then ask the follow-up question.
Then ask the question that reveals I didn't understand the previous answer either.
Surprisingly, people were usually happy to explain.
Anyway, after a few KT sessions and what I'd generously describe as a "bare minimum amount of research," my brain went where most developers' brains probably would've gone.
- The technology
- The age
- The tooling
- The learning curve
- The fact that some of these systems were designed before I was even born
All perfectly reasonable answers.
But while I was sitting there in the interview, another thought appeared:
"This feels too obvious."
Interviewers at that level usually aren't asking for the first answer that comes to mind. They're trying to understand how you think.
And the more I reflected on that question afterwards, the more I realized something interesting.
The hardest part isn't the technology itself.
Before I started working around large enterprise systems, my mental model of old technology was pretty simple.
Old technology meant outdated technology.
And outdated technology meant something nobody had gotten around to replacing yet.
I don't think I ever consciously believed that. But I definitely acted like it.
Then I got exposed to the reality of these systems. And that assumption started falling apart surprisingly quickly.
Because whether we think about them or not, a ridiculous amount of the world still runs on technology most developers never talk about.
- Banks
- Insurance companies
- Governments
- Airlines
- Large enterprises
Entire industries quietly depend on systems that have been running for decades.
Not because they're trendy. Not even because they're exciting.
But because they work.
Every day.
For years.
Sometimes longer than the careers of the people maintaining them.
No launch events
No Hacker News front page
No "look at my setup" posts
Just plain ol' reliability. And honestly, that's kind of impressive.
The more I thought about it, the more I realized the hardest part isn't learning how the system works.
Given enough time, most engineers can learn technology.
The harder part is understanding the responsibility attached to it.
When I'm building a side project, mistakes are annoying.
When you're working on systems that businesses depend on, mistakes become expensive.
Sometimes very expensive.
Suddenly the question changes.
It's no longer:
"Can I build this?"
It's:
"Do I fully understand the consequences of changing this?"
That's a completely different mindset.
And it's one I didn't fully appreciate until I started seeing these environments up close.
One thing I remember telling the interviewer was something along the lines of:
"The amount of verification and validation involved. Even small changes need to be checked carefully because the impact can be much larger than it appears."
Now at the time, I was thinking mostly about process.
Reviews. Testing. Approvals.
The sheer amount of caution involved.
Looking back, I think I was circling around the real answer without fully articulating it.
The caution exists because the responsibility exists.
As developers, we're constantly encouraged to move fast.
Ship.
Experiment.
Refactor.
Rewrite.
Try the new framework.
Try the new architecture.
Try the new thing.
Mainframe environments feel very different.
They force you to ask:
"Why does this exist?"
before you even think about replacing it.
And honestly, after seeing some of these systems, the replacement question becomes a lot less obvious than I once thought.
One realization I've had recently is that old doesn't automatically mean obsolete.
Sometimes old means battle-tested.
Sometimes old means reliable.
Sometimes old means thousands of decisions made by people solving problems I've never personally encountered.
That doesn't mean old systems are perfect. Far from it.
But it does mean they're usually far more interesting than they appear from the outside.
So if somebody asked me that interview question again today, my answer would be something like:
"The hardest part isn't learning the technology. It's understanding the responsibility that comes with it."
I know Uncle Ben I know
Looking back, I still wonder what answer the interviewer was hoping to hear.
If you've worked with mainframes, large enterprise systems, or have interviewed people for similar roles, I'd genuinely love to know:
How would you have answered that question?
What's a technology, tool, or system you underestimated at first, only to later discover there was far more depth hiding underneath it?
Top comments (10)
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. 😁
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.
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.