Shadowing Practice: How to ACTUALLY Get a DevOps Job in 2026 - Learn English Speaking with Video

What would it take for a complete beginner, someone with no IT job,

no production experience, and no idea where to start to become somebody that a company trusts with production deployments and infrastructure?

Is that actually realistic in 2026?

I think it is.

I think you can absolutely get there, but you need to understand what the path looks like and what you're building towards.

You need to understand Linux.

You need to understand the software development life cycle.

You need to understand scripting and you need to understand web hosting very well.

You can learn AWS, Terraform, Docker, Kubernetes in isolation, and that's fine.

It's useful, but putting those tools together and getting that real experience is what's going to take you to the next level.

It'll make you ready for the job.

And I'm going to be honest, going straight from beginner to a DevOps job is something that's not super realistic, unless you find some junior DevOps position where they're willing to train you in,

which is exceedingly rare nowadays.

But I don't want this to get you discouraged.

This does not mean that DevOps is out of reach.

It means you're going to build your way there.

By the end of this video, you'll know which first job to pursue, what to learn, what to build, and then when you should actually start applying for DevOps jobs.

So where should you start?

In my opinion, you should still start in help desk, tier one support, IT, maybe at an MSP.

You're going to have to understand how production systems work.

Then you move towards system administrator or cloud support.

Maybe you get a cloud engineer job and then eventually you become a DevOps person.

How long does this take?

Well, there's honestly no real minimum and it depends where you're at technically and with your experience.

I think increasing responsibility and exposure matters more than how long you stay in any given position.

You're probably going to be administering systems first, and then you're going to get that Linux and cloud experience.

But what if you're already a software developer?

This is an entirely alternate path.

From this side, you have to pick up the infrastructure stuff.

From the operations side, you have to learn Git, GitHub workflows and source control, pull requests, testing and staging environments, build artifacts and CICD.

And from the software side, of course, you have to learn the infrastructure stuff.

So either way, you're just learning the other half, essentially.

Now, what level of Linux do you actually need for this?

Well, Well, if an application that's running on a Linux server starts breaking, you should be able to troubleshoot using logs without going directly to a tutorial.

That means being comfortable with Linux users, processes, services, files and permissions,

packages, logs, SSH, networking, and then environment variables as well.

If you want something to move towards, I think RHCSA, the Red Hat Certified System Administrator, is a decent certificate to look towards.

I myself will probably get this at some point.

If you can't tell, I'm pretty bullish on certifications in general.

I think they really force you to get the experience needed to do these types of jobs.

So now you've started administering systems.

You've worked your way past help desk.

Now it's time for you to start understanding the software that's running on them.

You need to understand the entire software development lifecycle.

A developer starts with an issue.

They make a branch.

They commit their changes.

They open a pull request.

That code needs reviewing before it's built and deployed.

Then you need good monitoring and a way to roll back if something goes wrong.

And then you've got secrets all over the place.

API keys, tokens, database passwords, usernames, DB URL, all of this stuff.

Your app is going to need them.

So is your CI pipeline.

So are your Kubernetes clusters.

How you manage these secrets is very, very important.

I'd use a secrets manager, like in physical.

Full disclosure, that's the company that I work for.

But you could use any secrets manager.

The point is centralizing your secrets allows you to fine -grained scoped access to them.

You can rotate them from one central place.

You can sync them to all of these different places, whether that's GitHub, whether that's, you know, your CI pipeline, whether that's your Kubernetes clusters or Vercel or whatever other service you're using.

Now, this also makes CI and it makes local development so much easier as well.

The point I'm getting at is learning about secrets management has, to me at least, by proxy, taught me so much about how production infrastructure runs.

Now, on the note of production infrastructure, one thing that I personally wish I started learning earlier was Kubernetes.

I would learn Kubernetes as early as you possibly can.

I was a Windows system administrator.

I didn't do tons of Linux.

We had some Linux boxes that we were, you know, kind of managing but it's mostly just updates

and like easy scripts and stuff but i moved to the startup

and physical in the infrastructure security space

and this is like you know dev sec ops adjacent

and kubernetes was huge it was a big learning curve for

me i had to spend weeks learning kubernetes i was like

walking on the treadmill watching videos about kubernetes i was dreaming about kubernetes i was learning about kubernetes secrets

and how these apps ingest you know secrets

