An OS is an entire environment with an entire philosophy. You don’t get to just hand wave it away like this, when there are many people going for the same job who won’t.
It is wonderful that we now live in a world of highly portable development where you don’t need to get into the nitty gritty to do basic things, but you’re missing out too much detail here.
You know when you write a web app, when you start it, you need to bind to a port? Guess what provides that port? What does it mean to “provide a port”? How does it physically work? How does this differ on Linux vs BSD vs Windows? Are there reasons you should care?
You know when you write a mobile app you need to use public apis to do things like draw to the screen or get user input? Guess what provides those apis? How do these APIs differ from OS to OS? What’s missing that you always reach for? How does local storage work? Or a remote API call work?
And then arguably the internet itself - and I mean it in the sense of the RFCs that define the behaviour - is an OS in itself. When you type something into your browser location bar and hit enter you start a chain of processes that involve DNS resolvers, root servers and registries, multiple routing algorithms (at different levels of the stack from Ethernet or wifi up to BGP), get invoked as your packets try to find their way to their destination, and the replies try to move their way back. Way, way below the HTML and CSS is this monster of dependencies. How does all that work? Why is it built that way? What are the failure modes and can you mitigate them?
These questions are rhetorical but they are meant to provoke a little nudge of curiosity: there is a rich, deep vein of thought that has gone into every corner of that experience, and knowing a little more about it will allow you to develop better software higher up the stack.
And honestly, even though I have worked mostly in the web app sphere for 20 years, if somebody just hand waves it all away in an interview, I know there is a lot of training we will need to do to get them to a level where they can successfully debug 100% of the issues we will see in production (and therefore reduce the chances of me getting paged).
It’s not a red flag, but if somebody walks in just as good everywhere else and is locked and loaded on this, I’m inclined to hiring them instead.
It would take a curious person a few weeks at a couple of hours a day to learn enough about this stuff to be able to talk to it and apply that knowledge. Meeting candidates who have never even thought about it is frustrating.