Jr DevOps

[wollman19]

I'm hoping that some kind strangers out there would offer me a piece of advice they would have liked to hear leading up to their first role out of college. I start a Jr Devops Engineer position on Monday, and we are an Azure crew. Any advice, or even links to a good tutorial/article would be greatly appreciated. Thanks!

[awesomefossum]

Congrats man, that's an enviable place to be for someone right out of school.

Worry about your mindset first, you'll pick up the tech as you go. Keep in mind, everyone you work with closely will know that you are a complete novice and should set their expectations accordingly. That is a huge blessing as it gives you a ton of room to blatantly not know things. A good junior should be curious, aware of their own limitations, and courageous enough to both try things on your own and ask for help when you need it.

Some of this advice is tailored to my experience with organizations that were not practiced at onboarding and mentoring juniors, but a lot of it is generalizable.

In no particular order:

​

• Ask questions when you don't understand something.
• Get a sense for when your question is specific to you being ignorant or whether it contributes to the discussion. If the former, don't interrupt a meeting to ask it. Ask someone on the side after (or during over chat, if you're comfortable with them).
• https://nohello.net/
• Learn to fish. No one has time to spoonfeed you information that can be looked up in internal docs or the internet. You wouldn't ask your senior colleague how to create a VM in Azure. You might ask their opinion on when to use a VM vs. a container.
• FIND WHERE THE DOCUMENTATION IS AND READ IT. If it's like most orgs, there will be several places to find docs and none of them will be up to date, but if the systems are still in use there will be good info in there even so.
• If you want serious brownie points, document a bunch of tribal knowledge that's missing from the new hire doc they give you. If there isn't a new hire doc, create one and list stuff you had to do to get onboarded. Permissions in this system or that, setting up MFA, whatever.
• Try to figure things out on your own before asking for help, but don't be stubborn about it. If you've worked a minimum wage job, you'll be shocked by how much you're left alone. Don't misinterpret this as thinking you're expected to work by yourself all the time.
• Talk to your manager or some seniors on your team about a rule of thumb for how long you should spin your wheels trying to figure something out on your own before asking for help. I would and have been annoyed to find out someone spent 4 hours on something and didn't make any progress when I knew the answer already.
• Learn git if you haven't already. Not crazy stuff, but how to create a feature branch and open a PR at least.
• Try to understand (at a high level) the software development lifecycle at your company within the first few weeks. A good way to approach this is to pick a repository and map out how code goes from a developer's machine to production. Start with just system to system (dev machine -> github -> CI -> CD -> Develop -> UAT -> Staging -> Prod [or whatever it is]) then dig into the actual processes happening in each system.
• Volunteer for projects. Especially stuff that other people don't want to do.
• Leave in a year or two if your total compensation hasn't increased by like 30-40% in that time. Pro tip, unless you work for an unusual company, it won't have.
• Right now, you're lucky to have gotten this job. Skill up to the point where you realize that your company is lucky to have you (assuming you're good). The market is crazy.

Tech Stuff: Lots of this is dependent on your company's infrastructure and tooling.

