Hate to say it but that was my first thought as well. Read the section on signals. Besides being wildly incomplete and out of context (and basically useless in practice or in theory for those reasons), it's stuck in a section titled Linux Advanced, which I think says just about everything that needs to be said about the rest of the content leading up to it. Also, it's fucked in the head to put containers ahead of signals in your curriculum and it smells of YAML.

I don't know what LinkedIn is doing and how many SREs they've got sitting around "writing SLAs", but I'm not sure you should even be passing an interview for an internship if your operating system fundamentals are that weak. In anything anywhere near a production Unix system.

Perhaps I just don't understand what the actual role of an SRE is. I'm fully aware of what an SLA is. What I suppose is confusing is how the role of SRE came out of nowhere fairly recently. I know what a systems administrator does, and what a systems programmer does, and of various forms of title inflation that can be applied to both. SRE remains a mystery to me that crawled out of the web title soup sometime in the last decade.

Is it operations? Is it writing contracts and badgering programmers about that time they broke production? Are they like auditors? Do I need to take the SRE out to dinner and butter them up? I'm not quite sure based off of this content.

I've got nothing against nontraditional hires. I never finished college. But I absolutely despise the idea of somebody educated in this way being put in a position of authority.