I’m a DevOps Hiring Manager. Here’s How to Crack My Technical Interviews! (Part 2)
In my last post, I made some recommendations for how to get through the first round of interviews from the perspective of the hiring manager. In this post, I’ll discuss what we look for in the second round, where we look deeper into your experience and employment history, dig further into your technical knowledge, and assess how you will fit into the team.
Congratulations! You’ve made it to the next round of interviews. You’ve shown that you have the basic skills needed to do the job, so now we are going to review your employment history to get a sense of your overall experience and identify any gaps in your work history.
We’re also going to take a look at some of your more advanced technical and problem-solving skills. Additionally and importantly, we’ll try to understand your “soft skills”. That is, how effectively do you communicate your ideas? How easy are you to work with? At this point, we are looking at a bigger picture than in the previous interview.
Your employment history — We’ll step through your resume and have you explain what you did in your previous jobs. What were your responsibilities? What did you learn? What projects did you lead? We are not just interested in a list of jobs! We are also listening closely to understand how well you communicate with us, how well you can explain what you did, and how well you can help us understand complex systems. We may even pause you here to have you whiteboard a diagram or speak in more detail about an architecture you worked with. You should be able to provide quite a bit of information here from memory and present it in a way that is clear and understandable. If you struggle here to recall details or have a hard time explaining how everything works, this might indicate that you didn’t quite understand your systems, or have a hard time putting your knowledge into words. Both of these skills are incredibly important for a DevOps Engineer to master, and if you have them, it will set you apart from your competitors.
We also take a look at gaps in your employment history and check on whether there are lots of very short-term jobs that could indicate that you have a hard time finding or keeping your jobs. If you have these, you should be as honest about the reasons as possible. There are lots of legitimate reasons that someone might go without work for a time, and not every job you take will work out for the long term. The important thing is that we believe that we can rely on you to do good work and will stay with us once we hire you. Fair warning — It’s surprisingly easy to pick up that a candidate is being evasive or not telling the whole truth in the heat of an interview! We might not know exactly what happened, but someone who seems to be hiding something will probably not progress to the next level.
Expert Technical Questions — Here is where we try to gauge how advanced you really are. Can you speak accurately about a wide range of technologies? Can you explain some libraries or tools you would use to test access to a RESTful API endpoint? What can you tell us about encryption and cipher suites? How do you create new SSL certificates? Can you walk us through creating a docker-compose file that would deploy both a web server and a database? What is a unit test in software development? What are some different branching strategies in a git repo? We expect that if you are the real deal as a DevOps Engineer, you should be able to explain all of these things without much effort.
Troubleshooting — A key skill to have is the ability to solve problems under pressure when things break. In fact, this is probably the most important skill we have as DevOps Engineers. We might describe a situation where something is not working, and ask you to tell us how to fix it. Pro Tip! Troubleshooting does not just mean looking at logs! I get this answer fairly often when speaking with less experienced engineers, and then this is where they stop. Of course, you should look at logs, but in most cases that will not be enough. The logs give you an idea of what to try next when you are troubleshooting. We need to see that you can think your way through the whole problem.
The next steps will require you to think deductively. And the first step when deducing the problem is to start asking questions! For example, “tell me everything you were doing when the problem started” is totally a fair and valid question! So is “Tell me everything you know about the current problem”. That’s not cheating, and is in fact something we do every day on the job. Once you are armed with your log info and you have gathered as much as you can from your colleagues, you can begin by making a mental list of all the things that could be causing the issue, and then eliminating issues one by one until you have your answer. Is the service running? Why not? Is it a network issue? What is a tool you can use to test for that? Is it a database issue? How would you check on the health of the database? What tool would do this quickly? (Remember, Production is down! Time is money! Your boss is freaking out!) Can you find the service with its IP address but not its hostname? If so, what does that tell you?
If you can walk us through your process for bringing us back online, we will be quite impressed with your skills.
The last phase of this interview is reserved for you to ask us questions. This is quite important, as it will tell us a lot about you. Are you curious? Do you want to know about our technology stack? Do you seem interested in working with us? There is important information that we can get from you when you ask us questions — and as I said in my previous post, asking the right questions is a critical skill for engineers!
To close, there are a couple of things we are hoping to find out about you when you come in for this round of the interview process. We want to know that you have the right skills, of course! But we also want to know that we can trust you, that we can work together harmoniously, that we can rely on you and that you will be a net positive to the team. It’s hard to really get to know someone in the short time available in an interview, but it is your chance to show us your best, and coming in prepared will go a long way to achieving that!
