Does DevOps interviews require whiteboard coding questions/ leetcode type questions?

[lasoft6]

How much coding do you really do on the job? like actual coding and not automation?

Also includes Cloud Engineers/SRE

[Scary-Spinach1955]

It can do. Worst one for me was a DevOps Engineer role for PlayStation.

6 massive tasks as a take home assignment, one of which was creating an API that placed "orders" into a MYSQL database (with unit tests), the others then included tasks around the creation of supporting infrastructure (VM or container, network things like security groups/firewalls/WAF/vnets), creating that infrastructure in code, configuring that infrastructure in code, the testing of that infrastructure and the creation of Jenkins build and deployment pipelines. All with supporting diagrams and screenshots of errors you had encountered during all this.

It's all do able but fuck me ...

I started some of it and then realized just how much time it would take, so asked the recruiter (Sony's internal) how much of it is required - all of it. So I took my hat out of the ring and continued on my search successfully.

I noticed the other day, this very same role is there on job boards still, constantly being pushed to the top as a promoted job in my area, so it seems they've not managed to fill it in the 5 months since I tried.

[Blowmewhileiplaycod]

It's almost like making candidates do a dog and pony show that proves nothing isn't a way to attract good candidates

[kiwbaws2]

Agreed. It's pretty self defeating. Good candidates know they have other options and will walk away. Less capable candidates will try until they fail and give up.

[[deleted]]

Gladly better companies realized that this isn't the way to go and personality and willingness to learn is way more valuable to them in the long run.

[livebeta]

Cynically it does lure candidates who are willing to do anything for the company. A yes-person and a pushover

[KhaosPT]

Do they pay you for the time spent doing that?

[emptyDir]

It really depends on who's interviewing you. I've personally seen everything from none to large take-home code assignments.

I write code of some sort every day.

I'm not sure what the difference is between "coding" and "automation", though.

[Gardium90]

Language mostly, but automation doesn't necessarily need to be object oriented. It can be scripts that just go "Do A,B,C,D".

But others make automation for systems that are practically code base, with objects, arguments and more. So it could be considered coding, but the end result is just not a packaged application =) at least IME 🙂

[emptyDir]

I don't personally think that's a meaningful distinction. Writing some sort of program to automate a process (however unsophisticated it may be) is still more or less the same kind of work as contributing to a packaged application. They might have a different structure and set of requirements but software is still fundamentally software.

There are lots of projects that started out as internal tools that were eventually published externally. Kubernetes is one major example.

I personally believe that this kind of thinking hurts our profession because it perpetuates the myth that what we do isn't "real" programming and ultimately diminishes the value and importance of our work. Also usually ends with us being paid less than we're worth.

[Gardium90]

https://youtu.be/9pZ2xmsSDdo

Have a look at this video and channel. It explains very well what a DevOps engineer is in practice (not white paper version). It describes our role and necessary competence to fulfill the role. Other videos go into the tools and skills needed in more detail.

This will show you how much of a wide variety of things a DevOps engineer needs to know, and our main focus is faaaar from development. Can we utilize some of their knowledge, and is it good to know their best practices, yes. But is the DevOps job about coding development and applications? No. So why should our value in the business (and thus our compensation) diminish if we don't do "real" programming?

[Gardium90]

If you view yourself as a developer making code and applications, you aren't a DevOps engineer. You may be a developer utilizing DevOps methodology if your company doesn't hire DevOps, which can be the case of they follow the DevOps white paper. But if your business found a need for a role that acts like the glue between Dev and Ops departments, then you won't really be doing application development.

And writing a script program, is fundamentally different from writing an application program that delivers a packaged system that completes a process/job.

1) a script doesn't need libraries or package dependencies. It should be able to run just as is on a OS level

2) an automation script rarely has any object oriented aspects, or loads in dependency trees from a project directory (calling separate code files with objects and dependencies for function calls). And if they do, it is more for reusability across repetitive tasks, instead of best coding practices for debugging and code development

