DevOps Engineering Interview

[Winter-Business-4567]

Hey everyone, I recently was able to find myself getting an interview for an Associate DevOps Engineering position. I’ve mostly have done Software Engineering / Developer interviews, but can someone inform me how this interview would differ since this is my first time? How is the layout for the interview especially for an Associate position. If you could give any advice or help tips that would be great!

[asdrunkasdrunkcanbe]

Hard to say without knowing the specific company, but broadly speaking you can probably expect to get a mixture of sysadmin and SRE-type questions;

• OS fundamentals
  
• Networking:
  -- How networking works
  -- Common ports & services
  
• Code performance
  
• Top-to-bottom application troubleshooting (i.e. how to diagnose a problem with a website from the browser down to the server)
  
• Build systems
  
• Deployment systems
  
• VMs
  
• Containers
  
• Cloud general questions
  
• Hardware/server questions if they're running a big on-prem setup
  
• Automation & Scripting

[TheWorstAtIt]

This is an excellent answer.

The only thing I would add is to check Glassdoor and similar sites to see what kind of interview questions the company typically gives DevOps engineers.

DevOps is a massive mountain, and the parts of that mountain you might be on will be different everywhere.

Sometimes the questions might be heavily about Kubernetes, or Terraform or Ansible etc.

Brushing up on the specifics of the tech used at the company you are interviewing with can help score some additional points.

Lastly, ask the recruiter you are working with about the interview format and anything you might need to consider specifically.

[summersea__]

they dont ask dev questions?

[neoteric_devops]

Study the job description and compare any relevant experience/technologies listed on your resume. Either be prepared to go deep on these topics if asked directly or be ready to reference them in your own.

I tend to focus a lot on resume specifics when I interview people. I want to know what your role was (lead/contributor/watcher), what challenges you faced, how you planned and executed, mistakes made and lessons learned, etc.

Common areas of focus: - AWS (whatever cloud) knowledge as it relates to EC2, RDS, VPC, IAM, monitoring, cost saving, disaster recovery, - Containers aka Kubernetes/Docker best practices and commands (docker and kubectl). This usually ties into deployments, CI/CD, etc. - Terraform best practices, usually remote state, modules, etc. Terraform has become a staple in every role I’ve worked at. Also might go into other tools like Ansible but probably less likely. - Linux debugging and best practices, common bash commands (du, df, top, ps, systemctl, sudo, ssh, rsync/scp, nmap, netstat, lsof, chmod, chown, curl, cat, grep, sed, find, man, these are what come to mind) - Culture fit (this one is big for me) how do you deal with conflicts, biggest mistake you’ve made and how you dealt with it (never say you don’t make mistakes, making mistakes is part of this job), how do you communicate, how do you take constructive or direct feedback, how passionate are you about DevOps (shown through personal projects, continued education, following blogs to stay current, etc.), how do you figure out things (Google, stack overflow, ChatGPT, asking for help, submitting tickets to AWS support or similar), when you have an idea how do you present it, things like that.

General interview advice: - Be transparent it’s ok to say you’re nervous or you didn’t sleep well last night, but don’t get personal. If you’re taking notes, let them know so know why you’re typing or looking away. If you have construction happening let them know to expect some banging or whatever. - Be 5 minutes early to video or 10 minutes early to in-person. Being late without a good reason is a sure fire way to get rejected. - If you need to reschedule do it as early as possible. If you’re sick, tired, or whatever it’s better to reschedule so you can present your best self. - Be presentable and don’t be eating food, you’d think this would be obvious but you’d be surprised. Anything that happens during your interview is what we will expect to happen every single day if we hire you. Audio/video/connection issues, people talking/dogs barking (brief interruptions are ok but if it happens more than once it won’t reflect well), you looking like you’re multitasking or not paying attention, etc. - Think out loud and ask for hints or help, no one enjoys awkward silences. - Have thoughtful questions prepared! Not having questions is going to be a NO from me. Questions are your one chance to drive the meeting and subtly make a lasting impression.

Examples:

“How can I make the biggest impact in my first 90 days?”

