DevOps Technical Interview Questions : devops

reddit.com /r/devops/comments/4yf8cm/devops_technical_interview_questions/

[–][deleted] 11 months ago*

[deleted]

[–]BathroomEyes 5 points 11 months ago

How is knowing the difference between an IDS and an IPS a "hard Linux question"? It's a concept that's OS
agnostic. Also a fork bomb? That's more gee whiz than pertinent Linux knowledge to ask in an interview. Otherwise
it's pretty fair game to ask these in an interview where Linux background is required.

permalink
embed

[–]AsciiFace 12 points 11 months ago

Basic Linux knowledge is why I fail almost every software engineer turned "devops" applicant I interview.

At least fucking try to pretend you have done more than generate SSH keys one time, when you expect me to let
you develop infrastructure

[–]djk29a_ 3 points 11 months ago

I've had a hard enough time finding people that are ex-software engineers turned devops than network or sysadmins
that never learned much more than really basic Linux and mostly know vendor tools in their knowledge toolbox. It
depends a lot upon your recruiters though I suspect and may say more about who they're familiar with. Some of the
good software engineers have spent enough time on the command line through the years to have acquired some
decent bash-fu. If you were never a very good software engineer, I don't see how they'll ever be much better in
devops (although operations is a very different mindset to the point of technical approaches being almost mutually
exclusive).

I poke candidates to see if they could explain systems admin like they were software engineers first. If they talk
about how exponential back-off is not actually exponential time when I talk about how it's used in certain network
protocols and requirements for distributed systems job progress, we're on the right track. Unfortunately, none of the
jobs I had really stretched my algorithmic knowledge of everyday systems.

[–]pdp10 1 point 11 months ago

I'm curious to know the weaknesses coming from the other direction. I get the feeling some outfits want to quiz
netops on big-O or something.

[–]djk29a_ 3 points 11 months ago

If I was asking for a network guy that is going to build automation tools to some scale I'll definitely ask about sorting
algorithms and where hash tables are appropriate for storing data and progress that into a higher level question like
"given this criteria, would you prefer to use Redis or Postgresql for storage?" (using what they say they used on their
resume - presumption is that I know wtf it is though). But for the most part most places doing operations hardly
performs automation at a speed and scale that requires some serious thinking about time or space complexity. Most
places are still focusing on the k in k * 2n => O( 2 n ) when it comes to touching computers.

1/7
[–]ihatemovingparts 1 point 11 months ago

I'll definitely ask about sorting algorithms

IMO, knowledge of algorithms is a win (big-O, space/time tradeoffs, etc). If you're querying an API over any sort of
WAN or high latency link, time tradeoffs can easily come into play. AWS APIs and any sort of API proxy come to
mind. At my last gig we had a desktop product that made a few hundred API calls to endpoints in the United States
at startup. Not terrible for the majority of our users, but overseas (especially in China) people balked because
performance was atrocious. I always thought asking about sorting algorithms was a bit of a dick question, however.
Pretty much every environment will have a variety of sorting primitives.

At the other end of the spectrum, my current coworkers are the sort that want to understand all the minutia (which
sorting algorithms are IMO) to the extent high level concepts like maintainability and scalability suffer.

[–]djk29a_ 1 point 11 months ago

If you're talking about latency and networking, then we're still in the land of k instead of O(n) though. In a case like
that, knowing what bandwidth delay product is and what it helps measure is substantially more important than
whether you can figure out the pseudo-polynomial time algorithm for knapsack problem.

If you're asking candidates to use tools much more often than to write them, it's more important to ask about
knowledge and application of tools than whether they could write something from scratch, sure. But even still,
candidates that have zero idea about why quicksort is faster than a selection or insertion sort (or even down to why
quicksort is slower than an insertion sort) tend to write code that's not as elegant and have a tendency to come up
with pretty strange solutions in my experience. I saw a guy choose a data structure used as a sorted list of hashes
as... a hash of hashes that is sorted repeatedly. I've just never observed this kind of lack of thought about data
structures with people that can explain how quicksort works to some degree. Then there's the more common issue
of "I didn't think it was a big deal to loop through A, B, C, D, E, F, G... because computers are so fast" that happens
far more often with people that don't know where to cache / index and where not to beyond "I think we should setup
an index on a SQL table column."

But yes, there's absolutely more important technical skills than pure algorithms in team software engineering like
how to write maintainable code and to communicate to future engineers effectively without writing whitepapers that
nobody will read. This is almost impossible for me to gauge without seeing a work sample though, unfortunately.

