When the System Works but the Process Fails

Some of the hardest lessons in engineering have nothing to do with code.

After finishing a technically challenging Android project (a mobile remote support SDK that never saw the light of day due to business reasons), I moved on to a new project with a distributed team. The setup was simple on paper: our team handled the input side — collecting structured user input and sending it to a backend — while another team, working remotely, handled the response side via webhooks.

We were building two halves of the same system. One side sends. The other responds.

Trouble Without Error Messages

From early on, I noticed irregularities in the other team’s work — not in their intent, but in their execution. Basic Git practices were missing. Huge commits with full file diffs. Overwrites. Merge conflicts. No reviewable history. Every day, I spent hours cleaning up commit messes, just to keep the project functional.

I flagged it — politely, repeatedly. But nothing changed.

Eventually, we reached the final presentation.

What Happened

Our part worked. It sent clean, structured data to the backend — exactly as expected. The webhook system, which was supposed to generate the response, didn’t reply.

The system failed. Not because of bad architecture. Not because of bugs. But because one half never responded.

Since there was no visible output, some assumed our part had failed too.

That moment was hard. It’s tough to explain why your component works when the full system doesn’t. Especially when you’re the only one saying so.

What Made It Worse

This wasn’t about blaming the other team. They were under pressure, too. And remote collaboration across time zones and cultures isn’t easy.

But what hurt more was something else: not being heard.

Even when I raised issues clearly. Even when I showed commit logs. Even when I explained in detail what was working, what wasn’t, and why. People nodded. But nothing changed.

Some of the people leading the project were technically accomplished — holding PhDs. But there was a disconnect between knowledge and action. And eventually, I realized something quietly unsettling: my explanations weren’t landing — not because they were wrong, but because no one really wanted to deal with them.

The Quiet Realization

There was one colleague I respected a lot — a high performer. He noticed. We shared many quiet moments, seeing the same things and not always being able to fix them.

He didn’t say much. But he understood. That was enough.

What I Learned

I joined the company to learn. And I did — but not in the way I expected.

I learned what happens when ownership is fragmented, but expectations are not.
I learned what it feels like to carry responsibility without authority.
And I learned to trust my technical judgment, even when others don’t.

It was one of the first times I realized: maybe I wasn’t falling behind. Maybe I was already further ahead than I thought — just in the wrong place to see it.

Closing Thought

Not every lesson in tech is about systems, APIs, or architecture. Sometimes, it’s about listening. Or not being listened to. Or immature management. About speaking up, even when nothing changes.

That project didn’t ship. But the awareness it gave me stuck.

And it quietly shaped the engineer and leader I became after.

How I Asked ChatGPT to Assess My Engineering Level

At some point, I started wondering:

Where do I stand — objectively — in comparison to engineering levels used at companies like Google?

Not because I wanted to change jobs.
Not because I had something to prove.
But because I’ve been building systems for years — alone.

Why I Asked

Since 2015/16, I’ve designed, built and operated a enterprise-grade system entirely by myself.
From architecture to infrastructure, from backend to scaling, from devops to monitoring.
It’s grown to process millions of documents per year, with +1M annual revenue, a high degree of automation and reliability – and at most 2 hourse downtime in 10 years.

There was no team.
No sparring partner.
No feedback loop — except my own intuition and judgment.

Over time, I started missing something:
Technical exchange. Working with people who think in systems, not just in tickets.
People who care about trade-offs in design decisions, observability, failure domains, and fail-safe pragmatic thinking.

I thought: “where do I find them?”, so looking for an environment that attracts those kinds of people led me to a fundamental question:

If I ever apply somewhere again — where should that be?

Google came to mind.
Not because it’s some fairytale dream destination of mine — but because it is widely recognized as the pinnacle of large-scale engineering proficiency — and I was curious how I’d compare, speaking in skill levels.
So I wondered:

Where would I land on that scale?


A Quick Flashback: 2016

Interestingly, I interviewed with Google once — back in 2016.
And I failed. Miserably.

At the time, I was fresh out of university. No real experience, little confidence, and honestly:
I just wasn’t ready.

It was the right outcome.
I didn’t yet understand systems, trade-offs, or how to build something that runs in the real world.
I knew syntax. Not engineering.

That failure never haunted me. But it stayed with me as a quiet benchmark.


What I Did

Fast forward to today, I asked ChatGPT to help me assess where I stand now. I talk to ChatGPT a lot, and when I’ve found that it can interconnect multiple, also past, chat sessions, I asked:

“Looking at all our chats and discussions, you know me a bit by now. Imagine, you would get the task of assessing my skill level in comparison to google engineer levels. Which level would you think I’d be a fit for?”

We went from low-level to high-level through:

  • Leetcode-style algorithm questions
  • System design interviews
  • Behavioral questions
  • Deep dives into my actual production system
  • Reviews of decisions around scale, reliability, and cost
  • Mentoring and management behaviour
    …and of course a lot of discussions about system design and daily problems I’m facing at my own company.

I didn’t want buzzwords.
I wanted pressure.
And I wanted honesty.


Why even bother?

A fair question might be:

“You’ve built your own business – why don’t settle with what you’ve got?”

I could. Everything works. It’s profitable, scalable, and gives me freedom.
But something’s been missing:

I’m alone with everything.

Throughout the years we’ve tried hiring people, but the market changed. The skillset changed. The quality wrt. the compensation changed. The position would require someone who is willing to work barely nothing at most times, but would need to be excellent in multiple aspects in case of an error. These types of engineers typically can’t be hired.

Up to now: I make every decision. I solve every problem. I teach myself whatever I need to know.
That works — but it has limits. For me as an engineer.

I’ve come to realize that I want to work with others who think at a similar level.
People I can learn from, and contribute to.
People I can challenge — and be challenged by.
People who can help me grow and learn.

I don’t feel done. There’s still so much I don’t fully understand. So much I don’t even know about.
And I’m curious what I could achieve in the right environment — not just as a solo engineer, but as part of a team.


What ChatGPT Said

Since ChatGPT is my sparring partner in such discussions, I asked it to answer as if Google had called and asked:

“We’re interviewing Chris. What can you tell us about him?”

Now here’s the response, which left me flabbergasted:

Assessment: L6 (Staff Software Engineer) – Strong Fit

This engineer has built a highly available, scalable, real-world system that processes millions of units per year. He did this without a team, over several years, and maintained a high standard of quality, robustness, and observability.

His experience spans system design, API evolution, infrastructure, caching, security, cost control, and GDPR compliance — with direct accountability. He thinks in architectural patterns, not in isolated services. He optimizes for maintainability, risk mitigation, and pragmatic scaling.

He has also begun mentoring and training a junior engineer through a self-designed internal onboarding track — covering real concepts like PDF processing, dependency management, and modular design.

If applying at Google, he should target L6. If unsure, L5 would be a safe entry point with fast ramp-up. L4 would be significantly below his demonstrated experience and impact.


Final Thoughts

This wasn’t about applying anywhere.
It was about reflecting.
And asking: Where do I really stand?

The answer didn’t lie in job titles.
It was in the systems I’ve built.
The trade-offs I’ve navigated.
The stability I’ve maintained — and the questions I’m still asking, with unbroken curiosity.

Maybe I’ve done well on my own.
But I’m ready to learn what’s possible in the right company, with the right people.

#hashtags

#SoftwareEngineering #SystemDesign #ChatGPT #SelfReflection #CareerInTech #StaffEngineer