The DevOps Career Handbook E-Book

John Knight

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 269

Veröffentlichungsjahr: 2022

Beschreibung

DevOps is a set of practices that make up a culture, and practicing DevOps methods can make developers more productive and easier to work with. The DevOps Career Handbook is filled with hundreds of tips and tricks from experts regarding every step of the interview process, helping you save time and money by steering clear of avoidable mistakes.
You’ll learn about the various career paths available in the field of DevOps, before acquiring the essential skills needed to begin working as a DevOps professional. If you are already a DevOps engineer, this book will help you to gain advanced skills to become a DevOps specialist. After getting to grips with the basics, you'll discover tips and tricks for preparing your resume and online profiles and find out how to build long-lasting relationships with the recruiters. Finally, you'll read through interviews which will give you an insight into a career in DevOps from the viewpoint of individuals at different career levels.
By the end of this DevOps book, you’ll gain a solid understanding of what DevOps is, the various DevOps career paths, and how to prepare for your interview.

Leseprobe

The DevOps Career Handbook

The ultimate guide to pursuing a successful career in DevOps

John Knight

Nate Swenson

BIRMINGHAM—MUMBAI

The DevOps Career Handbook

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Rahul Nair

Publishing Product Manager: Meeta Rajani

Senior Editor: Athikho Sapuni Rishana

Content Development Editor: Yasir Ali Khan

Technical Editor: Nithik Cheruvakodan

Copy Editor: Safis Editing

Project Coordinator: Shagun Saini

Proofreader: Safis Editing

Indexer: Sejal Dsilva

Production Designer: Jyoti Chauhan

Marketing Coordinator: Nimisha Dua

First published: May 2022

Production reference: 1110522

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80323-094-8

www.packt.com

"In loving memory of Douglas Steven Swenson (1959–2022)

Without you and your unwavering support in my life, this book would have never been possible."

– Nate Swenson

Contributors

About the authors

John Knight is an engineering manager and former director with 17 years of DevOps experience, encompassing 8 different Fortune 500 companies. Lately, he focuses on digital transformations and enterprise migrations and wants to redefine what DevOps means for the next 10 years.

John is a lifelong learner, holding eight major cloud and DevOps certifications and two master's degrees, and he is currently working on a third, computer science, at Georgia Tech, where he hopes to focus on AI and ML and apply the intersection of the two fields to the next generation of AI/ML operations.

Outside of work, John spends time with his wife and four kids, enjoys streaming his favorite series, playing video games, and doing fun projects involving LEGO, robots, and Raspberry PIs.

Nate Swenson is a hands-on DevOps engineer with 12 years of experience within Fortune 100 companies in the insurance and finance sectors. Nate considers himself a DevOps generalist, although the majority of his work revolves around cloud infrastructure and Continuous Integration (CI) and Continuous Delivery (CD).

Nate is the lead DevOps engineer for a team responsible for a self-hosted GitLab platform, which, in turn, is responsible for the source code management and CI/CD for several hundred applications. Nate specializes in cloud infrastructure, coaching, and CI/CD process improvements.

Outside of work, Nate can be found hanging out with his wife and two daughters, exploring the outdoors, or tinkering with his custom home automation setup when he is not working.

"I want to thank my wife for her unwavering support throughout the entire journey of writing this book."

About the reviewers

