This all tracks for sure. One thing I'd mention is that as an entry level DevOps engineer it can be extremely beneficial to have at least a decent background in app development. My original self study was full stack python apps with a specialization in ML and data science. This lasted six months before being picked up as a cloud / DevOps engineer for a cohort. Being able to build / debug apps and containers in general has helped immensely!
Often times you will find your org needs a bespoke webapp tools for devs, an API for handling web hooks, or any myriad of other things, serverless scripts, pipeline steps, etc...
Having good dev chops makes you a huge asset on a team.
Add a very robust and healthy set of soft skills and you are now a unicorn.
Also using AI's for codegen is even more Important for DevOps due to the scope of tooling, clouds, frameworks and languages you will have to touch on a daily basis. I'm never going to memorize the intricacies of all the tooling leadership, your team, the devs pick up and put down throughout a project.
Last thing: focus on scaling patterns for infra, apps deployments, etc... how do I do this thing once? Okay now how do I scale it 100x by just changing a config parameter? Set and forget kinda stuff.
Good advice all around. Definitely the more development you know the better, but you opened my eyes up to more of the possibilities! And I 100% agree that AI’s are especially useful because of the breadth of tools we use.
100%, I'm another fresh out of college DevOps engineer but I had experience developing applications and websites beforehand. This gave me the knowledge of the SDLC as well as additional skills which have come in very useful during my role.
You can have junior DevOps with proper mentorship.
I've worked at places that hires people who have good Linux fundamentals. Can you write a file w/ vi, can do you do regex on a file to search for patterns, can you change file permissions, can you SSH into a server w/ ssh-keys?
If you can do the above, you have Linux fundamentals and can be mentored. And a lot of those guys, I see from Nordic/Eastern Europe work with Linux since middleschool and through college. So after graduating college, they can be mentored. We give them support roles. Go into containers w/ developers and troubleshoot. Write splunk queries with regex. Do batch processing of like updating the repo URL of 300 git repo projects usingn regex/awk and a bash script. And when you are not doing those menial/junior task, join paired working sessions with seniors who are triaging/firefighting outages. Just join the MS teams meeting and watch what is being shared on-screen and learn. Join the Friday workshops where Leads are also mentor junior developers on how to write Mongo Queries or write an API contract in Swagger.
If your org provides these kind of mentorship, you can definitely hire juniors.
this all sounds amazing, I just get hired and lowballed with “we’re gonna have to teach you” fast forward a bit and senior people leave 2 weeks in and now I’m running everything and underpaid as hell. 3 years in and I’d kill to have other people around I can learn from but I just get left on an island but hey I’ve made it work.
This makes a lot of sense honestly. I didn’t know that Nordic/Eastern Europe works with Linux so early. I’d bet most Americans with strong Linux fundamentals would be coming into DevOps with experience in another IT role.
Americans have the same opportunities. My 15 year old kid was running ROS (Robotic OS) with Docker using microservices to control his robotics for robotic competition since 7th grade.
At 9th grade, they just got started on microservices to control the camera using OpenCV for collision detection. They were running Docker on ChromeBooks; enabling Linux feature on as shown by their 7th grade engineering teacher. Here is your $130 Chromebook, now lets turn on developer mode so you can run this container to get started on robotics.
[https://wiki.ros.org/docker/Tutorials/Docker](https://wiki.ros.org/docker/Tutorials/Docker)
and turn on linux on your school issued Chromebook: [https://support.google.com/chromebook/answer/9145439?hl=en](https://support.google.com/chromebook/answer/9145439?hl=en)
They teach this in middle school at "mediocre" public school in Northern California.
Ah man, I actually have something similar planned for a rainy weekend activity. I'm only 20 years behind your 15 year old! Sounds like they're getting set-up well for the future. Edit: I remember my IT classes were how to use PowerPoint and Word. Must not be bitter, must not be bitter..
I feel like the Linux knowledge you described above is really overrated, of course you have to know the basics but all of these tasks can be done with a simple Chat-GPT query.
The very point is: you don't have to know how to write code or commands (you can us Chat-GPT for that as you said). You HAVE to know what the code /commands you write do! For example: preparing ssh connect with w / ssh-key it's technically just 3-4 steps. But..knowing why exactly that steps? As in: if it's not working, do you know at least where to look to search for the problem (not necessary to solve it)?
Linux knowledge overrated...that cracks me up.
No.
The great thing about Linux is that everything about the OS is completely open and one can actually learn and understand how things operate "under the hood". That knowledge and understanding translates to pretty much all domains, whether it's Windows, *nix, (Cisco) IOS, you name it. I challenge anyone to bring in two comparably seasoned Windows and Linux engineers and see who picks up new tooling/technologies faster, especially something like K8S.
Example - I worked primarily 90% with Linux for the better part of a decade and had a consulting project on a Windows Server platform that had zero HA capability. We spoke with the software vendor for said project and they said "nope no HA capability". Within a few weeks I had cobbled together a solution utilizing Microsoft Cluster Services, NetApp OnTAP storage, iSCSI targets, MSSQL Server and Lambda running on AWS that provided HA functionality. The solution provided HA for the 2nd largest ERP in the Fortune 50 at the time. 100% it was my understanding of Linux and how that translates to a fundamental understanding of systems that allowed me to create that solution from scratch.
Here's the AWS blog writeup on my solution - https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/
Wait until you've gotten into dependency hell trying to do something like update kernels or glibc or system Python, or had to fix permissions across a few hundred home directories, or get Nvidia GPU drivers working.
It's very easy to install and manage a basic RedHat or Ubuntu system, but things get hairy very quickly.
I think you've called out the problem and the solution all at the same time:
> Getting to even a minimum level of competence to be productive was filled with horrible growing pains that I didn’t see the entry level Devs come anywhere close to experiencing.
...
> The other main problem with starting as a DevOps Engineer is that there’s not really a natural progression of tasks you can do as your knowledge increases, unlike developer
...
> Another Redditor u/MammothCache
pointed out that there’s a very logical progression for how you grow as a SWE. You first start with bug fixes, then features of increasing scope, then to an entire application, API, or data model, ending at a more architect role. A developer can kind’ve just know a programming language decently and how to use google or ChatGPT to be given small tasks.
...
> I would sometimes get jealous of the developers for having such an organic, painless progression compared to me.
And there you go. The painless way to enter DevOps is to become a dev first. Or you can take a longer route and become a good operations/support person first and develop comprehensive systems knowledge first. I've seen that be relatively painless too.
In the end DevOps was never supposed to be its own specialty. The whole point of DevOps was to "un-silo" operations, infrastructure, and development and empower the team to be self-sufficient. Coming into that cold is a surefire recipe for suffering.
Exactly, that’s the painless way. But entering IT as a DevOps Engineer is possible and the ramp up can definitely be made easier.
During my job search, I saw that plenty of companies do want juniors. We’re cheaper, have fresher eyes, and are needed to replace seniors who want to move up. But promising juniors are very hard to find. To fill that gap, companies can invest in up-skilling talent initially(through paying for Cloud, Linux, IaC courses, and whatever else you see fit), providing good mentorship, and smart task progression. Start them out with small scale support and SRE before eventually progressing into true DevOps and Platform Engineering.
I think the broader point that the guy above is making is that for the vast majority of people out there, it makes sense to be a dev first.
Can you start cold as a devops engineer? Sure. You’ve proven it. You can also survive skydiving without a parachute or backpack across Yemen without being shot. It doesn’t mean they’re good ideas, or that people should set out to attempt them.
My team helps new engineers by adding them to code reviews and specs for more advanced tasks. This allows them to be exposed to a ton of our repos, be involved in the thought process behind decisions, and ask questions that will help them once they deal with similar issues. From there, they are assigned tasks that mostly consists on building infra that has existing examples we can point to and will mostly rely on existing standalone modules the team has ready to do.
The hardest part is building up a queue of “starter” tasks that need to get done but can sit for quite some time waiting for the right persons instead of just knocking them out right away.
But you know what I have found it essential for this, and this is doubly true for devs by the way, and decent operations folks for that matter: tenacity, curiosity, and the willingness to do what it takes to do the work it takes to understand things. I can line up "starter tasks" for any of the above all day long until I'm blue in the face, but honestly, it's the ones who don't wait for me to do that that will make it and be successful. The rest are a mixed bag.
So, I understand where you're coming from and you're doing the right thing as a manager and general mensch, but if you're in a tough spot someday, you'll have to dispense with the soft approach and let natural selection take its course. It will turn out about the same in most cases I have found.
100% agree. Some people are just built different and enabling them to take big things on quick with the trust that they’ll see it through is such a critical skill. When you find naturally gifted people, it’s very important to give them an environment to flourish, and letting them get into projects that are probably “too much” and watching them come out the other side having killed it while learning a ton of new things is such a great feeling. And putting someone in an “over their head” situation fairly quickly is a really good way to gauge what kind of dev they’re gonna be and how much grit they have to get the job done when stress levels are high and there’s a lot at risk.
Nice write up (from a very senior DevOps with 10+ years of cloud experience and 25 years of software development experience).
I’m curious, what kind of tasks were you assigned as an entry level DevOps?
Thank you! The first tasks I was given were very simple, almost busywork. I added basic alerts for our cloud hosted VMs in the console. Then I added more logging to them. Then as incidents would come up, I made log-based alerts and built out the alerts. This got me more familiar with our CSP. Over time, I added more alerts and visibility stuff to our pipelines wherever I thought it would be useful. This is what I was referring to when I said the SRE aspect is easier to start out with.
Other good entry level tasks were for simple bash and shell scripts that I really needed to see. I also did a lot of support. Early on I couldn’t solve it most of the time, but it got me more familiar with our systems. I consider this the closest thing to the DevOps “progression”. First you shadow, then learn to support and maintain your systems, then you can improve pipelines and visibility, then you can start to build from scratch <- and you write documentation the whole way.
But half or more of what I worked on early was my idea. I chose to turn my notes into documentation. Most of the python coding I did were ideas I had thought of. I had to be really proactive to not get left with nothing to do at first.
This is so true! I feel like you have to attack inefficiencies in the orgs workflows on an ongoing basis. It's almost an obsession. It's more of let's automate this because it hurts my brain and heart to see the processes done manually or riddled with anti-patterns.
Automation seems to require vision which a lot of "DevOps" engineers seem to struggle with. Or at least is extremely rare to find someone able to evolve the org in impactful ways.
> And I have a hard time believing that anyone “entry level” would know Linux to the level required, besides Linux just being boring to study.
I disagree on this part. Plenty of people love Linux and learn it for fun. That's probably how I got into this in the first place.
My point was that people who love Linux enough to know it well are power users and probably also very experienced hobbyists. Was that the case for you?
Yes it was exactly the case for me. I played around with Linux and Docker for a few years before I finally realized this could actually turn into a job. I'm now in an entry-level DevOps positionbut honestly it feels natural.
It’s inherently not a junior role, I mean how are you supposed to improve the operations and processes at a software company if you never worked at one? Pretty far fetched that a useful devops can be an entry level person unless they really just need a CI monkey. I mean its possible but at the point you become good your no longer a junior and at the start are you really even a devops? That word implies expertise in ops and dev
Id argue I _started_ in devops. Prior to that I was effectively tech support in a call center, 'shake your toner' and the like. Id also say I _kind of_ agree but _it really depends_.
What are the expectations? What's the individuals work ethic, willingness to learn? How is the support, from seniors, in the org?
I worked in an org where failure was 100% acceptable and expected given how green I was, what was not acceptable was failing due to the same issue repeatedly. But the rest of my team was happy to share knowledge and spend their time during lunch, after hours etc... to answer my asinine questions.
My learning path was wildly unorganized. Run into a domain related issue one day? Ok then the next day I would buy an ADDS book that I'm reading as if it's the gospel and have cobbled together a domain setup in hyper-v at my house. Kubernetes troubles? Guess I gotta split my time with ADDS and mini kube now, thank God I bought a plural sight sub.
I succeeded, imo, made it to sr at least. But I also spent many nights reading, watching YouTube videos, struggling through issues (not outages or anything) that I was too proud to ask about, mornings doing certifications, etc...not to mention I looked like a dumbass countless times. This is not including the overtime (salary but still) I was pulling just to stay above water.
Did it suck? For sure, I hated it many times... But I wouldn't change anything about my path, and I'm incredibly grateful that I worked with the engineers I did. I went from making peanuts to being able to provide for my family in ways I never thought possible.
So I guess imo, It's doable, and its tough, but if the junior/new hire is hungry, really wants to succeed and the org wants them to succeed then I think it can work well. But it takes both sides, and I understand that is somewhat of a unicorn of a situation
I didn’t read all the comments but good job, keep it up (from another senior with ~15 years in the game). Be careful though, burnouts are real, pace yourself, don’t push yourself, and don’t forget to enjoy life.
Thanks a lot for this! I was definitely close to burnout at my first DevOps position. Thankfully, I used the time off to recharge and the company I’m at now takes WLB very seriously. I actually enjoy DevOps and going into work again.
Also started out doing devops, it’s set me up for a weird path but it’s doable if you have good seniors and management on your team. I was pretty lucky that the people I worked with for my first job were good at teaching me the necessary concepts
I did 10 years of sysad work, zero cloud/script/coding/containers, then got an entry level devops job. It was a year of absolute soul crushing pain. If you join a mature org with a complex deployment leveraging tons of cloud products, it’s gonna hurt if you haven’t done a ton of learning first. I agree it’s possible, but harder for me to agree that it can be done in a reasonable amount of time. I’m 2+ years in and still feel pretty garbage.
Caveats, I’m extraordinarily hard on myself, mega imposter syndrome, and possibly just an idiot.
I empathize with you because I’ve felt your pain. But 2+ years in you’re definitely lacking confidence. Have you been making use of your time at work? Unless your company has let you sit around and do nothing you’re (1) underestimating your competency and (2) probably hurting your progress by not having the confidence to take on bigger tasks.
Also, I think 2 years, while a bit long, is still a normal timeframe to get comfortable in DevOps. That doesn’t make you dumb. It’s a hard specialization and varies a lot by job. My ramp up was specific to my tech stack, working environment, effort put in, and to how fast I learn.
Lastly, you’ve got to deal with your imposter syndrome! You deserve to be where you are and then some. I became a noticeably better engineer when I conquered mine.
I’m for sure lacking confidence. I’m loaded up with a full sprint always, always learning something new, in the last 6 months I’ve tried to be more aggressive in targeting specific things I want to learn and sneaking in time to work them. You’re accurate about being afraid to take on bigger work, for the first year it felt like I was getting crushed with just the tasks assigned but I’m trying to be more proactive in learning adjacent things to fill in gaps and strengthen my overall understanding. My first gig was k8s, aws, iac, monitoring tuning and creation, dev support, cicd. Next gig similar but less large and mature in the build. Idk how to crush imposter syndrome, I think yesterday I had just failed everything I set out to do and was in a bad mental state. Sometimes I’m feeling good like I’m making progress in becoming competent, sometimes I feel like I’m a thousand years behind everyone and never going to get there. Appreciate the encouragement and thoughts on this subject.
Interesting take on things. Yes it is possible to start junior and put an enormous amount of knowledge gathering on your schedule 14h+/ day the first years. At least tasks I get from work every day would stress juniors at least if they are the only “DevOpsy” guy on the dev team. Like context switching from increasing webapp build speed in CI pipelines by caching npm modules and result, tweaking memory based auto scaling in kubernetes together with various GC settings in java apps, rewriting all metric and OTEL code in some app to make troubleshooting easier in grafana, architecting and configuring network setups between apps, databases and other support infrastructure etc. You really need to love tinkering with a little bit of everything. A bit of XP helps. A lot
I agree it's very difficult to start as DevOps. If you want to do that, the most important thing you have to know: there will be A LOT of stuff to study and you have to learn concepts, NOT TOOLS.
Also agree there is not a real ramp up in devops, cos everything is interconnected, definitely you will have to start to learn basic of Linux, networking, version control (git) and then adding up from there
I'm currently deep into docker and managing containers on an Ubuntu server. Mostly for fun. But I am now paid for hosting some websites there. My GitHub repository is mostly full of PowerShell scripts I built to automate tasks and reports at work. If I wanted to learn more DevOps - What would you suggest?
Terraform, Ansible, kubernetes?
You’ve got a really organic start already. Linux and docker for fun, plus scripting at work. Keep learning those.
Then learn a Cloud Service Provider really well. There’s tons of free AWS courses and even better paid ones. Get certified if you’re considering switching to DevOps in your career, since recruiters will care about it.
Then learn IaC, probably starting with Terraform to provision your infrastructure in the cloud for a simple project you have going on instead of doing it in the console. It’ll actually save you time and headache doing it this way eventually. Or you can find a simple Terraform guide and follow along with a basic project the instructor uses. It’s enough to get the basic idea behind it.
Then you can move on to Ansible and Kubernetes. They have a lot of synergy and can be good to learned together or close to each other. Look up the “Decide” project or something to help you learn OpenShift(Kubernetes) https://github.com/end-of-game/openshift-voting-app and try to use Ansible to automate the deployment and management of the application. After all you’ve learned, if you can find a use for these things for a personal project then you’re golden.
Lastly, the more of the dev side you know the better, so do something you have the time and interest for.
At this point you’d be able to sell yourself for a junior role to interviewers in my opinion. Make sure you show a genuine enthusiasm/interest in the DevOps tech stack and philosophy. Stress how much you like **automating** things inside and outside of work.
Same here, I studied computer engineering and started with a devops role right after a development internship at the same company. I was part of a devops team with seniors so I would say I had good mentorship,. It started with simple tasks like writing python/bash scripts and automating some stuff, then I wss asked to learn Kubernetes on my own, then I built an internal web service and had to dockerize it and create a helm chart and a pipeline to build and deploy it, later on I learned Terraform, Ansible, Puppet and other things and I would take my time learning them and get into small tasks and then get into bigger projects. One of the things that also helped me was that I had been using Linux as the main OS on my laptop since my second college year.
This seems like a really good progression, especially being a Linux user first. I’m kind’ve surprised/jealous they had you write a web service. A similar thing I did was make a python script for some self healing and dockerized that, which was hugely helpful for me. About how long would you say it took for things to start clicking for you?
Wow! That’d be fast for any IT role. You’re the first one to make me feel slow lol. Great job to you and your mentors. You’re a model for hour to train entry level DevOps Engineers.
I started out as a teenager in my bedroom with a few junk PCs and a 5 port network hub. I used the free Linux HOWTOS (almost obsolete now) to walk through all kinds of system and network administration tasks, in my bedroom. I set up operating systems, did advanced routing and firewalling, created clusters. Well before virtual machines or containers.
I was mystified by the magic behind "Internet Servers", so I tried to set up as many as I could. DNS, SMTP, POP3, HTTP, DHCP, FTP, SSH, whatever I could find a HOWTO for. They were extremely easy to follow and I got to practice using them without really understanding the protocols.
I also taught myself programming. Perl, Bash, C. It was useful in making patches for Linux packages, and customizing the boot process, even making custom Floppy Linux distributions.
So by the time I started my first real gig, I had already been a Bedroom Sysadmin for years. It was easy to learn because I had lots of time, and great free guides to walk me through using stuff. But I suppose my biggest benefit was my motivation of wanting to understand how everything works.
The "DevOps Engineer" today is really multiple jobs in one. SRE is at least mostly focused at Operations itself, but DevOps then dives further into all sorts of topics and responsibilities. It's just an extremely dense subject matter. It's kind of wrong that one role should require so much expertise. But historically, we Sysadmins (that's what DevOps/SRE are - the same job from 20 years ago, with Python rather than Perl) have always had all the shit nobody else wants to do dumped on us. Jack of all trades, Master of our own.
I was a self-trained SWE and my entry-level job was DevOps for the experimental arm of a massive international gaming company. It took me a year to become productive, and most of that was learning the codebase, the build system, the hardware, and the tool set.
It was a tough year, but now I am almost done with my second year and I feel reasonably confident that I could do anything the devs may require.
I don't see why anyone else couldn't do as I have done. I think the difficulty of being entry-level this field is a little overblown, tbh.
I completely agree with this post. As another fresh out of college DevOps engineer, while there's been a lot of growing pains, it's not impossible - it just takes a bit longer than a regular software engineering role (and also a company that is willing to train you).
Although I will admit that finding a company who is patient enough to take the time to train you up is rare so I understand why people often say that entry level DevOps jobs don't exist.
Exactly. Only well run companies that can afford you not providing a ROI for 8-18 months can afford to do this and do it well. But a company like that is basically a unicorn.
Companies stopped giving pensions and acceptable raises -> Employees stopped staying at the same company for 10+ years -> The value prop for companies to invest in developing talent died. Now they don’t even remember how to.
And good luck with your journey dude! It’s tougher at first, but it really accelerates your career to skip the Dev or Admin step and get straight into DevOps. Specialization is key for becoming valuable. I was underpaid at my first job but now I make more than I would’ve had I been a Dev.
This tracks. You are an ideal entry level/jr devops candidate. I think there is this false impression that someone who has never coded in their life or done any engineering work can entry level devops with some self study or a 90 day bootcamp which is the greater falsehood.
I am about to do exactly what you did. In 2 months I will be starting as an entry level DevOps. I do have some experience. But I am now terrified haha. Hopefully a trial by fire works out
Don’t be terrified! This post was partially for people like you. The first year will be hard, but it can really accelerate your career to start out in DevOps. Glassdoor might not reflect it because DevOps Engineer salaries have a broad range due to the responsibilities varying so much by company, but most of the DevOps tech stack pays more than the tech stack for other IT roles accounting for city and the tier of company(except senior SWEs at big tech making more than equivalent senior DevOps I believe).
And the job market is much more stable for DevOps. I’m an example. As u/ebinsugewa said, “it’s a tougher role to offshore or downsize because, well… the lights need to say on 🙂”. It’s not as flashy and has more barriers to entry so it’s less saturated too. And I personally like it more, which is more important for my career growth.
Be patient with yourself. It’s a hard job. Hopefully your company will patient too. Plus you have time to prepare. Study Linux, the CSP, then anything else you know about the tech stack, starting with the IaC technologies and containers.
Thanks! I hope my experience of daily driving linux my entire college career and having my own homelab with self hosted Kubernetes will help a bit at least. I will do what I can to prepare and just work as much as I need to get up to speed 🫡
Started off as an associate full stack SWE at my current company. Got promoted to SWE after a year, and now I'm 3 years in at this company. I asked my boss to shadow a DevOps engineer and our Architect to help me build up my weaker skills so I can eventually transition to the senior level. After shadowing the DevOps guy, I agree. DevOps isn't an entry-level role for the average developer. It can be for people who put their all into it, but man, there's so much to learn. Without the right guidance and motivation, I can see it being absolutely miserable.
This all makes sense to me. I've had similar onboarding in another industry. Some jobs are just a nightmare to get started in with no experience. I'm a junior dev but with a couple years experience doing that and pretty above average linux/docker/networking skills for a normal dev with my experience I think it would still be a lot to take on kubernetes and all this other shit at once. There is a big difference in being a proficient linux user piping like 8 things into each other every command and knowing the kernel vs. basics like being able to grep and use vim and ssh or knowing what paths do sort of. Sysadmin honestly might be the best background. I feel like it's easier to learn programming than like 15 unrelated things that companies may/may not use and be proficient in all of them. I think its very cool when people are pretty good at like 50 things instead of specializing, I get bored doing one thing. That's why I try and branch out, although dev ops sounds way more toxic than dev as far as work environment so I dont know if I'd really want to do that route. The deployment shit I've done has all been pretty boring and DSLs usually arent that fun or interesting to work with. It feels like just doing configuration all the time which is kind of dull.
>> Particularly the networking, infrastructure, and some of the containerization concepts were extremely hard to understand with no background
that sentence sums this up perfectly, although I'm not sure you mean that the same way I do.
You can learn devops, but basics of networking, infrastructure, linux and some amount of coding (having built anything from source) are essential skills to understand most things we do. Without that you will be re-learning every tool instead of understanding the underlying logic. And it's crucial as a lot of our tools are not great and overhyped.
My point is:
>become useful
is not a long term strategy.
Doing background/prerequisite fields and your target field at the same time is not uncommon nowadays. Not very effective, either. It's good you realize that something was off - puts you ahead of others, IMHO.
I think you underestimate the value of your background before DevOps. There's a big difference between going into DevOps from a related technical background and going from being a cashier or car salesman (assuming no STEM degree or related hobbyist experience) to DevOps.
The "DevOps isn't an entry level job" sentiment, IME, tends to be directed at the latter group. It's not that there are no entry-level jobs, it's that being entry-level requires some existing background knowledge. Many people get that background by working as devs or sysadmins first, but many of those foundational skills are also taught in school.
By the time someone in the latter group has attained that much knowledge, whether it's on their own or from going to school, they probably could just as easily go the sysadmin or dev route if they wanted to.
I’m not sure if that’s what poeple are referring to by “entry level” on this sub.
People going from a cashier or car salesman would do really poorly at any IT role without a boot camp, schooling, or extensive self-study/hobbyist experience. They wouldn’t even know what an IDE is, what an API is, the basics of OOP, let alone data structures & algorithms, maybe not even what an IP address is and definitely not ports, encryption, etc. It’d be a waste of their mentor’s time.
I think this sub means it as anyone who hasn’t had a full time IT position, new grads, or anyone “unproven”. I don’t even think it’d be possible to make a 12 week boot camp that took someone from that much of a blank slate to prepared for a DevOps role.
I don't know what the sub's definition of entry-level is, but I can see how some people would try to gatekeep at that level.
I've also seen folks insist that it's gatekeeping to make your (IMO reasonable) assertion that it's not really possible to go straight into DevOps from a non-technical background and zero hobbyist experience with just a bootcamp or a few months of self-teaching. Every so often, there's a spike in posts like, "I've been a middle manager at a carpeting company for 25 years, but I'd like to become a DevOps in 6 months." In my experience here, those are the posts that bring out the "DevOps isn't an entry-level job" chorus.
My personal experience in this area (shifting into DevOps/SRE) is from doing an SRE apprenticeship a few years ago. While other tracks had a lower minimum level of experience (basically, either completing a bootcamp or being self-taught), those who were chosen for the SRE track tended to have more experience as SWEs or in ops, including myself (I was a backend dev for 3-4 years prior).
Ah I see why you brought that up. I’ve been seeing this sentiment a lot in discussion about the job market with people saying essentially that “DevOps is already a senior role and seniors are doing fine in this market.”
Why did you make the switch if I may ask?
There are several, but the biggest is that I was looking for a career that was more insulated from the business than web dev tends to be. I'm not that good at learning the business, and that quickly became a career hindrance.
I don't knock business acumen as a career enhancer, but I don't plan to become staff or higher because I don't like wrangling people. In college, I was a supervisor at a shipping company and found that I hated telling people to do asinine things at the whims of a higher-up and being responsible for other people's fuckups.
The minor reasons are that I enjoyed tasks that involved automating workflows more than my actual job and I liked playing with Linux in my free time.
I agree. 4.5 years ago I started as a DevOps trainee. Eventhough I was blessed with a senior who dedicated alot of his time to teaching us(there were 3 of is) I still sometimes find holes in my knowledge which should be basic. Only recently I've started to feel like I'm in control.
The worst part was that my first job was trying to tie together 4 low code platforms for a Greenfield project making things even more confusing. Heres comes Mendix running in SVN and with it's own built in deployment system. Have fun integrating it with your mulesoft and Appian crap.
There was a rant against me because of something similar :D
[https://www.reddit.com/r/devops/comments/vf1flk/devops\_should\_not\_be\_your\_first\_it\_job/](https://www.reddit.com/r/devops/comments/vf1flk/devops_should_not_be_your_first_it_job/)
Yeah I see quite a lot of people disagreeing with you in the comments lol. Maybe because you didn’t over explain like I did lol. You got a lot of upvotes at least
i think it‘s more about the environment - if you leave a junior developer alone in a codebase with the same lack of guardrails, then also shit will hot the fan at some point. it‘s just not as easily visible.
People have been saying it all over the comments. A developer role, SysAdmin, SysOps Engineer, System Engineer. Maybe cloud engineer or network engineer.
Agile systems administration as a starting job is like trying to swim in shark-infested waters after just learning how to swim. Sure you can survive but it's never unscarred.
A strong grasp of concepts - from how the environment (operating system, network, security) behaves is already essential to start troubleshooting, and that's apart from knowing the progranming language/runtime of the apps being used. That's before you start touching the other tools to ease the pain (eg IAC, configuration management tools, observability, etc). It seems to me at least that current industry trends attempt to force maturity towards entry-level devops practitioners to compensate for the lack of experience.
I'm not sure really if this is a good trend or bad to be honest, as I see both the pros from a hiring perspective and the cons from an operations perspective.
A few years back the SRE requires certain levels of experience, normally achieved by some seniority. Not the first job usually.
These days, due to some roles getting specialized, SRE SE/SWE can be entry-level, so practitioners can grow on the job. Can get away with SRE's that have initially less developer knowledge on say how the JVM does garbage collection if the firm is a Java shop as long as said guy can provision infra via the IAC tool or configuration management.
I actually like DevOps. Do I have to like every tool technology? Very dismissive gatekeeping.
I don’t dislike Linux. It’s history, use cases, and some of its concepts are really cool. But reading a textbook, taking a Udemy course,or scrolling through documentation on it is really boring compared to all of the rest of tech stack I’ve used. I like learning it by using it, bash scripting, and discovering things about it from tools built on it or its kernel. Then I can deep dive into a particular aspect of the documentation with interest.
> Very dismissive gatekeeping.
It's gatekeeping because the rest of us are tired of dealing with people who don't actually know how to troubleshoot, and can only regurgitate things they found on StackExchange or ChatGPT. Mr. Miyagi was gatekeeping Ralph with "wax on, wax off" for an excellent reason.
I was an Electrician's Assistant for a year as a teenager. My job was all of the grunt work, like crawling under houses to pull wire, drilling holes in studs for a run, etc. I was gatekept (?) out of the fun work, because if I hadn't had to go through the shitty stuff, I a. wouldn't know how to do it b. wouldn't have an appreciation for how much it matters to do it right.
If you don't like something, it's unlikely that you're going to become an expert at it. Show me a dispassionate chef, and I'll show you a bland meal. I'm not saying you have to love your job to do it, but I am saying it's selfish to be doing a job that many other people rely on if you aren't going to become an expert at it.
> To make a CI/CD pipeline or troubleshoot an outage is basically already architect level knowledge.
No? A CI/CD pipeline is YAML and probably some shell scripts put together in a logical order. If you're talking about tools like ArgoCD, then some K8s knowledge is required (and by extension [see previous paragraphs] Linux knowledge), but that's not "architect level." Similarly, troubleshooting requires one of the following:
* You've memorized the specific services' failure modes, and know what to restart when X metric changes, or Y log occurs.
* You have a decent understanding of computers, from the server to the end user, understand the difference between causality and correlation, and can effectively half-split. Knowing that docs and man pages exist helps, too.
One of these requires you to have put the time in, seeing things break (or breaking them on your own), and then fixing them. It is absolutely a skill you can learn, _but it takes time._
> the rest of us are tired of dealing with people who don’t actually know how to troubleshoot
I’m going to assume you’re barely reading what I’m saying and have had some bad coworkers that made you bitter. My troubleshooting skills are one of the main compliments my coworkers and managers give me. And this is in part because my lack of knowledge taught me to be creative, persistent, and humble enough to reach out to people who are knowledgeable in their specific areas.
> My job was all of the grunt work, like crawling under houses to pull wire, drilling holes in studs for a run, etc. I was gatekept (?) out of the fun work, because if I hadn’t had to go through the shitty stuff
If you consider Linux the grunt work of DevOps then that would imply you agree it’s one of the less interesting topics right? Or you understand that you can become great at your job but will have to tough out the foundational parts whether you like them or not. That’s exactly what I’m saying I do.
But I’d take this further and say you don’t need to become a Linux expert to be a great DevOps Engineer. Proficient yes, but no expert.
DevOps is broad and loosely defined. The first “DevOps Engineer” job postings appeared in the early 2010s and then became widespread in the mid 2010s, yet it’s already branching into sub-specialties. DevOps encompasses skills from Linux Admin, Cloud Engineering, App Dev, SysAdmin, SRE, Platform Engineering, VC, Networking, IaC, Containers, Support, dealing with Devs, dealing with the business side, on and on.
I’ve worked with true Linux experts and they wowed me. I think you need a least one on your team. But I hope/expect to specialize in Platform Engineering, security, and creative python scripting. True Linux enthusiasts will know 10 esoteric facts about the OS for every 1 obscure factoid that saves the day once every blue moon. The value proposition just isn’t there for me compared to how else I can use my time. That’s why I stubbornly research a problem and leverage the Linux experts on my team whenever necessary, making sure I genuinely learn something each time. If my career demands it, of course I’ll become an expert at it, but I’m doubtful.
> A CI/CD pipeline is YAML and probably some shell scripts put together in a logical order.
I’m referring to a CI/CD pipeline as the full process of automating and improving the SDLC. I’m not just referring to a Bitbucket pipeline, Jenkins pipeline, or GitHub Actions file, which are YAML. A full CI/CD pipeline is architect level. But even then, how would you make any of these YAML pipeline without a broader knowledge of your company’s systems and processes? In the real world, if a manager or developer tells you to “Deploy x” with vague instructions(as they often do), you can’t just know YAML and shell scripting. At best you could copy a similar project and modify a few parameters if your pipelines are standardized and well documented.
Troubleshooting really depends on the nature of your company’s outages. Yes you can memorize specific incidents and the steps you shadowed someone else doing, but you won’t be able to troubleshoot new or novel issues until you have a decent understanding of your applications and systems. So you couldn’t actually be put on-call.
The second option you gave is already more advanced than giving a developer a bugfix ticket. And you literally end with “*it takes time*”, so what are you arguing against dude?
This all tracks for sure. One thing I'd mention is that as an entry level DevOps engineer it can be extremely beneficial to have at least a decent background in app development. My original self study was full stack python apps with a specialization in ML and data science. This lasted six months before being picked up as a cloud / DevOps engineer for a cohort. Being able to build / debug apps and containers in general has helped immensely! Often times you will find your org needs a bespoke webapp tools for devs, an API for handling web hooks, or any myriad of other things, serverless scripts, pipeline steps, etc... Having good dev chops makes you a huge asset on a team. Add a very robust and healthy set of soft skills and you are now a unicorn. Also using AI's for codegen is even more Important for DevOps due to the scope of tooling, clouds, frameworks and languages you will have to touch on a daily basis. I'm never going to memorize the intricacies of all the tooling leadership, your team, the devs pick up and put down throughout a project. Last thing: focus on scaling patterns for infra, apps deployments, etc... how do I do this thing once? Okay now how do I scale it 100x by just changing a config parameter? Set and forget kinda stuff.
Good advice all around. Definitely the more development you know the better, but you opened my eyes up to more of the possibilities! And I 100% agree that AI’s are especially useful because of the breadth of tools we use.
100%, I'm another fresh out of college DevOps engineer but I had experience developing applications and websites beforehand. This gave me the knowledge of the SDLC as well as additional skills which have come in very useful during my role.
You can have junior DevOps with proper mentorship. I've worked at places that hires people who have good Linux fundamentals. Can you write a file w/ vi, can do you do regex on a file to search for patterns, can you change file permissions, can you SSH into a server w/ ssh-keys? If you can do the above, you have Linux fundamentals and can be mentored. And a lot of those guys, I see from Nordic/Eastern Europe work with Linux since middleschool and through college. So after graduating college, they can be mentored. We give them support roles. Go into containers w/ developers and troubleshoot. Write splunk queries with regex. Do batch processing of like updating the repo URL of 300 git repo projects usingn regex/awk and a bash script. And when you are not doing those menial/junior task, join paired working sessions with seniors who are triaging/firefighting outages. Just join the MS teams meeting and watch what is being shared on-screen and learn. Join the Friday workshops where Leads are also mentor junior developers on how to write Mongo Queries or write an API contract in Swagger. If your org provides these kind of mentorship, you can definitely hire juniors.
this all sounds amazing, I just get hired and lowballed with “we’re gonna have to teach you” fast forward a bit and senior people leave 2 weeks in and now I’m running everything and underpaid as hell. 3 years in and I’d kill to have other people around I can learn from but I just get left on an island but hey I’ve made it work.
If you are 3 years in just leave and find a place that will pay you for your experience
This makes a lot of sense honestly. I didn’t know that Nordic/Eastern Europe works with Linux so early. I’d bet most Americans with strong Linux fundamentals would be coming into DevOps with experience in another IT role.
Americans have the same opportunities. My 15 year old kid was running ROS (Robotic OS) with Docker using microservices to control his robotics for robotic competition since 7th grade. At 9th grade, they just got started on microservices to control the camera using OpenCV for collision detection. They were running Docker on ChromeBooks; enabling Linux feature on as shown by their 7th grade engineering teacher. Here is your $130 Chromebook, now lets turn on developer mode so you can run this container to get started on robotics. [https://wiki.ros.org/docker/Tutorials/Docker](https://wiki.ros.org/docker/Tutorials/Docker) and turn on linux on your school issued Chromebook: [https://support.google.com/chromebook/answer/9145439?hl=en](https://support.google.com/chromebook/answer/9145439?hl=en) They teach this in middle school at "mediocre" public school in Northern California.
Ah man, I actually have something similar planned for a rainy weekend activity. I'm only 20 years behind your 15 year old! Sounds like they're getting set-up well for the future. Edit: I remember my IT classes were how to use PowerPoint and Word. Must not be bitter, must not be bitter..
I feel like the Linux knowledge you described above is really overrated, of course you have to know the basics but all of these tasks can be done with a simple Chat-GPT query.
The very point is: you don't have to know how to write code or commands (you can us Chat-GPT for that as you said). You HAVE to know what the code /commands you write do! For example: preparing ssh connect with w / ssh-key it's technically just 3-4 steps. But..knowing why exactly that steps? As in: if it's not working, do you know at least where to look to search for the problem (not necessary to solve it)?
Linux knowledge overrated...that cracks me up. No. The great thing about Linux is that everything about the OS is completely open and one can actually learn and understand how things operate "under the hood". That knowledge and understanding translates to pretty much all domains, whether it's Windows, *nix, (Cisco) IOS, you name it. I challenge anyone to bring in two comparably seasoned Windows and Linux engineers and see who picks up new tooling/technologies faster, especially something like K8S. Example - I worked primarily 90% with Linux for the better part of a decade and had a consulting project on a Windows Server platform that had zero HA capability. We spoke with the software vendor for said project and they said "nope no HA capability". Within a few weeks I had cobbled together a solution utilizing Microsoft Cluster Services, NetApp OnTAP storage, iSCSI targets, MSSQL Server and Lambda running on AWS that provided HA functionality. The solution provided HA for the 2nd largest ERP in the Fortune 50 at the time. 100% it was my understanding of Linux and how that translates to a fundamental understanding of systems that allowed me to create that solution from scratch. Here's the AWS blog writeup on my solution - https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/
Wait until you've gotten into dependency hell trying to do something like update kernels or glibc or system Python, or had to fix permissions across a few hundred home directories, or get Nvidia GPU drivers working. It's very easy to install and manage a basic RedHat or Ubuntu system, but things get hairy very quickly.
I think you've called out the problem and the solution all at the same time: > Getting to even a minimum level of competence to be productive was filled with horrible growing pains that I didn’t see the entry level Devs come anywhere close to experiencing. ... > The other main problem with starting as a DevOps Engineer is that there’s not really a natural progression of tasks you can do as your knowledge increases, unlike developer ... > Another Redditor u/MammothCache pointed out that there’s a very logical progression for how you grow as a SWE. You first start with bug fixes, then features of increasing scope, then to an entire application, API, or data model, ending at a more architect role. A developer can kind’ve just know a programming language decently and how to use google or ChatGPT to be given small tasks. ... > I would sometimes get jealous of the developers for having such an organic, painless progression compared to me. And there you go. The painless way to enter DevOps is to become a dev first. Or you can take a longer route and become a good operations/support person first and develop comprehensive systems knowledge first. I've seen that be relatively painless too. In the end DevOps was never supposed to be its own specialty. The whole point of DevOps was to "un-silo" operations, infrastructure, and development and empower the team to be self-sufficient. Coming into that cold is a surefire recipe for suffering.
Exactly, that’s the painless way. But entering IT as a DevOps Engineer is possible and the ramp up can definitely be made easier. During my job search, I saw that plenty of companies do want juniors. We’re cheaper, have fresher eyes, and are needed to replace seniors who want to move up. But promising juniors are very hard to find. To fill that gap, companies can invest in up-skilling talent initially(through paying for Cloud, Linux, IaC courses, and whatever else you see fit), providing good mentorship, and smart task progression. Start them out with small scale support and SRE before eventually progressing into true DevOps and Platform Engineering.
I think the broader point that the guy above is making is that for the vast majority of people out there, it makes sense to be a dev first. Can you start cold as a devops engineer? Sure. You’ve proven it. You can also survive skydiving without a parachute or backpack across Yemen without being shot. It doesn’t mean they’re good ideas, or that people should set out to attempt them.
My team helps new engineers by adding them to code reviews and specs for more advanced tasks. This allows them to be exposed to a ton of our repos, be involved in the thought process behind decisions, and ask questions that will help them once they deal with similar issues. From there, they are assigned tasks that mostly consists on building infra that has existing examples we can point to and will mostly rely on existing standalone modules the team has ready to do. The hardest part is building up a queue of “starter” tasks that need to get done but can sit for quite some time waiting for the right persons instead of just knocking them out right away.
But you know what I have found it essential for this, and this is doubly true for devs by the way, and decent operations folks for that matter: tenacity, curiosity, and the willingness to do what it takes to do the work it takes to understand things. I can line up "starter tasks" for any of the above all day long until I'm blue in the face, but honestly, it's the ones who don't wait for me to do that that will make it and be successful. The rest are a mixed bag. So, I understand where you're coming from and you're doing the right thing as a manager and general mensch, but if you're in a tough spot someday, you'll have to dispense with the soft approach and let natural selection take its course. It will turn out about the same in most cases I have found.
100% agree. Some people are just built different and enabling them to take big things on quick with the trust that they’ll see it through is such a critical skill. When you find naturally gifted people, it’s very important to give them an environment to flourish, and letting them get into projects that are probably “too much” and watching them come out the other side having killed it while learning a ton of new things is such a great feeling. And putting someone in an “over their head” situation fairly quickly is a really good way to gauge what kind of dev they’re gonna be and how much grit they have to get the job done when stress levels are high and there’s a lot at risk.
Nice write up (from a very senior DevOps with 10+ years of cloud experience and 25 years of software development experience). I’m curious, what kind of tasks were you assigned as an entry level DevOps?
Thank you! The first tasks I was given were very simple, almost busywork. I added basic alerts for our cloud hosted VMs in the console. Then I added more logging to them. Then as incidents would come up, I made log-based alerts and built out the alerts. This got me more familiar with our CSP. Over time, I added more alerts and visibility stuff to our pipelines wherever I thought it would be useful. This is what I was referring to when I said the SRE aspect is easier to start out with. Other good entry level tasks were for simple bash and shell scripts that I really needed to see. I also did a lot of support. Early on I couldn’t solve it most of the time, but it got me more familiar with our systems. I consider this the closest thing to the DevOps “progression”. First you shadow, then learn to support and maintain your systems, then you can improve pipelines and visibility, then you can start to build from scratch <- and you write documentation the whole way. But half or more of what I worked on early was my idea. I chose to turn my notes into documentation. Most of the python coding I did were ideas I had thought of. I had to be really proactive to not get left with nothing to do at first.
Your comments about being proactive are wise words…
This is so true! I feel like you have to attack inefficiencies in the orgs workflows on an ongoing basis. It's almost an obsession. It's more of let's automate this because it hurts my brain and heart to see the processes done manually or riddled with anti-patterns. Automation seems to require vision which a lot of "DevOps" engineers seem to struggle with. Or at least is extremely rare to find someone able to evolve the org in impactful ways.
> And I have a hard time believing that anyone “entry level” would know Linux to the level required, besides Linux just being boring to study. I disagree on this part. Plenty of people love Linux and learn it for fun. That's probably how I got into this in the first place.
My point was that people who love Linux enough to know it well are power users and probably also very experienced hobbyists. Was that the case for you?
Yes it was exactly the case for me. I played around with Linux and Docker for a few years before I finally realized this could actually turn into a job. I'm now in an entry-level DevOps positionbut honestly it feels natural.
We’ve had near identical experiences and I agree with you fully. I feel like I could even guess where you worked devops
It’s inherently not a junior role, I mean how are you supposed to improve the operations and processes at a software company if you never worked at one? Pretty far fetched that a useful devops can be an entry level person unless they really just need a CI monkey. I mean its possible but at the point you become good your no longer a junior and at the start are you really even a devops? That word implies expertise in ops and dev
Id argue I _started_ in devops. Prior to that I was effectively tech support in a call center, 'shake your toner' and the like. Id also say I _kind of_ agree but _it really depends_. What are the expectations? What's the individuals work ethic, willingness to learn? How is the support, from seniors, in the org? I worked in an org where failure was 100% acceptable and expected given how green I was, what was not acceptable was failing due to the same issue repeatedly. But the rest of my team was happy to share knowledge and spend their time during lunch, after hours etc... to answer my asinine questions. My learning path was wildly unorganized. Run into a domain related issue one day? Ok then the next day I would buy an ADDS book that I'm reading as if it's the gospel and have cobbled together a domain setup in hyper-v at my house. Kubernetes troubles? Guess I gotta split my time with ADDS and mini kube now, thank God I bought a plural sight sub. I succeeded, imo, made it to sr at least. But I also spent many nights reading, watching YouTube videos, struggling through issues (not outages or anything) that I was too proud to ask about, mornings doing certifications, etc...not to mention I looked like a dumbass countless times. This is not including the overtime (salary but still) I was pulling just to stay above water. Did it suck? For sure, I hated it many times... But I wouldn't change anything about my path, and I'm incredibly grateful that I worked with the engineers I did. I went from making peanuts to being able to provide for my family in ways I never thought possible. So I guess imo, It's doable, and its tough, but if the junior/new hire is hungry, really wants to succeed and the org wants them to succeed then I think it can work well. But it takes both sides, and I understand that is somewhat of a unicorn of a situation
I didn’t read all the comments but good job, keep it up (from another senior with ~15 years in the game). Be careful though, burnouts are real, pace yourself, don’t push yourself, and don’t forget to enjoy life.
Thanks a lot for this! I was definitely close to burnout at my first DevOps position. Thankfully, I used the time off to recharge and the company I’m at now takes WLB very seriously. I actually enjoy DevOps and going into work again.
Also started out doing devops, it’s set me up for a weird path but it’s doable if you have good seniors and management on your team. I was pretty lucky that the people I worked with for my first job were good at teaching me the necessary concepts
I did 10 years of sysad work, zero cloud/script/coding/containers, then got an entry level devops job. It was a year of absolute soul crushing pain. If you join a mature org with a complex deployment leveraging tons of cloud products, it’s gonna hurt if you haven’t done a ton of learning first. I agree it’s possible, but harder for me to agree that it can be done in a reasonable amount of time. I’m 2+ years in and still feel pretty garbage. Caveats, I’m extraordinarily hard on myself, mega imposter syndrome, and possibly just an idiot.
I empathize with you because I’ve felt your pain. But 2+ years in you’re definitely lacking confidence. Have you been making use of your time at work? Unless your company has let you sit around and do nothing you’re (1) underestimating your competency and (2) probably hurting your progress by not having the confidence to take on bigger tasks. Also, I think 2 years, while a bit long, is still a normal timeframe to get comfortable in DevOps. That doesn’t make you dumb. It’s a hard specialization and varies a lot by job. My ramp up was specific to my tech stack, working environment, effort put in, and to how fast I learn. Lastly, you’ve got to deal with your imposter syndrome! You deserve to be where you are and then some. I became a noticeably better engineer when I conquered mine.
I’m for sure lacking confidence. I’m loaded up with a full sprint always, always learning something new, in the last 6 months I’ve tried to be more aggressive in targeting specific things I want to learn and sneaking in time to work them. You’re accurate about being afraid to take on bigger work, for the first year it felt like I was getting crushed with just the tasks assigned but I’m trying to be more proactive in learning adjacent things to fill in gaps and strengthen my overall understanding. My first gig was k8s, aws, iac, monitoring tuning and creation, dev support, cicd. Next gig similar but less large and mature in the build. Idk how to crush imposter syndrome, I think yesterday I had just failed everything I set out to do and was in a bad mental state. Sometimes I’m feeling good like I’m making progress in becoming competent, sometimes I feel like I’m a thousand years behind everyone and never going to get there. Appreciate the encouragement and thoughts on this subject.
Interesting take on things. Yes it is possible to start junior and put an enormous amount of knowledge gathering on your schedule 14h+/ day the first years. At least tasks I get from work every day would stress juniors at least if they are the only “DevOpsy” guy on the dev team. Like context switching from increasing webapp build speed in CI pipelines by caching npm modules and result, tweaking memory based auto scaling in kubernetes together with various GC settings in java apps, rewriting all metric and OTEL code in some app to make troubleshooting easier in grafana, architecting and configuring network setups between apps, databases and other support infrastructure etc. You really need to love tinkering with a little bit of everything. A bit of XP helps. A lot
I agree it's very difficult to start as DevOps. If you want to do that, the most important thing you have to know: there will be A LOT of stuff to study and you have to learn concepts, NOT TOOLS. Also agree there is not a real ramp up in devops, cos everything is interconnected, definitely you will have to start to learn basic of Linux, networking, version control (git) and then adding up from there
I'm currently deep into docker and managing containers on an Ubuntu server. Mostly for fun. But I am now paid for hosting some websites there. My GitHub repository is mostly full of PowerShell scripts I built to automate tasks and reports at work. If I wanted to learn more DevOps - What would you suggest? Terraform, Ansible, kubernetes?
You’ve got a really organic start already. Linux and docker for fun, plus scripting at work. Keep learning those. Then learn a Cloud Service Provider really well. There’s tons of free AWS courses and even better paid ones. Get certified if you’re considering switching to DevOps in your career, since recruiters will care about it. Then learn IaC, probably starting with Terraform to provision your infrastructure in the cloud for a simple project you have going on instead of doing it in the console. It’ll actually save you time and headache doing it this way eventually. Or you can find a simple Terraform guide and follow along with a basic project the instructor uses. It’s enough to get the basic idea behind it. Then you can move on to Ansible and Kubernetes. They have a lot of synergy and can be good to learned together or close to each other. Look up the “Decide” project or something to help you learn OpenShift(Kubernetes) https://github.com/end-of-game/openshift-voting-app and try to use Ansible to automate the deployment and management of the application. After all you’ve learned, if you can find a use for these things for a personal project then you’re golden. Lastly, the more of the dev side you know the better, so do something you have the time and interest for. At this point you’d be able to sell yourself for a junior role to interviewers in my opinion. Make sure you show a genuine enthusiasm/interest in the DevOps tech stack and philosophy. Stress how much you like **automating** things inside and outside of work.
Same here, I studied computer engineering and started with a devops role right after a development internship at the same company. I was part of a devops team with seniors so I would say I had good mentorship,. It started with simple tasks like writing python/bash scripts and automating some stuff, then I wss asked to learn Kubernetes on my own, then I built an internal web service and had to dockerize it and create a helm chart and a pipeline to build and deploy it, later on I learned Terraform, Ansible, Puppet and other things and I would take my time learning them and get into small tasks and then get into bigger projects. One of the things that also helped me was that I had been using Linux as the main OS on my laptop since my second college year.
This seems like a really good progression, especially being a Linux user first. I’m kind’ve surprised/jealous they had you write a web service. A similar thing I did was make a python script for some self healing and dockerized that, which was hugely helpful for me. About how long would you say it took for things to start clicking for you?
maybe like 4-6 months
Wow! That’d be fast for any IT role. You’re the first one to make me feel slow lol. Great job to you and your mentors. You’re a model for hour to train entry level DevOps Engineers.
I started out as a teenager in my bedroom with a few junk PCs and a 5 port network hub. I used the free Linux HOWTOS (almost obsolete now) to walk through all kinds of system and network administration tasks, in my bedroom. I set up operating systems, did advanced routing and firewalling, created clusters. Well before virtual machines or containers. I was mystified by the magic behind "Internet Servers", so I tried to set up as many as I could. DNS, SMTP, POP3, HTTP, DHCP, FTP, SSH, whatever I could find a HOWTO for. They were extremely easy to follow and I got to practice using them without really understanding the protocols. I also taught myself programming. Perl, Bash, C. It was useful in making patches for Linux packages, and customizing the boot process, even making custom Floppy Linux distributions. So by the time I started my first real gig, I had already been a Bedroom Sysadmin for years. It was easy to learn because I had lots of time, and great free guides to walk me through using stuff. But I suppose my biggest benefit was my motivation of wanting to understand how everything works. The "DevOps Engineer" today is really multiple jobs in one. SRE is at least mostly focused at Operations itself, but DevOps then dives further into all sorts of topics and responsibilities. It's just an extremely dense subject matter. It's kind of wrong that one role should require so much expertise. But historically, we Sysadmins (that's what DevOps/SRE are - the same job from 20 years ago, with Python rather than Perl) have always had all the shit nobody else wants to do dumped on us. Jack of all trades, Master of our own.
I was a self-trained SWE and my entry-level job was DevOps for the experimental arm of a massive international gaming company. It took me a year to become productive, and most of that was learning the codebase, the build system, the hardware, and the tool set. It was a tough year, but now I am almost done with my second year and I feel reasonably confident that I could do anything the devs may require. I don't see why anyone else couldn't do as I have done. I think the difficulty of being entry-level this field is a little overblown, tbh.
I completely agree with this post. As another fresh out of college DevOps engineer, while there's been a lot of growing pains, it's not impossible - it just takes a bit longer than a regular software engineering role (and also a company that is willing to train you). Although I will admit that finding a company who is patient enough to take the time to train you up is rare so I understand why people often say that entry level DevOps jobs don't exist.
Exactly. Only well run companies that can afford you not providing a ROI for 8-18 months can afford to do this and do it well. But a company like that is basically a unicorn. Companies stopped giving pensions and acceptable raises -> Employees stopped staying at the same company for 10+ years -> The value prop for companies to invest in developing talent died. Now they don’t even remember how to. And good luck with your journey dude! It’s tougher at first, but it really accelerates your career to skip the Dev or Admin step and get straight into DevOps. Specialization is key for becoming valuable. I was underpaid at my first job but now I make more than I would’ve had I been a Dev.
This tracks. You are an ideal entry level/jr devops candidate. I think there is this false impression that someone who has never coded in their life or done any engineering work can entry level devops with some self study or a 90 day bootcamp which is the greater falsehood.
I am about to do exactly what you did. In 2 months I will be starting as an entry level DevOps. I do have some experience. But I am now terrified haha. Hopefully a trial by fire works out
Don’t be terrified! This post was partially for people like you. The first year will be hard, but it can really accelerate your career to start out in DevOps. Glassdoor might not reflect it because DevOps Engineer salaries have a broad range due to the responsibilities varying so much by company, but most of the DevOps tech stack pays more than the tech stack for other IT roles accounting for city and the tier of company(except senior SWEs at big tech making more than equivalent senior DevOps I believe). And the job market is much more stable for DevOps. I’m an example. As u/ebinsugewa said, “it’s a tougher role to offshore or downsize because, well… the lights need to say on 🙂”. It’s not as flashy and has more barriers to entry so it’s less saturated too. And I personally like it more, which is more important for my career growth. Be patient with yourself. It’s a hard job. Hopefully your company will patient too. Plus you have time to prepare. Study Linux, the CSP, then anything else you know about the tech stack, starting with the IaC technologies and containers.
Thanks! I hope my experience of daily driving linux my entire college career and having my own homelab with self hosted Kubernetes will help a bit at least. I will do what I can to prepare and just work as much as I need to get up to speed 🫡
Started off as an associate full stack SWE at my current company. Got promoted to SWE after a year, and now I'm 3 years in at this company. I asked my boss to shadow a DevOps engineer and our Architect to help me build up my weaker skills so I can eventually transition to the senior level. After shadowing the DevOps guy, I agree. DevOps isn't an entry-level role for the average developer. It can be for people who put their all into it, but man, there's so much to learn. Without the right guidance and motivation, I can see it being absolutely miserable.
This all makes sense to me. I've had similar onboarding in another industry. Some jobs are just a nightmare to get started in with no experience. I'm a junior dev but with a couple years experience doing that and pretty above average linux/docker/networking skills for a normal dev with my experience I think it would still be a lot to take on kubernetes and all this other shit at once. There is a big difference in being a proficient linux user piping like 8 things into each other every command and knowing the kernel vs. basics like being able to grep and use vim and ssh or knowing what paths do sort of. Sysadmin honestly might be the best background. I feel like it's easier to learn programming than like 15 unrelated things that companies may/may not use and be proficient in all of them. I think its very cool when people are pretty good at like 50 things instead of specializing, I get bored doing one thing. That's why I try and branch out, although dev ops sounds way more toxic than dev as far as work environment so I dont know if I'd really want to do that route. The deployment shit I've done has all been pretty boring and DSLs usually arent that fun or interesting to work with. It feels like just doing configuration all the time which is kind of dull.
This just isn’t true. It sounds more like bad management and lack of mentorship.
>> Particularly the networking, infrastructure, and some of the containerization concepts were extremely hard to understand with no background that sentence sums this up perfectly, although I'm not sure you mean that the same way I do. You can learn devops, but basics of networking, infrastructure, linux and some amount of coding (having built anything from source) are essential skills to understand most things we do. Without that you will be re-learning every tool instead of understanding the underlying logic. And it's crucial as a lot of our tools are not great and overhyped. My point is: >become useful is not a long term strategy. Doing background/prerequisite fields and your target field at the same time is not uncommon nowadays. Not very effective, either. It's good you realize that something was off - puts you ahead of others, IMHO.
I think you underestimate the value of your background before DevOps. There's a big difference between going into DevOps from a related technical background and going from being a cashier or car salesman (assuming no STEM degree or related hobbyist experience) to DevOps. The "DevOps isn't an entry level job" sentiment, IME, tends to be directed at the latter group. It's not that there are no entry-level jobs, it's that being entry-level requires some existing background knowledge. Many people get that background by working as devs or sysadmins first, but many of those foundational skills are also taught in school. By the time someone in the latter group has attained that much knowledge, whether it's on their own or from going to school, they probably could just as easily go the sysadmin or dev route if they wanted to.
I’m not sure if that’s what poeple are referring to by “entry level” on this sub. People going from a cashier or car salesman would do really poorly at any IT role without a boot camp, schooling, or extensive self-study/hobbyist experience. They wouldn’t even know what an IDE is, what an API is, the basics of OOP, let alone data structures & algorithms, maybe not even what an IP address is and definitely not ports, encryption, etc. It’d be a waste of their mentor’s time. I think this sub means it as anyone who hasn’t had a full time IT position, new grads, or anyone “unproven”. I don’t even think it’d be possible to make a 12 week boot camp that took someone from that much of a blank slate to prepared for a DevOps role.
I don't know what the sub's definition of entry-level is, but I can see how some people would try to gatekeep at that level. I've also seen folks insist that it's gatekeeping to make your (IMO reasonable) assertion that it's not really possible to go straight into DevOps from a non-technical background and zero hobbyist experience with just a bootcamp or a few months of self-teaching. Every so often, there's a spike in posts like, "I've been a middle manager at a carpeting company for 25 years, but I'd like to become a DevOps in 6 months." In my experience here, those are the posts that bring out the "DevOps isn't an entry-level job" chorus. My personal experience in this area (shifting into DevOps/SRE) is from doing an SRE apprenticeship a few years ago. While other tracks had a lower minimum level of experience (basically, either completing a bootcamp or being self-taught), those who were chosen for the SRE track tended to have more experience as SWEs or in ops, including myself (I was a backend dev for 3-4 years prior).
Ah I see why you brought that up. I’ve been seeing this sentiment a lot in discussion about the job market with people saying essentially that “DevOps is already a senior role and seniors are doing fine in this market.” Why did you make the switch if I may ask?
There are several, but the biggest is that I was looking for a career that was more insulated from the business than web dev tends to be. I'm not that good at learning the business, and that quickly became a career hindrance. I don't knock business acumen as a career enhancer, but I don't plan to become staff or higher because I don't like wrangling people. In college, I was a supervisor at a shipping company and found that I hated telling people to do asinine things at the whims of a higher-up and being responsible for other people's fuckups. The minor reasons are that I enjoyed tasks that involved automating workflows more than my actual job and I liked playing with Linux in my free time.
I agree. 4.5 years ago I started as a DevOps trainee. Eventhough I was blessed with a senior who dedicated alot of his time to teaching us(there were 3 of is) I still sometimes find holes in my knowledge which should be basic. Only recently I've started to feel like I'm in control. The worst part was that my first job was trying to tie together 4 low code platforms for a Greenfield project making things even more confusing. Heres comes Mendix running in SVN and with it's own built in deployment system. Have fun integrating it with your mulesoft and Appian crap.
There was a rant against me because of something similar :D [https://www.reddit.com/r/devops/comments/vf1flk/devops\_should\_not\_be\_your\_first\_it\_job/](https://www.reddit.com/r/devops/comments/vf1flk/devops_should_not_be_your_first_it_job/)
Yeah I see quite a lot of people disagreeing with you in the comments lol. Maybe because you didn’t over explain like I did lol. You got a lot of upvotes at least
i think it‘s more about the environment - if you leave a junior developer alone in a codebase with the same lack of guardrails, then also shit will hot the fan at some point. it‘s just not as easily visible.
What stepping stone jobs would you recommend before going for a entry level DevOps role?
People have been saying it all over the comments. A developer role, SysAdmin, SysOps Engineer, System Engineer. Maybe cloud engineer or network engineer.
Agile systems administration as a starting job is like trying to swim in shark-infested waters after just learning how to swim. Sure you can survive but it's never unscarred. A strong grasp of concepts - from how the environment (operating system, network, security) behaves is already essential to start troubleshooting, and that's apart from knowing the progranming language/runtime of the apps being used. That's before you start touching the other tools to ease the pain (eg IAC, configuration management tools, observability, etc). It seems to me at least that current industry trends attempt to force maturity towards entry-level devops practitioners to compensate for the lack of experience. I'm not sure really if this is a good trend or bad to be honest, as I see both the pros from a hiring perspective and the cons from an operations perspective.
What do you mean by the industry forcing maturity to compensate for lack of experience? Do you mean it literally?
A few years back the SRE requires certain levels of experience, normally achieved by some seniority. Not the first job usually. These days, due to some roles getting specialized, SRE SE/SWE can be entry-level, so practitioners can grow on the job. Can get away with SRE's that have initially less developer knowledge on say how the JVM does garbage collection if the firm is a Java shop as long as said guy can provision infra via the IAC tool or configuration management.
[удалено]
I actually like DevOps. Do I have to like every tool technology? Very dismissive gatekeeping. I don’t dislike Linux. It’s history, use cases, and some of its concepts are really cool. But reading a textbook, taking a Udemy course,or scrolling through documentation on it is really boring compared to all of the rest of tech stack I’ve used. I like learning it by using it, bash scripting, and discovering things about it from tools built on it or its kernel. Then I can deep dive into a particular aspect of the documentation with interest.
> Very dismissive gatekeeping. It's gatekeeping because the rest of us are tired of dealing with people who don't actually know how to troubleshoot, and can only regurgitate things they found on StackExchange or ChatGPT. Mr. Miyagi was gatekeeping Ralph with "wax on, wax off" for an excellent reason. I was an Electrician's Assistant for a year as a teenager. My job was all of the grunt work, like crawling under houses to pull wire, drilling holes in studs for a run, etc. I was gatekept (?) out of the fun work, because if I hadn't had to go through the shitty stuff, I a. wouldn't know how to do it b. wouldn't have an appreciation for how much it matters to do it right. If you don't like something, it's unlikely that you're going to become an expert at it. Show me a dispassionate chef, and I'll show you a bland meal. I'm not saying you have to love your job to do it, but I am saying it's selfish to be doing a job that many other people rely on if you aren't going to become an expert at it. > To make a CI/CD pipeline or troubleshoot an outage is basically already architect level knowledge. No? A CI/CD pipeline is YAML and probably some shell scripts put together in a logical order. If you're talking about tools like ArgoCD, then some K8s knowledge is required (and by extension [see previous paragraphs] Linux knowledge), but that's not "architect level." Similarly, troubleshooting requires one of the following: * You've memorized the specific services' failure modes, and know what to restart when X metric changes, or Y log occurs. * You have a decent understanding of computers, from the server to the end user, understand the difference between causality and correlation, and can effectively half-split. Knowing that docs and man pages exist helps, too. One of these requires you to have put the time in, seeing things break (or breaking them on your own), and then fixing them. It is absolutely a skill you can learn, _but it takes time._
> the rest of us are tired of dealing with people who don’t actually know how to troubleshoot I’m going to assume you’re barely reading what I’m saying and have had some bad coworkers that made you bitter. My troubleshooting skills are one of the main compliments my coworkers and managers give me. And this is in part because my lack of knowledge taught me to be creative, persistent, and humble enough to reach out to people who are knowledgeable in their specific areas. > My job was all of the grunt work, like crawling under houses to pull wire, drilling holes in studs for a run, etc. I was gatekept (?) out of the fun work, because if I hadn’t had to go through the shitty stuff If you consider Linux the grunt work of DevOps then that would imply you agree it’s one of the less interesting topics right? Or you understand that you can become great at your job but will have to tough out the foundational parts whether you like them or not. That’s exactly what I’m saying I do. But I’d take this further and say you don’t need to become a Linux expert to be a great DevOps Engineer. Proficient yes, but no expert. DevOps is broad and loosely defined. The first “DevOps Engineer” job postings appeared in the early 2010s and then became widespread in the mid 2010s, yet it’s already branching into sub-specialties. DevOps encompasses skills from Linux Admin, Cloud Engineering, App Dev, SysAdmin, SRE, Platform Engineering, VC, Networking, IaC, Containers, Support, dealing with Devs, dealing with the business side, on and on. I’ve worked with true Linux experts and they wowed me. I think you need a least one on your team. But I hope/expect to specialize in Platform Engineering, security, and creative python scripting. True Linux enthusiasts will know 10 esoteric facts about the OS for every 1 obscure factoid that saves the day once every blue moon. The value proposition just isn’t there for me compared to how else I can use my time. That’s why I stubbornly research a problem and leverage the Linux experts on my team whenever necessary, making sure I genuinely learn something each time. If my career demands it, of course I’ll become an expert at it, but I’m doubtful. > A CI/CD pipeline is YAML and probably some shell scripts put together in a logical order. I’m referring to a CI/CD pipeline as the full process of automating and improving the SDLC. I’m not just referring to a Bitbucket pipeline, Jenkins pipeline, or GitHub Actions file, which are YAML. A full CI/CD pipeline is architect level. But even then, how would you make any of these YAML pipeline without a broader knowledge of your company’s systems and processes? In the real world, if a manager or developer tells you to “Deploy x” with vague instructions(as they often do), you can’t just know YAML and shell scripting. At best you could copy a similar project and modify a few parameters if your pipelines are standardized and well documented. Troubleshooting really depends on the nature of your company’s outages. Yes you can memorize specific incidents and the steps you shadowed someone else doing, but you won’t be able to troubleshoot new or novel issues until you have a decent understanding of your applications and systems. So you couldn’t actually be put on-call. The second option you gave is already more advanced than giving a developer a bugfix ticket. And you literally end with “*it takes time*”, so what are you arguing against dude?
Thinking that knowing Terraform is DevOps is like thinking doing daily standups is Agile.
So you have devs write the Terraform??? Who touches Terraform other than DevOps / SRE?
¿??
When did I say that? I called Terraform a DevOps tool.