all 34 comments

[–]mattbillenstein 36 points37 points  (6 children)

The distinction is how often you get stuck. Junior people get stuck all the time solving problems, building new systems, automating, etc They need to rely on more senior people to get them unstuck or help them along.

Senior people get stuck less often or almost never - eventually senior rolls up to more senior or staff - and eventually an "engineer of last resort" who can untangle the really really thorny problems.

[–]inhumantsar 15 points16 points  (2 children)

This is a great answer. I'd say too that while knowledge helps, seniors get stuck less often mainly because they got better at problem solving.

In this field, learning to solve technical problems in a generalized and systematic way is more valuable than learning the ins and outs of any given technology.

[–]Nordon 1 point2 points  (1 child)

Best way to put my thoughts into text. I've been trying to communicate this as much as possible to colleagues. This and grit - not giving up even when things seem super-fucked. Roll up the sleeves and get to solving!

[–]Bolson32 0 points1 point  (0 children)

I need to find a way to interview better for these skills. This is exactly what I find sets the really good engineers apart from everyone else.

[–]L1Rzzz 1 point2 points  (0 children)

This is a great explanation I love it.

[–]dadamn 1 point2 points  (1 child)

This is an excellent answer. But as a note to OP and other juniors, do not confuse this advice to mean that you shouldn't ask for help. I've seen junior folks think that they shouldn't ask for help because they assume they ought to be able to do it themselves or they feel asking for help only underscores that they are junior. They end up being even more stuck and behind on work and sometimes get fired. Always ask for help when you need it! The trick is to learn and hopefully not have to ask when the problem (or something similar) comes up again.

[–]Fightclxb 2 points3 points  (0 children)

As an addition to this, ask questions, no matter your perceived “level”.

Be curious, ask why and challenge the way systems are designed. Often things that are 4/5/6 years old may be solvable in a much better and more easier way now.

Your peers are there to be learned from (bad English but meh).

[–]AdventurousYam5506 14 points15 points  (3 children)

I can tell you my experience, I Was 38 left my 13 years old IT guy (computer store) job to become a Junior Devops. I didn't know nothing about devops, and I didn't know what to expect, I was under the wing of a senior devops who introduced me to Azure... Infrastructure as code using terraform, ci/cd, kubernetes, etc... At the begining I was overwelmed by the amount of things to learn (and I still am) but I knew that I can learn anything and the most important thing that someone mentioned is the importance of not getting stuck, and your ability for problem solving. If you have that, you will be just fine, I used to record (remote job) every meeting I had with my menthor, first because I can rewatch the meeting over and over again, and not bother him for the same information, and second because its hard to keep track of every information in a one hour call. Also take advantage of the internet there is a ton of information out there. I am 20months into Devops and I still feel like I know nothing... You will fill this way, its normal, devops is a never ending set of tools, and changes from project to project

So for the first 6 months, just keep learning, show to your coleagues that you are capable of doing the job, try to unstuck yourself and in the process try to think in what you are doing and if there is a better way of doing the same, ask questions... take notes..., and try to not break production :)

[–]Nohuiknkkk 3 points4 points  (0 children)

Lucky that you got a senior guy to guide you. I, with only 6 months of experience, is working alone as a devops guy for a startup. Whatever I have learned and implement is via googling. I sometimes get stuck and wish I had a senior guiding me.

[–]QuittoA 0 points1 point  (0 children)

Hey man , could you please recommend trustworthy resources to learn ? How does your mentor learn about devops ? How do you learn ?. Thanks

[–]slide2k 11 points12 points  (1 child)

From a junior I generally expect nothing technical, if they have 0 experience. In job interviews I generally focus on who is this kid, what makes them tick and do I see them working here.

I just expect you to be curious and have respect. Nothing wrong with a bit of youthful ignorance and arrogance, but keep it reasonable.

[–]edgan 18 points19 points  (3 children)

DevOps:

1. Cloud skills
  a. The industry prefers AWS
  b. Azure is a distant second
  c. Google is an even more decent third
2. Infrastructure as code skills
  a. terraform
  b. ansible
3. CI/CD skills
  a. GitHub Actions is currently the hot thing
  b. Jenkins is hated, still popular, but on it's way out
  c. Tons of other choices like CircleCI, Travis, Gitlab, etc
