The problem is that DevOps is not really a title or a role, its a mindset. It can be summarized as “You build it, you run it” and is supposed to solve the age old problem that arises from the disconnect of developers and sysadmins, where developers just hand over code to the admins without ever having given much thought about how to run it reliably (aka. “You go figure that out, not my problem.”) and the admins being super protective of their painstakingly curated servers and databases that of course you as a developer obviously cannot have any access to whatsoever and of course your app has to work with the 10year old java version that ships with RHEL. The consequence was basically a lot of grief on all sides and huge waste of productivity.
The idea of DevOps is that these two responsibilities merge into on. That means that the team responsible for building the software also needs to take care of how to test it, how to build it, how to deploy it, how to monitor it, how to scale it, how to debug it, etc. This is now mainly incorporated into the software developer / “full stack” role.
The confusing part is, when you look at job postings, the DevOps engineer is often described as “working closely with” or “supporting / assisting” the development team. This goes pretty much against the principle of having the development team having responsibility for their own work. Instead, it’s often just a re-branding of the old role with the title du jour. It also often details the pecking order, namely devops being support for developers.
Given that, if a company offers a DevOps position, you should spend some time finding out what that actually means for you, your work and your career. More often than not, it may put you in a box that only comes with restrictions for not obvious benefit.