Meet Munachimso Victor Nwaiwu, a proud member of (
At Google, he's at the forefront of enhancing critical backbone network fabric, making substantial improvements in capacity, performance, and efficiency. His impact extends to optimizing network reliability, streamlining complex processes through automation, and driving significant reductions in project turnaround times.
A strong believer in continuous learning, Munachimso is currently expanding his expertise by studying for his CCNP Data Center certification and makes it a point to read vast amounts of technical literature to stay ahead in the field. He also holds key certifications such as the Google IT Automation with Python Professional Certificate, CompTIA A+ and Network+, and the Cisco Certified Network Associate. His commitment to the field is further demonstrated through his initiatives like NetworksByMuna.com, where he shares practical insights to empower the next generation of network engineers. His goal is clear: to leverage automation and his deep understanding of networking to build more efficient, reliable, and scalable infrastructures for the future.
“Paint me a picture of this morning—where are you, what’s on the screens,
what’s the coffee order?”
This morning, I'm at my home office in San Jose, California. The first thing I do when I
sit down is go through my personal bug list on one screen, checking for updates on the
various projects and network issues I'm currently tackling. On my other screen, I have
my IDE open, where I'm deep into developing the Go code for the current network
operations workflow I'm building.
While I'm not a coffee person, my morning ritual involves a green smoothie almost
every day. My go-to mix is apple, bananas, ginger, berries, spinach, and avocado – it's
incredibly creamy and rich; you should definitely give it a try!
“When someone outside tech asks what you do, how do you explain it without
using the word ‘packet’?”
I currently write code to automate the deployment and management of the largest
private network in existence – think of it as building and maintaining the massive digital
highways that power a huge part of the internet, but all under one roof. I also perform
tasks to ensure that all the changes and expansions we make to this network are done
safely and without disruption.
“Which dashboard, log, or chat channel gets your eyeballs first—and why?”
The first thing that gets my eyeballs in the morning is our team chat. That's where the
latest updates on projects are discussed, so I can immediately get a pulse on what's
happening and where I might need to focus.
When I'm on duty, however, my absolute first stop is the bug queue. There's nothing
quite like starting the day by closing out a high-priority bug—it gives you this immediate
sense of accomplishment. Plus, if there's a complex bug, knowing about it early allows
me to properly plan my day and allocate enough time to tackle it effectively.
“How do you triage between alerts, tickets, and longer-term projects?”
It boils down to this: alerts, tickets, and then longer-term projects, in that order. You
quickly learn to master the art of context switching, as you're often juggling multiple
alerts, various tickets, and several long-term projects all at once.
Alerts definitely take priority and often demand my focus for most of the mornings. On a
good day, the immediate fires should be down by noon. Then I dive into tickets, starting
with those that just need a quick update or a simple closure. After making progress
there, I shift to my long-term projects. If I can move those forward, I'll then try to close
out one or two more tickets before the end of the day.
“What’s one CLI command or script you run so often it feels like muscle
memory?”
That's a great one! For me, it's definitely the history | grep | tail combo.
Working at Google, there are so many tools, each with its own syntax, that it's almost
impossible to memorize them all. So, I just rely on my history bank. If I've done a similar
operation before, I don't have to rack my brain trying to remember the exact command. I
just grep my history for keywords and then tail the output. Most times, those last few
lines are exactly what I need, and it keeps my terminal from getting flooded with too
much information. It's a lifesaver for efficiency!
“Who’s pinging you most during the day—security, app teams, the NOC,
Vendors?”
Ah, when I'm on duty, it's definitely the TPMs (Technical Program Managers) who are
pinging me the most! My team is responsible for the workflows that enable our
deployment processes, and these TPMs are on tight deadlines, constantly tracking
those workflows. So, if a deployment workflow pauses at a strange spot, I know I'm
getting a ping within five minutes. And I totally get it—their need for speed keeps all of
us on our toes!
“How does documentation fit in: love it, automate it, or necessary evil?”
For me, documentation is multifaceted. While I'm deeply committed to automating
processes, I see automation more as an evolution of documentation rather than a
replacement. For example, when I build tools or scripts, like the network operations
workflows in Go I'm currently working on, the code itself needs to be well-documented.
That means clear comments, meaningful variable names, and comprehensive
READMEs so other engineers can understand, use, and maintain it effectively.
So, while automation might reduce the need for manual, step-by-step guides for
repeatable tasks, it introduces the critical need for code-level documentation and
architectural overviews. It's not just a necessary evil; it's a necessary investment in the
longevity and maintainability of our automated systems, ensuring that our work can be
understood and leveraged by others down the line.
“What’s a ritual your team uses (stand-up, war room, memes) to stay synced?”
For my team, our most valuable ritual for staying synced is our weekly tech talks. Each
team member rotates giving a presentation on what they're currently working on. It's a
fantastic way to keep everyone up-to-date on ongoing projects, new automation tools
we're building, or complex network issues we're tackling.
What makes this even better is that these tech talks are recorded and added to our
educational library for new hires. This means we're solving two problems with one
stone: we're staying perfectly aligned as a team, and simultaneously building a rich,
practical knowledge base that helps our new colleagues quickly get up to speed on the
intricacies of our network. It's an incredibly efficient way to ensure continuous learning
and seamless onboarding.
“Tell me about the last incident that broke your flow—what failed, how did you
unravel it, what did the post-mortem change?”
The last incident that truly broke my flow involved debugging an old, roughly 500-line
Bash script that completely lacked any tests. This was back before we had the luxury of
AI code generation tools like Gemini, and it was far from the best experience. The script
was critical for a network operation, but it just kept failing in subtle, non-obvious ways. It
took a painfully long while to pinpoint the exact problem.
My low-tech trick that saved the day was resorting to brute-force logging: I ended up
putting echo statements on almost every single line of that 500-line script to trace its
execution and variable states. It was tedious, but it eventually revealed the unexpected
condition causing the failure. It really hammered home that logging is king – a principle
that's applicable in every coding context.
That frustrating experience was one of the major catalysts that spurred me to actively
join the effort to migrate most of our legacy Bash scripts to more reliable languages like
Golang, and to focus on creating robust, testable GoCLI tools. It reinforced the
importance of maintainability, testability, and using the right tools for complex
automation in critical environments.
“On the flip side, what small win recently made you quietly fist-pump?”
A small win that recently made me quietly fist-pump happened during a discussion with
my manager about an operations process our team works on. I thought I had a solid
grasp of it, but as we were speaking, I decided to ask a clarifying question. That simple
question unexpectedly turned into about 30 minutes of deep discussion, which
completely cleared up things I thought I knew but actually didn't.
That moment right there was an unexpected win, because that newfound clarity of
understanding helped me move so much faster in automating that very process. It really
underscored for me that sometimes, key understanding is far more valuable than the
actual implementation itself.
“Which tool in your stack feels irreplaceable today, and which one you’d swap
out tomorrow if budget allowed?”
If I had to pick one irreplaceable tool in our stack today, it would unequivocally be the
CLI tool for our network model database. This tool is incredibly simple yet unbelievably
efficient and productive. It allows us to write quick queries to search for any information
on the network, from individual links all the way up to entire data center sites. Given the
sheer scale and complexity of Google's network, having such immediate and granular
access to this authoritative source of truth is absolutely critical for troubleshooting,
planning, and validating any changes. It's the ultimate single pane of glass for network
intelligence.
As for a tool I'd swap out tomorrow if budget and cycles allowed? It's less about a
specific tool, and more about the redundancy across some of our internal databases
and tools. Given Google's immense size, we inevitably have some databases and tools
that are duplicates or serve very similar purposes, leading to fractured data sources and
fragmented workflows. If I had the power, I would converge almost all of these
redundant databases and tools. Streamlining these into fewer, more authoritative, and
better-integrated systems would massively improve efficiency, data consistency, and
overall operational clarity.
“How much of your day is still ‘click and type’ versus pipelines and APIs?"
That's a great question, and one I think about a lot! Ideally, I'd want to be 100% focused
on pipelines and APIs, and honestly, a significant and growing portion of my day is
dedicated to that. Because my work is heavily focused on automating deployment
operations and building robust workflows, a large chunk of my time is spent developing,
testing, and iterating on those very pipelines and APIs. However, some "click and type"
still exists, typically for initial investigations into new or unusual issues, very specific
edge cases that aren't yet automated, or final human validation checks. So, while the
goal is always to maximize automation, my day is heavily skewed towards pipelines and
APIs, and I'm always looking for ways to push that percentage even higher!
“What new tech (AI-ops, EVPN, NetDevOps pipelines, etc.) has already
changed your routine?”
The new tech that has already significantly changed my routine is AI code generation,
particularly with tools like Gemini.
I've never been a big fan of Bash scripts – they can be unstable, error-heavy, and
notoriously difficult to test reliably. This meant I used to spend a significant amount of
time troubleshooting old Bash scripts or just trying to decipher their logic. Also, because
almost every API service at Google has a CLI version, Bash scripts were often used to
call and verify the output of code, which always felt like it took more time than it should,
especially with the intricate string syntax when calling commands.
Now, with AI code generation, I move so much faster with Bash scripts. Tools like
Gemini can break down complex scripts for me, explaining them clearly, and even help
me generate new ones more efficiently. This has freed up a lot of my time from tedious
debugging and allows me to focus on the core Go development for our network
operations workflows.
“Where do you see the biggest skill gap for the next generation of
engineers?”
I'd say the biggest skill gap for the next generation of engineers, both in Network
Engineering and Software Engineering, is a lack of foundational knowledge and deep
fundamentals.
In Network Engineering, many younger engineers, myself included at times, are eager
to jump straight into automation and high-level coding. There's less natural interest in
diving deep into the fundamentals of protocols like BGP, OSPF, or ISIS. While I might
not configure these protocols daily in my specific role, I genuinely enjoy reading about
them, and I've seen firsthand how that foundational knowledge sets you apart. It's
evident in the senior engineers on my team; their deep understanding of how things
work at a fundamental level makes them exceptionally better at troubleshooting and
problem-solving.
Similarly, in Software Engineering, particularly with frontend developers, I've noticed a
trend where many younger developers don't fully grasp the underlying HTML/CSS,
relying almost entirely on advanced frameworks. While I don't expect anyone to be
building a website from scratch with just HTML, I strongly believe that core
understanding is necessary and key to long-term success. Without those strong
fundamentals, it's harder to truly diagnose complex issues or innovate effectively when
the frameworks don't quite fit.
“What podcast, blog, or RFC has influenced you most this year?"
This year, the blog/resource that has influenced me most, and truly serves as an
inspiration for my own efforts at networksbymuna.com, is networklessons.com.
It's become my absolute go-to for referencing and refreshing my knowledge on
networking technologies and concepts. What makes it so impactful for me is how
brilliantly it explains complex networking concepts in incredibly easy-to-understand
ways, even for someone outside of tech. That ability to simplify and clarify, without
losing technical accuracy, is something I deeply admire and strive to replicate in my own
writing. It's a goldmine for understanding the fundamentals and seeing them applied in
practical, digestible formats.
“How has USNUA membership shaped your career or mindset?”
Being a member of USNUA has truly exposed me to the beauty of a vibrant and
engaging community within the networking world. I absolutely love the community
culture, the collaborative vibe, and the wealth of shared knowledge.
While I'm eagerly looking forward to my first opportunity to attend a physical USNUA
event, the recorded educational content from their meetings has been an immense
benefit. It's my go-to for deep dives into various topics and staying current with industry
best practices. Beyond the content, the biggest gain has been the opportunity to build
connections and, crucially, to see what other network engineers across the industry are
getting their hands on. Understanding those real-world challenges and solutions from
different perspectives is incredibly valuable and keeps me inspired and informed.
“Any hallway-conversation or slack thread that paid unexpected dividends?”
For me, it's about diligently paying attention to Slack threads – they've paid unexpected
dividends more times than I can count. I can't go into specifics, but there was a complex
problem being discussed in our team's thread, and I found the solution someone posted
to be incredibly intuitive. I made a point to star that solution. Sure enough, some weeks
later, I encountered that exact same issue when I was on call. Because I had starred it, I
didn't spend nearly as much time troubleshooting as it would have originally taken to fix
the bug.
Now, it's a personal practice to always quickly skim through the team chat, even if a
conversation doesn't directly involve me. I consciously make an effort to star
commands, tips, or tools that I believe could be useful down the line. More often than
not, it pays off significantly, saving precious time when you're under pressure.
“What would you say to a member who lurks but hasn’t engaged yet?”
Don’t overthink it, just jump in…it is an awesome community!
“If you could DM ‘Day-One-Engineer-You’ three lines of advice, what would
they be?”
● Master the fundamentals – truly understand how things work under the hood; it's
your ultimate superpower.
● Always ask questions – the only thing worse than not knowing something is
thinking you know something that you actually don't.
● Build your network of people; relationships and shared knowledge are invaluable.
“What habit keeps you grounded when the pager refuses to stay silent?”
When the pager is going off repeatedly and it feels like the network is screaming, the
habit that keeps me grounded, as a Christian, is to disconnect for a bit.
I'll step away for a quick 5-10 minute walk, not necessarily to think about the problem,
but just to clear my head through praying and meditating on scripture. It's about
breaking that intense focus and letting my mind reset with a spiritual perspective. Then,
when I plug back into the issue, I try to reduce the tense atmosphere by listening to
sermon messages. It helps me maintain a calm and grounded mindset, allowing me to
approach the problem with clarity and focus.
"CLI or GUI?"
My answer is simple: both have their perks, and it truly depends on the task at hand.
GUIs definitely win for ease of use and a lower learning curve, especially for quick
visual checks or when a task doesn't require deep, granular control.
But for flexibility and sheer power, CLI is king. When you need to automate, script
complex operations, or troubleshoot at a deep level across a massive network, the
command line provides the precision and efficiency that a GUI simply can't match. So, I
leverage both, choosing the right tool for the right job.
"Favorite RFC?"
To be completely transparent, I don't regularly read RFCs yet, though it's definitely
something I want to incorporate into my learning routine in the future. My primary history
of learning, especially for foundational and emerging networking concepts, has really
come from books, technical blogs, and video tutorials.
So, instead of an RFC, I'd have to give a massive shout-out to all the fantastic technical
content creators out there.
“Most underrated layer of the OSI model?”
For me, the most underrated layer of the OSI model is definitely Layer 1: The Physical
Layer.
I'll admit, I'm also guilty of sometimes overlooking it, as it's not as "glamorous" as the
higher-level protocols or automation. However, I constantly have to remind myself not
to. If your physical infrastructure isn't perfect—a bad cable, a dirty fiber
connection—nothing else works. I've seen seemingly simple Layer 1 issues bring down
critical services, and they can be notoriously difficult to troubleshoot without the right
tools. It's the silent, foundational workhorse that, when it fails, makes everything else
irrelevant.
“Go-to snack before a maintenance window?”
My go-to snack before a maintenance window is a mix of granola, nuts, and
crackers/biscuits, all soaked in milk like cereal. It's surprisingly satisfying and provides
steady energy without being too heavy. If I'm not necessarily hungry but just want my
mouth to be busy, I'll just snack on nuts.
Thank you to Muna for taking the time to share their insights and experiences with us.
Their perspective on the various Network tools offers valuable knowledge for other Network Engineers.
Have suggestions for future interviews? We'd love to hear from you. Send us an email at info@usnua.com
Disclaimer: The opinions expressed are those of the interviewee and do not necessarily reflect the views of their employer.