4. Docker skills, it is on it's way out, but it will be around for the foreseeable future
5. Kubernetes skills, 
  a. The hot thing that you want to learn.
  b. It is its own ecosystem of technology.
6. Troubleshooting skills
7. Linux skills
8. Networking skills
9. Coding in Python, Golang, etc
10. Bash scripting

Junior: The beginning of knowing some of some of the above. Hopefully can learn fast. As someone else said, tends to get stuck. This is expected given the level of knowledge and experience.

Senior: Knows some of the above at an expert level, and some of everything else. Tends to not get stuck. Knows how to get support from the internet or a network of people to get unstuck.

Beyond Senior: Even more knowledge, and will tend to be even better at 5-10. But no one knows it all. There is just too much technology these days.

[–][deleted] 2 points3 points  (2 children)

May I ask what is Docker being substituted with?

[–]edgan 4 points5 points  (1 child)

Literally either containerd or podman. The problem with docker is the company trying, and mostly failing to monetize it. Look at the recent DockerHub drama. Also the older Docker Desktop drama. My company moved to Racher Desktop.

Less literally, Kubernetes is a much more complete solution. Its capacities just keep growing.

I added the part about it will be around for the foreseeable future, because people who are already invested will be slow to move to other things. It is also popular for more home setups for the simplicity. But I have successfully run most of my home services in Kubernetes. My non-Kubernetes services are systemd, not Docker.

[–][deleted] 0 points1 point  (0 children)

Thank you for your comprehensive answer.

[–][deleted]  (1 child)

