Getting a new tech job in 2020 is no small feat. These days, we expect our tech workers to know more than ever. Maybe you’re just starting your job search. Or maybe you’re in the middle, and you’ve discovered that there are some gaps in your knowledge. That’s OK! The tech universe is vast, and nobody is an expert on everything.
While it’s OK to have gaps in your knowledge, those gaps might be the difference between landing a job and another rejection letter. So, when you identify one of those gaps, it’s good to view that as an opportunity to learn some things. That’s what we’re going to do today. Odds are, you’re here because you’re interviewing for a job that uses Kubernetes in the near future. Maybe you’ve recently had a job interview around Kubernetes that didn’t go so well. Or maybe you’ve worked with Kubernetes in the past, but it’s been a while since you interviewed. Maybe you just want some pointers to help you get started.
Whatever the reason, I’ve compiled a few questions about Kubernetes that I think you’re likely to encounter. After each question, we’ll talk a bit about why that question is important, and how you can give an answer that your interviewers are likely to love.
How Is Kubernetes Related to Docker?
This question is here to warm you up. When I interview candidates, I always try to start with a simple question to help them ease into the interview. Interviews are stressful situations! The goal of this question isn’t for you to launch into a thirty minute speech detailing your every iota of knowledge. Instead, this is here to give you a chance to break the ice.
No single answer to this question is going to land you a job. Sorry! But a good answer here will set you on good footing for the rest of the interview. So, what does a good answer to this question look like? For starters, you’re going to want to show that you know what Docker is. Talk about the way that Docker containers simplify application deployment. Explaining how they enable teams to deploy full containers that contain everything needed to run a single application. Then, you’ll want to pivot to talking about how multiple containers working in concert allow for more complicated applications. This is your opening to then talk about how you need to orchestrate those containers, to make sure they’re all working together well.
If you follow that outline, you’re going to give your interviewer everything they’re likely looking for.
Why Would You Choose Kubernetes for Container Orchestration?
After your first softball question, this question is looking for context. The interviewer is likely asking to try to understand how well you understand the use case for Kubernetes. The best answer here isn’t to talk about why you would choose Kubernetes, but rather why you did. Being able to talk about decisions around Kubernetes you made in the past and relating them to the role in question is the best way to answer this question.
But let’s say that you’ve never worked in a role that used Kubernetes before. That’s OK. Maybe this is a stretch goal for you. If that’s the case, there’s another way that you can give a knockout answer to this question. Talk about a situation in the past where Kubernetes would have been a good fit. Perhaps you worked in an organization that utilized Docker containers, but didn’t have an orchestration system in place. If that’s the case, talk about problems that Kubernetes would have fixed. Things like simplifying deploys or self-healing ecosystems. Brush up on your benefits of Kubernetes, and identify shortcomings you’ve lived with in the past. Then talk about the ways Kubernetes would have alleviated those problems.
Can You Compare Kubernetes and Docker Swarm?
This question is asking you to show your knowledge of the broader container orchestration ecosystem. This is the sort of question where you should expect to see a variety of follow-up questions. However, when faced with a question like this, I like to ask a clarifying question before I launch into an answer. I do this because there are really two directions you can take this answer. The first is to dive into the very technical. If this is what they’d like to know, it’s a good idea to understand the low-level differences between Kubernetes and Docker Swarm. You can talk about things like the differences in networking architecture, or the different APIs between systems.
Instead, your interviewer might ask you to talk about some of the higher level differences. If this is the case, you can outline how many people consider Kubernetes more difficult to set up, but more customizable than Docker Swarm. You might also talk about Kubernetes’s self-healing architecture. Another great way to highlight the difference is to talk about their relative communities. If you’re not connected with the Kubernetes community, this interview process is a great place to start.
The are two key things you’re looking to do with this answer. The first is ask a good clarifying question. Asking clarifying questions is a critical skill in planning good projects. By showing that you can ask smart questions, you’re showing off that skill to your interviewer. Secondly, you’re looking for a highly-tailored response based on the answer your interviewer gives.
What Does It Mean That Kubernetes Is Self-Healing?
This question might feel simple. Kubernetes’s self-healing properties are actually pretty straightforward. The orchestration system identifies when a container is behaving improperly, and it replaces the failing container. Pretty easy, right?
Well sure, but that’s a B-answer at best. This question isn’t about your grasp of a basic property of the Kubernetes architecture. Instead, think of this as an opportunity to talk about the value Kubernetes’s self-healing has provided in the past. For instance; if you’ve personally experienced downtime due to failing containers, talk about the pain that caused. Did you have to wake up in the middle of the night, or deal with an angry client because something broke? Use that as a springboard to talk about the ways that self-healing architecture prevents those problems. If you’ve lived through a Kubernetes transition before, compare your stress levels before and after.
Once again, the key here is to talk about the ways that you’ve benefited from Kubernetes, or identify ways it would have helped in stressful jobs previously. This is an approach that’s expandable to any aspect of Kubernetes your interviewer might care to talk about.
How Should You Secure a Kubernetes Cluster?
This is a very open-ended question. You probably shouldn’t expect to hear this exact question during an interview. If you do, remember to ask those clarifying questions before you dive into an answer. More likely, though, is that you’ll be asked about specifics around securing Kubernetes. Integrating DevOps and Security roles into a DevSecOps mindset is a trend growing in popularity.
Unless you’re interviewing for an explicit security role, most interviewers aren’t going to expect a point-by-point answer to this question. Instead, they’re ensuring that you have a basic grasp of security measures required to build a strong application. It’s a good idea to brush up on Kubernetes Security Essentials. As with many other answers: if you’ve done this before, it’s a good idea to expand on your history here. If you haven’t, but you have a personal anecdote about the ways your Kubernetes security has failed in the past, that’s great to share, too. Just make sure you have a clear takeaway from the encounter.
There’s No Secret Way to Get Hired
This is an unfortunate truth. I wish there was a secret way to show that you’re obviously the best person for the job. Instead, the key to landing that new job is to know your stuff and illustrate how you’ve grown through your career. As always, it’s a good idea to brush up on your Kubernetes essentials. But I find that when I’m interviewing for a new job, the key way to set myself apart is to talk about the ways I’ve faced problems similar to the question at hand. When I do this, I’m able to connect my experience and skills back to the problem at hand and illustrate how I’m prepared to use those skills to help the team I’d be joining.
The other important thing that I like to remind myself is that interviewing is a skill, too! Like we noted earlier, an interview is a high-pressure situation. Performing your best in that context isn’t easy! You’ll need to practice your interview skills. You might come out of an interview feeling like you did poorly. If that’s the case, spend time thinking about guides like this one, to help you improve. Don’t dwell on previous interviews, nit-picking everything you said. But do think about ways you wish you’d done better, and focus on one or two for your next interview. You might not have gotten that last job, but your new job is just around the corner.
This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.
