Welcome to HackerNoon’s Meet the Writer Interview series, where we learn a bit more about the contributors that have written some of our favorite stories.

So let’s start! Tell us a bit about yourself. For example, name, profession, and personal interests.

I am Jeleel Muibi, a platform and infrastructure engineer based in London. My work sits where cloud and on-premises infrastructure meet: networking, platform lifecycle, recovery and the controls that make an operation safe to repeat.

I created HybridOps, an open-source infrastructure runtime that carries declared intent through policy, execution, verification, recovery and teardown. Outside the engineering itself, I enjoy writing. It gives me room to slow a problem down and explain why a system behaved the way it did.

Interesting! What was your latest Hackernoon Top story about?

My latest Top Story is "The Deployment Failed. The Resources Are Still Running." It starts with a simple contradiction: the deployment failed, but the network and virtual machine it created are still live.

A red command tells us that a process stopped. It does not prove that the infrastructure rolled back. The article follows that failure through state recording, pending work, recovery and verified teardown. HybridOps Core is the working implementation behind it, including a regression path for partial provider mutation.

Do you usually write on similar topics? If not, what do you usually write about?

Yes, mostly. I write about the points where infrastructure automation can look complete while leaving an operational question unresolved. That includes platform engineering, sources of truth, reproducibility, recovery and the boundary between a useful tool and an operable platform.

The subject changes, but the questions are usually the same: who owns the state, what proves the result and what does the next operator inherit?

Great! What is your usual writing routine like (if you have one?)

I rarely begin with a blank page and a topic. It usually starts with a failed test, an awkward recovery or behaviour that was harder to explain than it should have been. I reproduce it, inspect the code and run records, and read the source documentation before deciding what I can honestly claim.

Once I know the exact argument, I tend to write the opening and conclusion first. The final pass is mostly subtraction: removing unsupported claims and details that belong in product documentation rather than the story.

Being a writer in tech can be a challenge. It’s not often our main role, but an addition to another one. What is the biggest challenge you have when it comes to writing?

Scope. An infrastructure failure is rarely only one thing. It can touch networking, identity, remote state, policy and recovery in the same run. The difficult part is giving readers enough context to trust the argument without making them carry the whole platform in their heads.

What is the next thing you hope to achieve in your career?

I want HybridOps to become an established open-source operating layer that engineers use, question and improve in real environments. The next stage is building a broader maintainer and user community around it, working directly with teams that face these problems, and bringing more of the implementation into public talks and industry collaboration.

Wow, that’s admirable. Now, something more casual: What is your guilty pleasure of choice?

Overengineering jokes. I wrote a complete [GoatOps incident report](https://hybridops.tech/goatops) involving a goat, a fibre uplink and a very questionable SLA. It began as a small joke and somehow acquired root-cause analysis, mitigations and lessons learned.

I have to admit that most of my hobbies eventually become technical. Writing was supposed to be the non-tech one, but that plan clearly failed. I still enjoy the quiet part of it: stepping away from the screen, letting an idea settle and returning when I can explain it simply.

Next, I am working on the point where a successful machine-image build becomes safe for another system to trust. A green build proves construction. It does not prove that a fresh consumer can clone the image, boot it, reach readiness and retire cleanly.

The work draws on a HybridOps evaluation across Ubuntu, Rocky Linux and Windows images, with disposable-clone checks and state-based handoff to downstream consumers.

What’s your opinion on HackerNoon as a platform for writers?

What I value is that a practitioner can start with a real implementation and still tell a readable story. HackerNoon gives technical work reach without forcing it to become a product pitch or flattening the writer's voice.

The editorial process improved how this article was presented, and seeing it become the lead story on the homepage made that reach very real for me.

Thanks for taking time to join our “Meet the writer” series. It was a pleasure. Do you have any closing words?

Build the thing, test the awkward path and write down what actually happened. In infrastructure, the failure case often teaches us more than the happy path. Thank you to HackerNoon and to everyone who read, commented on or challenged the article.