and where the source of truth should be

and how external secrets operator works

and how authentication from your kubernetes cluster to you know your secrets manager works And then that's just secrets management.

Of course, there's like the entire architecture of how Kubernetes works, right?

What a pod is, what a node is, how the control plan works, what the, you gotta learn the command line commands, the kubectl commands, I like calling them kubectl commands.

This is all important stuff.

And it's stuff that I wish I started learning earlier.

Because once you start to understand ingress and deployments and services

and this cluster architecture and really like how all of this high level pieces kind of fit together, I think something clicks in your mind about distributed infrastructure and distributed systems.

And when you start thinking like this, it makes you more of a systems thinker.

And this is 100 % necessary if you wanna be a DevOps professional.

Now there is a cert in the space, as I'm sure you could guess.

I do wanna get it at some point.

It's called the CKA, the Certified Kubernetes Administrator.

There's actually a few of them.

This is just kind of like the first one, the main one.

And I really think that this would be worthwhile for you to get, because in order to get the cert, you have to be able to administer, troubleshoot and debug Kubernetes things really fast and

so it just kind of forces you to be an expert

once again in this domain now alongside this you need real

kubernetes projects as well now how would i use ai in

this entire process well i would definitely be using ai i

would use it to help me script i would use it to help understand what the scripts are doing understand

that you don't have to know the exact syntax of the language

100

that you're scripting in in order for you to be a

101

devops professional nowadays like i'm gonna be honest with you nobody software engineers included or i should say very very, very few are handwriting code letter by letter anymore.

102

It's mostly reviewing the output that an AI created.

103

Now, this might not be as fun as handwriting code, but I can tell you debugging is a lot more fun

104

because you don't have to spend days at a time looking through stack traces and trying to track something down manually.

105

So you've got to understand how an API works.

106

You've got to understand error handling.

107

You've got to understand environment variables.

108

You've got to be using AI extensively if you want to be successful in tech nowadays.

109

But most importantly, it's the context.

110

You need to understand which systems can I and should I automate, whether it's with AI, whether it's with a script, whether it's with N8N or something of that sort.

111

In DevOps, you're managing millions, billions of dollars of infrastructure.

112

So it's important that you know what you're doing when you're dealing at these different levels.

113

You know, if you're doing something locally on your device and just testing something out, you can automate it with AI.

114

If it works as you go up this kind of responsibility ladder, we have to have the context about where you can safely run certain things and what the fallback plan is.

115

This is huge.

116

And this isn't just unique to DevOps.

117

This works in IT.

118

This works in software development.

119

This works for platform engineers.

120

This is for everybody, right?

121

You have to have context around what you're doing.

122

Don't be reckless, essentially, is what I'm saying.

123

Now, what project would I build that kind of brings all of this together?

124

I would build a small containerized application with a database, put it in GitHub, use pull requests

125

and the entire software development kind of process in order to actually merge things into main, set up some CI tests and GitHub Actions, build it, deploy it on Kubernetes,

126

you know, set up DNS and HTTPS and host it on real production servers.

127

Once it works, break some stuff, mess up DNS, mess up a credential, mess up some setting with the database

128

and understand deeply why you've messed this thing up

129

and how you've messed it up and how you could fix it in production.

130

Now, putting together this project requires a lot of curiosity and conscientiousness.

131

Again, you're going to be working with AI to actually set something up for you, but it's quite a lot of work to make up the entire environment and try and mimic a real world scenario and,

132

you know, use GitOps and use again, this pull request workflow and understand all of this hosting stuff.

133

And then also introduce purposeful problems.

134

Like this is a lot of work.

135

I'm not going to lie to you.

136

And does this count as production experience?

137

Of course not.

138

You don't have to lie and say that you've managed production Kubernetes clusters before you actually have, but it is experience.

139

It's useful experience.

140

And through the process of doing all of this work that is going to be painful, you're going to learn a lot of useful stuff

141

and this my friends will help you in an interview

142

and help you talk confidently about things

143

and as i'm doing this i would be writing blogs i

144

would be you know making articles i would make a website

145

somebody asked this in the youtube comments the other day

146

that was like hey how public should i be with my

147

learning nowadays being public is as easier as it's ever been

148

because you can use ai to help you be public of

149

course don't just push out slop nobody's going to like that

150

