Have you ever thought you are not good enough at work? You are not that smart to get that job, and it’s all just luck? That’s called the “Impostor Syndrome”! And it’s common than you think because many people don’t even dare to talk about it! 🎭

To make it directly to the point, this post will cover the following questions (mainly focusing on DevOps, but it’s still valid for software engineering, and also in general):

1. What is impostor syndrome, and what is not?

2. Why does impostor syndrome hit hard?

3. What to do about impostor syndrome?

1. What is impostor syndrome, and what is not?

Impostor syndrome is one of the most common issues in all industries, and the tech industry is no different. In case you didn’t hear this term before, it basically means (and here it’s directly quoted from Wikipedia): “The subjective experience of perceived self-doubt in one’s abilities and accomplishments compared with others, despite evidence to suggest the contrary”. It’s a psychological phenomenon, not a clinical syndrome or a disorder.

First of all, it’s essential to understand that impostor syndrome is a general concept, not specifically related to the DevOps or software engineering domain; however, it’s critical to recognize that impostor syndrome itself is not a single type.

We will not go into details about this, but here are some types of people who feel they are impostors:

• The Perfectionist: “If it’s not perfect, I failed”.

• The Expert: “If I don’t know everything, I don’t belong here”.

• The Lone Wolf: “If I ask for help, it means I’m incompetent”.

• The People Pleaser: “If I don’t keep everyone happy, they’ll think I’m not good enough”.

Finally, on the other end of the spectrum, there is “Dunning–Kruger effect”, which is “the systematic tendency of people with low ability in a specific area to give overly positive assessments of this ability”. We will not cover this here; it’s a topic for another day.

2. Why does impostor syndrome hit hard?

2.1. Growth doesn’t follow one pattern

Growth isn’t linear; it follows various patterns. You have probably heard that many times, but most people forget about it. Many people experience self-doubt because their brain becomes anxious when it cannot find a clear pattern of growth, and fills the gaps with that feeling. Growth rarely moves in a straight line; it’s actually like body types, it comes in different shapes and sizes.

This is not just about DevOps or the software industry; it’s a human thing! The irony is that impostor syndrome can hit when you try to move forward or when you do nothing new at all. Basically, because it’s not driven by action, it’s a state of mind!

In reality, steady growth is mostly not possible; human growth is not a mathematical equation and is influenced by numerous factors.

2.2. Software development is a super dynamic domain

Compared to other industries, software production is a relatively new domain; however, it’s one of the fastest-growing domains and is constantly evolving. Every couple of years, we see new technologies and standards, as well as ever-evolving methodologies.

Imagine an industry that changes at lightning speed! Let’s admit it, there is a lot of fear of missing out (FOMO) in this domain. It’s challenging to keep up with the changes all the time, which leaves a lot of room for unknowns and uncertainties.

The domain is cyclical, and every cycle brings something new, whether it’s Cloud Computing, IoT, Blockchain, or now AI. So, by default, the nature of the industry feeds the impostor syndrome.

2.3. DevOps requires special skills and knowledge

The DevOps methodology was born out of the significant shift in the software production process. The old methods couldn’t cope with that kind of change; hence, DevOps is by definition extremely dynamic. Do you remember what the DevOps symbol is? It’s an infinite loop! ♾️

Many people in software engineering are familiar with the various specializations within the industry; however, when it comes to DevOps, most people (including the DevOps specialists themselves) believe in DevOps as a single, monolithic concept and aren’t even familiar with DevOps Topologies. Therefore, many people panic when they haven’t heard about some of those topologies and environments.

For the same reason, DevOps requires a different engineering profile. A successful DevOps Engineer is both a generalist and a specialist at the same time, i.e., an engineer with T-shaped skills.

You cannot be just a generalist or just a specialist. You should be both at the same time! And, as usual in the modern age, humans tend to excel in one area more than others. And that comes with a lot of insecurities.

2.4. DevOps titles don’t represent the skills

DevOps has evolved over the years, which is a good thing. However, whether we like it or not, at a certain point, it became a hype and trend where everyone wants to have the DevOps badge!

And besides the different flavors of the DevOps role (such as DevOps Engineer, Site Reliability Engineer (SRE), Cloud Engineer, Platform Engineer, etc.), you will find people who do DevOps but don’t have the title, and you will find people who have the title but don’t do DevOps! That’s enough to have a lot of anxiety, uncertainties, and self-doubt.

