Red flag questions to ask in a Linux interview

> Apprehension toward containers is a red flag.

Unqualified statements like that are unqualified B.S.

Not all environments gain anything from containers, and if you have "ultra-stability" requirements like, e.g., those found in banks, avoiding newfangled containers for oldfangled methods which are known to work well and for which the organization has long-proven fallbacks is not only legitimate, but arguably preferred.

Use things you need and don't use things you don't. If someone makes a general statement that you need something for everything - that's a flag more red than Soviet Union's.

> Is everything glued together with a few bash scripts

The whole GNU/Linux world is glued together with a ton of {ba,}sh scripts (typically - there are exceptions, of course). Sometimes, all you need is another small one. And, of course, sometimes (and quite frequently) it's not a great idea. Depends on what you need to do and what it could evolve into.

> Apprehension toward containers is a red flag. With tools like KubeVirt, even VMs can now be run on platforms like k8s.

Same principle applies. Extra technology to set up and maintain is a liability. But if adding something helps you to remove a need for something more complex, then it's logically best to make smaller sacrifices than bigger ones. Unless, of course, you shift this liability to a contracted party and you're happy about it - that also works.

> 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.

A script being in Perl is is not "technical debt". There is nothing wrong with Perl. On a personal level I don't especially like Perl, but it's a perfectly functional language that's fit for purpose and I would never claim there is something with with a script just because it's written in Perl.

Of course there can be plenty of good reasons to replace such a script: if it doesn't work well, if its too hard to adapt to new requirements, or something else. But merely "it's Perl" is a complete non-reason.

And such scripts don't need to be "old" in the first place; maybe people actually like Perl and is something that works well for them? So the assumption is some old crufty script is wrong in the first place.

This entire list is an enormous red flag of "I have one preferred way of doing things and anything else is wrong". These are the sort of people that will join a team, spend 2 years rewriting perfectly working systems to ... other perfectly working systems, and then leave after two years with a far greater mess than when they arrived for everyone else to clean up while they can spunk off keywords on their CV.

Would the following be a red flag?

"We promote modern languages like Python! We've had our own Python 1.5 based fork for 20 years now; there's some documentation, mostly from 10yr ago when the guy who started the project died. But we've got a good maintenance team and they understand almost all the magic he wrote in."

> Apprehension toward containers is a red flag.

"(almost) all our servers are in containers: we started buying cases after Ptyhon dude died, too. Previous server generations that live as stacks of unsecured hardware on shelves are being upgraded as can by the maintenance team."

This list reflects the patterns of thought that get continual transition to the current “best practice” technologies and ballooning cost with no real business value. I would rather know that the firm runs on a twenty year old Perl script orchestrating Common Lisp and COBOL services than hear that it’s “pushing modern languages”

for me as am experienced senior-engineer these are not "red flags" but challenges:

lets introduce modern ways of solving problems & automating processes, if they are feasible and meaningful ... (eg. sadly even container are not the proper tool for every use-case ... ;))

but a red flag would be for example, if those things are "carved in stone", eg.:

1. "if you work for us, you are not allowed to introduce modern methods", because $EXCUSE

2. we have to cling on to our inefficient/manual way of doing things, because $COLLEAGUE doesn't want to change his_hers habits originating from the mid to late 1990ties

3. etc...

been there, tried to change things despite such signs of resistance against change - didn't work out ... in every single case ;))

just my 0.02€

Someone asking some of these questions in an interview would be a red flag for me.

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.

Gentlepeople! Remeber people have opinions, like they have fingers to type them...

These could be red flags for the author, I respect that. These are not universal, yet they could be good conversation starters.

Consider that if you don't hear the answer that you expect, maybe you can contribute something of great value to the company... Or receive a lesson on the complexities of a particular business.

Also, language-itis itself can be a problem. We love the shiny, and forget the old... I am not saying that punch cards and FORTRAN are the tool of the future, but maybe FORTRAN is the right tool for a specific problem...

I don't know if you have noticed... But programming languages could potentially mean very little, soon.

"Apprehension toward containers is a red flag."

This is a garbage take. There are obvious security considerations that a firm may or may not be ready to take one that come with container use, much less organizational knowledge.

Thoughts on my list? What "green flag" questions do you like asking?

The blog is currently down for me, so here's an archived version in case it helps anyone else:

https://web.archive.org/web/20231117165517/https://blog.abct...

People use containers because their work (code, scripting around it, ...) is so fragile, it needs a very specific version of a specific Linux distro, and probably has a huge dependency footprint.

Being gung ho for containers is the red flag: it communicates that their shit is not clean, portable and with low dependencies.

> Apprehension toward containers is a red flag.

Maybe they have been burned before? If your workload does well without containers, porting it to a container-based infrastructure and operating that is a huge sink of person hours with no business gain.

Modern languages like Python was kind of amusing. Don't get me wrong Python serves it's purpose but it first appeared in 1991...

> Most large places have legacy tech you’ll work on, but an “ain’t broke don’t fix” approach to technical debt is a red flag. A push to web apps is a green flag.

Very happy to see this up near the top so I know I can disregard the rest of the article. That's the attitude that helps drive enshittification of everything.

A "Linux interview" is in of itself a huge red flag

Only at a hyperscaler should any job description be "Linux" - otherwise you should be interviewing for solving business problems - the solution to which could include Linux (but probably should be at a much higher level of abstraction)