I Wasted 2 Years Learning DevOps Wrong. Here's What I'd Do Instead.

[00:02] be uncomfortable to hear. Most people learning DevOps and Cloud are making the same eight mistakes. And these mistakes are costing them years of time and even

[00:15] thousands of dollars. And honestly, I have made many of these mistakes myself when I was starting out. And then I've seen it happen throughout my career with colleagues, with engineers I've mentored, and yes, with our boot camp

[00:30] students before they joined our program. The pattern is always the same. But the good news is every single one of these mistakes is completely avoidable if you know what to look for. So, in this video, I'm going to walk you through the

[00:46] eight biggest mistakes that people make when learning DevOps and Cloud. So, let's dive in. Mistake number one, focusing on tools instead of concepts. Here's the first mistake and it's probably the most common one I see.

[00:59] People obsess over tools. Docker, Kubernetes, Terraform, Jenkins, GitHub Actions, Argo CD, Flux. Every month there is a new tool. Every week someone is hyping the next shiny thing. And people panic. Should I learn this new

[01:15] tool? Am I falling behind? Everyone is talking about this specific tool on LinkedIn. So, should I learn it? Should I jump on it? And I was the same. But this is what I learned over time. Tools come and go. Concepts, however, stay

[01:30] forever. Take CI/CD tools as an example. Jenkins, GitLab CI, GitHub Actions, Circle CI, Azure DevOps, Argo CD, and there are so many more options now. If you only learned one tool, memorizing the specific syntax, the specific

[01:45] configuration, became really good at it, you would panic when you join a company and find out they use a different one. But if you understood the concepts of CI/CD, what a pipeline is, what stages and jobs are, how artifacts flow through

[02:00] the pipeline, how to handle secrets, how to integrate with Docker registries, AWS to integrate with Docker registries, AWS and Kubernetes, and mostly why all those concepts are important and what do they help you solve. If you have the

[02:14] knowledge of concepts, you can pick up any CI/CD tool in just a few days. Same with infrastructure as code. If you only memorize Terraform syntax, what happens when you join a company using Pulumi or when they're using CloudFormation? But

[02:28] if you understand the concepts of declarative infrastructure, state management, you can work with any infrastructure as code tool. I hear this one constantly. I learned AWS, but my new job uses Azure. Do I need to start

[02:41] over? Well, the answer is no. Cloud concepts are the same. Compute is compute, storage is storage, network is networking on any cloud provider. It's places and they are called different names, but the underlying concepts

[02:55] are identical. So here is what I finally understood. Stop chasing tools and start understanding concepts. Learn what a CI/CD pipeline actually is before you

[03:07] worry about Jenkins or GitLab CI or GitHub Actions. Learn the concept of infrastructure as code before you stress about whether to learn Terraform or Pulumi because once you understand the concepts, you can switch tools easily

[03:21] when needed and you are not intimidated by new tools appearing. Plus, you can have intelligent conversations about architecture because you're not tied to picture. And finally, you can make decisions about which tool fits which

[03:37] And here's the biggest part. Understanding concepts makes learning the tools much faster. Mistake number two, learning DevOps tools in isolation. Now, even if you do focus on concepts, there is another related mistake that

[03:52] people make. They learn Docker, then they learn Kubernetes, then they learn infrastructure as code, then they learn CI/CD. Maybe even understand concepts behind each tool, but they never learn how these tools or concepts work

[04:07] together. And I say this all the time. Someone will message me saying, "I know Docker and Kubernetes and Jenkins, but I'm not getting job offers. What am I doing wrong?" And when I dig deeper, I usually find out they can run Docker

[04:22] commands, they can deploy to Kubernetes, but they have no idea how to build an actual end-to-end pipeline that takes code from Git repository, builds a Docker image, pushes it to registry, deploys it to Kubernetes.

[04:36] They know the individual pieces, but they cannot connect them properly. Why they don't get job offers? Because knowing tools in isolation does not make you valuable to companies. Companies don't need someone who knows Jenkins.

[04:49] They need someone who can build an end-to-end CI/CD pipeline that integrates with Docker, deploys to Kubernetes, uses Terraform for infrastructure, includes proper monitoring. So, they need someone who

[05:01] can connect the dots. And honestly, I made this mistake early in my career as well. I learned each tool separately. I thought, "Okay, I know Jenkins now, so that's a check. I know Docker now, check. Let me learn Kubernetes

