Building Kubernetes careers: hiring, certifications, and emerging roles

Bart: First things first, can you introduce yourself? Who are you? What's your role? And where do you work?

Note: While this transcript snippet doesn't contain any technical terms that require hyperlinks, I noticed the speaker is from CloudBolt Software. If the full introduction were to include more details about her professional background, there might be opportunities for additional linking.

Yasmin: My name is Yasmin. I'm the COO at CloudBolt Software and I work remotely from my home office.

Bart: And what first brought you into the Kubernetes and cloud-native ecosystem?

Yasmin: I was at Puppet for a while, and someone reached out from a company called StormForge that was doing Kubernetes optimization. Kubernetes was always a space I wanted to get into, transitioning from the traditional VM world. I happened to luck out that I liked the people and wanted to learn more about the technology.

Bart: This ecosystem moves very quickly. How do you stay up to date with all the changes that are happening?

Yasmin: I'm very lucky that we have many engineers entrenched in the Kubernetes community. We have internal Slack channels where we discuss new Kubernetes alpha features. I follow the Kubernetes Slack channel for updates, and I get a lot of new information from events like KCDs and KubeCons.

Bart: In terms of people in the ecosystem who have helped you level up along the way, is there anyone you would like to mention in particular?

Yasmin: When I first started at StormForge about three years back, I was introduced to Kubernetes concepts through Justin Garrison's "Containers on the Couch" shorts. The one with the HPA and VPA, hitting the bucket of water, really helped me visualize the concepts. It made learning the technical side much easier. People joke that short-form visual formats are taking over, but the reality is they did make the concepts more accessible. I even met Justin at a KubeCon and was a bit starstruck, telling him, "Thank you. You taught me everything I know about Kubernetes." That definitely helped me a ton.

Bart: I was lucky enough to see Justin just yesterday at a conference. I'm in Amsterdam right now and I emceed the event yesterday. He did his entire 40-minute talk with one slide, just telling a story. He's an incredible communicator, taking those complex concepts and making them much more digestible and not so scary. Massive shout out to Justin. Kubernetes can mean so many different things to different people. Yasmin, what is Kubernetes?

Yasmin: Kubernetes represents freedom—freedom to build as you need it and break away from traditional licensing models. You hear horror stories with companies like Broadcom. What I like about Kubernetes is, first, it's open source, and second, it's really easy to deploy. It's not necessarily easy to manage once you get to scale, but it gives you the freedom to break away from traditional infrastructure and traditional deployment methods, providing scale at your fingertips.

Bart: When looking at potential candidates from a hiring perspective, because you lead product teams, what are the things you look for in Kubernetes-focused resumes? What stands out to you?

Yasmin: Everybody in an interview process wants to prove their technological knowledge and how good they are with Kubernetes. But what I focus on is how they think about problems and how creative they get. Within the Kubernetes landscape, there's something for every problem, and you can stitch together pieces. It's less about how well you know one piece of technology and more about how you think creatively to bring all those pieces together.

In interview processes, I like to ask people random questions and observe their thinking process in solving problems, rather than focusing on the specific solution or answer they provide.

Bart: Okay, so more about the how and not necessarily the end result. I think that's good. It's something people often mention: there are technical challenges around Kubernetes, but the people challenges can actually be much bigger. Problem solving and building into a team framework can be very important. In terms of balancing practical experience versus certifications—because certification is one pathway to gain knowledge—how do you balance those two elements when evaluating candidates?

Yasmin: For us, CKA is definitely very important, especially because as we work with customers or prospects, that credibility is crucial. We want to make sure when we say we know something, we actually have proof behind it.

For example, one of the new hires I just brought on is on his path to getting a CKA. To me, it's less important whether you have a CKA when you join—it's more about whether you're excited about getting one and have the aptitude to take that path. You're going to learn along the way. I know very seasoned Kubernetes experts who failed their first CKA. It's not about passing on the first try, but understanding the pieces to reach that certification.

It's the most relevant certification we've seen. You've spoken to Rafa Brito on our side before. He co-wrote a book with Chad on how to pass the CKA and has a ton of horror stories. It's also nice to have people like that on staff who can help others as they pursue their licensing or certification. On certifications as a whole, I'm not a huge cert person, but I do think the CKA is something that's pretty important in this space.