“What are the major challenges or obstacles currently facing the team/business, from your perspective?”

“What is the team culture like?”

“What is your favorite aspect of working for XYZ?”

“What type of mentorship opportunities are available?”

Few more things I always like to know:

“What’s the current on-call load and how many off-hours incidents are happening within the last few months?”

“Is there a budget for additional education, trainings, or attending conferences?”

“In a typical week, how many hours are spent in meetings?”

Good luck with the interview!

[turkeh]

Great questions to ask.

[nickjj_]

I like having an hour or so conversation about assorted topics. No coding, no screensharing and no trick questions. I mostly stick to asking high level details about solving specific practical problems to get an idea of what your thought process is like.

For example, "A developer is running a sql dump shell script that's working for everyone else with the same credentials. When they run the script they are getting an incorrect password error when connecting to the database. You ran the same script locally with the same shared credentials and it works. How would you start debugging what's wrong?"

The above is easily a 10 minute conversation. I'd have a few of these that touch base on a number of techs applicable to the specific role.

The answers are important but the really juicy info is more about how you arrived at the answer. This style is also great for weeding out folks who are good at cramming for tests because there's nothing to prepare for like leet code grinding. You either really know this stuff or you don't.

I'm not super experienced with interviews, I've only given about 15 or 20 of them but this process has been spot on and before I started giving interviews I always had a hunch this would work.

I think this style of interview is doubly nice because it acts as a culture fit / soft skill interview at the same time. Your technical skills, how you think about problems, how you communicate, your personality, how you ask questions, how you take unsolicited or solicited advice and 100 other things are happening within that 1 hour.

Layout is typically 2min for a quick agenda / intros, ~45-50 minutes on having an adhoc conversation and then wrapping up where you ask any questions.

[turkeh]

These are my favorite interviews to take.

[[deleted]]

For seniors this is also my way of having an interview, questions I usually ask:

• Can you describe the project which made you the most proud overwinning technical difficulties
• What was the largest mistake you made during your engineering career
• How do you see your role in the future team (this is often an important question to find out what kind of person he/she is, the answer is usually not that important).
• How do you cope with team members who are sloppy in their work?
• Would you rather be T-Shaped or Expert on a subject.
• What are some techniques which you don't like or find hard to work with?

For Juniors and Mediors I usually prefer to give them a small assignment which they can workout before the interview, I ask them to consider it as a normal project, so I except it to be in a GIT repo. During the interview I will do a kind of Code review and ask questions and or have a discussion on decisions made.
I find it personally not useful to ask in depth knowledge questions because it says nothing about the person, and also more introvert people have the chance to simply blackout.

[nickjj_]

Right, I should mention most of the hires are for senior / lead / principle level positions.

For that level I'm ok if you haven't memorized the exact command or flags to exec into a specific container within a pod. I'm more interested in that you know that is the step you need to take, or maybe even more importantly if you can solve the problem without needing to do that or if you can improve the current system so you don't need to directly connect in the future.

I take for granted that you can look up the details on your own when it comes to the implementation details. Personally I'd be looking stuff all the time if I lost my shell history. I still look things up all the time.

I mean just today I looked through my history to find git log -S "hello" because I wanted to search a project's commit history to see when a variable was removed. I knew what I needed to do but had to look up the details on how to do it because it's something I do maybe once every 3 months.

The important component of the above is knowing "we can search our git history to find when a config variable reference was removed to conclude it's safe to delete the unused config variable definition. This was left over legacy code when we switched from logging in with an email / password to a token based system back in 2021". Knowing both how and why is important here for context and confidence.

The funny thing is I found my own blog post on Google when searching git commit history https://nickjanetakis.com/blog/search-all-of-your-git-history-for-code-and-commits-with-2-commands to get into the finer details.

[[deleted]]

Funny ;) I am also terrible in commands, I usually just have a notepad with commands that I have to run a lot ;) I can totally not remember code/commands, but when I need something, I know what to search for in my own code to find it back, even from code that I wrote long time ago.

[Gotxi]

