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.
Hey, I'm Prakshal! I'm a Site Reliability Engineer at Apple, where I lead a global SRE team keeping large-scale infrastructure running smoothly. I've been in the cloud and DevOps world for about 6 years, and these days I'm especially excited about how AI is changing the way engineers work.
I did my Master's from San Diego State University, which is also where I really fell in love with the California lifestyle and never quite left!
Outside of work, I'm pretty sports-obsessed. I play a bunch of different sports, but ultimate frisbee and tennis are my two favorites. There's something about ultimate frisbee that just brings a great energy, competitive but always a good time.
My latest HackerNoon top story was about "Scaling AI Inference on Kubernetes: The Case for Token-Based Autoscaling", something I got really deep into while researching and experimenting with LLM inference in production environments.
The core problem I explored was how autoscalers treat every request as equal, but a 200-token and an 8,000-token request are nowhere near the same amount of work on a GPU. The core argument was that request count is the wrong scaling signal for LLM inference, and you need to scale on token throughput instead, basically measuring what percentage of your fleet's actual GPU capacity is being consumed rather than how many requests are coming in. I walked through the full implementation using vLLM metrics, Prometheus, and Kubernetes HPA with custom metrics, and also touched on rewriting SLOs around time-to-first-token since that's what users actually feel. It resonated with a lot of engineers who had hit the exact same wall!
Yeah, pretty much! I tend to write about what I'm researching, learning, and going deep on, cloud, Kubernetes, reliability, observability, and increasingly the intersection of AI with all of that. If I'm exploring something new or going down a rabbit hole on a concept, it usually ends up as an article.
Lately I've been really drawn to the challenge of taking AI to production at scale, not the toy demos or the "hello world" LLM tutorials, but the real gritty stuff like what breaks, why it breaks, and how you build systems that hold up when things get serious. I think there's a huge gap between AI working in a notebook and AI working reliably at scale for millions of users, and that gap is where I love to spend my time, both professionally and as a writer.
Honestly, I don't have a strict routine. Most of my ideas come from personal research and projects I pick up because I just love exploring and trying out new things. When I go deep on something and hit something unexpected or spend way too long figuring something out, that's my signal it's worth writing about. I keep a running note of ideas, and when something genuinely excites me, I just sit down and write it out in one focused block. I can't really write in small windows; I need to get into a flow state. But it comes together fast when I'm writing from a place of genuine curiosity and hands-on exploration rather than just theory.
The biggest challenge is walking the line between being specific enough to be useful and general enough to be responsible. I work at a major tech company, so I'm always thoughtful about what I share and make sure my writing stays focused on general engineering knowledge and my own personal research rather than anything internal. But at the same time, vague theoretical content doesn't help anyone. The real value comes from writing that feels grounded in actual production experience, so I'm constantly thinking about how to bring that authenticity without crossing lines. Getting that balance right where it's genuinely insightful but also appropriate - that's the part I spend the most energy on.
Honestly, my biggest goal is to go deep on researching and building tools around making AI infrastructure more reliable. That space is still so early, and there's so much that needs to be figured out, I want to be someone who's actively contributing to solving those hard problems rather than just talking about them.
At the same time, I really want to build something meaningful around community. There's a growing group of engineers sitting at the intersection of AI and DevOps, and I don't think there's a strong enough space for them yet to learn, share, and grow together. I want to help create that. Whether it's through my writing, open source tooling, or just bringing people together, giving back to the community is just as important to me as the technical work itself. Both feel like the same mission, honestly: pushing this space forward together.
Playing Ultimate Frisbee for 3 to 4 hours straight even when my feet are absolutely killing me. Like I know I should stop; every step is telling me to stop, but there's something about being out on the field that just makes it impossible to walk away. I'll wake up the next morning barely able to walk and still have zero regrets about it.
Sports honestly take up most of my free time outside of work. Ultimate Frisbee is my biggest obsession, but I also play tennis and swim regularly. I love the variety; each one gives me something different. Ultimate Frisbee is all about the energy and the people, tennis keeps me competitive and sharp, and swimming is almost meditative; it's the one time my brain is completely off. For someone who spends most of the day solving complex problems, having that physical outlet is everything.
I'm currently going deep on AI reliability and infrastructure tooling, so expect a lot more content around that. I have a few things brewing around making LLM systems more observable and resilient in production, the kind of stuff that doesn't get written about enough because most people are still focused on the model side rather than what happens when you actually have to run it at scale reliably. I also want to start writing more about the DevOps and AI intersection from a practitioner's perspective: real problems, real solutions, no fluff. Basically, if you're an engineer trying to figure out how to make AI actually work in production, stick around because that's exactly what I'm going to keep writing about.
Honestly, it's one of the best platforms out there for technical writers because it actually rewards genuine knowledge sharing. The audience is made up of real practitioners who can apply what you write, so there's no pressure to water things down or make it clickbaity. You can go deep, stay technical, and it lands with the right people. If you're a tech writer sitting on the fence about it, just start. It's the kind of platform that gives your knowledge the reach it deserves.
Thanks for having me; this was genuinely fun! To anyone reading, whether you're an engineer figuring out how to take AI to production or just navigating the wild intersection of AI and infrastructure, keep building, keep sharing, and keep pushing the space forward. The best solutions to these problems are going to come from the community, and I truly believe we're just getting started. And if you ever want to nerd out about AI reliability or ultimate frisbee, come find me. Always happy to connect!