Bart: The CNCF will be very happy to hear that. It's a great way to know that someone's put the work in, that there's a common framework and understanding of the different concepts covered in that CKA certification. Looking ahead, we're talking about AI and ML constantly, but perhaps other profiles as well. What kind of Kubernetes-related roles or skills do you see growing most in the next three to five years?

Yasmin: I see AI and ML, which everyone's talking about these days. But the other area I'm particularly interested in is FinOps Kubernetes engineers. These are engineers who handle the platform's day-to-day operations and are increasingly being asked to provide insights into platform spending.

Kubernetes has many shared costs, and many teams struggle with chargeback mechanisms. Developers often view resources as free because they aren't directly paying for them, but these are actual business expenses. Because of Kubernetes' complexity, a typical FinOps person in the finance team can't easily break down costs. You need someone who truly understands the technology and platform.

I'm hearing more about platform engineers who are now wearing a FinOps hat, providing reports to finance teams and helping developers understand cost allocation. This isn't just about resources within a specific namespace, but also shared costs like kube-system, and how those are distributed.

Platform engineers are helping developers understand their actual resource usage, showing them that by right-sizing, they could optimize their existing resources instead of constantly requesting more. This level of detailed analysis requires deep technical background and platform knowledge.

Bart: And it's interesting that engineers might be pivoting more towards this FinOps position. What about people entering the Kubernetes world from another background? Maybe they're on the product side or even on the finance side and want to get more into the Kubernetes world. What advice would you give to someone trying to make that transition?

Yasmin: It's hard. Part of the journey is knowing it will be challenging. Sometimes, acknowledging the difficulty helps because you don't feel like you're constantly failing. Instead, you understand it's an uphill battle, and you continue to chip away at it.

Advice for people in non-engineering roles trying to transition to Kubernetes: Start with the basics of core infrastructure. Forget Kubernetes initially and focus on understanding how to provision infrastructure, like basic EC2 instances. Learn what "cloud" means and get comfortable with those concepts.

As you grasp the basics, gradually go deeper. Learn about containers, then move on to Kubernetes. Don't jump from zero to 100 immediately. If you're in finance or FinTech, find the bridge that helps you transition step by step.

Bart: There's a debate around the difference between vendor versus end-user career paths, with people trying to figure out whether it's about building a product or working in a large, heavily regulated institution. What do people misunderstand the most about this divide of vendor versus end-user pathways?

Yasmin: I actually have been on both sides. I started out as an end-user around 2016 when I deployed my first Docker container. My engineering manager suggested I check out Docker, and it was so early that the site was down often. That was my first experience in the container world.

Fast forward over 10 years, and it's amazing how far we've come. Being an end-user helped me understand the mindset when looking at technology to solve a problem—the whole build versus buy approach. For me, it was always about not wanting to manage infrastructure, but focusing on things that move the business forward.

Being on the vendor side is cool because you get to see that lens across every industry. I was in retail, in e-commerce, and was actually a Puppet user at the time. Transitioning from an end-user to the vendor that built the software was interesting. I wasn't a fan of Puppet initially, but then I understood the benefits of putting work upfront.

This career transition helps people empathize with those on the other end. I often hear people say that large organizations, especially in retail, lack innovation—but that's not true. At Staples, we sold office supplies, yet the team internally built an entire platform using Go in the early days. We even hosted a Go meetup around 2016-2017.

You don't typically imagine a retail company selling office supplies doing cool things in the tech community. But it is possible. End-users often drive innovation by pushing vendors to meet their needs. There's good on both sides. I like the vendor side and appreciate how it has helped my career journey.

Bart: Last thing, as a bonus question, if there's anything the Kubernetes community could do better, what do you think it would be?

Yasmin: I don't know if I should say this, but the community needs more organization. It's challenging having a community that is so geographically dispersed and diverse in technologies. Different folks have different initiatives—from observability to infrastructure provisioning—all trying to move in the same direction. This complexity is evident in our events, and we've been participating in numerous CNCF and Kubernetes events.

Organization is probably the biggest challenge. Prospects often ask about upcoming Kubernetes features, but it's difficult to provide insights because features can remain in alpha for extended periods before switching to beta. When you have many people working on a project that isn't vendor-backed, coordinating efforts becomes complicated. Despite these challenges, it's been a great community to be part of.