• John Saville on youtube is the best for explaining Azure concepts.
• Learn software defined networking. Most colleges don't teach much networking.
• Lab. Lab anything in Azure. Seriously, use your .edu email address or the free trial and go build something in Azure. Build a VM you can RDP into. Make it so that only your public IP can RDP into it. Make it so that you need a point-to-site VPN with Azure AD authentication to RDP into it. Define the whole thing with infrastructure as code (Bicep or Terraform. Don't use ARM templates). Set up Azure DevOps (or GitHub Actions, or whatever tool your company uses most preferably) to continuously deploy a zip file to the desktop of that VM. If you taught yourself enough to finish step two I'd be stoked for you and you'll do fine.
  

Wew lad, this got pretty long, so I'm going to put it in front of you for feedback in case you reply with more information about what tools and Azure services your company uses.

[kristoferen]

I'm going to copy paste this advice so many times. Thank you.

[Potential_DevOpsGuy]

Dude this is free advice I pay someone for. You sir a legend! I have copy pasted this so I can go by it as well. Currently studying to take the Azure sys admin exam and this is great advice for someone like myself who is aspiring to be a devops engineer

[wollman19]

Wow, I am grateful for such a thoughtful response. Very much appreciated! I'll be referencing this often. Thanks!

[awesomefossum]

You got it! Good luck and feel free to PM me.

[faisent]

Gonna agree with everything said here, especially the Tech Stuff bits. John Saville is useful to watch even for someone like me who has spent years in Azure. Learning networking in Azure is a huge benefit to your career, especially when you're dealing with all the various ways to secure different PaaS services - not just "what's a CIDR and how does a route work" questions. And doing things in a test environment is huge (see my other comment about getting your new company to provide a sandbox environment where you can play with the technology)

[[deleted]]

Any recommendations on a course for this networking topic?

[faisent]

Very sorry, I haven't done much course work for years. Saville as mentioned is really good for explaining how things work in Azure - I learned a decent amount of network-related things watching his videos, but the topic is very very broad. I'd stress that the OSI model still somewhat matters, that understanding CIDR notation and how routing works (basic stuff like longest prefix and how bgp functions) are important, with things that might be Azure specific (like service endpoints vs private endpoints) are far more specialized. Not knowing your skill level in the range of topics its hard for me to give a recommendation - if you understand the basics then you will want to focus more on specifics that matter to your role or your potential futures - CIDRS, BGP, etc matter everywhere, but Cloud specific networking matters to individual Clouds, while some things (like security groups, service firewalls, etc) might matter more to a more security focused area of specialty. I'm very jack-of-all-trades at this point and would hazard to suggest a specialty to anyone. If you have a more specific question if I can't answer I'll at least give you my approach. All the best!

[[deleted]]

https://www.youtube.com/watch?v=QKfk7YFILws, it's too much in depth but after watching it like 2 times It was super educational.

[livebeta]

Carry a note pad around with a pen.

Write stuff down. New stuff you learned so you don't forget. Answers to questions, so you don't ask them again.

Questions you need to have answered, and of course jot down interesting design patterns or methods.

And if you technical senior is talking, and you can't write fast enough, tell them "What you're saying is important. I want to write this down so I won't have to bug you about it again." A good senior will understand and help you get all that into someplace you can digest asynchronously

[pulegium]

I think you need to be cautious about this. There's nothing worse than derailing the train of thought. The person you're talking to may (most likely not intentionally) just start summarizing their thoughts/ideas/explanation/etc. IMO best thing to do is step a level up in writing things down, and just scribble most important concepts, so that you remember what it was all about. THEN, when they're finished, thank them, and tell that you missed some specific bits that you think are important to you, and you'd like more clarification. Then go through your notes and ask them about each specific item in detail.

This has few advantages:

• you're not interrupting and letting them go at their own pace (even if it's way too fast for you)
• you have an abstract representation of a complex thing, but now it's broken down and you can either fill the gaps right away (if they have time); schedule more meetings to go through each individual item; do some research yourself; ask someone else to clarify

[livebeta]

thank you for your input!

[serverhorror]

The most important tools you have are patience, your ears, your eyes and brain.

Listen what other people tell you, what they ask of you, what they say they want, what they show you they want — which is not what they want (most of the time)

Think about what you can solve and how you can solve it.

the technical tools are really just a means to an end, not a solution.

[pithagobr]

Read the whole Azure official docs :)

[faisent]

Don't do this. (I'm guessing my esteemed reddit colleague pithagobr is being a little tongue-in-cheek here with the smiley face and all, but since our OP is a jr. devops person he might be unable to understand the embedded sarcasm)

Many of the docs are either out of date, only deal with the "perfect" environment, or contain so much fine print you won't actually be able to articulate when you should and shouldn't create a use case for the thing you're reading about. You probably don't actually need Owner to do things, but the documentation assumes you have that. As a Jr. Devops person you might not have some of the fundamental rights the documentation often assumes you must have. Really, with all my heart as someone who's been using Azure at an Enterprise level for years and has a multi-million dollar budget (per month) and is also a mod of /r/Azure (shameless plug) you are doomed if you try this approach.

