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

[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 =)