DevOps is... a different thing from systems administration. It's a different role. DevOps is all about quickly getting code into production, while systems administration is the opposite; systems administration is all about keeping the code that is in production now working. Sure, both will push new releases; but if the new release breaks something, a SysAdmin will have a well-tested rollback plan and use it. The DevOps will roll forward a fix. (This attitude is obvious in how puppet, a DevOps tool if I ever saw one, works.)

If you read any of the DevOps documentation, they talk about this, about how SysAdmins stand in the way of progress and upgrades and change in general. And most SysAdmins agree; making sure that systems that work don't change without good reason is central to the SysAdmin role, and brings it into conflict with the DevOps role.

Personally, I think that SysAdmin roles have a better chance of surviving a downturn than DevOps roles (though the latter certainly become more numerous when we are in the pleasant part of the business cycle.)

Usually you see SysAdmins at places with important legacy code, where the biggest danger is that something that works now will break, and DevOps at places where moving fast is important; where if you don't roll out the new thing you will die anyhow, so maintaining what you've got isn't as important. SRE is the role, usually, when those companies actually get big and start making money, but still maintain their code.

The SRE role is interesting because it has both the UNIX and network fundamentals, the "don't break what is there" (and the fix what is there, usually by means other than a re-deploy) roles that the SysAdmin has, as well as the automation roles that the DevOps has.

If we're splitting things out by how they interview, in DevOps interviews, they usually care deeply about which configuration management tools you have used in the past, and the programming questions are often object or design-pattern related. The networking questions are also very high level, usually; about higher level protocols. Often they make you demonstrate that you can use APIs and the libraries used to interface with same, and parsing the http response with regexes doesn't count. There is usually little focus on UNIX or networking fundamentals, though you may be required to have some. I have been asked questions about design patterns at DevOps interviews. (I have recently started going through the 'gang of four' design pattern book, and I'm finding that almost everything I didn't understand about object oriented programming was actually just me not knowing design patterns.)

SysAdmin interviews are the opposite. You may be required to have touched some kind of configuration management system and have some ideas about the higher level protocols, but mostly it's about your understanding of UNIX and networking fundamentals. You get lots of points if you can operate a http api without using a library, few points for operating the same api using the library you usually use. Knowing how to use strace is a requirement and knowing how to use a debugger and read a backtrace is more important than any amount of design patterns for a sysadmin job. The programming problems they give you, though, at a sysadmin job, are usually way easier than the programming problems at a DevOps job (and you can impress people with C at a sysadmin interview.)

SRE interviews are both, and generally have a higher programming bar than both, and generally only exist at large and profitable companies. Companies large enough to hire SRE generally don't use off the shelf configuration management systems outside of corp (which is a different sort of thing again.) but you are going to have to describe configuration management concepts if you want that SRE job.

But saying that SysAdmin and DevOps are the same role or somehow doing the same thing is one of those things where people who identify as either one will feel insulted.