Infrastructure & Systems
Experience working close to infrastructure, production environments, system administration, servers, networking, access control, and operational reliability.
Fetching data...
Fetching data...
About / Engineering Profile
I build systems that work under real production constraints.
I'm a software engineer interested in building reliable software systems and solving problems that exist beyond the code itself.
My engineering path has taken me from infrastructure and systems work into backend engineering and, more recently, production AI systems. Each stage changed the way I think about software - from how systems run, to how applications scale, to how intelligent systems can be made useful and dependable.
My path into software engineering didn't begin with AI. It began much closer to the infrastructure that makes software possible.
Working with servers, operating systems, networks, access control, deployment environments, production incidents, and reliability constraints taught me that software never exists in isolation.
I became increasingly interested in building the applications and services running on top of that infrastructure. Eventually, that curiosity led me toward AI - not simply because models were becoming powerful, but because I became interested in the engineering problem around them.
The question became how to take AI beyond demonstrations and integrate it into reliable software systems: systems with clear boundaries, useful behavior, and a way to earn trust over time.
I build systems that work under real production constraints.
Security should be part of the architecture, not something added after the system works.
I prefer solving a problem with the simplest reliable architecture before adding another service, cluster, or dependency.
I want to understand where complexity and bottlenecks actually come from before optimizing them.
AI systems need boundaries, validation, observability, and predictable interfaces just like any other production system.
A system is not finished because it works in development. It is finished when it can survive real users, failures, changing requirements, and operational constraints.
Hawassa University
A progression from understanding the environment to shaping what runs inside it.
Experience working close to infrastructure, production environments, system administration, servers, networking, access control, and operational reliability.
A transition toward building backend services, APIs, databases, asynchronous systems, and production applications.
A current focus on integrating AI into real software systems, particularly backend platforms, retrieval systems, and intelligent application workflows.
How hands-on infrastructure experience informs my approach to AI and backend platform development.
Gained deep understanding of kernel tuning, networking fundamentals, memory management, Linux firewalls, and server operating systems.
Designed high-concurrency Python REST APIs, asynchronous database connection handling, Redis caching layers, and transaction isolation.
Automated application packaging with Docker, Kubernetes, and Red Hat OpenShift manifests, setting up CI/CD test and deployment automation.
Combined database and infrastructure knowledge to build production vector search platforms (pgvector), hybrid BM25 search, and AI agent tools.
After working through technical problems, projects, architecture decisions, and career questions with ChatGPT, I eventually asked a different question:
What kind of engineer do you think I am?
I don't seem particularly interested in technology for the sake of technology. I'm usually trying to understand how things actually work, how they fail, and how they can be made reliable enough to use in the real world.
My path has also been somewhat unconventional. I came from an infrastructure and systems background, where servers, networks, operating systems, access control, deployment environments, and production problems are impossible to ignore. That experience shaped the way I think about software.
I tend to look beyond the code itself.
When I build a backend, I think about the database, concurrency, failure modes, deployment, security, observability, and what happens when the system has to serve real users. When I work with AI, I don't want the model to simply produce an impressive response. I want to understand how the surrounding system makes that response useful, controlled, reproducible, and safe.
The part that stands out
If I had to describe one characteristic that consistently appears in the way I work, it would be restlessness.
I'm rarely satisfied with simply making something work.
I want to know why it works.
Then I want to know what happens when it doesn't.
Then I usually want to rebuild it better.
That mindset can sometimes make the journey slower than it needs to be. I can spend a lot of time questioning architecture, comparing approaches, refining a project, or trying to understand a concept deeply instead of accepting the first solution that works.
But I also think that is becoming one of my strengths.
I'm learning to turn that curiosity into engineering discipline: choosing the simplest architecture that solves the problem, understanding the trade-offs, and knowing when something is good enough to ship.
I'm still developing as an engineer, and I don't pretend to know everything.
What I do know is the direction I want to take.
I want to build software that is useful beyond a demonstration - backend platforms, AI systems, developer tools, and products that have to operate under real constraints.
I'm particularly interested in the space where backend engineering, infrastructure, and AI systems meet.
That's the kind of engineering I want to keep getting better at.
Building something I can trust.
A next step
I'm interested in working with people who care about building useful, reliable software - not just impressive demos.