[–]ihatemovingparts 0 points 10 months ago*

If you're talking about latency and networking, then we're still in the land of k instead of O(n) though.

D'oh.

If you're asking candidates to use tools much more often than to write them, it's more important to ask
about knowledge and application of tools than whether they could write something from scratch, sure.

Fundamentally I think that using tools is going to be more common than actually needing to write them. My
experience has been that typically ops stuff is not as unique as many people would like to make it appear, and that
the real value is knowing knowing when you really do have a unicorn.
2/7
That's not to say that coding is not useful. In fact, when using tools because it allows you to contribute back to and
engage the community in more meaningful ways.

But even still, candidates that have zero idea about why quicksort is faster than a selection or
insertion sort (or even down to why quicksort is slower than an insertion sort)

OK. ELI5. Why? XD

I took a brief gander at the explanations on Wikipedia and it looks like: a selection sort has predictable (fixed)
performance and preserves the order of equal sort items... but quicksort's worst case is equivalent to an insertion
sort's performance.

I saw a guy choose a data structure used as a sorted list of hashes as... a hash of hashes that is
sorted repeatedly. I've just never observed this kind of lack of thought about data structures with
people that can explain how quicksort works to some degree.

I... what? Geez. To me that goes beyond even rudimentary algorithm knowledge and more to the if you're doing the
same thing repeatedly perhaps you should figure out how to stop repeating yourself.

"I didn't think it was a big deal to loop through A, B, C, D, E, F, G... because computers are so fast"

Having some rails experience this is pretty amusing to me. Ruby objects are big, nasty things and Ruby will bog
down quite nicely iterating over surprisingly small collections.

The counterpoint is that immutable stuff that's all the rage these days where you're encouraged to iterate and return
a new immutable collection versus modifying your existing one.

This is almost impossible for me to gauge without seeing a work sample though, unfortunately.

IMO this isn't really an unfortunate situation. IMO something applied like a work sample is going to be far more
useful than something abstract like regurgitating CS coursework.

When I've sat on the other side of the interview table I enjoyed giving fizz buzz. More than simply testing algorithmic
knowledge it provides insight into a person's thought process. And it's an incredible low pass filter. Most people I've
given it to failed. And I gave an explicit instruction that they could look at Wikipedia or anything they desired for
clarification. Seriously. People utterly failed rather than copying and pasting code from Wikipedia.

I had one guy insist he was an (ba)sh wizard. He spent about fifteen minutes trying to figure out the modulo operator
(okay he's showy not pragmatic, doesn't know his limitations, didn't try to find an alternative solution). I had another
guy ask a couple questions, knock it out in python, walk through the code mentally, run it, then hand it over to me.
The latter was pretty rare.

[–]djk29a_ 1 point 10 months ago

3/7
Because this is devops, engineers may want to know enough about programming and fundamental algorithms to not
be laughed out of a room by developers and ostracized, but if they don't I will accept eagerness to learn in its place.
Refusing to sit and handle just your corner of the world with a hardline "it's not my job" attitude is pretty much an
instant-fail for me less excusable than failing FizzBuzz.

OK. ELI5. Why? XD

Divide and conquer works well on many problems. Hide and go seek is faster with more people seeking and that
work together carefully.

While fizzbuzz culls non-programmers or hunt-and-coders, most competitive tech companies can't afford to set it as
a bar for their in-person interviews even if it's only a few minutes due to some competent people being offended by
such a test, but that's another debate entirely.

[–][deleted] 11 months ago*

[deleted]

[–]echnaba[S] 1 point 11 months ago

I think it went reasonably well. I work in a Microsoft/Azure shop, and the position was for a Linux/AWS shop. There
were some questions I didn't understand about Amazon, but I think that link really helped out with the other
questions. There were lots of questions about network setup that I didn't even expect until you sent the list.

permalink
embed

[–]Merakel 2 points 10 months ago

Nice list. Is there a list of answers, at least to the ones with 'right' answers?

permalink
embed

[–]blakfeld 8 points 11 months ago*

Other people have said good things, but I think DevOps is more big picture stuff.

In an interview, I assume you're pretty proficient at scripting/programming, and know basic systems administration.
Some people hark on those things, but I only ask enough to ensure I could trust you to be left alone with it.

What I really want is architecture.

I usually describe a service, and then say "Okay, now we've received the Reddit hug of death, and after that spike
our new normal is double what it was. How do we survive that spike, and maintain the new normal."

permalink
embed

[–]xgunnerx 4 points 11 months ago

I wish this was the top comment. That's actually how we conduct (a large part) our interview. We draw up a basic
4/7
lamp stack from the early 2000's and then ask them to draw and discuss how they would scale it to modern days
standards. We ask them to talk about various pieces and parts along the way, why they chose this over that, how
are they securing things, important metrics, etc. There's no PASS/FAIL here, just a sense of how proficient someone
is. I've found this approach VASTLY superior then launching a bunch of various textbook linux questions/scenarios
at them.

[–]echnaba[S] 2 points 11 months ago*

I wish the interview was like that, lol. Is your company hiring? And is working in Dallas or remote a possibility?

[–]echnaba[S] 1 point 11 months ago

Dang, nothing in Dallas area. Thanks though.

[–]blakfeld 2 points 11 months ago

I'm remote out of Austin, so, if you're interested you should apply anyway.

[–]echnaba[S] 1 point 11 months ago

Good to know, thanks.

[–]Xophishox 2 points 11 months ago

We were very much similar to this as well and are hiring.

Edge web hosting in baltimore. Both devops + implementations people (strong dev + systems admin skills)

[–]berserkeMaster of None 7 points 11 months ago

Aside from the ops stuff, fizz buzz in any language, what 99th percentile means, when to use a bar graph instead of
a pie chart, what to do in a sev 1 outage, sev 4, how you deal with a manager/coworker you don't get along with,
how you manage your documentation, when to think absolutely automating something.

There are plenty more, just what comes to mind.

permalink
embed

[–]shabangbinbash 5 points 10 months ago

I essentially never stop interviewing, just to see what's out there and what people look for. A lot of questions should
be, rightfully, environment specific to see how well your knowledge matches up with their environment. But
generally, if I had to hire someone, it would be:

1) Have you ever used git before?