but build things and be curious as much as you possibly can

151

and learn in public it's going to help you so you're a complete beginner where do you start i would learn networking, Linux, and Git at a very basic level, and I would start building one application.

152

I would still get my beginner level certificates and try and go to, you know, tier one help desk, system administrator, something of that sort, MSP, things like this.

153

I would use AI to teach me as much as possible.

154

I have a video on Matt Pocock's slash teach.

155

It's an AI skill

156

that you can use to help AI teach you over a long period of time with some goal in mind.

157

It's super, super good.

158

Definitely go check it out.

159

Matt Pocock is the goat of AI skills.

160

Now, when should you start applying for DevOps jobs?

161

Again, I would generally say you should start learning things earlier than you think you should.

162

So as you're getting your system administrator position, you should be learning Kubernetes.

163

You should be learning all of this software side of things.

164

You should be learning how infrastructure actually works.

165

Of course, you're going to do that in your job as well.

166

Once you have a year, year and a half of troubleshooting experience under your belt with just real technical systems, it doesn't have to be distributed systems and all of this insane stuff,

167

I would start applying understanding that this application process is going to be a longer application process.

168

It's not going to happen overnight.

169

But as you have this technical job and you're learning these technical DevOps applicable things, start applying for a job.

170

And then also understand what the job is.

171

You are going to be a jack of all trades.

172

You're going to be managing infrastructure.

173

You're going to be up at 3 a .m doing on -call rotation stuff.

174

You're going to be the guy or girl who everyone expects to know everything, even though you don't.

175

And in today's day and age, working in big tech, things change every two weeks.

176

Like legitimately, the thing that you thought was super important two weeks ago might not be super important anymore.

177

And there's another thing that you have to learn that's super important.

178

This for some people is mentally draining.

179

This for me invigorates me because I'm always learning new things and it's super duper fun.

180

And I feel like I get to be at the bleeding edge of technology.

181

And so this is really cool.

182

So yeah, guys, this has been how to actually get a DevOps job from zero in 2026, 2027 seven, I imagine this is still going to carry over.

183

I wish you luck.

184

If you have any questions, you know, leave them in the comments.

185

I read every single one.

186

Thank you so much for watching and we'll talk to you in the next one.

187

Goodbye.

📺 Mismo canal

How I Escaped Help Desk Fast (Step-by-Step)

Business EnglishInterview EnglishUniversity Students

✨ Recomendar Video

63 oraciones

¿Qué es la Técnica de Shadowing?

Shadowing es una técnica de aprendizaje de idiomas respaldada por la ciencia, desarrollada originalmente para la formación de intérpretes profesionales y popularizada por el políglota Dr. Alexander Arguelles. El método es simple pero poderoso: escuchas audio en inglés nativo y lo repites en voz alta de inmediato, como una sombra que sigue al hablante con solo 1-2 segundos de retraso. A diferencia de la escucha pasiva o los ejercicios de gramática, el shadowing obliga a tu cerebro y músculos de la boca a procesar y reproducir simultáneamente patrones de habla reales. Las investigaciones muestran que mejora significativamente la precisión de la pronunciación, la entonación, el ritmo, el habla conectada, la comprensión auditiva y la fluidez al hablar, convirtiéndola en una de las metodologías más efectivas para la preparación del IELTS Speaking y la comunicación en inglés en el mundo real.

Técnica de shadowing: lee la guía completa paso a paso →

Shadowing Practice: How to ACTUALLY Get a DevOps Job in 2026 - Learn English Speaking with Video

How I Escaped Help Desk Fast (Step-by-Step)

How To Land Your First Junior Dev Role

Top 10 Linux Job Interview Questions

How I Would Start Cybersecurity in 2026 (If Starting From Zero)

Fastest way to become an AI Engineer in 2026

Operations Manager Interview Questions & Winning Answers (Complete Guide)

Google Interview Tips That Actually Get You Hired

How to Become a Sales Engineer | Without Any Experience

What It Really Takes to Become a Full-Time Day Trader at 21

I cloned 3 apps and now make $35K/month

Cracking the Behavioral Interview for Software Developers

If you’re an aspiring product designer, watch this (roadmap included)

¿Para quién es este video?

Palabras y frases para "robar"

Cómo mejorar el acento con este video

¿Qué es la Técnica de Shadowing?