To conclude this section, Software Engineering and DevOps are, inherently, a fast-moving field that requires different skills compared to many other roles in the software industry. Put all that together, and it’s no surprise that the field has plenty of insecurities.

So, how to handle this? The following section is actually for everyone, whether you are a DevOps specialist or a software engineer.

3. How to deal with impostor syndrome?

3.1. Self-awareness is the key!

We all know that there is no silver bullet; however, if there is one, it’s for sure “Self-awareness“! It will not stop impostor syndrome from kicking in, but Self-awareness will suppress it to a minimum by setting realistic expectations.

Understanding yourself will help your healthy growth. You can handle many things with confidence if you know your strengths. And you are less vulnerable if you are already aware of your weaknesses.

Also, it’s fine if you don’t know, as it’s always way more what you know, and what you don’t know, you don’t know is even more (no need to puzzle over, just look at the chart above). There will always be people better than you, and you will always be better than others. Know what you bring to the table, and you will be fine.

3.2. Your perception is not the reality!

Let’s face it, a big chunk of the impostor syndrome is coming from your mind! You “think” you know less, and you “think” others know more, and you “think” different people in the same position will be better than you! As you see, it’s a delusion in the first place.

Always try to support your thoughts with numbers and facts. And it’s challenging unless you have self-awareness (as mentioned earlier). Moreover, ensure that you have trusted and credible people to share your thoughts with, who will help you validate those thoughts and provide honest feedback to you. Remember, you shouldn’t just ask a “friend”, you need some honest feedback and, at the same time, have the knowledge about the topic.

By combining self-awareness (internal) with this support group (external), you will be able to pinpoint precisely where you stand and in which direction you need to head.

3.3. Track your achievements!

One of the most underestimated ways to deal with impostor syndrome is “tracking”! If you don’t track your wins, it’s easy to feel like an impostor. Tracking your progress and achievements helps you understand your capabilities more clearly. It also provides you with something objective to counter self-doubt.

In fact, it’s not only essential to fight impostor syndrome but also for healthy growth. The human brain tends to magnify mistakes and dismiss success (do you remember how often your brain pops up and reminds you of an embarrassing situation?).

Create a space to track your achievements, whether it’s a notebook or a board, physical or electronic. Just do it and make it visible to you, and ensure to update it continuously (some people update it every x amount of time, like quarterly, while others update it whenever they achieve something).

3.4. Sometimes it’s you, sometimes it’s not!

Ultimately, you have to take responsibility for your actions. You're probably not an impostor; you could be not good enough! Which is fine, just do something about it! If you applied the previous points, you should be able to know your capabilities and what works for you and what doesn’t. In many cases, it’s just about finding the right way that fits you to make it (and no need to fake it).

On the other hand, sometimes it’s not you, it’s the environment around you! Taking the blame for everything will not help the situation. Perhaps you should try an alternative approach or consider a different environment. For example, you shouldn’t be afraid to ask, but the environment around you doesn’t provide you with the psychological safety.

However, it’s important to remember:

• Acceptance doesn’t mean being passive or uninterested; you still need to do whatever you can to address any limitations on your end.

• Don’t swing to the opposite extreme and slip into the Dunning–Kruger effect, where you start believing you’re better than you actually are.

4. Final thought

Leaving impostor syndrome unaddressed could significantly limit your career growth. That feeling will happen from time to time, but you can minimize its effect by following the methods above.

Understanding yourself takes time and comes in phases, but it leads to self-awareness, which is essential for both personal and professional growth. Self-awareness will help you a lot, but you still need external feedback; find people who can support you. That could be your manager, mentor, or a friend in the same domain.

And if you ask anyone with years of experience in the software industry, they will tell you that the total number of true impostors they’ve met is probably fewer than they can count on one hand!

Thanks for your time, and hope you enjoy the journey! Here is a kickoff checklist:

• 📃 Read the frequently asked questions page (it has much valuable information).

• ⭐ Star the project repo on GitHub (for better visibility).

• 🌐 Join the Telegram group (for interactive communication).

Happy DevOpsing ♾️

Bottom line: Every time you do something related to DevOps, security is no longer a luxury!

The advanced DevSecOps section has been added to the roadmap website 🙌

As mentioned previously, the roadmap is for all career levels, not just beginners. Thus, after the foundations, we are gradually adding more advanced content.

Like all advanced topics in the roadmap, they're much better when written by someone with daily hands-on experience in that field, and that's what we did.

