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?
