Does it make sense for a sysadmin to know a numeric notation for chmod ? Probably. Would I ask that on an interview ? Nope If you need to ask why then you have probably never worked in a heterogeneous environment.
The only suggestion I would make is that a good tool is present and working then I don't expect a penalty. I expect tools to not be present accordance with standard minimalist setups and to pay extreme penalties if I need to call a package manager or move to a less minimalist install to complete the task.
I can come up with tons of scenarios when where you do not really know the internals you can get stuck easily. Like if I do chmod -x on the chmod binary. Does it prove anything if the candidate is not able to solve such task ?
We were interviewing a new admin for the sysadmin/maintenance team and her answers to "how would you solve this problem?" were "Open that file and check that these variables are set and, if not, set them". One of the more jerkish people there went down the rabbit hole of "How are you going to edit that file? What if you don't have vim? Okay, what if you don't have emacs? Nano is gone too" leading to the response that made us hire her: "Well, in that case the system is probably completely hosed and we need to stop configuring things and focus on recovery. But I think you are looking for me to tell you a sequence of commands that involve cat. If you give me five minutes I can check stack overflow and get back to you with those"
Which I personally think should be the response for stuff like that. Understand there is an alternative and a way to resolve the corner cases and know how to get that info if needed.
Actually I believe being a sysops/devops or whatever you want to call it is one of the "most" challenging jobs in the IT industry. You get zillions of technologies you have to administer and maintain but it's impossible to master all of them. What makes a good admin is the ability to learn,adapt,ask for a help and knowing where to look for an answer. It's easy to look up the parameters if you know the fundamentals.
Interviewing for me as a devops person is one of the most frustrating experiences. You are often asked questions that are specific to the environment of a company you are interviewing with. It's unbelievable how many times I've been asked about parameters of tar, du etc. It's totally stupid. And imagine interviewing with a company that uses only a specific subset of technologies and they heavily emphasize on that.
And just targeting a limited subset is kind of reasonable. Because, odds are, you will be. If you are running infrastructure for a web server you probably will have decided on a few solutions and have time to experiment with new ones on a new platform. Scientific computing? Same deal. It is the same logic by which coders should learn a range of languages and tools but will probably use a very small subset at any given job.
And I think that the semi-automated tools COULD detect stuff like that. One point for each solution presented and maybe something akin to those god awful rubrics for the more complex ones. So going with the tar approach (after twenty years, I know xzvf and czvf and can use a test file to figure out the order):
1 point for a correct answer 0.5 points for typing "man tar" or "<google> tar" And then a subset of the remaining 0.5 for each letter and the order of operations. So something like tar xvf foo.tar.gz ./foo would get you most of the credit.
The big problem with stuff like this is that it should ONLY be used for an initial filter, but it will inevitably be used as "Only the top N people matter".
Just as I like project euler gamified as a fake ideal programming project, I would like a systems game where the point is optimizing for the worst case with minimal tools.
Add an IDE, a choice of editors, all kinds of softskills requirements that are more significant to an employer than these base primary skills. Now, I wonder why I am working for free as I am no longer just practicing our core/universal skills in an idealized/timeless environment. The better place to do that form of showing off work realistic skills is in OSS projects.
I've been one for a short while, and get to play devops from time to time. When I see a machine so broken that it can't give me a tty, it's time for a reboot (if last command caused it - actually don't remember it ever happening), full reinstall, or trash. I won't lose any time recovering it. If there's some important log on the disks or anything, mount the disk on another machine.
Now, I've recovered a broken machine plenty of times at home. I've edited files with sed and pipes because I broke every other editor available. I have never actually edited the memory with sed, but I could if I had to. But all that is at home, where it's fun to create a crazy configuration, and totally not fun to throw things away. It's fun, but completely unproductive.
Before then I was an sysadmin for a little while, but I don't really see what difference the role makes. I've never had a job where I didn't at some point need to deal with a legacy serial console of some sort misrouted through incompatible aggregators, etc, in order to deal with a networking problem and/or auth problems.
The idea that I would blind reboot a system in a failure mode I can't diagnose is not something I would normally consider until I've exhausted all means and only if I know a fair bit about it. I'm sure some of my colleagues did things like that as some were developers with relatively little system knowledge, but only a few were stupid enough to mention losing failure data through laziness to senior staff.
> It's fun, but completely unproductive.
? If I had a page for you should have diagnosed and every time you hit a swiss cheese failure with that attitude than I wouldn't use computers at all anymore.