Whether you want to specialize in DevSecOps or apply advanced concepts in your work, this section gives you a solid foundation on which to build.

With all the recent security breaches in software supply chains, DevSecOps is no longer nice! You need to start applying as much of it as possible every day.

Start: DevSecOps Growth

Thanks for your time, and hope you enjoy the journey! Here is a kickoff checklist:

• 📃 Read the frequently asked questions page (it has much valuable information).

• ⭐ Star the project repo on GitHub (for better visibility).

• 🌐 Join the Telegram group (for interactive communication).

Happy DevOpsing ♾️

A painting titled "Why so many people don't evolve appropriately in their career!" (mostly juniors and mids, but sometimes also seniors) ... Here is why!

The best senior engineers are not strong in pure technical skills, but are also outstanding in tech-related stuff, mainly in making people around them get better and step up! (especially juniors)

There is a clear pattern in the tech industry: a person's entire career is heavily affected by their first job! If their first job was great and they worked with smart, open, humble, and supportive people, their career later will be much better, and vice versa.

And what helped juniors the most was that seniors gave them a chance to move forward (of course, juniors still need to make a lot of effort on their side).

So, dear senior, seniority is not just technical! It's also about working with people and making sure they are moving forward! In the following sections, we will cover some takeaways.

The following 4 top points are essential for seniors and juniors equally!

1. Junior development could be started from day one

There are many seniors treating juniors like "babies"! They always think the juniors are still young and inexperienced in everything. And they must wait a bit longer before getting involved in some tasks.

People's development could start from day one. And as a senior, you don't need to wait to support juniors around you. And juniors need to learn "how to think" to solve problems instead of just looking for a solution to a problem. It's kinda like "MVP pyramid", where you have a small chunk from many skills instead of a big chunk from a single skill.

2. No need to be a senior to start developing people

There is no correlation between your experience and developing people. You don't need to wait till you are a senior to support the people around you. One junior or mid in a group of juniors could enhance the whole group significantly.

That could be done by asking questions, supporting others, or making a competitive state in the group. You could be this person or find someone else to pair with them and proceed.

3. If there are no seniors to support you, find them!

We all know that life is not perfect. And it's hard to find that great senior who could help and support you in your career. Many strong seniors technically could not be that informative or interested/reasonable in people's development at all.

Whatever the reason, that great senior you are looking for may not be in your current company! So you need to find them. You need to find a mentor outside your current company to guide your career.

Again, life is not that perfect! In reality, finding that mentor is hard; if you find one, it's harder to keep in touch with them for a long time. So you will mostly need to see more than one person and learn the best from each one.

4. Don't wait for someone to make your personal development plan

Last but not least, a word for juniors ... most of the time, you will need help from seniors to make your personal development plan; however, you don't need to wait, and you can make your own. You need to put more effort into making one by asking more seniors and collecting all the data, which could help you build your plan.

Those were some of the points that few people focus on; it’s important to emphasize them.

Thanks for your time, and hope you enjoy the journey! Here is a kickoff checklist:

• 📃 Read the frequently asked questions page (it has much valuable information).

• ⭐ Star the project repo on GitHub (for better visibility).

• 🌐 Join the Telegram group (for interactive communication).

Happy DevOpsing ♾️

Nowadays, Docker containers are a de facto standard in the market. Software Engineers and DevOps Engineers work with containers every day.

Start: Docker Container Best Practices

This hands-on project to apply the top 18 ✅️ Dos & 🚫 Don'ts Docker container best practices like:

Essential Practices

• Use Dockerfile linter

• Check Docker language-specific best practices

• Create a single application per Docker image

• Create configurable ephemeral containers

Image Practices

• Use optimal base image

• Pin versions everywhere

• Create an image with the optimal size

• Use multi-stage whenever possible

• Avoid any unnecessary files

Security Practices

• Always use trusted images

• Never use untrusted resources

• Never store sensitive data in the image

• Use a non-root user

• Scan image vulnerabilities

Misc Practices

• Leverage Docker build cache

• Avoid system cache

• Create a unified image across envs

• Use ENTRYPOINT with CMD

If there is one piece of advice from this project, it will be: Use the Dockerfile linter! Use it via CLI or integrate it with your IDE (e.g., VS Code hadolint extension), and integrate it with your CI pipelines! Using it will avoid at least 50% of the Docker issues with your eyes shut!

Start: Docker Container Best Practices