[05:15] so that I can check that one off." But when I got to my first DevOps project, I realized that knowing them separately meant nothing. I had to learn how they fit together under pressure on the job, which was stressful and inefficient.

[05:29] Think of it like this. Learning tools in isolation is like having all the ingredients for a cake, but not knowing the recipe. You have flour, eggs, sugar, but you can't bake. So, here's my advice on how to avoid this mistake. Every time

[05:44] you learn a new concept and tool, immediately integrate it with what you already know. Don't just learn Docker, build a Dockerized application and deploy it with CCD pipeline. Don't just learn Terraform, use it to provision

[05:58] infrastructure, a real proper infrastructure on AWS. Then deploy your infrastructure. Don't just learn monitoring, integrate Prometheus and Grafana into your existing projects based on real use case. And this is how

[06:16] I eventually learned to think like a DevOps engineer, not by mastering individual tools, but by understanding how they work together so that I could solve actual use cases and real problems, because that's what companies

[06:31] actually need. Now, back to the next mistake, which is not doing projects or starting too late. So, this one is related to the second one, but it's even worse. People consume content. They watch tutorials. They read books, blog

[06:47] articles. They take courses, but they never actually build anything. And never actually build anything. And again, I was guilty of this one as well. When I was starting out, I made this exact mistake. I spent literally months

[07:02] watching tutorials, taking notes. I told myself, I need to learn bit more before I start building. I'm not ready yet. And I waited way too long to actually start building projects. And you know what happened? After months of this, when I

[07:17] finally started building, I realized how much I didn't actually understand. All this theory I consumed, it didn't stick because I never applied it. Because theory without practice is almost

[07:30] useless. You can watch 100 hours of Kubernetes tutorials, but if you never actually set up a cluster, configure services, deploy applications, and troubleshoot the issues, you will never really understand Kubernetes. Like

[07:44] during interviews, the hiring managers can immediately tell if you've just watched videos or you've actually done something. And I've been on both sides of the table as an interviewer myself. When I hire DevOps engineers, I can spot

[07:59] someone who only has theoretical knowledge within the first 5 minutes because they can't answer questions like, "How would you troubleshoot this?" or "Why would you choose this approach over that one?" And this is what I

[08:12] learned the hard way. You should start building projects early, not after you finish learning everything and feel ready and confident. So, do not wait until you know enough because you will never feel like you know enough to get

[08:26] started building things because building things is how you get confidence and how you build the knowledge. So, when I finally figured this out, I had this one finally figured this out, I had this one personal project that I kept building on

[08:39] learned, I integrated it into that same project instead of starting from scratch. And that's exactly how I really understood how everything worked together. And that's actually why I built the entire

[08:55] popular DevOps training program ever, around end-to-end projects because I want students to get this great overview of how everything fits together and avoid all these knowledge gaps. I didn't want anyone else to waste months like I

[09:12] did learning theory without applying it because the fastest way to learn is by doing, not by watching, not by reading, but actually building. And when you start building real projects, one of the first practical challenges that you'll

[09:28] run into is how do I securely access and connect to my infrastructure? I have been there and this This exactly what Tailscale, the sponsor of this video, solves. Tailscale is a modern zero trust connectivity platform that uses secure

[09:44] peer-to-peer connections and identity-based access to make it very identity-based access to make it very easy to connect from and to any device or service anywhere. So, your CI/CD pipeline can securely reach private

[09:58] services like databases without complex networking or managing secrets. So, you don't need self-hosted runners just for access. Your team can SSH into servers without managing keys, and your Kubernetes clusters can connect across

[10:14] environments. No open ports, no firewall rules. So, make sure to check out rules. So, make sure to check out Tailscale. The personal plan with up to 100 devices is always free, and if you want to bring Tailscale to work, you can

[10:28] want to bring Tailscale to work, you can use code Nana for three free month on any paid plan. All the links and information is going to be in the video description. So, check it out below. Mistake number four is chasing only

[10:42] certifications. Now, this one will surely resonate with many of you. So, let me tell you about the certification trap. Israel, one of our DevOps graduates, had made this exact mistake.

[10:55] After finishing Udemy courses and not getting interviews, he thought, "Maybe I need a certification." So, he went for certified Kubernetes administrator, so CKA certification. He studied, he passed the exam on his first try, and then he

[11:09] started applying for jobs again. Still nothing. With no results. Well, he got some interviews, but he wasn't getting past the interviews. And this is when he realized something important. I want you to hear this directly from him. The