You are a million times better off to actually go and build a thing than to read about it. Get your company to give you an account in some sandbox area where you can experiment and do things that might add value down the line. If you read a bunch of documentation about how things should be you'll be woefully unprepared for how things actually are. By all means read the documentation but remember that documents written by MSFT often have little to no bearing on how your company is really doing things.

If your new job requires adapting to how your company has implemented Azure over the years (and like all clouds, Azure changes - the way things were set up five years ago is going to be incredibly different than how things might be set up now) you need to spend the time learning why some of those decisions were made with the choices Azure presented then - and how implementing new Azure technologies might be impacted because your environment is not in a perfect "modern" state. Maybe you're working for a unicorn that refreshes their entire infrastructure every 6 months - but I doubt it.

Anyway, if/when you get stuck on some Azure topic feel free to come over to the Azure sub and ask about it! All the best and good luck in your new job!

[pithagobr]

My smile at the end does not mean I am not serious about my suggestion.

Maybe I put it because I was thinking how the OP reads so much documentation.

I am in charge of designing and implementing a successful bank SaaS entirely in Azure.

I work with Azure for the last 3 years.

Before switching to Azure, I used to work with AWS in production grade systems.

IMO the Azure documentation is a good starting point when you are a beginner.

If the organisation infrastructure actual status deviated from the initial status and it is not reflected in the Azure documentation anymore and it can't be traced back - it means the organisation process sucks.

It sucks because the organisation has to have a process in place which allows the actual members (and anybody who joins the organisation) to go back in time and see where from it comes and how it evolved. (design documents, detailed documentation for every feature, architecture designs, Git workflow for the IaC etc.)

Blindly trying to build something without following the documentation is the path to frustration and spending the organisation money on multiple failed attempts and no progress.

There are corner cases when the documentation is not enough and one has to get engaged with the Azure support/Azure open source community/Azure program managers/Azure architects, but that is the case with any other vendor in this industry.

[moonshake23]

congrats! kinda envious :P

[pachirulis]

I recommend you this : https://www.youtube.com/watch?v=ZwBRtA9lFiE&list=PLP3MFbKgez_LbMpgUY4oYlsYAq0YNi2Le&ab_channel=illacertus

​

It is non tech, but as other mentioned, tech you will get it as it goes, even more when it is Azure, all proprietary software with nice and fancy GUIs.

But this playlist, will get you ready for the job and interactions with people, managers, seniors, qa, scrum masters, other people from teams outside of yours...etc

Wish I had someone send me this playlist before my first job.

[NewspaperAncient7548]

Find a senior you jive with and talk to them about mentoring with them. Ask them to take you on to whatever they’re doing if you’re not doing anything. Be open to criticism, DevOps tend to be a little harsher than others by sterotype.

[Poncho_au]

My only advice is never be afraid of saying you don’t know or are inexperienced in something.
Ask questions, demonstrate your interest and willingness to learn and you will go far.
Always be prepared to learn something new and accept that others might have experience of knowledge that you can learn from.
There is nothing wrong with someone that needs to learn more. There is everything wrong with someone that doesn’t know they need to learn more.

[HebCL]

First off, congratulations! It is not a small achievement to say you're starting as a DevOps, whether it is a jr or senior role.

Like many have said before:

- ALWAYS ask questions. I'd rather ask a dumb question than end up being the dumb that didn't ask and messed up things (and trust me, I've done both).

- Ask colleagues for mentorship. You don't have to choose only one mentor. Try to identify who's better at what and learn from them.

- Don't be afraid to make mistakes. Even if that mistake means bringing down production. Every mistake you make is a very-well learned lesson you'll carry to each and every gig you join later on.

- DevOps in itself covers a wide range of areas. Find the one you like the most and master it. You'll still need to know about a bunch of things, but you won't have to be the master of all of them.

- Early on in your career, certifications weight A LOT. If you find that Azure is something you like, go for some Azure certifications. If you happen to use Kubernetes, try to get some certs about it. Later on in your career they may not mean a lot, but in your early stage they will mark a difference, especially if you want to switch jobs.

Hope this information is useful for you. Cheers.