5 ms·
These guides are so basic it's remedial for anyone with experience in this role, but highlights the problems of finding someone on the market that is exceptiona
by walth 3y ago
These guides are so basic it's remedial for anyone with experience in this role, but highlights the problems of finding someone on the market that is exceptional in such a multitude of skillsets.
- JohnBooty 3y agoI feel like most companies eventually hit the "it's hard and expensive to find experienced engineers, let's hire cheap code school grads or other nontraditional hires en masse" phase. That's not a good sign IME[1] but it seems inevitable, so it's crucial to make the best of it - I think standard intro curricula are a great way to do it. It's also a pretty clear "canary in the coalmine" indicator. If a "nontraditional hire" cannot master or simply can't be bothered to learn the onboarding curriculum, that's a clear warning sign w.r.t. the viability of that hire. ______ [1] To be clear I'm not entirely against inexperienced/nontraditional hires. I'm against the situation where a company wants to make the absolute newbies a majority of their hires because like, hey, they can learn from the senior devs by osmosis or whatever.
- lrem 3y agoEh, not necessarily. While the internal SRE education at Google starts with assuming a slightly higher skill floor, we make every new hire go through it. Including people with a relevant PhD and/or a decade of experience in similar roles. Just making sure everyone is on the same page regarding jargon is probably already worth it. Even funnier, my extended team requires further education in the particular skills we need here. Even an internal transfer with years of Google SRE experience needs to go through it. It’s just cheaper to spend some months on probably repeated training, than to discover a knowledge gap/misaligned intuitions in the form of a large post-mortem.
- zigbopt223 3y agoHate 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.
- cmilton 3y agoI have heard this role thrown around a lot more recently in our progression to cloud deployments. I still haven’t decided if this is just an attempt by companies to get even more work out of a single employee, or this new combined role is really a necessity.
- Chris2048 3y agoPersonally, I think this is one area we are lucky to have existing certs: LPIC. Just sign up to Linux Academy (now A Cloud Guru) and do LPIC 101, and you have a basic understanding.