[11:22] first thing I would tell anybody is do not chase after certifications at the certification most times just keep people in the loop, like watching tutorials. Most of the certification we see out there are just like multiple

[11:36] need to click. Even the solution architect by AWS is just like multiple B. I would like to advise them to go hands-on, understanding what you are because at the end of the day certification is not going to It's not

[11:51] going to get through past the door, right? It can be attractive as it is certification is more or less useless if you don't have the skills. So, he hit happening in the market right now. Companies are caring less and less about

[12:06] what certifications you have collected and more about whether you've actually built something that works. Now, not all certifications are equal. Some actually require you to solve actual problems under time pressure, but most of them

[12:20] they're multiple choice tests that you can literally just memorize and companies know this. They have seen too many certified engineers who cannot interviewed people with impressive certifications who get stuck when

[12:35] they're asked to explain how they would troubleshoot a real problem or how they would build an infrastructure. So, certifications are becoming a baseline, not a differentiator. Now, before you misunderstand me, certifications are not

[12:50] completely useless, okay? Anna, another graduate from our program, became a golden Cubstronaut. And that's incredibly impressive. She was actually the first person in Switzerland and the first woman in Spain to achieve this.

[13:04] And certifications are great for things like validating your knowledge, getting like validating your knowledge, getting past HR filters, or showing commitment to learning, but they're terrible as your only strategy. So, instead, this is

[13:19] the strategy that actually works. Build projects first, get hands-on experience, and then get certified to validate what you already know how to do. So Israel eventually got the

[13:32] certification. But that's not what got him hired. What got him hired was his ability to have a technical conversation about how systems work together. His ability to explain concepts and answer questions to the hands-on projects that

[13:47] questions to the hands-on projects that he added to the CV. So his understanding of why you do things a certain way was the major factor. Again, I want you to hear this from him himself. So I asked him a question during our performance

[14:00] review one day I asked him that, "Why did you decide to hire me? Like what from other candidates?" I believe that they are This is the United Kingdom. We have different people who are very good. What he told me was that people who

[14:14] even qualified. They don't even know what they are doing. You can see people who doesn't know anything about DevOps just throwing in their CV. The only way experience is to actually have a one-on-one conversation with them. And

[14:26] when he did, most of them don't even know anything. That I was the only person who was able to not just explain the tools but also explain it conceptually from how they work, the missing pieces, and everything together.

[14:39] My knowledge on how to optimize pipeline, you know, how to set up a Kubernetes cluster, and all of that what actually stood me like what actually Other people just say they use Jenkins to do that but I was able to explain how

[14:53] to optimize Jenkins flow, how to run jobs in parallel, how to have like mono boot camp, how to have different microservices having different pipelines me. I said, "Wow." You can actually watch the full interview I had with him

[15:08] here if you want to hear his full journey. So basically don't chase certifications thinking they are the golden ticket because they're only one piece of the puzzle, not the entire puzzle. Mistake number five, being cheap

[15:24] with your education. When I moved from Georgia to Austria in my early 20s, I was just starting out. I had no money and I certainly did not see my time as a precious thing. I was learning programming from YouTube videos trying

[15:39] to save as much money as possible and I thought I was being smart by not spending money on any courses, not even the cheap ones. Now, 12 years later, whenever I want to learn a new skill, I always take a shortcut by learning from

[15:55] an expert so that I can shorten my learning curve and get faster to my learning curve and get faster to my goal. Why? Because I finally learned goal. Why? Because I finally learned that you're either paying with time or

[16:07] paying with money. But eventually, you are paying a price in any way. And it doesn't even have to relate to IT. I personally use this principle for every aspect of my life. For example, last year, I started learning guitar. I could

[16:19] have watched free YouTube tutorials, but instead, I have a guitar teacher coming to my apartment every week because I know from experience that structured guidance gets me to my goal 10 times faster, saves me frustrations, saves me

[16:33] time and makes the process more enjoyable. So, let me be clear up front. It's absolutely possible to learn DevOps for free. And as you know, at Tech With Nana, we create tons of free tutorials with extremely high quality. So, we put

[16:49] a lot of resources in that and they have helped thousands or sometimes hundreds of thousands of engineers to level up. So, I'm not saying it's impossible, but you need to be aware that it will take you longer, like much longer. Again,

[17:04] speaking from my own experience because here's what happens when you rely only here's what happens when you rely only on free scattered content. You spend 10 months watching scattered tutorials, you get even more confused because different