Docker
Cloud Providers (AWS / GCE / GKE)
5/7
 Terraform
Packer (if not docker)
Maven / Gradle

6) If AWS, do you have any experience setting up autoscaling groups? Security groups?

These are pretty general questions, but people may ask you specific ones as well. One that I've asked before is:

"What is the first file that puppet reads when it runs?" (init.pp, site.pp, are possible answers depending on
context they give you)
"What is the name of the file you organize your code into in Ansible?" (Playbook / main.yml / role, are all
possible answers).
"What library would you use in Python if you were making a script to talk to AWS?" (boto)
"What file extension does terraform look for?" (.tf)

Also, and mostly importantly, don't bullshit someone. If you're caught bullshitting, you're chances of getting the job
go to 0. Tech people can smell bullshit a mile away. Just be honest. If you don't know an answer, it's ok to say "I
haven't used this before" or "I honestly don't know the answer, but I'd like to know it." That looks far better.

permalink
embed

[–]echnaba[S] 2 points 10 months ago

I definitely agree with the last part you said, about not bullshitting. During the interview I made sure to say if I didn't
know something. And once they explained the answer, I tried to relate it to something I do know, so hopefully it got
across that I understood what they were talking about.

[–]Xophishox 5 points 11 months ago

You're going to be asked lots of questions that focus on scripting, automation infrastructure, your competency in
managing cloud systems, your knowledge of providers (vsphere, aws, digital ocean, azure), Your ability to support
multiple different languages (java stack, node stack, oracle stack, etc). You'll need to to show confidence in your
ability to support a wide range of OS deployments, and hardware/virtual infrastructure. Understanding of core
windows, & *nix principles and how they work is very very key to our job, system tuning, application deployment,
architecting etc.

DevOps is very much systems administration with the ability to understand the requirements of developers and
supporting them. Anything you've ever had to ask a sys admin to do for you, is something you'll potentially be
questioned on.

All of my DevOps interviews went as such.

1. Discuss overall knowledge & technical aptitude I had with various systems. This includes Hardware
Knowledge (think deployment of datacenter hardware, whats required, what would need to be architected for
a proper deployment), It includes Software knowledge, IE what applications are you comfortable supporting,
(Databases, Web Servers, Automation (puppet chef ansible)) etc.

2. part was always code review, showing that i am confident in deploying automation code (chef/puppet in my
case) as well as defining Infrastructure as code, and showing my ability to understand it.

6/7
3. is always a general linux / windows (relative to env) knowledge test. ie Something tricky is broken or
randomly acting funny and you need to figure it out. One interview i had for a contract position was a simple
logrotate change (re-sizing of the logs before rotation). Simple but if you dont know it, thats bad.

permalink
embed

7/7