I think that it's less important to make the distinction nowadays because systems engineers use developer tools and modern practices. 25 years ago when I was a "Junior Linux systems administrator" my peers kept their vast collection of shell scripts on a file server if you were lucky - some hoarded their own "craft" and kept them on their personal workstations. Scripts got copied onto machines and executed. There was no CI/CD because in most places, systems folk didn't use version control. The best we had back then was a PXE boot server + kickstart files + custom packages. Married to virtualization, this gave you a pretty flexible way to roll out big changes without having to run around with CDs and then manually install and configure software. If you were really lucky, some bright spark put the package source files in CVS, and maybe even triggered RPM automatically, so newly built or rebuilt servers were in an almost ready state from the start. But system state would begin to drift immediately, and you could almost guarantee that the Apache config in one box wouldn't match the next. While frequent automatic server rebuilds were the gold standard, few shops actually implemented that. That meant that systems engineers needed to be able to fix anything. Manually. This required intimate familiarity with the content of system files for GRUB, PAM, dhcpd, init scripts, if-scripts, LDAP, NFS, Apache, SendMail... In fact, the ability to manually hack on those things were the skillset for a systems engineer. Look at the RedHat 6 RHCE exam curriculum!

If you could write complex shell or perl scripts, and you knew how to dig into performance metrics on the fly, you were a god. (Yeah, capturing and displaying system metrics was in its infancy, and most shops simply didn't know how to do it)

While some systems were built to be "horizontally scalable", you were lucky if you worked with systems that weren't SPOFs. You were happy with redundancy via active/passive failover (and that was probably a manual affair). Maybe if you were really lucky, you worked for a SaaS that served a monolithic website via a fleet of webservers behind an F5 loadbalancer. "Wooooah!". But you still set up those F5 VIPs and pools manually.

The modern systems engineer rarely has to do anything like this, even though the underlying technology is similar. These days everything you care about is in git, and is mostly testable on git push. Modern companies, including tiny 4-person SaaS startups, can have infrastructure-as-code, configuration-as-code, packer configs, dockerfiles, container orchestration, CI/CD, metrics collection, USE/RED metric graphs for every system with alerting, pager, incident handling runbooks...

At some point over the last 25 years, the term Systems Engineer could mean that you're an expert in the old ways or the new ways. When you advertised for a DevOps engineer, it left no doubt that you were looking for the modern variety and expected that experience and skillset.

You can also advertise for zookeeper or chef, but if you want people doing X, a good bet is to advertise for X.

I asked for alternative suggestions and offered what we use. If you have suggestions of alternative titles you've successfully used to hire without slowing things down I'm all ears.

> What's DevOps skills in your opinion?

The most important skill is knowing to not fall for the bait that is this question so that you can actually work.