[17:18] sources teach things differently. You have huge knowledge gaps because free content is never comprehensive and all-encompassing because they just don't go deep enough and you're always missing something. So, you get overwhelmed and

[17:33] sometimes discouraged and you just give up because you're not getting anywhere. Then, you spend another 6 month trying to piece everything together. You're still confused about how things connect, but this is the worst part. When you get

[17:46] but this is the worst part. When you get stuck, you have no one to ask and if that could be the most discouraging one. Now, think about it. You're working through a Terraform demo. You hit an error. You spend 4 hours debugging. You

[17:58] still can't figure it out. You give up and move on, never actually understanding what went wrong. In a structured program, you have experienced DevOps engineers that support you. When you get stuck, you get unstuck quickly,

[18:11] but importantly, you also learn why something went wrong. You don't waste days being blocked on a simple configuration issue and that's important when you want to move fast, but also keep the motivation for going. Now, I'm

[18:23] not saying don't troubleshoot yourself and try to figure things out on your own. That's how you actually learn the most and it's an important skill in itself, but at some point, it's better to get help to be able to continue and

[18:36] move on. But, it's not just about having someone to ask when you're stuck. It's also about having fellow learners around you who get it, who are on the same journey as you because learning alone is extremely isolating and I know this

[18:50] because I did this journey for a whole year learning Kubernetes alone. If I had a community back then, people going through the same struggles or people a few steps ahead of me who could help or experienced engineers that I could ask

[19:05] questions to, I would have saved myself so much time and frustration. Now, let's talk about opportunity cost because it's real and most of us totally ignore it. A

[19:17] software engineer who knows DevOps is more valuable than the one who doesn't. A test engineer who can not only write automated tests, but build infrastructure to run those tests and maintain those systems gets paid more. A

[19:33] sysadmin or a network engineer who understands cloud and infrastructure as code does not get laid off when companies modernize or even shrink their resources. DevOps and cloud is a premium

[19:47] skill that increases your value automatically regardless of your engineering role. And that means, and we're getting to the calculation here, if you waste 1 year learning inefficiently, basically with no

[20:00] inefficiently, basically with no results, you just lost 25 to 35,000 in potential income you could have been earning if you had a acquired those skills sooner, which is logical, right? But there is another cost that people

[20:14] don't think about. The cost of not being confident at your job for another year confident at your job for another year and building a fear that sometime in the future you may be replaced by AI or another engineer who learned DevOps and

[20:30] added other skills to their knowledge. And I think this one is even more important than the financial cost. Because what happens is that, let's say you finally land a DevOps job or engineering job with DevOps focus, but

[20:43] you have knowledge gaps. You're not confident. You can't contribute at the level that you should. You're learning on the job things that you should have learned before. And guess what? I know about this because around 30% of our

[20:57] boot camp students are already working DevOps and cloud engineers. They are actual practitioners, but they feel something is missing and they hate it. They're employed, but they're not confident. So, they want to learn to

[21:12] fill those knowledge gaps because they can't contribute the way they want to. So, yes, you can learn for free, but count the real cost of that. The higher income you are losing out and the delayed confidence once you get the job.

[21:27] So, here's my point. Invest in quality education if you can. If you're already employed, use your stable income to speed up your skill development. It is an unfair advantage over others who are being cheap and won't invest in

[21:42] themselves. And looking back, I have never once regretted investing money in my education and in my skill set. And again, I was cheap myself. So, I have made this mistake more times than I can count. And the thing is, I'm not saying

[21:59] you need to spend $50,000 on a university degree, but if you're serious about changing your career or leveling up and you can afford it, then structured programs are the best way to

[22:13] reach your goals 10 times faster. I personally always invest in myself and my skills because I've learned that in the long run, it always gives me the highest ROI. Mistake number six, learning only in sandbox environments.

[22:28] Now, this mistake deserves its own section because it's one of the most damaging ones that I see. A lot of people love sandboxes. I did as well. When I was learning programming, I was using platforms like Codecademy with

[22:43] preconfigured environments. Everything is set up for you. Click here, copy this is set up for you. Click here, copy this command, paste it here, boom, it works. Green check mark, confetti, dopamine hit, next lesson. Repeat the same cycle.

[22:56] And I completed entire courses this way. HTML, CSS, frameworks on JavaScript, module after module. I thought I was becoming a developer. But guess what happened when I secured my first job as a software engineer. I had no idea about

