Suresh Sigera

Chief Technology Officer, Spokata LLC

New York City

Suresh Sigera is the Chief Technology Officer at spokata.com. A real-time SaaS platform that converts text content into audio summaries. As CTO, Suresh is responsible for Spokata’s technology strategy and plays a key role in software engineering by driving new initiatives. In addition to overseeing Spokata’s technology strategy, Mr Sigera is responsible for leading innovation through Spokata’s R&D lab and leveraging emerging technologies to bring the newest innovations to news publishers all around the world. He is also an Adjunct Lecturer in Computer Science at the College of Staten Island, City University Of New York. In recognition of his exemplary service in the classroom, Suresh has been selected as a member of General Assembly's Distinguished Faculty program. Suresh serves as a member of the GA Python Product Advisory Board.

What is your favorite technical skill to work with on your own projects and why?

Java — and at this point, we're talking over 20 years together. I've watched the language evolve from J2EE nightmares to the elegance of modern Spring Boot, and honestly that journey is part of why I still love it. When you've been working with a language that long, you stop thinking about syntax and start thinking purely about design. On personal projects I gravitate toward distributed systems — event-driven architectures with Kafka or RabbitMQ, microservices with clean bounded contexts, deployed and automated on AWS with Terraform. The combination of mature Java engineering paired with cloud-native infrastructure is where I feel most at home. Still presenting interesting problems after all this time.

Microservices architecture, without question. Not because it's trendy — because watching a student go from writing a single monolithic app to understanding how to decompose a system into bounded contexts, configure Spring Cloud, manage inter-service communication, and ship it all to Kubernetes is genuinely remarkable to witness. I bring a lot of production history into those conversations, which means I can tell students not just how to do something but why we do it this way now, what we tried before, and what broke. That context is something you can't get from documentation. There's always that moment in class when it clicks for someone — that's the moment I teach for.

The gap between classroom theory and production reality is enormous in software engineering — closing that gap is what drives everything I do at GA. Having built real systems at scale and then turned around and taught Fortune 500 engineers at companies like Microsoft, Google, Deloitte, and McKinsey, I know exactly where that gap lives. Engineers don't struggle with syntax — they struggle with judgment. When do you introduce Kafka? How do you design a service boundary you won't regret? How do you secure a Spring API in a way that actually holds up? I want people leaving my courses able to make those calls on their own, confidently, on day one back at their job.

Stop waiting until you feel ready — you won't. Pick one thing that genuinely intimidates you, go deep, and build something real with it. Break it, fix it, understand why it broke. That's the only loop that actually builds confidence. I still hit problems I haven't seen before — that discomfort never goes away, you just get better at sitting in it productively. Also, don't skip the fundamentals. I teach Programming Language Theory, Operating Systems, and Data Structures at St. John's University as an Assistant Professor, and every semester it becomes clearer — the engineers who invest in theory are dramatically more adaptable than the ones chasing frameworks. The frameworks change. The principles don't.

The work that shaped me most wasn't in a classroom — it was the years I spent building systems where downtime actually meant something. At Spokata we were running real-time news ingestion and ML inference pipelines on AWS, microservices talking to Bloomberg, Amazon Polly, AccuWeather — the kind of stack where a bad deployment at the wrong moment is a very bad day. That experience sticks with you in a way that no course can replicate. The Tamkeen engagement in Bahrain was a different kind of challenge — less about writing code and more about translating deep Java and Spring architecture knowledge into something that could drive a country's digital transformation agenda. That's a different muscle. And somewhere in that work, explaining hard things to people who really needed to understand them, I found something I wasn't expecting. I realized I genuinely loved it. Not just the technical problem-solving, but the human side of it — meeting people where they are, understanding what's blocking them, and finding the right way to make something click. That's really where teaching found me, not the other way around. The empathy I bring into the classroom came directly from being in the trenches — I know what it feels like to be stuck, to be overwhelmed by a system that feels too big to understand. That never leaves you, and I think students feel it. Oxford's Systems Analysis program, the ML research at Essex, the security studies work I'm finishing now — it all feeds into the same thing: trying to understand complex systems from as many angles as possible. But it's the people side that keeps me coming back.

WHAT SURESH’S STUDENTS ARE SAYING...

"Suresh ALWAYS gave his full attention in every lecture and activity. I cannot rate his teaching prowess highly enough, capable of meeting individuals where they're at in their current understanding of a topic, from beginners to advanced students. If I felt capable in a given area, he was thoughtful enough to challenge me further in my learning. I could not ask for a better instructor. I would consider myself extremely fortunate to have someone like Suresh as a mentor as I advance in my career."

In recognition of his exemplary service in the classroom, Suresh has been selected as a member of General Assembly’s Distinguished Faculty program.