Daniele Fontani is the Chief Technology Officer (CTO) of Sintra Digital Business and has worked as a senior developer, team leader, and architect on a host of enterprise projects. He has a master's degree in robotic science and another master's degree in project management. His experience in technology extends to many technologies (Java, PHP, and .NET), platforms (SharePoint, Liferay, and Pimcore), and techniques (Agile, DevOps, and Application Lifecyle Management (ALM). He is interested in agile techniques, project management, and product development. He implemented Digital Experience Platforms (DXP) for banks and the loan industry as a team leader and software architect. In the pharma industry, he has designed and developed retail portals for the training and social engagement of retailers.  

"A special wish to all the readers of this book – may this book give you the tools to start a prosperous career."  

Satish Balakrishnan is an experienced cloud and DevOps architect with experience in companies such as Accenture, Hewlett Packard Enterprise, Singapore-MIT Alliance, and start-ups. He has an association with Microsoft as a Senior Cloud Solutions Architect for the APAC region. He has written numerous articles on the cloud and blockchain that have been published in the CDOTrends, Techopedia, Blockchain Council, and IEEE newsletters. Satish has also authored a book called Terraforming the Cloud.

Table of Contents

Preface

Section 1: A Career in DevOps

Chapter 1: Career Paths

Earning potential

Constant learning opportunities

Impact on the company

Flexibility

Overview of DevOps history

Lean manufacturing

Agile

Extreme programming

DevOps

DevOps culture

Customer-centric

Foster collaboration

End-to-end ownership

Continuous improvement

Automate everything

Continuous learning

DevOps career paths

DevOps generalist

DevOps specializing generalist

DevOps security specialist

DevOps cloud specialists

Summary

Chapter 2: Essential Skills for a DevOps Practitioner

Scripting, coding, and programming

Navigating the command line

Scripting

Source code management

Git

SCM

Infrastructure management

Capacity planning

Infrastructure provisioning

Deployment

CI/CD concepts

Continuous integration

Continuous delivery

Cloud-native frameworks

Containers

Microservice architecture

Soft skills

Beginner DevOps certifications

AWS certifications

Google Cloud certifications

Azure certifications

Other resources

Summary

Chapter 3: Specialized Skills for Advanced DevOps Practitioners

CI/CD pipeline DevOps engineer

Maintaining a shared pipeline library

Infrastructure as code

Cloud and application modernization

Advanced cloud skills

Application modernization

Choosing a modernization approach

Containers and container management

Container management software

Security

CI/CD process security

Environment and data security

Advanced DevOps certifications

AWS certifications

Google Cloud certifications

Azure certifications

Kubernetes certifications

Competency matrix

Matrix breakdown

Compensation in relation to level and competency

Summary

Section 2: The Application Process

Chapter 4: Rebranding Yourself

Ways of improving your LinkedIn profile

Updating your headline

Recommendations

Additional sections

Updating your resume to match the career you are after

Contact information

Objective

Experience

Updating and or creating your personal web page

GitLab Pages tutorial

Sections to include on your personal web page

Leveraging Twitter and other social profiles

Twitter

Medium

Summary

Chapter 5: Building Your Network

LinkedIn the right way

Getting noticed

Building lasting connections, online and offline

Building connections in virtual settings

Building connections in a personal setting

In real life

Quality over quantity

Networking and conversation starters

Lean Coffee

Lightning talks

Conversation starters

Summary

Chapter 6: Mentorship

The importance of mentorship

Assistance and guidance toward setting achievable goals

The motivation to help you achieve your goals

Career coaching

Useful advice

The mentor-mentee relationship dynamics

Choosing the correct mentor

Questions to ask when looking for a mentor

Asking an individual to be your mentor

Additional ways to get connected with a mentor

Mentors as a reference

Have you asked your mentor to be a reference?

Have you worked with the mentor?

Has your mentor seen you use your skills? Are they confident about your skills required for the role?

Summary

Chapter 7: Working with Recruiters

Different types of recruiters

First-party recruiters

Recruiting agencies

Freelance recruiters

The recruiter's role at various stages of the interview process

Where to find them and how they can find you

How to present yourself

How to negotiate

Things that do not work

Things that do work

Following up, but when?

The waiting game

Etiquette for following up with recruiters

Summary

Section 3: Interview Process

Chapter 8: Preparing for Your Interview

Phases of the interview process

First-round interview

Technical interview

Follow-up rounds

Best ways to prepare

What to expect

Tricks of the trade

Common mistakes

Things that do work

Summary

Chapter 9: Interviews Step by Step

Typical interview walk-through

First-round interview

Technical interview

Additional rounds

Offer stage

Non-typical interview walk-through

Tests

Out-of-the-box design

Tell me about a time

Summary

Section 4: Tips, Tricks, and Interviews

Chapter 10: DevOps Career: Tips and Tricks

Tips for transitioning to a career in DevOps

Personal DevOps journey

Stay on track, but entertain your interests

Life is busy; prioritize and focus on things important to you

Opportunity is often disguised in a deceptive facade

Making an internal career change is sometimes easier than changing jobs and companies at the same time

Apply for roles you find interesting, even if you do not meet all the requirements

Things to avoid during the interview process

Avoid providing inaccurate or misleading information when applying for a position

Avoid neglecting to respond to recruiters after you have applied for a position

Avoid inconsistent information across social profiles and your resume

Things to do during the interview process

Discuss your side projects

Come prepared, ready to discuss tool alternatives

Summary

Chapter 11: Interviews with DevOps Practitioners

Interview with a senior DevOps manager

Interview with a senior DevOps engineer

Interview with a DevOps architect consultant

Interview with a tech executive passionate about neurodiversity and inclusion

Summary

Why subscribe?

Other Books You May Enjoy

Preface

Navigating any career is difficult; navigating one that is the culmination of many different careers can feel almost impossible. This book will aid you in navigating the field of DevOps and help prepare you for a career in it. The second half of the book focuses on techniques to use during each stage of the interview process to increase your odds of being a top candidate.

Who this book is for

This book is for anyone who wants to learn more about DevOps, pursue a career in DevOps, or advance their career in the field of DevOps.

What this book covers

Chapter 1, Career Paths, explores the history and culture associated with DevOps, followed by various career paths available in the field of DevOps.

Chapter 2, Essential Skills for a DevOps Practitioner, covers the skills required by all DevOps practitioners, regardless of level.

Chapter 3, Specialized Skills for Advanced DevOps Practitioners, covers the skills required for advanced careers within the field of DevOps.

Chapter 4, Rebranding Yourself, provides tips for updating your social presence as well as your résumé.

Chapter 5, Building Your Network, covers getting your skills noticed by the right people, which is key to landing a job, and offers tips and tricks on building your network to include the right people.

Chapter 6, Mentorship, focuses on the value of mentorship and how to connect with a mentor.

Chapter 7, Working with Recruiters, examines how most jobs are being filled by a combination of internal and external recruiters, giving you advice and tips on how to work with both.

Chapter 8, Preparing for Your Interview, provides tips on how to ensure you are prepared for your interview.

Chapter 9, Interviews Step by Step, walks you through what to expect at each stage of the process for both typical and non-typical interviews.

Chapter 10, DevOps Career: Tips and Tricks, provides a brain dump of the authors' 25 years of collective knowledge on things they have seen work and not work when interviewing.

Chapter 11, Interviews with DevOps Practitioners, revisits candid, open interviews with DevOps practitioners at various stages in their careers.

To get the most out of this book

This book assumes that you have a technical background. However, the only thing that is required to be successful in using this book is a desire to learn.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781803230948_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "The –it command runs the container with an interactive terminal."

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: "Navigate back to GitLab to the project you just pushed, and click on Settings | Pages to view the URL where your site is published."

Tips or Important Notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you've read The DevOps Career Handbook, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content.

Section 1: A Career in DevOps

In this section, you will learn what it takes to be successful in DevOps, as well as various career paths and competencies required at various levels.

This section comprises the following chapters:

Chapter 1, Career PathsChapter 2, Essential Skills for a DevOps PractitionerChapter 3, Specialized Skills for Advanced DevOps Practitioners

Chapter 1: Career Paths

A DevOps career path is never linear, does not have a single point of entry, and can diverge at any moment. DevOps careers are rooted in Lean, Agile, and Extreme Programming (XP), making it as much a culture fit between a candidate and employer as a technical fit. In this chapter, you will get a history lesson on DevOps that will aid in discussions with recruiters and hiring teams in the future. You will also be introduced to different skill profiles, which will help in determining the direction you take your career.

The following topics will be covered in this chapter:

Why you should pursue a career in DevOpsOverview of DevOps historyDevOps cultureDevOps career paths

Reading 200+ pages on a career you are not sure you want to pursue seems silly; time is a resource that is in short supply. In this section, we will cover why you should pursue a career in DevOps; specifically, why you should choose DevOps over other IT-related careers.

Earning potential

DevOps is constantly ranked as one of the highest-paying professions, with a median salary of $100,000. Entry-level DevOps engineers can expect to earn anywhere from $75,000 up to $145,000. As you progress in your career, you can expect to earn more. Look at the following graph:

Figure 1.1 – DevOps salaries

Another reason you should consider a career in DevOps is you will never get bored as it is ever-evolving, which allows many opportunities to learn new skills.

Constant learning opportunities

Part of your job as a DevOps engineer is to stay up to date with the latest tools, technology, and trends that are occurring in the industry. DevOps engineers get paid to learn! It is one of my favorite things about my role as a DevOps engineer. As a DevOps engineer, you will ward off boredom while at the same time future-proofing your career.

Impact on the company

As a DevOps engineer, you will be delivering features used and felt by every part of the company. There is no other technical position where your efforts will have such a significant impact on the business.

Flexibility

As a DevOps engineer, you will have the flexibility to work where you want, when you want. Remote work has become increasingly accepted across the technology industry; DevOps teams were doing this before it was considered cool. Collaboration tools including Slack and Jira have made asynchronous work possible. What this means is you do not have to work the same hours as the rest of your team – at least not all the time.

So, Why Should You Pursue a Career in DevOps?

As a DevOps engineer, you will be highly compensated, constantly learn and apply cutting-edge technology to solve problems impacting the entire business, and have the flexibility to work where and when you want.

Overview of DevOps history

You are reading a book on DevOps, likely meaning you have a basic understanding of what DevOps is; if not, there's no need to worry – that will be covered as well. The history of DevOps is less known even within DevOps communities. First, we'll go back to understand key elements that came before DevOps that laid the groundwork and created the environment needed for DevOps to grow.

Lean manufacturing

Lean manufacturing is a production method aimed primarily at reducing cycle times within the production system as well as response times from suppliers and to customers.

The term Lean was coined in 1988 by John Krafcik and defined in 1996 by James Womack and Daniel Jones. Lean manufacturing is well-established as a set of best practices for manufacturing. Often branded as the Toyota Manufacturing Method, Lean manufacturing strives for process optimization across the manufacturing floor. Continuous improvement is the mantra for Lean manufacturing and practitioners continually evaluate ways to do the following:

Keep inventory at a minimum.Minimize the queue of orders.Maximize efficiency in the manufacturing process.

Agile

In the early 2000s, traditional waterfall methods were evolving and being replaced by Agile, which required a large culture shift that focused on team empowerment. Agile is based around 4 core values and 12 principles. Some were adopted into DevOps as it evolved (https://kissflow.com/project/agile/values-and-principles-of-agile-manifesto/).

Extreme programming

XP aims to improve software quality and responsiveness to changing customer requirements. If you are thinking that sounds a lot like Agile, you wouldn't be wrong; it is a type of Agile software development. The biggest difference between XP and other Agile frameworks is the emphasis placed on the code and development (https://en.wikipedia.org/wiki/Extreme_programming).

The main contribution XP gave DevOps was Continuous Integration (CI). CI was a term introduced in 2001 by Grady Brooch and was published as the Brooch method soon after.

DevOps

The exact inception of DevOps will forever be debated; it is widely accepted that between 2007 and 2008 is when the movement started. It was a perfect storm of events that allowed and triggered the DevOps movement. The dysfunction in the software industry, namely between IT operations and software development communities, was the spark that ignited the movement, but it was the pioneers of Agile, Lean, and XP who were responsible for the initial fuel of the DevOps movement.

In a world absent of DevOps, developers and IT operations belonged to different corporate hierarchies and Key Performance Indicators (KPIs) for IT operations and development were asynchronous and detrimental to the other. These conditions created teams siloed from one another, causing a breakdown in communication, and ultimately leading to failed deployments, missed deadlines, and angry customers.

In 2008 Andrew Shafer, a software engineer, tried to put together a meetup session entitled Agile Infrastructure at an Agile conference in Canada. Patrick Debois, an Agile practitioner, was the only one there. The two had a long conversation, which today is known as the spark that ignited a fire that became a movement known as DevOps. Andrew and Patrick formed a discussion group for other people to post their ideas for how to solve this divide between development and operations later that year. In 2009, the first DevOpsDays was held, in Belgium, which turned DevOps into a buzzword forever cemented in history. The DevOps movement continued with local meetups around the globe. Around 2010, open source software focused on DevOps began growing in popularity; Jenkins CI server software and Chef infrastructure provisioning software were a couple of pioneers.

Pro Tip

Understanding the history behind the job title you are applying for will make you seem more serious about the role and conversation much more natural. Dig deeper and read some books such as The DevOps Handbook and The Phoenix Project. They will only increase your chances of success further.

The following diagram gives a timeline of key dates in the history of DevOps:

Figure 1.2 – History of DevOps timeline

Now that we have learned about the history of DevOps, let's look at DevOps culture in the next section.

DevOps culture

DevOps is a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology (https://en.wikipedia.org/wiki/DevOps). Diving deeper into that definition, we learn DevOps is a multi-faceted practice. DevOps has seven guiding principles that combine to form DevOps culture. DevOps culture aims to decrease cycle time, apply incremental changes, and create a more streamlined development process.

The following diagram gives a graphical representation of the seven principles of DevOps:

Figure 1.3 – DevOps culture – principles

Now we will take a deeper dive into each of the seven principles of DevOps.

Customer-centric

Test often, get end user feedback frequently, and fail fast. The feedback loop between the customer and end users of products needs to be as short as possible. All actions taken by a team should be focused on the experience of the end user. This is also where the saying shift-left comes from, meaning the sooner a feature is tested for bugs, the quicker it will be resolved, and fewer downstream dependencies will be compromised.

A Tale of Two Start-Ups Bidding to Develop a Fitness Tracker for a Large Insurance Company

Need: A wearable device that will track users' fitness.

Acceptance Criteria: A wearable watch-like device that tracks various workouts.

Company X employs test-driven development and has weekly demos where they receive feedback. During a demo, they showcase a device and describe plans to track running and cycling. They learn that a big portion of their customers are swimmers. The team takes the feedback and shifts priority from running and cycling to swimming. The customer is impressed.

Company Y does not feel it is necessary to have demos as their past applications have done relatively well. The team focuses on the running and cycling workout tracking ability. During acceptance, they receive feedback that the watch must have the ability to track swimming. The development team is unable to meet the requirements in the given time frame. The customer is not impressed.

Outcome: Company X is awarded the contract and goes on to be a billion-dollar company. Company Y is not awarded the contract and receives poor press leading to another failed start-up.

Foster collaboration

The collaboration between the development team and IT operations teams is the most basic must for DevOps. Removal of silos ensures collaboration and alignment across entire organizations, ensuring a singular focus on the customer.

A collaborative culture is most effective when implemented using a top-down approach; executive sponsorship should be lined up ahead of any major culture shift. Another, much slower, approach is grassroots initiatives within an organization. A group of like-minded individuals with a platform to share on is all it takes to start a revolution. The trouble with the latter approach is overtime burnout can occur if you work tirelessly to make a change and see no results time and time again. Instead start with something you do have control over, such as your team.

Robert Weidner is a senior director at Optum and is one of only 26 Certified Enterprise Coaches in the world and is also my mentor and former manager. While working under Robert, our team was empowered to choose what micro team we worked in. We were also encouraged to hop over and help any other micro team who needed our support. When it came to stack ranking the team and fitting us to the bell curve for our bonus, we did our reviews of each team member during an offsite with the entire team present and in the hot seat while receiving feedback. It was frightening, but it worked because the team trusted each other.

End-to-end ownership

Feature teams ensure end-to-end responsibility by giving the team a vertical slice of a product, a feature. The feature, Feature 1: Button X, has two user stories: one for development and one for testing. The definition of done for the feature also requires the feature to be deployed successfully. This can be seen in Figure 1.4. The final piece to note is the ongoing support of Button X also remains with the team. Our company has started to call this You Build It, You Own It (YBYO). The rationale behind this concept is that the team who built something is going to have the most knowledge about it when there is a production issue.

Figure 1.4 – Feature-centered team (E2E ownership)

In traditional development methods such as waterfall, teams are broken down and created at the activity level, also known as a horizontal slice of work. Ownership of a feature is split among various teams. In the following example, three teams must interact with the feature before it makes it to the end user, and another team is responsible for ongoing support. This is problematic; the operational support team is oftentimes not aware of the most recent changes the development team made, leading to extended downtimes and outages:

Figure 1.5 – Waterfall teams

Now, we'll talk about continuous improvement.

Continuous improvement

Continuous improvement was inherited from Lean. The entire team should be encouraged and, more importantly, empowered to make changes without fear of failure. Teams instead use failure as opportunities to improve on flawed processes. This is also known as failing forward. Failing forward allows for better control over risks as well as continuing to push the team forward. For your entertainment, the following is a script (continous_improvement.sh) to ensure your team is empowered to make improvements, continuously:

Figure 1.6 – Continuous improvement shell script

The preceding script is a simple script that defines the flow of how the continuous improvement flow would operate if it were a shell script.

Automate everything

While doing research for this book, I noticed two common wordings: automate everything and automate (almost) everything. Further research revealed a common theme in types of processes that should not be automated, items with no payback, and items including a high degree of design or visual inspection, as seen in the following list (https://dzone.com/articles/what-to-automate-and-what-not-to-automate):

Automation with no ROIDesign Final QC of an application

Processes should have the least amount of manual intervention possible. The reason for this is simple: humans are error-prone while machines (computers) are excellent at executing high-volume repeatable tasks.

Next, we will cover continuous learning, a DevOps principle that is important for individuals looking to enter the field of DevOps, as well as those looking to stay relevant in the ever-changing field of technology.

Continuous learning

Technology is evolving at an astonishing rate; the most well-known example of this is Moore's law. Moore's law is the observation that the number of transistors in a dense Integrated Circuit (IC) doubles about every 2 years (https://en.wikipedia.org/wiki/Moore%27s_law). The number of transistors that fit into a microprocessor reached over 10 billion in 2017. It was under 10,000 in 1971( https://ourworldindata.org/technological-progress). Being a continuous learner is a personal attribute that will get you hired.

Pro Tip: You Must Be a Continuous Learner If You Wish to Succeed in DevOps

Creating a public project using a new technology is a great way to showcase this to potential hiring managers. Another way is to make sure to leave digital breadcrumbs of the most recent articles you have read, whether it be a post on LinkedIn or a tweet on Twitter.

An example that sticks out is an interview for a senior DevOps engineer role that was down to the final two candidates. Both candidates had tenure with the organization, exceeded the qualifications, interviewed well, and had advanced degrees. The candidate that received an offer displayed a hunger for knowledge throughout the interview process in subtle ways. The candidate chose to focus not on their degree but on a side project that had the purpose of teaching the candidate Golang. The theory of data science was being demonstrated with the application and it was cool. What stuck out, and continues to, was the candidate's desire to learn new things.

In summary, the combination of development and operation along with the seven DevOps principles, when applied together, form the DevOps culture. DevOps is a completely unique derivative of Lean, Agile, and XP aiming to shorten the feedback loop between development and the end user.

Take a look at the following visual depiction of DevOps culture broken down into the practices and principles:

Figure 1.7 – DevOps culture chart

In summary, DevOps culture contains seven guiding principles, as seen in Figure 1.7. In the next section, different career paths for a DevOps engineer will be discussed.

DevOps career paths

The field of DevOps is dense and is challenging to navigate, even for experienced practitioners. DevOps consists of eight core practices and follows seven basic principles. Unsurprisingly, there are numerous career paths in the field of DevOps. The generalist is the most common DevOps role.

A DevOps generalist is comparable to a Swiss Army knife, which is designed to handle as many tasks as possible. It can cut rope, open a can, cut wire, and if needed, the Swiss Army knife could fillet a fish. A DevOps generalist can create a deployment pipeline, write infrastructure as code scripts, and manage an Elastic Kubernetes Service (EKS) cluster in Amazon Web Services (AWS) if necessary.

A DevOps specialist is comparable to a fish fillet knife, which is singularly designed to fillet fish most effectively. The knife's profile, blade material, and ergonomics are finely tuned for a singular task, slicing fish. For example, a DevOps cloud specialist has spent their career focused on becoming an expert in cloud infrastructure, cloud architecture, and cloud security, and managing an EKS cluster in AWS is what they do in their sleep. It is likely that they would find a more cost-efficient way to do it than a non-cloud specialist.

A DevOps specializing generalist is comparable to an Everyday Carry (EDC) knife with a trailing point blade. This knife has ergonomics similar to a Swiss Army knife but a blade profile giving it the ability to fillet fish at a comparable level to a fillet knife. A DevOps specializing generalist who spent the past 10 years working in an AWS environment would be able to complete most DevOps tasks but would excel at those that involved AWS services.

Common skill profile shapes for a generalist, specialist, and specializing generalist can be seen in the following diagram:

Figure 1.8 – Skill profiles

The profile of your skill set can be very useful when determining how to classify yourself. Start with a comb. Each prong (skill) has a similar length (depth). The comb shape is typical of a generalist. The second common profile is the T shape. A T has a single line (skill) that has a full length (depth). The T shape is typical of a specialist. An E-shaped profile, sometimes referred to as an unequal comb, has prongs (skills) of differing lengths (depths). Oftentimes, one or several skills have a definitively greater depth than the rest. The E shape is common for a specialized generalist.

A mentor told me the unequal comb (E shape) skill profile is the only true measure of an individual's skills. The comb shape is flawed because it assumes all skills have an equal depth, which is impossible. The T shape has a lack of detail; it shows a singular skill the individual is highly adept at but does not account for the other skills possessed by the individual.

Pro Tip

For this chapter, do not focus on what is required for the example skills listed as they will be covered in the next chapter. Instead, focus on how the skill profiles relate to the different types of DevOps engineers' specific requirements.

Common skill profiles fitted to the E profile can be seen in the following diagram:

Figure 1.9 – Skill profiles (E profile fitted)

In the following sections, we will take a look at skill profiles for a DevOps generalist, specializing DevOps generalist, as well as several skill profiles for DevOps specialties. We will begin by looking at the skill profile