[23:11] Git. I barely used the terminal. I didn't know how to install tools with package manager or set up development environment. When someone said clone the repository, I froze. When I needed to debug an error, I didn't really know how

[23:25] to do it. And here's the thing, knowing all this stuff around coding was just expected. Nobody was going to teach me Git or terminal basics. They assumed that I already knew it as a junior engineer. Because in the real world,

[23:40] these aren't extra skills. They're fundamental skills. You should know how to use Git as a developer. Long story short, I felt completely unprepared, like an impostor. It felt like I had learned to swim in a kiddie pool and

[23:56] suddenly got thrown into the ocean. And honestly, this experience was so painful for me that it's exactly why I created our IT Fundamentals course to help others avoid the same pain. Covering all those critical things that I was missing

[24:13] for the first two years while working as a junior developer. Because they somehow get skipped during learning or training. Because people assume you just learn them at work, which you usually don't for a long time. Because the truth is,

[24:29] in those sandbox environments, you're literally just copy-pasting commands that someone else wrote into an environment that someone else configured. And it feels great during learning. You have no errors, no

[24:41] troubleshooting, no headaches. You're moving fast without any issues. But the would you rather experience troubleshooting for the first time during your learning or during your first week on the job? Because think

[24:56] about it, and with DevOps, this problem is more critical. DevOps is all about connecting cloud platforms, orchestrating containers, automating

[25:08] deployments, configuring security, managing real systems, and dealing with real problems. So, sandbox learning is like being baby-sat through DevOps. really goes wrong, nothing breaks, so you're just following instructions

[25:24] almost blindly and intuitively. It's like going to kindergarten when you naturally, it won't give you the confidence that you need to tackle issues in real projects. Because when something breaks at work, and it will

[25:39] break, there is no pre-written command to copy-paste. There's no sandbox tutorial to follow. It's just you and error message and the problem you need error message and the problem you need to solve. So, real learning means facing

[25:52] to solve. So, real learning means facing the exact challenges that you at work. And real DevOps is not about what works, it's about fixing things that don't. And this is exactly how I learned on the job. My first week as a DevOps engineer,

[26:07] I broke things. I had to fix them. I had to read error logs. I had to troubleshoot. And that's what made me competent. So, you need that experience while learning. And yes, you might spend a few dollars on cloud resources while

[26:22] a few dollars on cloud resources while learning, but that investment pays for itself because when you get to your job, you're not panicking and asking for help because you've already faced this challenging during learning, but without

[26:35] pressure. Or think about the job interview itself. When they ask you, You won't have to lie because you actually did it on real infrastructure actually did it on real infrastructure with real challenges and not in sandbox

[26:48] controlled environment. Again, ask yourself, do you want to learn in a safe sandbox where everything always magically works, or do you want to learn on real infrastructure where you'll face the same challenges you will face in

[27:02] your actual job? Because if I could go back, I would always choose the second option. Yes, it's harder, but it would have prepared me for the reality.

[27:18] looked at a DevOps roadmap online? You know those big diagrams with boxes for every tool and technology? They're overwhelming, right? Now, here's the problem with most roadmaps. They tell you what tool to learn, but they don't

[27:32] tool, why you need to learn it, when to use why you need to learn it, when to use it, how it connects to other tools, and where to actually learn all of this. So, you look at the roadmap and you see

[27:45] Docker, Kubernetes, Terraform, Jenkins, Prometheus, Grafana, Bash, Python, Git, thousand other technologies, and you think, I need to master all of this and be expert and proficient in all of these tools? The answer is no, you don't. You

[28:02] need to understand maybe 20% of each tool that covers 80% of real-world use cases. And most importantly, the connections between them, which you

[28:14] don't see on the roadmaps. But, how do you know which 20% that is? Roadmap also doesn't tell you that. The roadmap says, learn Kubernetes, but a good program says, learn Kubernetes core concepts, pods, services, deployments.

[28:30] Understand how networking works. Learn how to deploy applications. Then, integrate it with your CI/CD pipeline. Then, add monitoring. And here is a real project where you will use all of these together. Let's go through it

[28:44] step-by-step together. I'll explain everything while we go. That's how it should work. See the difference? One gives you a list, the other gives you a complete journey with clear milestones and destination. And look, we create

[29:00] roadmaps as well. You can find them and download from our website. I have roadmap videos on YouTube. So, there's definitely some usefulness to them. Like they give you a very rough overview, so you know where to even start and how the