Thanks for your time, and hope you enjoy the journey! Here is a kickoff checklist:

• 📃 Read the frequently asked questions page, it has many valuable information.

• ⭐ Star the project repo on GitHub for better visibility.

• 🌐 Join the Telegram group for interactive communication.

Happy DevOpsing ♾️

TL;DR

The roadmap website has a new feature allowing readers to filter content based on relevancy. So all Software Engineers (Backeng, Frontend, QA, etc.) can earily benefit from the DevOps knowledge on the website. 🎉

The roadmap goal was to be a one-stop shop for anyone who wants to enhance their DevOps skills (Foundations, Projects, and Interviews).

When the roadmap started in 2024, the main focus was DevOps roles (e.g., DevOps Engineer, Cloud Engineer, Platform Engineer, SRE, etc.). However, many Software Engineers (e.g., Backeng, Frontend, QA, etc.) were interested in the DevOps topics.

A new feature allows the audience to filter content based on relevancy. Now, it’s possible to hide the detailed DevOps role topics (i.e., those only needed by DevOps Engineers).

What’s New?

Regardless of your role, you can enhance your skills in the DevOps, Agile, and software production areas, which are included on the website 🎉

Each section will show the targeted audience; you can hide any detailed DevOps topics. Click on the audience to hide/show their relevant content.

Currently, there are three audience groups: DevOps Roles, Software Roles, and All Roles. The “All” group covers general knowledge topics for everyone even non-technical people.

As a Software Engineer, you should learn DevOps, but you don’t need to be a DevOps Engineer. Because at the end of the day, DevOps is not just a role!

Want to enhance your DevOps knowledge? Just go through the roadmap and read the topics tagged for the Software Role!

Get Started Now!

Thanks for your time, and hope you enjoy the journey! Here is a kickoff checklist:

• 📃 Read the frequently asked questions page, it has many valuable information.

• ⭐ Star the project repo on GitHub for better visibility.

• 🌐 Join the Telegram group for interactive communication.

Happy DevOpsing ♾️

Overview

The Dynamic DevOps Roadmap was created in 2024 to address the challenge of starting a DevOps engineer role, as the DevOps model has various implementations and patterns. Yet many other learning roadmaps still follow a linear path (i.e., learn one topic to the end, then move to another, and so on), which doesn't work well with the DevOps role.

Hence, having such a dynamic MVP learning roadmap was critical to increase the chances of entering the market and swiftly starting a job as a DevOps Engineer (and to provide guidance and best practices for all Software Engineers).

2024 Top Highlights

• January: Started the writing marathon.

• October: Published the website. 🎉

• November: 100% done. 🎉

• November: Interview best practices added.

• December: 250 quiz questions added.

• December: GitHub repo reached 1.5k stars. ⭐

• December: 100 common interview questions.

Some Statistics

• 1.7K GitHub Stars. ⭐

• 24K Visitors, 177K Views. 🎉

• 8 Contributors, 20 Pull Requests, and 135 Commits. 🙌

What’s Next?

In 2025, we plan to work on:

• Easy Filtering: To help anyone wasn’t to enhance their knowledge about DevOps easily (basically all Software Engineers who don’t play the DevOps role on a daily basis).

• Learning Plan: To help DevOps Engineers progress easily with the roadmap.

• Projects: In addition to the main end-to-end project, more use-case projects will be added.

• Interview: Adding scenario-based interview questions, which are more likely to be in real-world interviews.

• Growth: Add more about career growth and advanced topics for areas like DevOps, DevSecOps, Cloud, SRE, Platform, DataOps, and MLOps.

Thanks for your time, and hope you enjoy the journey! Here is a kickoff checklist:

• 📃 Read the frequently asked questions page, it has many valuable information.

• ⭐ Star the project repo on GitHub for better visibility.

• 🌐 Join the Telegram group for interactive communication.

Happy DevOpsing ♾️

The Dynamic DevOps Roadmap reached a nice milestone with 1.5k starts on GitHub (If you like the project, please give it a star ⭐ on GitHub for better visibility).

Furthermore, the roadmap is continually enhanced and polished. So, please meet the latest additions to the roadmap … quiz questions!

The quiz has been added to the end of the roadmap's 6 foundations modules. Each module has more or less 40 questions, 20 shows, and shuffled each time.

The quizzes aim to help the learner touch all DevOps parts end-to-end (covering all areas like theoretical, hands-on, quiz, interview questions, and later growth).

