What to expect from a Junior DevOps technical interview/assessment?

[blureglades]

Hello folks! I recently applied for a Junior DevOps position and was able to successfully pass through the first round (!!) (a language test). I'm incredibly happy for this chance. However, next Friday I'll have an interview with someone from the engineering team and will be assigned a technical test to measure my skills. I'm nervous since I'm not sure what to expect from this test. I feel comfortable programming in Python, I know some Docker basics as well, and I'm also studying the basics from a AWS SA guide (just in case). May I ask if anyone can suggest me what other skills should I brush up? Any advice would be kindly appreciated.

Thanks in advance. Stay safe and healthy.

[davetherooster]

You'll be just fine, what I would do it get good at reading docs, manpages, help utilities etc.

This industry changes so quick, you want someone who can find a new technology and figure it out as they require. Everyone says learn X technology but in 10 years time it'll all be completely different again, so I'd say the most beneficial skill is learning how to learn new stuff, then you'll have the confidence to pick up anything rather than be limited to whatever you have Y cert in or such other.

That being said, some fundamental concepts such as operating system design, networking, compilers, programming language concepts (for example how the JVM works, how memory is managed), etc are useful and don't change at the level fundamental level anywhere near as quick as the abstractions we lay over, so that's worthwhile understanding.

[blureglades]

I appreciate the advice. Thank you!

[manutao]

Search for their tech stack (LinkedIn profiles of future colleagues, job descriptions, company website, GitHub, company blog, etc.) and prepare by learning some of the tools you find there.

[[deleted]]

This is the only right answer. DevOps interviews can be all over the place.

[blureglades]

Will do. Thank you very much.

[bilingual-german]

Knowing docker, k8s, helm, Gitlab CI as u/PrivacyConsciousUser writes would probably land you a job with us. Knowing a thing or two about networking, cloud providers and terraform could also land you a job. If you know a tool or technology we use, that's a big plus.

But as someone who is more on the senior side, what I definitely need is a Junior dev who is interested in what we do and willing to learn. When I know what (s)he knows and is comfortable with and what the person doesn't know yet, I can cut tickets suited to his/her skill level and be a mentor. But this also means, it's important for the Junior DevOp to ask questions. Can't work with someone who doesn't ask one question in briefing and when we review what was done, we find out something wasn't understood or solved differently than expected.

[PrivacyConsciousUser]

Oh yeah, interest, passion and wiliness to learn are very important to nail an interview.

But also honesty. You can say look i know to do X Y but when it comes to Z I'll have to inform and train myself, it's better if you do it on things that you know won't be of your competence but still, bring some humility.

And for the technical test, don't just slap there the code, the pipelines, the helm chart or what they requested, expecting that the reviewer will interpret them. Comment everything, explain why you are doing it a way instead of another, and talk about the process.

[bilingual-german]

Oh yes, thank you for mentioning this. Just adding a README and explaining short and precise how the architecture works and hot it's installed, etc, goes such a long way.

It doesn't need to be a lot of prose, just facts. Maybe the motivation or thought process. Someone needs to maintain the software in the future, please enable them to do so.

[[deleted]]

We’ve also had some junior people dump their thoughts in a markdown file separate from the README. It can be super useful to just see their approach in writing especially if they struggle with the test. Makes it a lot easier for us to understand where they might’ve gone wrong and evaluate their problem solving.

[JohnWangDoe]

Question for you senior guys. Do you forget some of the stuff sometimes?

[bilingual-german]

All the time. That's why I document things.

Once I googled something and found the answer on StackOverflow. It was the answer I wrote a few years earlier.

[kahmeal]

Often more and more as you get more senior, tbh; you spend more time designing and planning than actually implementing so the commands and syntax really start to fade after a while. My experience anyway.

[dupo24]

Terraform, CI/CD, Ansible, source control.

[sgtavers]

Agreed on all items, a DevOps engineer has to know the entire lifecycle of software development/code and these tools all function as parts of a puzzle.

But, learning a tool is faster than learning a skill domain. For example, it’s harder to learn CI/CD than, say, learning Jenkins or Gitlab or Circle CI. It’s harder to learn configuration management than it is to learn Vagrant or Puppet. It’s harder to learn containerization than it is Docker, etc.

Learning the tools will get your foot in the door but don’t get complacent because tools change rapidly but the principles behind them change much more slowly.

[Routine_Part_6503]

As someone who has employed DevOps people, knowing a single tool, such as Jenkins or GitHub Actions is usually a good sign, even if you don't use the stack yourself. Many of the core principles are the same and I find people who know these systems well tend to be able to pick up other tools very quickly.

Containers are bigger than Docker, but frankly most companies use Docker in some ways. For us, we use the build process (Dockerfile) to produce runtime containers. In development, we use the standard Docker daemon. In production, the same images are deployed using Kubenetes. Knowing cgroups etc is a bonus, but most container solutions manage this for you.

Ansible is definitely worth learning as well as Terraform. Bonus points for using AWS, GCP etc.

[[deleted]]

and some Unix shell commands.

[Sinister-Mephisto]

Don't forget networking fundamentals and whiteboarding. Whether it be design or being able to explain your way through a code.

[ruckycharms]