[29:15] journey will look like in case you decide to follow it, but it's all on a very high level. So, this is what you need to understand. Don't expect roadmap to teach you DevOps. Don't expect it to tell you how deep to go or how to

[29:31] tell you how deep to go or how to actually apply each tool on the roadmap.

[29:43] opportunities. And most engineers don't even realize they're making it. So, as you can imagine, I experienced the impact of building in public first hand. When I started recording Kubernetes tutorials to document my learnings,

[29:58] despite not looking for anything and without any expectation, I started to receive consulting requests with very high hourly rates daily because my knowledge and experience was made visible. But you know what? I would

[30:12] visible. But you know what? I would rather tell you the story of one of our graduates because I think it relates more with you and it also makes the point that you don't need to become a full-time educator like I am. It works

[30:26] with a much smaller scale as well. So, he was a sysadmin at a mid-size company and went through our DevOps program. He learned Docker, Kubernetes, CI/CD, the whole stack. Then he went back to work and applied everything. Automated their

[30:42] backup processes, reduced deployment time by 70%, saved them thousands in cloud costs, so became really valuable for the team and the company. His team loved it, his team leader was happy, but nobody above them knew about it. Not the

[30:59] engineering director, not the VP, not the recruiters who could have offered him better opportunities. So, he was doing excellent work in private. So, I advised him to start posting on LinkedIn. Nothing fancy, just updates on

[31:15] what he was actually implementing at work. A simple diagram of his CI/CD setup, a decision-making process, a post about Docker networking issue that he just solved. Within 2 weeks, his VP commented

[31:29] on his post, a recruiter from a Fortune 500 reached out to him, and other boot-camp graduates of ours at a different company asked if he was open to opportunities. So, same skills, same work, different visibility. And I know

[31:45] work, different visibility. And I know most engineers hate self-promotion. It feels fake, it feels forced, like you're showing off. And I get it, I felt the same way, but this is how you can think about it. You're not bragging, you are

[31:59] teaching. Like, share the Terraform module that you debugged for 3 hours, or post the monitoring setup that caught a production issue. Write about the CI/CD mistake that cost you 2 days, because someone else is struggling with the

[32:14] exact same problem right now, and your basic knowledge is gold for someone earlier in their journey. And while you're helping others, you're also building proof of your skills, creating content that recruiters can actually

[32:29] see, differentiating yourself from 100 other DevOps engineers or certified Kubernetes admins, and especially if you are a junior engineer. The job market can be tough. So, if you're not marketing yourself while you're

[32:45] employed, you are kind of setting up yourself to panic apply when the layoffs start. So, I always strongly advise to start building and learning in public.

[32:57] start building and learning in public. Now, not when you're desperate. mistakes in detail. So, the question is how to avoid all of this. Here's a

[33:12] framework that actually works. First, choose a structured program. If it's a really good one, it will solve almost all these problems for you. Not scattered YouTube tutorials, including ours, not random Udemy courses, but a

[33:28] comprehensive program that teaches you tools and concepts and how they fit together. With a good program, you should be building end-to-end DevOps processes. And by the end, you should have a portfolio

[33:42] projects that you can showcase. This should be real projects that demonstrate that you can architect and also implement complete systems, not just use individual tools and their syntax. And the good program will have you learning

[33:57] on real infrastructure, not sandboxes. Yes, it's going to be harder, but that's the point. Now, look. Yes, our DevOps bootcamp is built exactly this way. Otherwise, I won't have the experience to tell you about all these mistakes

[34:11] because I've literally seen how we've solved these issues for our students. But, that's not the point here. The point is find a program that fits your specific needs and your situation and use it to fast-track your career.

[34:27] Second, get certified strategically, which means build hands-on skills first, then get certified to validate what you already know, not the other way around. Third, and this one makes huge difference, share your learning journey.

[34:42] Post your projects, write about problems you solved, help others who are one step behind you. As you saw, I made many of these mistakes myself when I was starting out. So did Israel and Anna and hundreds of our students.

[34:56] But we all corrected course and that made all the difference. And that's why I wanted to share this with you so that you can avoid wasting months, sometimes years, going in circles because companies are really desperate for

[35:11] qualified engineers right now. And by avoiding these eight mistakes, you're already ahead of most people trying to break into this field. Now, if you found this advice valuable, then please share it with someone who's also learning

[35:24] well. And as always, thanks for watching and I'll see you in my next video.