- Reading the SRE book from Google to get a glimpse of the SRE philosophy. A lot of companies rebrand their Sysadmin or DevOps roles as SRE because it's trendy. Many businesses do not need SRE and need to make sure they understand the idea behind it before doing so.
- Learning Golang for such a role is becoming increasingly vital. So many SRE tools including Kubernetes, Prometheus, and Terraform are written, and extended, in Go that it's almost a requirement next to learning Bash.
- A lot may disagree on this one, but get yourself some certifications. SRE is kind of a broad role and companies do not know how to assess the skills of candidates, and unfortunately they often rely on certifications to do so. You don't have to enroll in the most challenging ones as a junior, but just one or two basic certifications to get a rough idea of a provider or service capabilities. Choose wisely.
It can be difficult to show off any personal project in such a field, but you could try to create your own infrastructure as a side project, self-host some services and provision them with Ansible for example.
But most importantly as a new SRE, find yourself a good team and good mentors within that team. Getting into SRE without any previous experience is a hell of a ride, but a very rewarding one. Like previously said, SRE roles are jack of all trades and the field is so broad you never stop learning :)
I started my IT career 2 years ago and my programming isn't that strong. I got pinged for a SRE job recently (my background so far is very much Linux based so I must have matched some filter) but I'm not strong in development, k8s (or even containers), or all of the other cool stuff I see on HN. I know I can lab stuff out, but that's not anywhere close to doing it live.
I don't want to be a SRE for Google, but I'd like to learn some more on the reliability side of my world and bring things like Git, Puppet, System design, etc and not be left behind in this wave that's approaching. My organization isn't too involved in the cloud, so a lot of upcoming tech seems out of reach.
I wouldn't treat this as a course to be completed. Think of it as a guide, or a map, on your journey to getting smarter about tech. And it's a lifelong journey. Don't let anybody here convinced you that you're supposed to know everything, because technology is so complex at this point that nobody knows all of it. Just keep broadening your skills, and deepening them where you are passionate, and you will build yourself an enjoyable and productive career.
Also why not Google?
Not trying to bring myself down but trying to be realistic :)
Then also learn the calculus of software engineering: Logic. A good short intro is Huth & Ryan. The book covers some advanced topics in later chapters, but you don't need that if you don't want to. Logic is also timeless, and very practical. You can gain the ability to model check things, which is really really cool and used pretty often for e.g. distributed systems. This can unlock many cool positions for you.
Logic can also take you to logic and declarative programming. Something also worth investing into, and pretty addictive. For that, there's nothing better than The Art of Prolog.
>Because of the lack of these resources, we felt that individuals have a tough time getting into open positions in the industry
Source: I'm a new grad, I went through almost all this, but my application wasn't shortlisted.
Not a native speaker, so maybe I just don't understand what you're saying.
IME, SRE roles are jack of all trades position, so you're not necessarily expected to be an expert in any one thing, which makes it easier to learn many things at the surface level, instead of learning a few things in depth. Which practically means that you will learn a lot on the job. This is especially true, since you're expected to learn some technology that's only seen internal to the company. So, showing they you have the ability to learn can perceived as much more important than specific knowledge.
As a hiring manager there is no way to know you've done this unless you somehow demonstrate it.
I normally won’t hire a jr. But I have made exceptions if they have clearly worked through a lot of code exercises, koans, etc.
My daughters boyfriend thought he was hot stuff for getting a masters degree.
After a friendly chat, I informed wife that boy was going to have a bad time getting anything. This is someone that had a lot of connections.
A year later and he sells mortgages.
It's harder if you're trying to get hired specifically for a technology that's a gap in your skills.
The other surprise was new grads being directly hired to SRE positions and it was my impression you needed professional skills in another area (at least sysadmin/cloud or programming) to transition over. That means there's a whole isolated career track for SREs now, but maybe LinkedIn hiring new grads for SRE is an anomaly.
Newer Devops / SRE is about be declarative, letting them system build itself up.
Mindset of old sysadmins is more tribal knowledge.
You can get stuff done crazy fast are are awesome. But heaven help anyone that needs to mess with it.
Well placed like MIT were actually good
Traditional education for practical purposes was, for much of human history, focused much more on apprenticeship-style learning than degrees. Colleges and universities were not considered a prerequisite for lots of technical jobs such as carpentry, architecture, toolmaking, clockmaking, or even banking and accounting.
If we look at the last century or so, instead of the breadth of human history, we'll see a different story. Perhaps this is a good scope to consider, seeing as the history of Computer Science and programming largely falls into this time period.
If we want to consider digital computing, the dawn of our field had plenty of people coming to programming "from industry", to use a modern term. Experienced professionals learned to program outside of degree programs, because there were no degrees to be had in computer science or programming.
Many early pioneers in programming and digital computing came from EE programs and Mathematics departments.
This is the early tradition of programming and computer science.
Today, though, if you were looking to start a career as an SRE or as a programmer, a Math degree would be a poor choice. It is traditional, in that it was a common early path, but it is much less likely to prepare you for the type of job relevant to this thread.
An individual with a degree in Literature would likely be considered a non-traditional candidate for a programming job. An individual with a degree in Mathematics may be considered the same. A Math degree may have a lot of computational focus, or none at all.
- Senior SREs
- Staff SREs
- Manager, SRE
- SRE Intern
Disclaimer: work for LinkedIn
There is an incredible number of metrics around every AWS service, and the decoupling of things via queues, topics, APIs etc. mean there are a lot of moving parts.
It’s unlikely that a “good” sysadmin / SRE, or even a team of them, could efficiently replicate the versatility and reliability offered by cloud services.
You need a half dozen engineers working full time to replicate what the cloud gives you, and still buy the hardware ahead of time. That's 6 months of straight project development with 6 people and capital for a rack full of gear.. that's like $1.5M USD outlay for one year. For close to feature parity for core services I mean, nobody would normally build all that just to put a crappy web app online.
OR hire one SRE to set up a cloud stack in two months and only pay for what you use, $200K for one year or $100K for a short contact.
The decision for where the hardware will exist may be advised by SREs, but is generally not exactly in their wheelhouse. SREs tend more towards lowering the cost and maximizing the utilization of whatever methods the company as a whole decides to use.
Running our primary DB cluster in AWS for a month costs more than the purchase price of the hardware the cluster runs on.
> At Linkedin, we are using this curriculum for onboarding our non-traditional hires and new college grads into the SRE role.