• Module 1: Welcome to the DevOps World - Quiz

• Module 2: Basics - DevOps Core - Quiz

• Module 3: Start - Laying the Foundation - Quiz

• Module 4: Expand - Constructing a Shell - Quiz

• Module 5: Transform - Finishing the Structure - Quiz

• Module 6: Keep Improving - Quiz

Thanks for your time, and hope you enjoy the journey! Here is a kickoff checklist:

• 📃 Read the frequently asked questions page, it has many valuable information.

• ⭐ Star the project repo on GitHub for better visibility.

• 🌐 Join the Telegram group for interactive communication.

Happy DevOpsing ♾️

After 12 months of work, the roadmap has been released, a FREE pragmatic plan to kickstart your DevOps Engineer career in the Cloud Native era following the Agile MVP style!

Unlike many other roadmaps, this roadmap is effective, impactful, and, most importantly feasible because it takes a different approach following 3 principles:

• Progressive: MVP-style learning path works in phases.

• Non-Linear: Faster and more solid growth in less time.

• T-Shaped: Depth in expertise, breadth in knowledge.

In addition to the roadmap, there will be community activities, including mentorship, job posting, online meetings, workshops, career tips and tricks, and more.

The roadmap's main goal is to help new DevOps Engineers start their careers and land their first jobs, yet it’s still useful for anyone in the software domain, including Software Engineers and experienced DevOps Engineers, as it also covers the modern tech stack and best practices.

The roadmap is not just purely technical but also dives into topics like Agile planning, interview questions, and interview best practices. It’s meant to cover the end-to-end DevOps domain.

Thanks for your time, and hope you enjoy the journey! Here is a pre-start checklist:

• 📃 Read the frequently asked questions page, it has many valuable information (really, do it!).

• ⭐ Star the project repo on GitHub for better visibility.

• 🌐 Join the Telegram group for interactive communication.

Happy DevOpsing ♾️

While DevOps is a hot topic all the time, it's particularly hard to start DevOps engineer as your first job. Many engineers believe that it's not possible at all to begin as a DevOps professional without first working as a developer or in operations (I totally disagree with that!).

Almost every day, people struggle to start as fresh/junior DevOps engineers. They usually follow some roadmap (typically roadmap.sh/devops). But still, they cannot land their first job, and sadly, many of them eventually give up!

This post explains why most roadmaps don't work for DevOps roles and won't help you start your first job as a DevOps engineer. It also discusses the best way to start in a DevOps role without prior work experience. While it might not work for everyone, it has been successful with all the people mentored in the last couple of years.

TL;DR

Dynamic DevOps Roadmap was created to fix the challenge of starting a DevOps engineer role, as the DevOps model has various implementations and patterns. It's even more complicated (but still possible) if that's your first job without previous software industry experience. Yet, many learning roadmaps like roadmap.sh/devops still follow a linear path (i.e., learn some topic to the end, then move to another, and so on), which doesn't work well with the DevOps role because a skilled DevOps engineer is a T-Shaped skilled. Adopting a dynamic MVP learning roadmap increases your chances of entering the market and starting your first job as a DevOps engineer without previous software hands-on experience.

DevOps Topologies

First, let's start with the DevOps model itself. It is a high-level methodology that can be implemented in various ways, making it super challenging. Hence, the DevOps engineer role has no unified definition or standard requirements.

I will not delve into the cliché DevOps is not a role; it is a culture (because in reality, it doesn't work like that! DevOps is not just a culture, and it is also a role), but here it’s important to emphasize that not all DevOps engineers are the same!

Also, it’s worth mentioning "DevOps Topologies", which covers different team structures that implement DevOps. It shows many bad and good DevOps patterns.

Given that no one-size-fits-all team topology works for every organization, it's wrong to say starting your career as a DevOps engineer is not possible. But there are situations where it's extremely challenging to do so, such as being the sole DevOps engineer in a team or even in a company.

So, what can you do to increase your chances of landing your first job as a DevOps engineer? You should have T-shaped skills and leave no stone unturned in your learning journey!

T-Shaped Skills

The T-shaped skills approach combines broad and deep skills in a specific field. The horizontal bar of the "T" represents a broad range of general knowledge and skills across different disciplines or areas, and the vertical stem of the "T" represents deep expertise in a specific area. It's simply a mix between being a specialist and a generalist at the same time!

The T-shaped skills will help you to work in companies with different DevOps patterns. You can easily transition between different areas in the DevOps spectrum. Not only that, but it will also help you handle new challenges effectively. In fact, the best DevOps engineers possessed T-shaped skills.

Does it mean there's no I-shaped DevOps engineer who specializes in certain areas and has no knowledge in other areas? We can argue that it's possible, but it may limit the available opportunities and companies you can work with.

Actually, as you progress in your career, it's better to develop more specialization (i.e., more vertical stems), and after a couple of years in the industry, your next step should be Pi-Shaped skills (search also for M-Shaped and Comb-Shaped skills, but it's a topic for another post).

