HackerNoon editorial team has launched this interview series with women in tech to celebrate their achievements and share their struggles. We need more women in technology, and by sharing stories, we can encourage many girls to follow their dreams. Share your story today!

Tell us about yourself!

I’m Sai Joshitha Kathari, and I work as a Senior Site Reliability Engineer. My background is mainly in large-scale distributed systems, Kubernetes and OpenShift, cloud and on-premises infrastructure, observability, CI/CD automation, and production reliability.

A lot of my work is around making systems more predictable and reducing manual operational effort. That can mean improving deployment validation, troubleshooting incidents, looking at application and infrastructure signals together, or automating checks that engineers would otherwise have to repeat manually.

One project I’m particularly proud of involved automating Kubernetes post-deployment validation. The process used to take around 45 minutes manually, and we were able to reduce it to about two minutes.

Outside of work, I also enjoy writing about reliability engineering and Kubernetes, speaking at technical events, and participating in peer review and engineering communities.

Why did you choose this field in the first place?

I did not start my career with a plan to become an SRE. I became interested in this area after working more closely with production systems and seeing how different they can be from development environments.

I liked understanding what happens after an application is deployed, because production introduces so many things that you do not always see during development: traffic, scaling, resource limits, networking, dependencies, failures, and unexpected interactions between components.

When I started working with OpenShift and Kubernetes environments, I found that really interesting. You might begin by looking at an application issue and then realize the real problem is somewhere else, maybe resource pressure, autoscaling, networking, or a downstream service.

That kind of troubleshooting naturally pulled me toward SRE.

I also liked the automation side of it. If a team has to perform the same manual check over and over, I tend to start thinking about how that process can be made more consistent.

What tech are you most excited/passionate about right now and why?

Right now, I’m very interested in distributed systems, Kubernetes, observability, and AI-assisted SRE.

There is so much operational data available now: logs, metrics, traces, alerts, deployment events, infrastructure signals, and application-level data. During an incident, the hard part is often not collecting information. It is figuring out which information actually matters.

That is where I think AI can be useful.

For example, it could help summarize an incident timeline, group related alerts, highlight unusual patterns, or help an engineer narrow down where to start investigating.

I still think the engineer has to validate the conclusion. Production environments have a lot of context that a model may not know.

What tech are you most worried about right now and why?

I’m cautious about using AI in production operations without enough verification.

If a model gives a wrong answer during an incident and someone acts on it immediately, the situation can become worse very quickly.

The same thing applies to automation in general. Automation is useful, but it has to be designed carefully. If the logic is wrong, automation can apply that mistake much faster than a human would.

So I’m interested in AI and automation, but I also think validation, rollback, observability, and human judgment are still very important.

What are your hobbies and interests outside of tech?

I like traveling and exploring new places, and I enjoy spending time with friends and family.

I also enjoy writing and speaking, even though those are still somewhat connected to technology.

Writing actually helps me think. When I try to explain a technical issue clearly, I usually notice whether I really understand it or whether I’m just used to working around it.

The same thing happens with speaking. You have to simplify the problem enough that someone outside your immediate team can follow it.

Let's talk about breaking the glass ceiling. What were the biggest challenges you faced as a woman in tech, and how did you deal with them?

One of the challenges is confidence, especially when you are working in areas like infrastructure, DevOps, or SRE where there can still be fewer women in the room.

Earlier in my career, I sometimes assumed that other people understood much more than I did.

With experience, I realized that nobody knows every layer of a distributed system. Even very experienced engineers have to investigate, ask questions, and test assumptions.

That changed how I approached difficult problems.

I became more comfortable taking ownership even when I did not have the complete answer at the beginning.

Writing and speaking publicly also helped me. It gave me a chance to see that the technical problems I was working on were relevant to other engineers too, not just to my immediate team.

I do not want to invent a dramatic story just because the question expects one.

For me, the bigger issue has been representation.

When you do not see many women in infrastructure, systems engineering, or SRE roles, it can affect whether younger engineers imagine themselves doing that kind of work.

I think it helps when women are visible not only as people working in technology, but as engineers solving production issues, designing systems, speaking at conferences, reviewing technical work, and making technical decisions.

That kind of visibility matters over time.

What was the biggest setback/failure that you faced, and how did you manage it?

Some of the hardest moments for me early in my career were production incidents.

When something is failing in production, people want answers quickly, and sometimes you are looking at behavior you have never seen before.

At first, that pressure can make you want to jump to the first explanation that looks reasonable.

I learned that it is better to slow the investigation down just enough to be systematic.

I usually start with what changed, then look at application health, pod behavior, logs, autoscaling, node pressure, cluster events, and dependencies. I try to narrow the problem instead of guessing.

That approach came from experience. I was not naturally calm the first time I had to deal with an incident. It is something I learned.

What's your biggest achievement that you're really proud of?

One of the projects I’m most proud of was automating Kubernetes post-deployment validation.

The manual process took around 45 minutes, and the automated version reduced that to about two minutes.

The time improvement was important, but I liked the fact that the process also became more consistent. Engineers no longer had to rely entirely on remembering the same sequence of manual checks every time.

I later had the opportunity to speak about that type of work with the Kubernetes community, which was meaningful to me because it turned something I worked on in practice into something I could share with other engineers.

I’m also proud of the progress I’ve made outside my day-to-day role through technical writing, speaking, reviewing, and participating in engineering communities.

In your opinion, why do we see this huge gender gap in the tech industry, and how can we reduce it?

I think there are several reasons, and they start pretty early. Exposure, encouragement, and seeing people like you in technical roles all matter.

But once women enter the industry, I think it is also important that they get real technical ownership.

That means opportunities to work on hard problems, lead technical initiatives, handle incidents, design systems, speak about their work, and move into senior technical roles.

Representation is much more powerful when people can see women doing the actual technical work, not only being present in the industry.

Who is your tech idol? Why?

I do not really have one specific tech idol.

I tend to admire engineers who are technically strong but also good at explaining things and helping other people improve.

The engineers I learn the most from are usually the ones who can look at a complicated system and explain what really matters without making it sound more complex than it needs to be.

I also respect people who treat failures as a chance to improve the system instead of immediately looking for someone to blame

Do you have any advice for aspiring girls who want to join the field?

Do not wait until you feel completely ready.

Technology is huge, and nobody knows all of it.

Pick something that genuinely interests you and spend time understanding it. Build things, read documentation, troubleshoot problems, ask questions, and try to automate something you repeatedly do manually.

Also, share what you learn.

You do not need to be the top expert in the field before you write something or speak at a meetup. If you learned something useful, someone else may find it useful too.

And if you are one of the few women in a room, do not automatically assume that means you are in the wrong room.