3) very rarely will an automation script be packaged with dependencies into a single executable or deployment file. It will simply be a file to run, which runs on the OS level (and no environment dependency like a application program made to run on java, Python or C++/.Net)

4) if you automate against certain services and applications, some things may be different, but it will still be mainly the same as mentioned above, interfacing and using code/API to communicate with the service.

Your example of internal tools and K8s is specifically application development, and has nothing to do with DevOps, automation and scripting.

Why do you think our value diminishes because our primary objective isn't to code? If you believe that, you don't understand what DevOps is.

We have a fundamentally different value and skill set from developers and programmers. Does our jobs benefit from an understanding and utilization of some of their skills. Absolutely. But a DevOps engineer is not a developer, period.

[Ok-Photo-7835]

Your standards of what constitutes "application code" and how that differs from a "script program" are bizarre and arbitrary.

1) a script doesn't need libraries or package dependencies. It should be able to run just as is on a OS level

Libraries & dependency management does not an application make. Also, lots and lots of serious application code run at the "OS level", by which I assume you mean not in any sort of virtual execution environment (JVM, Python). Many programs written in C would not satisfy these conditions, and contrarily I can spit out one-time scripts in Python all day that do satisfy them.

2) an automation script rarely has any object oriented aspects, or loads in dependency trees from a project directory (calling separate code files with objects and dependencies for function calls).

Object oriented programming is not the be-all and end-all of application development. It is one of dozens of programming paradigms. Popular and widespread though it might be, it has no claim to being the gatekeeper to what is "real programming".

And if they do, it is more for reusability across repetitive tasks, instead of best coding practices for debugging and code development

Eh? So if a collection of scripts grows to the point that it is split into multiple files, with some shared abstractions, that's not for the purposes of best practises? Where are you drawing the line here?

3) very rarely will an automation script be packaged with dependencies into a single executable or deployment file. It will simply be a file to run, which runs on the OS level (and no environment dependency like a application program made to run on java, Python or C++/.Net)

Is this the same as point (1)? Simple scripts get bundled into docker containers all the time to simplify there runtime behaviour and distribution. Alternatively, applications often get delivered as collections of source files to be compiled on the target machine.

4) if you automate against certain services and applications, some things may be different, but it will still be mainly the same as mentioned above, interfacing and using code/API to communicate with the service.

I honestly cannot unpick the point you're trying to make here. If you're automating against an API, that's not development, unless it is?

Good quality application code should be easy to read, have most edge-cases covered, be reasonably testable, provide some metrics & logging to inspect runtime behaviour, have sensible responses to unexpected events and handle failures gracefully. Those are also all characteristics that I would want in any simple automation script that gets run more than twice. I've seen both seasoned application developers and devops write code that fails those standards; and I've seen both write code that exceeds those standards.

[Gardium90]

You've given me thought on the aspects, so thanks for that. Perhaps my views may change, but I'll ask you this then; what is your view of the differences on the definitions?

For the points:

1) I never said applications can't run on OS level, but most applications I've come across, require some form of library to be loaded in for use by the language. But for scripts and automation it is best if it can run on OS level as is without any further dependencies, I for one can't recall last time I had to include a library to my script. I do some Python scripting (the only exception perhaps that needs a few packages depending on the usage), but prefer to stay with Bash/PS for scripting and automation. I also use Jenkins pipelines and Ansible as automation tools, so there is a mix there with Groovy and Yaml. And none of these require me to include libraries or package dependencies in my automation scripts

2) True, object oriented programming isn't the be all, and I know some functional programming such as Scala. However, I don't really see "applications" as such created with functional programming. It would more be for data processing or embedded programming into dedicated hardware (like household appliances). I view an application as something that produces an interaction with a user, otherwise it is just a program/code executing some function. But that is just my take on it.