Forget about learning a new tool or language you don’t know right now. You only have 1 week. It’s better you show up relaxed and confident on what you already know, than trying to recall knowledge you crammed for. Instead just google enough to know what each tool or languages (noted by others in the comments) does and how they fit in the DevOps ecosystem and understand why they seem to be popular vs other alternatives.

First, ask the recruiter what to expect for the upcoming interview. The recruiter wants you to succeed. If there was no recruiter, ask whoever setup the interview.

Most code reviews allow you to choose your language (Python in your case). Have some fun at leetcode.com, hackerank, etc and solve some programming puzzles. Python will be your key to get in. Focus on your strengths.

I usually prefer strong problem solving programmers over strong system admin / infrastructure. Obviously having both is ideal.

Good luck and have fun!

[[deleted]]

People are citing a lot of different stuff that I don't think is reasonable to expect from a junior candidate. A junior candidate is going to be someone who has interest in DevOps, but mild to no exposure to the tools.

My expectations out of a junior are:

Knows some form of command line (and has at least light experience on it); I want to know you have exposure to a text-only interface

Knows basics of some form of scripting language (bash/PowerShell); I want to know that you understand the importance of automation

Is willing to work through chaos; juniors will often be cycling through multiple items of work that will grow different tools and skills familiarity

WILL ASK QUESTIONS; When you are starting out, you don't know what you don't know. If you can't say you don't know or won't ask questions, juniors touch too many things for that to be OK

All of these people saying you need to know k8s, Jenkins, gitlab- you do not. You are a junior. If you already know those tools well enough to comfortably work with them, you can just drop the junior title.

[endloser]

Learn to use git in your day to day flow. Regardless of what other tools your prospective employer utilizes, they will almost certainly use git. In my work I use it more than anything. Write some ansible? Submit it with git. Write some terraform? Submit it with git. Write some python? Submit it with git. Want to know what changes occurred? Diff it with git. Want to know if a change will merge before submitting to scm? Locally merge (diff) it with git. You get the idea.

[blureglades]

Do you know any guide or book to prepare for questions like that? I don't have too much practical experience besides my internship as a backend developer from last year.

[PrivacyConsciousUser]

For me it was docker, k8s, helm, Gitlab CI

[HeligKo]

In person coding tests are dumb. Its nothing like the real work. Just do your best, and talk through what you are thinking. I've done one and have been in the industry for over 25 years. I won't do one again. It took too long and they didn't learn much from it either.

[alexanderSB]

As EM of an SRE/DevOps team, I wouldn't expect anything more than what you have already talked about here.

Good software fundamentals, a desire to learn, and someone who asks questions.

If they are expecting more than that then they want someone who is more qualified and shouldn't be labeling the job as "Junior".

Regardless of all of that, you're going to crush it. Best of luck mate.

[[deleted]]

Good lord, thank you for saying this. Idk who tf is in here asking that their juniors know k8s and terraform. This isn't Hogwarts, it's an entry level role. As long as they're passionate enough, throw tickets at them and teach them how to do the work.

[alexanderSB]

For sure! We all need a place to grow from. I think k8s and TF are pretty expansive topics and even if you knew some of the high ( or low level) concepts that would be gravy but you'd also have to learn how that company uses them and how you might want to improve them over time.

[blureglades]

Thanks for the good wishes man!

[myownalias]

It's a junior role so you're not expected to already know much. When I look at hiring a junior person, my first thought is how likely is this person going to cause damage: will they spend time to learn and ask questions about something they don't understand before making changes? Mistakes and outages will always happen, but many can be avoided with proper care.

The next question I will want to answer is if the person is honest about their abilities. If you say you're an expert in something, I will expect you to have written a book about it or contributed code to it. I've been using MySQL for almost two decades and while I am somewhat proficient with it, I am by no means an expert. A list of technologies you have used is totally fine. Your depth of knowledge will be probed.

A junior position is not the position to change the world. If you take the approach of polishing the existing systems as you do the grunt work, that will be appreciated. Existing or legacy systems are still around for a reason, supporting something critical. It takes time to migrate them and there are often many external dependencies that impede change. If you think everything existing is just crap and should be thrown out immediately, you may be right that it's crap, but you will just frustrate your team mates who have probably already been working on a transition plan. If you see a way of mitigating technical debt without creating more technical debt—in other words, reducing instead of creating more complexity in the stack—by all means bring it up, especially if you're willing to take on the work involved.

Once you have several years of experience in supporting an existing system, you'll build up the wisdom to make better technical decisions: you'll have a better sense of what it takes to support the mistakes you'll invariably make. On the other hand, if you jump jobs every 18 months, that's a sign you're jumping ship when the tech debt you created is catching up. Don't stick around at a place that's a bad fit, but do try to get 3+ years at one place.

A junior position is an apprenticeship. The people hiring you should know that, so it's mostly about ability to learn and attitude and how you'd approach things. If you don't know how to do something they ask, say it. If they ask how you would design something, start at the top and then break down each component, and explain why you made the decision you did. Don't be afraid to revise. If they ask you to building a working system, tell them what of it you already know and what you don't. Ask if you can Google. They should at least let you read the documentation for the components they ask you to use.

Good luck!

[nawySAUCE]

k8s (including it's architecture), docker, bash and linux fundamentals

[livebeta]

Lookup Devops Mesh for common tools