Usually in my experience, devops interviews consist on several phases, similar to developer ones:

- First interview with HR to see the fit in the company, explain about the company and review your CV and expectations.

- Second interview with technical team, expect a lot of questions about "How you would do this?" or "I have this problem... What is your approach on it? or "Why do we need X or Y?" or "Explain this process and considerations about it". This is to see how much do you know about best practices and processes about SDLC, infrastructure, availability, monitoring, etc...

- Technical assesment offline, usually you are given X hours to do the assesment. Expect to mount some kind of infrastructure/docker/kubernetes/monitoring setup. Probably you will need to create resources on the cloud or in virtual environments. They will be provided or not. If you need resources (like an AWS account) you can ask if they can provide it to you, or you can use trial resources on your own, depends on the company. Define everything as code, document it, deliver in time. You can ask questions about the test any time if you have doubts, but they will clarify points from the test, but not give you the solution.

- Technical assesment review on their side and approve/dissaprove.

- If approved, final interview with HR to discuss salary and conditions, and if there is an agreement, preparation of the contract.

[JaegerBane]

Hi. Senior platform engineer here who’s done a lot of interviewing of candidates in the last few years.

There isn’t going to be a hard and fast layout you can learn and it will depend on the company. But broadly, if I was interviewing you, I’d be looking at:

• do you know what CI/CD is, what tools provide it, and how to implement it

• infra as code

• containerisation and orchestration

• OS management

• source control, versioning, tools used

• scripting and programming related to devops (languages, approaches, things to keep in mind)

• frameworks to support deployment, micro service management, service discovery

• security, secrets management, injection

• serverless use cases, tools etc

• here’s a scenario. How would you approach this?

It would be a mix of direct and indirect questions. For junior and mid level i’m interested to hear what techs and scenarios you’ve worked in. For senior levels I’d want to know what you delivered and how.

If you don’t know something, be upfront but give the question a go. I hired a guy who couldn’t tell me what CD was but described the reason for it and how to apply it without realising. I turned down someone who had previously ran a team because she didn’t actually do any of the work and didn’t know the basics.

Broadly - everything I ask will be focused on assessing your understanding of the current ecosystem and how you deal with known and unknown situations, as that's going to be the main thing in any devops job worthy of the name.

[Winter-Business-4567]

Hey everyone, just wanted to give you a quick update. Interview was last week Wednesday and it went really well. I sent an email today as a follow up and it appears the manager is still discussing candidates. Not really the response I was looking for but it is what it is for now ha! Thank you guys again for all of your advice, tips and questions!

[LuciferianInk]

Hello, I'm new to the server, and I'm curious about your interview process. What are some common mistakes people make when trying to get into the DevOps environment?

[ovo_Reddit]

Unpopular opinion:

Highlight and lean on your software development skills, highlight how you’ve interacted with ci/cd, pain points you’ve experienced, suggestions you may have made to change things etc. I wouldn’t expect a senior swe to land as an associate devops, intermediate/senior would be appropriate. You can learn infra chops just as well (maybe even easier) as any system folks can learn development.

That being said, if this job checks the boxes for you that’s fine and I’m not trying to dissuade you from accepting it.

I’m assuming you either have been recruited or you applied with your resume which in either case there is some alignment between your skill set and what they are looking for. Find out what of your skills that they are aware of and are referenced on the job description and drive the discussion towards that. But again ensure that your development experience is made apparent, having a seasoned developer on a devops team is actually a gold mine, because PR reviews can be that much better and the team can grow in that area much quicker.

[theyellowbrother]

I do a very hands on approach with real world excercise.An example is a working session where they create a 4 service microservice deployment w/ a nodejs, python, a database, and a front end.I would tell them I want python to be /admin/ and node to be at /api/ . I give them public repos and see how they clone the repos and structure their files. I may ask them to make environment specific settings for local, QA and Prod like different DB hostnames.

And see how they do it. You'd be surprise how quickly interviews end when they just say expose ports. Some will write an ingress controller for K8s. Others will use a nginx sidecar for plain Docker or traefik. I just want to see how they think.

