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:
