5 red flag questions to ask in a Linux interview

Subtle gotchas that tell a lot about a firm’s tech culture

Red flag made with three pieces of paper-based sticky tape

What are your change control processes like?

You want a nimble firm where it doesn’t take a month to change a VLAN, but also values stability of the prod environment. What permissions hierarchies are there? Who approves what? What needs a PR and what doesn’t?

Do you promote modern languages like Go, Python and Rust?

Most large places have unavoidable legacy infra you’ll work on. Does prod hang on by a Perl script someone wrote in the early 00s, or is there an active drive to address technical debt? Consider a push toward web apps a green flag.

Do you promote “infra as code” frameworks like Ansible and Puppet?

Are homemade configuration tools being used? Sometimes this might be impressive but wacky reinventions of the wheel require investigation.

What are the firm’s views on containers?

Apprehension toward containers is a red flag. With tools like KubeVirt, even VMs can now be run on platforms like k8s. Containers significantly reduce support burdens due to a “Bring Your Own Environment” approach. This makes your life easier. Resource-wise, it’s a lot cleaner than a “VM for everything” approach too. Mature firms probably have a balance of bare metal, some VMs and a container orchestration system like k8s or Nomad.

How do you deal with server upgrades, and what happens to out-of-support distros?

It’s unreasonable to expect the firm to run the latest bleeding edge Linux kernel. That may introduce instability. It’s also unreasonable if the entire estate is running RHEL 6. Are exceptions made for old boxes? What support is expected if a BU can’t move away from a legacy box? Who signs off risks? An even bigger red flag is lots of different distros in the environment without a good reason.

I’d like to “sticky” a very succinct comment from a reader on Hacker News:

And here I thought I was the crazy one for having been burned by the negative answers to these questions in the past and thought I was the only one asking. It's been my experience that the actual content of the answer doesn't really matter, the technology or process could lean one way or another for all I care, it's the candor by which the questions are answered:"oh god no we don't use container shit" (actual answer I've had) versus "it's something we're looking into and evaluating"."why do we need to use config management shit" (actual answer, same company as above) versus "we've had some success with it, struggles otherwise, do you have experience that you could lend us with that?""change control? you mean doing everything as root and cowboying it doesn't count? what kind of idiot are you?" (less verbatim answer, same company, but hints at what I'm getting at).If the interviewer answers like a child (and I have been the receiving end of that), I don't really care about the answers at all. If they are thoughtful, I'll considering going along with the rest of the process.