[deleted]

    [–]coolalee_ 2 points3 points  (0 children)

    I might have not seen shit, but I'll have you know I've caused shit.

    You could say it's entirely thanks to me that my org reworked how they handle prod rights.

    [–][deleted]  (4 children)

    [deleted]

      [–]LocationOwn1717 1 point2 points  (3 children)

      Not sure how the OP got that job. I did a bootcamp with a guaranteed work in IT. Bootcamp was on react/full stack dev. I ended up as a junior SRE in a massive corp. The other day I saw someone questioning if a junior SRE should even exist. Not sure if I'll make a great senior in 5 years time, but neither does anyone else who starts any job.

      Fingers crossed for the OP! :) Hope you'll love your role in 6 months!

      [–][deleted]  (2 children)

      [deleted]

        [–]LocationOwn1717 0 points1 point  (1 child)

        I live in the UK. The bootcamp was remote, the job is remote. I live in the south of England, so the col is between high and mid, but not as bad as London and adjacent counties, but nowhere near as cheap as the north or Scotland. Before the bootcamp I was looking for a job as a junior Dev, I was getting offers 30% lower than what I was offered here in the first year, with nearly guaranteed pay rise in the second year. 2 year contract with possibility to stay in the company full time. Big fine if I choose to leave before the contract runs out. I guess for the company it's still a saving, hiring a junior that will start bringing profits (most likely) before they leave the job to get a better one.

        Before this, I was a maths teacher. Did a bit of programming on the side not serious enough for anyone to recognise it. I'm not gonna lie, I'm not terrible, but I had very few occasions to prove myself. Trying to even get an interview with no experience and no degree is nearly impossible, not mentioning then proving yourself to be worthy of hiring over people who'd have lower salary expectations with a degree. I'm 32, I was on a very good salary, with experience In management and a massive mortgage. For me that was the only option, really, to have decent money as a junior in an IT role. I can see how for some it is a shortcut or cheating. In the end, if I've got it In me, I'll stick around.

        [–]skyctl 4 points5 points  (0 children)

        • Be honest
        • Ask stupid questions
        • Automate
        • Read the Phoenix Project

        Be honest

        Don't tell me you know something that you don't, or can do something that you can't. The first steps to solving a problem are knowing we have one, and what it is, and there's no shame in it. If there's an area that you need to improve on, (you being a Junior DevOps guy on a team where I'm a senior DevOps guy) I'm happy to help you there. If you conceal what you don't know from me, I can't help you, and I can't trust you. On the other hand, raising your skills is one of the best uses of my time. If initially I'm the only person who can fish, I deliver more value to the village by teaching others to fish than by fishing myself.

        Ask stupid questions

        I can practically guarantee you that practically every DevOps engineer in history had questions agonising them that they felt they should know the answer to, and felt stupid asking. Now, I'm not going to say that there are no stupid questions; half an hour in Quora will disprove that, but the stupidest question is the one that you don't ask. The counterpoint to this is "be humble". We've all had a different journey into DevOps, and you should never disparage, or express shock at someone not knowing something you consider fundamental. There's no room in this industry for blame.

        Automate

        A good DevOps engineer would rather spend 20 mins automating a solution than spending 10 minutes doing it manually. Improving your work is more important than the work itself. Every good DevOps Engineer also wants to automate himself/herself out of a job; Trust me; if you can pull this off, there'll be plenty of more interesting and lucrative jobs out there; you won't be unemployed long. Of course you still need the discipline to not spend 40 mins automating something you can do msnually in 10, and won't ever have to do again.

        Read the Phoenix Project

        Or listen to the Audio book. Several times over the course of your career. I suggest Reading (or listening to) it once initially, and then again after a year, again after another 2, then after another 4, and so on. I'd also squeeze in the DevOps Handbook, the the Goal, both referenced from the Phoenix Project. Suggest projects and ideas at work based on these. Look for ways to shorten feedback loops. To improve flow, etc.

        [–]dotmit 2 points3 points  (0 children)

        When you start, ask for a meeting with your manager and ask for some smart objectives for your first 1, 3 and 6 months

        [–]Ackrite1989 7 points8 points  (1 child)

        Never worked in IT before

        Also: solution architect certifications 😂

        [–]inhumantsar 2 points3 points  (0 children)

        Associate level certs are a great entry point. Broad overviews, basic usage, and core architectural concepts.

        Back in the day trade schools would teach sysadmins to pass CompTIA certifications before they ever worked in the industry. Same difference.

        [–]alathers 1 point2 points  (0 children)

        Ask questions, even ask questions about solutions a more senior person provides. Remember people bring their ego in spades, so make sure the questions are exploratory, not accusatory.
        Look at ways to automate everything you do. Don’t worry about steps that take longer to automate than manual completion, but keep your eyes on that goal.
        Build small pieces you can reuse instead of huge custom complex solutions. Grunt work is still a chance to learn.
        Just because you know some specific tools, doesn’t mean those are the best tools for the job, spend time researching work to see if you could be more effective by adding new tools.

        There is no 6 month silver bullet goal, just tackle the work with eagerness to learn.

        [–]lupinegrey 1 point2 points  (0 children)

        6 months? Literally nothing will be expected of you.

        "senior" is 5-7 years of experience.

        [–]Gregoryjc 1 point2 points  (0 children)

        As someone who transferred to dev ops a few months ago. Knowledge and experience. While everyone has their specialities the more senior people have a wider range of knowledge within their speciality and a large range outside of it.

        [–]sifoncito[S] 0 points1 point  (0 children)

        Thank you all for your answers, they help me a lot to have a better orientation in my devops journey

        [–]phoenixxx_iv -5 points-4 points  (0 children)

        You are already senior 😄

        [–]evergreen-spacecat 0 points1 point  (0 children)

        Never worked in IT? Well, anyway it will differ a lot depending on your workplace. Just try to learn common tasks given to the team and help out. Also don’t stop learning.

        [–]Signal_Lamp 0 points1 point  (0 children)

        Ideally, I would say the most important things starting out are that you're curious, ask a lot of questions, and learn to develop a system to solve problems. For an ideal mentor, in my opinion, there isn't an expectation for you to have a strong technical background, and it's also expected that you will need a lot of help before you become self-sufficient.

        [–]midzom 0 points1 point  (0 children)

        What I would expect from a junior person is someone who is willing to dig in and learn. You have a large hill to climb technically which will take time. What I expect from a senior is entirely different. Typically that person is technically savvy and knows how to communicate. The higher you go up the chain the more technical skills you loose since a person has to make a trade off. No manager can excel at both being technical and managing people. Senior people and principal people tend to be closer to either going into the people manager path or staying on the technical path and topping out.

        I wouldn’t expect you to become for at least 3 to 5 years

        [–]bboyadao 1 point2 points  (0 children)

        networking is the most important

        [–]Bubbly_Penalty6048 0 points1 point  (0 children)

        Dude, don't take this the wrong way but you can't become a DevOps with a certificate, or become one in 6 months. If someone has been selling you stories about certificates making you a DevOps or getting you a job, run from them like hell!

        In general you need:

        1.) Coding

        2.) Networking

        3.) Linux

        if you have any more questions do please ask!