To summarize this section, you should aim to gain exposure to various areas of DevOps practices and technologies without delving too deep into each one. Yet, you need to dive in-depth into some of them (according to the market or organizations you target). Your roadmap shouldn't be linear, but follow the MVP-style approach!

MVP Learning Roadmap

You have probably heard before about the "Minimum Viable Product" or MVP, a basic version of a product with enough features to satisfy early users and gather feedback for further development, which is commonly associated with Agile methodologies. Interestingly, this approach can also be applied to learning roadmaps too!

Over the years, there have been a lot of people wanting to start their career as DevOps but completely lost! That's probably because they try to progress in a linear fashion. Typically, they will follow some roadmap like roadmap.sh/devops and start learning the topics one by one top down. For example, they spend a couple of weeks with Linux, then a month learning programming language, then some time with the containers, and more time with Kubernetes. Several months passed, and they found themselves stuck in the middle of the roadmap but still unable to get any job because many topics were untouched!

The truth is that the linear vertical learning path DOES NOT WORK in the DevOps field! You need to follow an MVP-style learning roadmap where you learn in iterations and touch multiple parts at the same time (not necessarily equally). Each iteration should focus on a primary topic while exploring related side topics. So after a month, you already know about each topic in the roadmap, and after the 2nd month, you have the basics, and after the 3rd month, you have a good base, and so on.

By adopting an MVP-style learning roadmap, you can ensure that you cover various aspects of DevOps while continuously building upon your knowledge. This approach allows for a more well-rounded understanding and a better chance of landing your first job as a DevOps engineer.

• The model on the left iterates horizontally in equal chunks over each area (good). It's simple and straightforward. Each area (e.g., OS and code, containers, and cloud, etc.) has a fixed weight based on its importance in daily work. You don't need to think a lot about the next step. From the left to the right, you learn about each area and reach basic knowledge in all of them.

• The model in the center iterates horizontally in dynamic chunks over each area (better). It's the same as the previous one but a bit more advanced, where hands-on knowledge is needed to decide the right weight for each area (based on factors like targeted market, learner skills, or background). This approach is more efficient; however, it requires guidance from an experienced DevOps engineer (e.g., a mentor or career coach) to define the weights correctly. It's even more critical when you have some constraints like time or so (they are usually there in career shifts).

• The model on the right iterates vertically over each area (bad). Don't do that! It has several drawbacks. For example, it delays your market fit, where, in most cases, you cannot work as a DevOps engineer until you have completed all areas. Additionally, there is no space to review your learning approaches or holistic feedback in general. Finally, it's missing the connection between different areas, at the end of the day at work, you don't use a single skill at a time. There are actually many disappointed people in the middle of the roadmap because they still didn't get the full picture.

So, to ensure a more effective learning journey, it is recommended that an MVP-style learning roadmap be adopted. This roadmap allows for iterative learning across multiple areas while also considering the relevance and importance of each area in real-world DevOps work.

The Solution!

A dynamic MVP-style learning roadmap is one of the best ways to start as a DevOps engineer.

Let's put everything together. Based on experience mentoring people in different stages (starting their first job, career shift, moving to another work style or company), the approach of using a dynamic MVP-style roadmap with hands-on projects designed by an experienced DevOps engineer has been highly successful. That means each project will cover all DevOps areas used in the job. It's also essential to understand the targeted market and organizations because, with different DevOps topologies, the DevOps engineer role requirements vary.

In conclusion, to start working as a DevOps engineer, you don't need to know "everything" about the software development life cycle (SDLC), nor start as Dev or Ops and then switch to DevOps. In many DevOps topologies, you can secure your first job as a DevOps engineer if you invest enough time in learning (not only the technical aspects) and follow an MVP-style roadmap. Also, undoubtedly, having a senior DevOps on both ends (during the learning and in the company where you apply) will make your start much easier.