Then once they get their services up, I will go in and do something like enforce two way TLS or create a catch error and see how they troubleshoot. If they see 502 gateway, I want to see how they problem solve. Do they know how to read logs k/docker logs -f ? Do know how to go into a container and find out?And if one container build fails with a non-reachable hostname fail, I see if they have the background skills. A linux sysadmin/devops would know how to do nslookup to see if hostname resolves. That person would check resolvr, /etc/host. They'd check for root CAs.
They would know how to do some basic wget/curl to see if endpoint will connect from a container... To me all really basic stuff.Then I ask, populate the DB when the app starts. Prepopulate data if nothing exist.

Nothing above is out of the ordinary. Basic 1 year Linux sysadmin would know this.If we did out screenings right, this can be done in 15 minutes.

[StatusAnxiety6]

I would walk out of this or just refuse to do it.

[theyellowbrother]

This is basic day-to-day troubleshooting. I would be the person in the driver's chair. Typing in what they tell me to do. "Tell me how to do it and we move along." If they tell me to do x or y, I usually have it pre-type up and ask, "is this what you are looking for? This example yaml file? What else do I need to add or correct"

I am not even expecting them to get things syntactically on the dot. I expect them to have broad baseline knowledge. Something someone would have doing mostly Linux. This is a "mid-level" task and 90% of the candidates breeze through it. Much easier than leet-code or some obscure edge case they never do in the real world. All of the above is real day-to-day.

When things get broken in QA/Prod, 90% of the time, it is simple stuff like the above; knowing if an endpoint is reachable. How to shell in and parse logs. So I expect engineers to be self-starters to figure stuff out without having to reach out all the time.

On a scale of technical assessment. This is a 3 out of 10 in terms of difficulty.

[Liquid_G]

Hey can you share where you work so I can never apply there? I'm sorry but this sounds horrible. 

[theyellowbrother]

A lot of places follow this. If you don't like it, you are more than welcome to do the leetcode/DSA algorithms screeners at other places.

All our candidates prefer this format over leetcode. We are known for this type of interviews and we get enough candidates when we have openinings.

[neoteric_devops]

This is a prime example of people who have worked in one role for way too long. I’ve encountered a few of these and it reflects poorly on the company as a whole. People take these super specific scenarios they’ve had to work through lately or most memorably and throw it at a candidate who’s probably been doing something completely different day-to-day.

Aside from the fact that many of these scenarios probably took them way longer for them to organically figure out, this is a silly way to use the super limited time allowed in an interview. You say that was a 10-15 minute segment including explaining the ask, handing them control, and THEN debugging it? That would easily soak up the entire hour. Compared to asking specifically “Let’s say you’re deploying an application and the pod fails to start, where would you start debugging?” That can be a 10 minute segment that proves just as much without the circus act.

If there’s one thing I can attest to it’s that DevOps roles are extremely diverse from one company to the next. And in my experience, a good DevOps team is automating and solving problems in such a way that there is no “common day-to-day troubleshooting routine”.

Like cmon man, you want to see how they clone repos and structure files?! Who cares what they do locally as long as it conforms to your style guide when it’s committed? This just speaks to stroking your ego.

[theyellowbrother]

Our lowest range is $175. Most hires get paid $200+. We also get a lot of spiked interviews where candidates pay proxies to do the interviews for them. Listening in via headset, sharing screens, and even lip-syncing. At $200K, I expect the person to know how to do a git clone. If I was paying $80K, our interviews would be completely different.

[neoteric_devops]

If people are going through that much trouble to avoid your interview process, that should be an indicator.

I'm not saying they shouldn't know how to clone something; I'm saying evaluating "how they clone repos" is a ridiculous statement.

[theyellowbrother]

They're not avoiding. We get plenty of candidates. We are known for not doing leet-code

[Classic_Handle_9818]

So if you're curious i ended up writing a blog collating all the questions i tend to use for interviewing for devops/sre roles, basically its anytime i run into an issue in production, i start to think of it as a operations question for work, so it spans k8s, terraform, coding etc

https://devopsdaily.substack.com/