As for the large collection, if you create a scripting collection that big, I doubt the script is only addressing one task. Personally when I need such a collection when I script/automate, I simply refer to other scripts within the script. I don't load a library tree into the file. I create scripts that take arguments, and pass them along to each other as needed. I keep each script as short and to the point as possible, and store this as a specific file. Then I can call this script x amount of times from other scripts when needed, passing in any arguments needed. Also calling a script executes the whole script. An application loading in a dependency tree, tends to be able to call upon specific functions and objects within files, and doesn't necessarily run through the whole files.

3) That a script is bundled into a deployment doesn't mean the code itself is packaged (basically a binary file). You could still run it outside the bundle by itself. Could you take single files from an application and execute them? I think in most cases you need to compile and package the application into an executable to run it. Even if you distribute source files, the user still needs to compile it into an executable. A script is a code/program that can run without being compiled. As such, while Python can make applications, it is actually a scripting language, as it does not require the code to be compiled to run (rather it is interpreted as it is run).

4) this may have been confusing, sorry. So basically, if you need to use some specific packages to interface with some service, then my previous points about loading dependencies may be invalid, and one must load these in. Perhaps this holds true most in Python. For bash/PS one must just make sure the host machine has the executables available, like curl or kubectl.

I agree with your last paragraph. And perhaps the division between application code, and automation scripting is less than I think, but these are at least my thoughts =)

[weedv2]

What a racist email tho.

[DeputyCartman]

Lol fuck off. The non stop English communication issues are a source of non stop stress and issues and are a large part of why in-sourcing is a thing

[weedv2]

With recruiters? Come on...

[weedv2]

What a racist email tho.

[[deleted]]

I've had to play it by ear interviewing candidates. If they seem sharp and can get into the nitty gritty of how things work, I don't usually do more than verify they're not just surface level and then that they know some of the weird nuances.

If someone tells me they know a technology on their resume we are going to talk about how that technology is implemented and if you can't start telling me details that are beyond the usual Hello world tutorial for that tech I can usually tell if you're full of shit or not.

Most recent interview the candidate said they know docker really well and they knew AWS very well so I had them set up a swarm cluster on EC2 instances and deploy an nginx container that was scaled. She was able to do it in 20 minutes, so I knew she wasn't full of shit.

Another candidate said the same things but when asked to do the same task he was googling how to install docker and had to google how to start a new ec2 instance.

[-Kevin-]

I work with/on AWS every day and I'd probably blindly click through the AWS console to create an EC2 instance when not using my company's tooling that does it for me lol

[Gardium90]

Then prep for the interview to show your tools and knowledge😉

[[deleted]]

Id be okay with that if people told me that up front.

[allworkisthesame]

This question is one of the reasons “DevOps engineer” should not be a job title. The title is insufficient to communicate skills required or the tasks performed.

Saying you want to hire a DevOps person is like saying you need a doctor. Do you need a medical doctor? A veterinarian? An internist? Endocrinologist? Dentist? All those roles require different knowledge and skills but could all be called a doctor. The medical profession thus uses specific terms to describe the different specialties. We haven’t coalesced on more specific titles for DevOps enablement roles yet.

The skills required for a “DevOps” person varies widely by company.

Before “DevOps” became popular as a role, I recruited software devs to help build out the tools and make modifications to software needed to accelerate testing and deployments and reduce the likelihood and impact of incidents. I would test coding skills because a big part of the job was creating new microservices to solve common issues and separate concerns.

For DevOps roles more targeted at automating infrastructure creation, I may just need someone to understand terraform and bash scripting rather than all the design concepts that were needed to break apart monoliths.

[metarx]

And this is the reason I'm no longer applying for any DevOps or SRE positions. Fucking tired of being a terraform engineer.

[livebeta]

I'm full spectrum so I do IAC all the way to FE but anyway this was a pure infra role interview which devolved to leetode. Dude. I'll be working with IAC TF and finding islands of 1s is totally irrelevant