Intro 4

About the Author 4

Purpose of this Book 4
What to Expect 5
What Not to Expect 6
What is DevOps? 6
People 7
Process 8
Technology 8
Measuring Everything 10
Summary 10
Actions 11
Make Your Top Ten List 11
Getting Started 11
Culture 12
Requested Skills 13
Size 13
Financing 15
Finalizing The List 16
Summary 16
Actions 17
Build an Unforgettable Resume 17
Formatting and Layout 17
Content 20
Summary 22
Actions 22
Bring the Opportunities to You 23
LinkedIn 23
Job Posting Sites 26
GitHub Contributions 27
Training and Certifications 28
Summary 28
Actions 29
Mission: Land a DevOps Job 29
Where to Start 29
When to Apply at Your Top Ten List 31
What to Do Differently 31
Summary 32
Actions 32
Personal Connection through Cover Letters 32
When to Use One 32
How to Write One 33
Summary 34
Actions 34
How to Nail the Phone Screen 34
Scheduling and Reconnaissance 34
 Preparing for the Phone Screen 35
Know Your Screener 35
Prepare Your Answers 36
20-Minute Countdown 38
Passing the Phone Screen 38
Summary 40
Actions 41
Interviewing 41
Know Your Interviewer 42
Culture Fit 42
STAR Method 44
Interview Conversation Flow 47
Dealing with Direct Technical Questions 48
Subjective interviewers 49
Objective Interviewers 50
Asking Questions 51
Practicing 52
Summary 53
Actions 53
Conclusion 54
Appendix 56
Experience Stories 56

Intro

About the Author

My name is Brett Petrusek, and I have been working in DevOps for over two decades. I have
conducted over a thousand interviews and have been an interview candidate over two hundred
times. My career has taken me to the world's largest corporations, and to small businesses
where I served as the entire IT staff.

Over the past 20 years, I have honed my skills as an engineer, ranging from designing and
building high-performance computing clusters to developing gene sequencing programs and
software for deploying and managing enterprise cloud infrastructure. As a business person, I
have launched three technology companies, co-founded a biotech startup, and co-founded a
blockchain event ticketing company. I am passionate about technology, but even more
passionate about sharing my experiences to help others realize their own dreams and
aspirations.

At the time of writing, I hold the position of Principal DevOps Architect at the world's largest
cloud provider. One of my responsibilities is to hire exceptional talent to strengthen our DevOps
skill set and cater to the largest enterprise customers in the world. I conduct a minimum of one
interview per week, and sometimes as many as five. Additionally, I work directly with C-level
executives at Fortune 50 companies, assisting them in planning and implementing DevOps
transformation strategies. I contribute to the acquisition of talent by conducting interviews,
developing questionnaires and coding exercises, as well as creating recruiter training programs.
This experience has given me a unique perspective on the skills that companies seek. It also
means that I have a direct impact on the DevOps community through my contributions to
community blog posts, official company website content, and open-source projects, to name a
few. DevOps is an integral part of my daily life, as I practice it at a strategic executive level all
the way down to code development.

Throughout my career, I have learned what sets certain individuals apart from the rest. In this
eBook, I will share the secrets I have discovered. These insights will give you an advantage
over the thousands of other candidates who may possess similar skills listed on their resumes.
These secrets can make the difference between hearing "We'll call you" and "How soon can you
start?"

Purpose of this Book

This book was written to serve two outcomes: (1) getting you into a job that you love and (2)
getting you paid above market price. The first point is very important. I want to positively affect
the DevOps industry in which I passionately participate. Being in a job you love makes you more
productive. The more productive you are, the more likely you are to succeed beyond Day 1. The
more you succeed, the stronger the DevOps industry becomes and the more value we generate
in the world. All of these small steps become self-fulfilling prophecies of success to grow the
revenues of the companies to which we contribute. And that translates to more jobs and more
money for us. Always remember to Think Big.

The second point is just as important as the first because being rewarded for your hard work
brings satisfaction to your life, which further emphasizes the first point. I know there are jobs
that pay very low salaries, but people love them anyway. I applaud those people for doing that
work, most of which is extremely necessary for humanity. However, having enough money to
feel safe and secure in the present and the future is important to our happiness, regardless of
what anyone tells us. I'm not suggesting that you need a Lamborghini to be happy, but not living
paycheck to paycheck removes stress from your life and allows you to be more productive,
which, again, reinforces point one.

To boil it down, this book is about finding happiness in your job and in your life.

What to Expect
Expect to work hard. I will provide you with a wide range of specific tasks, some of which may
be easy, while others will pose a greater challenge. Certain tasks may come naturally to some
individuals but prove difficult for others. Depending on where you are in your career journey,
some of these tasks may not be immediately feasible. It's possible to accomplish certain goals
within a day, while others may require more than a year. Remember, nothing worthwhile comes
easily.

Prepare yourself for a complete shift in your work mindset. My aim is to guide you towards
building a career, not just finding a job. The distinction lies in the fact that a career is a lifelong
pursuit that rewards you with more than just financial gain. It shapes your sense of self and your
life as a whole. I want you to wake up each morning eager to go to work, to create value by
building innovative solutions, and to form meaningful relationships with people.

I will help you perceive and articulate the DevOps world in a different light. Using metrics and
business outcomes, I will demonstrate how to craft meaningful descriptions of your work that will
resonate with recruiters, technical peers, and business executives. By the time you finish this
book, you will grasp the essence of delivering business value through technology.

You will learn how to establish mechanisms for collecting data that will keep you informed about
technological advancements companies seek to leverage in their business roadmaps. Armed
with this knowledge, you can position yourself as a thought leader in the field of DevOps and
enhance your desirability. You will stand out among other job candidates.

Expect to gain a fresh perspective, a heightened level of motivation and excitement, and a killer
resume.

What Not to Expect

This is not a life hack book. The steps I outline throughout are not cheats. It requires hard work
and discipline to achieve the kind of success I want you to have. Not everyone will be able to do
it. Some will have to work harder and longer than others. There is not some magical phrase to
put on your resume or say to a hiring manager to get a huge salary with a signing bonus. If it
were that easy, everyone would be doing it.

Do not expect to finish reading this book and have a job in less than a week. Sure, it's possible,
but it's unlikely. I can't tell you how long it will take to find your dream job, and everyone will
have to balance their financial and life commitments with the level of effort required to achieve
the results I propose in this book. This is not a checklist of items where you get handed a job
when they are all completed. Finding a job and preparing for that final interview is a full-time job
in and of itself.

Finally, this book is for people that already have some level of DevOps work experience. This is
not a “DevOps for Dummies” book. I expect you to have a foundational understanding of
DevOps and some experience in the field. The general rule of thumb is that you have 1-2 years
of relevant DevOps work experience for this book to be helpful.

What is DevOps?
If you are going to work in DevOps, you need to be able to explain it with both a short summary
and in great detail. Everyone has their own definition, so it's important that you have a short
answer that sums up all the concepts of DevOps. You will want to be able to recite this to an
interviewer. Don't just throw a bunch of buzzwords together. It should be a cohesive statement
that defines a specific action. This is how I respond when asked this question:

DevOps is about increasing the speed and quality of software delivery and using software
development practices to increase the speed and consistency of operational processes.

Don't make it any more complicated than that. As I said, everyone seems to have a different
definition, but DevOps is most obvious when applied to practical situations or using
comparisons. For example, creating a plan to build a massive piece of software that will take the
development teams more than six months to deliver is not DevOps. Breaking a giant plan into
pieces that can be delivered in two-week increments, each of which has clearly defined
business value, is DevOps. I am not going to linger on definitions. Instead, I am going to focus
on how DevOps is reflected in people (culture), processes (business), and technology. I am then
going to talk about how to use metrics as the language to describe delivering business value
through DevOps. Lastly, I will decompose "dev" and "ops" into the software development
lifecycle (SDLC) and operational automation.

An important theme you will recognize throughout this book is that DevOps is a unique blend of
technology and business skills. There is heavy overlap between the definitions of success for
DevOps and for business. For companies that deliver value to their customers using software, it
comes as no surprise that technology and business are intimately connected. Because of this, it
is not uncommon to find DevOps engineers that have a higher than average business acumen,
including human resource management and business process management. I like to think of
DevOps engineers as their own kind of entrepreneurs, constantly seeking business efficiencies
that drive positive impacts to the top and bottom lines of the business. This is the kind of
candidate that not only excels during the interview process, but in their role at the company.
People that can demonstrate and articulate the blending of technology and business will
naturally gravitate towards leadership positions in the companies they serve.

People
DevOps heavily relies on company culture for successful implementation. Many people
mistakenly believe it is solely about selecting the right tools. However, without a proper DevOps
culture, a company cannot fully embrace DevOps. The people aspect of DevOps involves
organizing smaller, agile teams that align with delivering specific business functionality, such as
a component of a product. It also encompasses the mindset of team members, their interactions
with external teams, and the way they make architectural decisions.

Highly efficient development teams often have a focused scope or "knowledge domain." They
don't need to possess extensive knowledge of numerous technologies to be productive. Instead,
they excel in one or two technologies and are capable of making design and implementation
decisions independently, without relying on external teams. These teams take ownership of their
entire service, from start to finish. New team members can quickly get up to speed and
contribute valuable code. They provide well-written, publicly accessible documentation about
the services they are responsible for. Other teams can integrate those services without requiring
direct guidance, which minimizes disruptions to the development workflow. This concept is
known as "self-service." A significant goal for any team should be empowering others to
consume their services with minimal or no assistance.

Adopting a DevOps mindset means making architectural decisions that prioritize backward
compatibility and reversibility. It involves employing open-source principles, developing and
publishing small, composable components in a company's internal or external code repositories
for use by other teams. Developers should exhaust the possibilities of reusable components
before writing functionality from scratch.

Above all, a good DevOps team member is always mindful of the "customer" of their services.
They view everything they do through the lens of the customer's experience and how it will
impact their interaction with the service. Experimentation is encouraged to discover new ways to
benefit the customer, but it should be conducted in a safe and well-tested manner. A competent
DevOps engineer always has a plan to thoroughly test any new features before releasing them
to production. In fact, the first question a DevOps engineer should ask themselves before
developing a new feature is: How am I going to test this?

It is crucial to be able to articulate the importance of DevOps culture to a business. One

effective exercise is to provide examples of previous companies you have worked for that
lacked a strong DevOps culture. For instance, a company that organized its teams into silos
based on databases, applications, and infrastructure. Write down these examples and include
bullet points explaining how such a setup negatively affects the business. Then outline the
changes you would make to improve the situation and how they align with fostering a strong
DevOps culture.

Process
The most common process or framework associated with DevOps is Agile, which is the process
for planning and executing development work. Agile's goal is to break apart large development
efforts into smaller units that can be delivered in a short amount of time, called a "sprint." A
sprint is typically one to two weeks long but never more than four. Work from a sprint can be
released as it becomes available using continuous delivery mechanisms or at the end of the
sprint as a bundled release.

Most people do not grasp the most important goal of Agile: it focuses on delivering business
value at speed. Breaking apart large development efforts into smaller units of execution may be
helpful from a testing and release perspective. But if it does not deliver value that the business
can use to generate revenue, acquire more customers, or keep existing customers, then you
are missing the entire purpose of Agile. This is where the overlap between "people" and
"process" is most apparent. A good scrum master or product manager will look at their feature
development roadmap and balance "enabling" features with "customer" features to deliver
maximum business value quickly. There is no prescriptive guidance for this. It is unique to every
product. Regardless, you must be able to articulate why Agile breaks apart work into smaller
units. That reason is for the business to get a return on the development investment and realize
the value faster.

In addition to Agile, there are all sorts of day-to-day activities that align with good DevOps
hygiene, like trunk-based development, test-driven development, feature toggles, ephemeral
test environments, local testing, and quality gates. You should be able to speak intelligently to
any of these DevOps processes.

Take a moment to collect some examples from your experience of how poor Agile
implementation led to slow development velocity or the inability to complete features on time. A
typical example is constant priority changes from management. Describe why this was a
problem and then propose a solution to fix it, including why you think it would improve things.

Technology
DevOps technology can be broken down into three major areas: code pipelines, monitoring, and
configuration management.

Code pipelines are typically represented as a linear pipeline of events, starting with code
development and ending with production deployment. The time it takes to get from one end to
the other is called development lead time. The purpose of DevOps is to make that time as short
as possible with the intent of realizing business value as fast as possible. To accomplish this,
automation is used to test the functionality of newly developed code. The technology
frameworks and patterns used to drive the build, testing, publishing, and deployment of code
artifacts are commonly referred to as "tooling." Code pipelines are the most typical technical
implementations done by a DevOps engineer. The goal of code pipelines is to automate the
SDLC process and provide fast feedback to developers about the quality and functionality of
their code as they develop it.

Monitoring is the practice of collecting information about code, infrastructure, and applications
that can be used to understand quality and health. A good DevOps engineer will measure
everything and then analyze the data to understand whether improvements or regressions are
being introduced. Data is the foundation on which all decisions should be made, and the data
collected from code development and infrastructure health tells the business everything it needs
to know in order to maximize efficiency and speed. Instrumentation should measure everything
about the SDLC process, from how long it takes to develop feature code to how many bugs
escape into production. In addition to the SDLC process, application health, infrastructure
health, and performance should be measured both in production and non-production
environments. An organization should provide a self-service instrumentation and telemetry
platform to make it as easy as possible to extend and add metrics that provide valuable insights
into the functioning of applications, infrastructure, and development processes.

Configuration management takes many forms, but they are typically either infrastructure
configurations or application configurations. Many configuration management frameworks are
available, but you should be proficient in at least one for infrastructure and one for applications.
Codified configurations also have their own SDLC process that should be managed just like
application code, versioned and checked into a code repository. Automated systems should
exist to prevent configuration drift and to alert relevant support staff if it does occur. Nothing
should be deployed without a codified configuration. The expectation should be that an entire
environment can be torn down and rebuilt in less than one day and, ideally, even faster than
that.

The most common mistake that organizations make is to focus their DevOps transformation
entirely around tooling without also implementing changes to their culture and business
processes. While tooling is important, without a solid DevOps culture in place, there is no
amount of automation that can fix every problem.

Write down every DevOps tool that was used in your last position. Then point out all the ways
that those tools failed to deliver on their promise of increased development velocity. A common
example is when code build systems become unmanageable behemoths that add unneeded
complexity to software projects. They are not self-serve, require excessive support from an
external team, and do not actually reduce defect escape rates or increase deployment
frequency. After you have found a good example, describe a solution that involves good
DevOps culture and process. Feel free to be as detailed as you can.

Measuring Everything
Above all else, DevOps emphasizes the importance of measurement. To determine if there has
been improvement, measurement must come first. Good DevOps engineers don't make
changes based solely on "best practices" or what is considered the "right way." They
demonstrate that a change is beneficial through data gathered from measurements.
Measurements can be conducted using various methods, not limited to technology or
automation, although those are preferred approaches. Many companies lack fundamental
DevOps practices and may be unable to provide metrics such as average deployment
frequency. However, it is still possible to derive such measurements using existing data sets.
For example, one could examine commits and merges to mainline branches in git repositories or
analyze audit logs for tasks and stories in the company's issue-tracking system. Production
monitoring data is another potential source. There are numerous places where low-level data is
collected, even unintentionally, that can be utilized to derive meaningful DevOps metrics.

The well-known DevOps metrics, known as the DORA metrics, include deployment frequency,
lead time for changes, mean time to recover, and change failure rate. Each of these metrics has
underlying low-level metrics, but they all contribute to one of these four key metrics. It is
important to consider metrics in everything you do and say. When building something in your
job, you should be able to measure its impact, utilizing well-established and understood DevOps
metrics.

To prepare for upcoming interviews, examine the DORA metrics that align closely with your
work. For instance, if you focused on Continuous Integration and Continuous Deployment
(CI/CD), you likely emphasized deployment frequency and lead time for changes by
implementing testing and deployment automation. If your role was more operational, you might
have focused on mean time to recover and change failure rate. Next, delve deeper and identify
additional metrics relevant to your work. For example, if your efforts aimed to reduce change
failure rates through fully automated deployments, you likely reduced the number of
deployments requiring manual operating procedures. If you developed infrastructure as code to
maintain consistency across different environments, you were lowering the percentage of
configuration drift. Make an effort to identify as many metrics as possible to measure the impact
of your work.

Summary
This book is not designed to impart vast wisdom about the complexities of DevOps. I assume
that you have a working knowledge of DevOps, but I encourage you to think of it in terms of
people, processes, and technology. In addition to those lenses, you should be aware of how to
measure the impact that DevOps has on an organization. The four DORA metrics are the
foundational metrics to which all meaningful DevOps measurements roll up. You should be able
to associate any task that you are performing as a DevOps engineer to one of these metrics. If
you cannot, you are not doing DevOps.

Actions
● Write a one-sentence description of DevOps that you can memorize and recite during an
interview. Be able to explain every word in your statement.
● Research the four DORA metrics and understand what they mean. Be able to explain
each of them in detail.
● Research other DevOps metrics and be able to identify which high-level DORA metric
they correlate to.
● Think through the last thing you did at your job. Write a one-paragraph description of
what you did, which DORA metric it aligned to, how much it improved that DORA metric,
and the business outcome.
Make Your Top Ten List
Chances are, if you are reading this book, you are actively searching for a new job. You could
be currently employed but unhappy. You could have lost your job to a layoff. You could have
resigned because you finally had enough and wanted a fresh start. Whatever your position, you
need to have a plan. And that plan starts with knowing where you want to go next.

In this chapter, I am going to teach you to search for a company instead of a job. I will walk you
through the criteria that you should use to judge a company and determine if it deserves your
attention. After you complete this section, you should have a list of the top ten companies where
you would like to work. A job at any of these is the holy grail of this book and will be my top
priority for you.

Before you just start rattling off big names and your eyes become dollar signs, we are going to
review some criteria that you should use to evaluate these companies. Then you can determine
if they are a good fit for your personality and skills. The prerequisite for any company is that they
have an opening in your physical location or are open to fully remote work with travel
requirements that match your preferences. If there are companies that do not have job
openings, but you really, really like them, you can still add them to the list. Keep in mind that you
may have to wait a long time to land a job in one of those companies, depending on their size
and industry.

Getting Started
What do you like to do when you're not working? Maybe you like to spend time outdoors. Maybe
you are a spiritual person. Maybe you like dogs. Maybe you like playing games. Whatever your
interests are, there is a company that makes products that appeal to those interests. A great
way to start your search is to make a list of all the companies that make products that align with
your interests. DevOps is so ubiquitous in business that almost every company needs someone
with your skills.

The trick here is to be specific. Start by making five major categories of your interests. Then
under each major category, come up with 3 to 5 more specific categories. For example, if you
love dogs, then three subcategories could be dog product retailers, dog trainers, and dog
veterinarians. If you search those keywords along with the keyword "jobs," you will find
hundreds of companies hiring in those niches. Start researching these companies by visiting
their websites and reading their LinkedIn and Twitter posts. When you find one that looks
appealing, make a note of it. You don't have to be very discriminating at this point; just follow
your instinct. Don't worry if the required skills of their job descriptions aren't a perfect match. We
will deal with that later. Record 5 companies under each of the subcategories. When you are
done, you should have between 75 and 125 companies that you will reduce after evaluating the
criteria in the following sections.

Culture
The most important criterion for evaluating a company is its culture. This is what will keep you
motivated and passionate about your work, drive you to grow as an individual, and make you
excited to get out of bed in the morning. It will empower you to deliver value and make you
proud to be part of the greater team. There is an innate human desire to connect with
like-minded individuals around you, and nurturing that desire will bring you immense satisfaction
in your job and your life.
Companies that value culture will put more emphasis on your soft skills during the interview
process. This means that they will want to understand more about how you work and how you
approach problems rather than your technical experience. Technical skills can be learned
through experience and training, while social skills are much more difficult to acquire.
Culture-based companies know this. I recommend this type of company to people who are just
beginning their careers and don't have a lot of technical experience. However, I strongly
encourage everyone to find a company that has a strong culture that aligns with their personal
values. As I said before, culture companies attract a certain type of employee, and you are more
likely to get along with like-minded people, which in turn makes you more productive and
happier.

Culture is an intentional characteristic of a company that is a reflection of its leadership. When

evaluating your potential companies, you will want to research the high-level executives. This
information is typically found on the company website or on LinkedIn. Search the web for their
names and see what kind of information you can find about them. Look them up on Twitter and
LinkedIn and see what kinds of things they post and what they have to say. You may not be
working directly for these people, but they set the tone for the company and select their direct
reports, which then select their own direct reports, all the way down to you. The people that run
the company directly influence the company culture, so knowing who they are is a crucial part of
your evaluation.

Requested Skills
You might have noticed that I have not mentioned anything about the skills requirements in the
job descriptions as a criterion for whether or not you choose a company. This is because I am
going to show you how to use your experience to demonstrate why they should hire you, even if
you don't have the specific skills they need. Now this is not a blanket statement. Obviously, if
you have no experience with a technology like Kubernetes and the job description is specific to
managing Kubernetes clusters at scale, there is no amount of talking you can do to convince a
hiring manager that you are suited for that job on day one. However, if you have experience
running large VMWare clusters, I can teach you to demonstrate how that experience is relevant
to running Kubernetes clusters. And because you have the foundational knowledge, you can
quickly become proficient at meeting the job requirements.

You still need to consider the required skills in the job description as criteria for your company
selection with regard to your salary expectations. If you are not a strong match, you may have to
negotiate a lower starting salary to get the position. This may be acceptable to you if working for
the perfect company is more important than getting a few thousand more dollars a year in
salary. My general rule of thumb is that you should have relevant experience for more than half
of the skills being requested. Job descriptions are usually bulleted, so count each bullet as one
point. If there are 10 bullets, you should have relevant experience in 6 or more. The first bullets
typically carry more weight, so I would add that having relevant experience in the first 3 is a
good idea.

In addition to finding strong matches, I want you to find some companies with job postings that
are beyond your experience level. These could be companies that require more work history
than you have (e.g., 3-5 years of experience with a skill or technology where you only have 1-2)
or require skills with which you have little or no experience. Make special note of these positions
by using a star or different text color to list them. We will call this the "Practice List." If you come
across job descriptions that you are overqualified for or have a low salary range but still look
interesting, you should add those too. We are going to use these positions to practice the skills
we learn in the next chapters.
Size
Micro companies typically consist of 1-6 employees and are often startups. They operate in
high-paced, high-stakes environments where each employee carries multiple responsibilities. As
a DevOps engineer in a micro company, expect to work long hours with interruptions on nights
and weekends. DevOps engineers are sought after in these companies as they require
individuals who can handle various tasks. Due to the demanding nature of the role, you can
negotiate a higher salary. However, be prepared to accept a higher risk due to potential
instability or the viability of the company. Work-life balance may be compromised, and burnout is
a risk. Executive stakeholders in micro companies tend to be emotionally driven, expecting the
same from others. The main advantage of working in a micro company is the exposure to the
business growth process. Through direct interaction with executives, you will learn how the
company operates as a business and gain insights into financial aspects, making it invaluable
experience for future entrepreneurs. This type of company is recommended for engineers who
are single, comfortable working odd hours, able to handle intense production support situations,
looking for financial advancement, or have aspirations of starting their own company in the
future.

Small companies are typically startups that have either progressed beyond the initial stages or
established companies that have found a profitable operating equilibrium. In small companies,
you can expect a higher level of specialization in your role compared to micro companies. As a
DevOps engineer, you may work as part of a software development team or focus solely on
writing infrastructure code. While some cross-discipline work may exist, it is less prominent.
Small companies offer greater flexibility for lateral and vertical movement within the
organization, allowing you to experiment with different job roles and technologies to gain
experience. Small companies funded by external investors, such as venture capitalists, can offer
competitive salaries and benefits. Established small companies that do not rely on external
investment may offer less competitive salaries, but they have proven financial stability over time.
Externally funded small companies are recommended for engineers who are single, comfortable
working odd hours, seeking job role flexibility, desiring opportunities for lateral and vertical
growth within the company, and looking for financial advancement. Established small companies
are recommended for engineers who are single or married, starting or have a family, enjoy close
companionship with coworkers, and prioritize work-life balance.

Medium companies encompass a mix of advantages and disadvantages from the previous
company sizes. Compensation will be average, but lateral and vertical movement may be more
challenging. The most noticeable difference in medium companies is increased bureaucracy.
Scaling from a small to medium-sized business requires implementing more business
processes, which can impede value delivery due to additional checks and balances. Expect to
encounter new workplace vocabulary such as "separation of duties" and "least privileged
access." Experimentation may be restricted, and barriers to communication between teams can
increase. The tradeoff is that medium-sized companies generally expect less value delivery per
employee compared to small companies, resulting in a less intense work environment with more
relaxed deadlines. However, missing delivery dates may have more catastrophic consequences.
Due to the company's size, employees may feel less motivated to deliver value as they may not
see the direct impact on customers. Medium-sized companies also tend to exhibit the 80/20
rule, where 20% of the people do 80% of the work. Some coworkers may be present solely to
collect a paycheck. If working in a medium-sized company, you need to be comfortable with this
fact. Medium companies are recommended for most individuals, as there is sufficient cultural
diversity to find a company that suits one's preferences. People who may not thrive in
medium-sized companies include future entrepreneurs, those who dislike bureaucracy, office
politics, working with disengaged colleagues, or those seeking higher-than-average salaries.
Large companies and enterprises share similar work perspectives as medium sized companies,
with the distinction being that enterprises can absorb financial losses during economic
downturns more easily. Large companies often carry high leverage (debt) as they aim to grow
into enterprises. They are typically publicly traded and subject to significant regulatory
compliance requirements. Expect red tape in almost all aspects of work, including annual or
quarterly training, complex time card systems, status reports for deliverables, and a
considerable amount of time spent in meetings. In return, the job itself tends to be less
demanding, with longer timelines for implementation. These companies prioritize adherence to
protocol over technical deliverables. Salary expectations are average, but larger companies
usually offer comprehensive compensation packages, including retirement accounts with
matching contributions, health savings accounts, and other perks compensating for the lower
base salary. Large companies are recommended for individuals who are financially stable (own
a home, have savings, limited debt), aged 35 or older, have families (married with children), and
seek work-life balance. Entrepreneurs looking for jobs with contained responsibilities during
regular business hours to allow time for their own business ventures outside of work hours may
also consider large companies.

Financing
It is extremely important that you understand how a company you want to work for pays its bills
(most importantly, your paycheck). Without going into the intricacies of corporate finance, I will
provide a brief overview. There are private companies, and there are public companies. Private
companies do not offer their stock to the public, whereas public companies do. This means that
public companies have a fiduciary responsibility to their shareholders, which are made up of
potentially millions of people. Publicly traded companies value their stock price above all other
things, including their employees.

Private companies' stock is owned by the founders, angel investors, venture capitalists,
company employees, and other private investors. Private stock is typically granted as a perk for
being an advisor to the company, an investor, or an exceptional employee. Stock is a form of
equity, but companies can also be funded through debt, which takes the shape of loans from
banks or other financial institutions. Smaller companies tend to raise capital through equity,
whereas larger companies introduce debt in addition to equity. Why is all of this important to
you? It's important because you need to know the financial position of your employer to
determine the level of risk you are taking on by working for them. Companies that have high
growth requirements to reach profitability are riskier to work for in an economic downturn. Their
investors will force them (either through vote or through pressure) to reduce costs (i.e., fire
people) when their negative cash flow becomes too much of a burden (i.e., they are burning
through their investment capital too quickly). These types of companies will offer higher salaries
in return for the risk you take by working for them.

When researching companies, you should perform due diligence into their financial structure
and determine the level of risk you are willing to take. For those of you that are living paycheck
to paycheck and have little or no savings, I recommend a company that is cash flow positive
(i.e., they are profitable) and has a 5+ year track record of consistent or growing revenue and
profit margins. Some of this information is available if the company is public, but for private
companies, you will have to perform some research by yourself. Websites like Crunchbase offer
this kind of information for free but will provide more information if you sign up for an account.
Again, part of having a plan is about having the necessary data to make an informed decision.
Finalizing The List
After reading through the above sections, define the ideal company you want to work for in
terms of those criteria. For example, you want to work for a medium-sized company that has a
strong culture, is privately owned, and is currently profitable. Now go back to the website and
LinkedIn profiles of each of the companies you wrote down and begin re-evaluating each one
through that lens. Cross the ones off the list that do not meet your requirements and reduce the
list as much as possible. You will likely end up with many more than 10 companies, even after
you narrow them down with your requirements, but that's OK. Continue to look at the list on a
daily basis and organize it from most interesting to least interesting. Follow the companies on
social media and allow their posts to influence how you think of them. It will take some time, but
certain companies will float to the top. The companies that gravitate towards the bottom can be
used for practicing your skills.

Summary
Before going into battle, you should have a plan. Searching for a job is no different. Having a top
ten list of your preferred jobs and companies will bring you focus and provide solid data to build
your resume. It also gives you a more specific goal than just "getting a job," which will motivate
you on a daily basis. To find your dream job, you need to know what kind of company you want
to work for. Use culture, required skills, size, and financials as your criteria to evaluate
companies. Then determine if they are the right fit for you.

Actions
● Make a list of your five major categories of interest. Under each major category, come up
with 3 to 5 specific categories. Search those keywords on the web and record 5
companies under each subcategory that appeal to you and fit your criteria.
● Reduce your list as much as possible using the criteria you learned in this chapter.
Spend time reading through the company websites and their LinkedIn profiles and posts.
Discriminate as much as possible.
● Prioritize the list from most interesting to least interesting.

Build an Unforgettable Resume

I am going to completely change how you think about resumes in this section. Having read
literally thousands of resumes, I have learned what grabs the attention of recruiters. You must
begin thinking in terms of delivering business value. Demonstrating that you understand the
connection between the solutions you build and the business value they deliver will separate
you from the pack immediately. This is not just something you should do to write a great
resume; it is a mindset that you should use in everything that you do at your job. If you can't
explain the business value associated with your actions, you shouldn't be doing it. Asking these
questions of your manager will also show them that you are more than just an engineer; you are
a business person. DevOps is a multidisciplinary fusion of business, technology, accounting,
and human resource management. You must understand how all of these intersect and, most
importantly, translate to value. Once you grasp this, writing your resume will be easy.

The lessons here will also be used in the "Bringing Opportunities to You" chapter. They will form
the foundation needed to develop your interviewing skills. I will focus primarily on content but
first need to touch on formatting and layout to define some helpful guardrails.
Formatting and Layout
Recruiters are tasked with reviewing hundreds, if not thousands, of resumes, which often leads
them to become lazy and impatient. Their primary objective is to filter resumes quickly by
visually scanning for keywords. If they cannot find the desired keywords within the first five
seconds, they will move on to the next resume. It is crucial to understand that recruiters rarely
read resumes from beginning to end or even complete full sentences.

To capture a recruiter's attention effectively, I recommend keeping your resume concise, limiting
it to no more than two pages. If you have an extensive work history, focus on the last five years
of experience. If your resume extends to a third page, it is highly unlikely to be read, and any
important content on that page may be overlooked.

To begin, the header section should contain the following information: your name, your email,
your phone number, your city and state, and the link to your public GitHub profile. I recommend
using 18 to 24-point, bold font for your name to make it stand out. Use 10 to 12-point, regular
font for the rest. Adding your GitHub profile link is very important. Most resumes I see do not
contain a link to a GitHub profile. When I see one, it tells me that the candidate knows how to
code (otherwise, they wouldn't be sharing it) and that they contribute to open-source projects.
Most importantly, they are proud of the code they write, putting it on public display for everyone
to see. More on this in the "Bring Opportunities to You" chapter.

Below the header, I recommend breaking your resume into four sections: an objective,
education and certifications, a skills list, and, lastly, experience. Human psychology plays a
heavily in consuming a resume. The use of bold, underlined, or all-caps text can be leveraged to
focus the attention of the reader. Each section header should be in all caps, bold, and
underlined, but in the same size font as everything else. I recommend an extremely boring Arial
or Times New Roman font at 10 to 12-point size. Do not get creative with fonts. Use the
standards. Any additional cognitive strain that you impose on the reader will likely be met with
frustration or impatience. Use the larger font size if you need to fill the two pages. If you are
having trouble fitting everything into two pages, go smaller.

The objective statement is a long sentence that quickly describes you and what you want to
achieve in your career. A good example of this is "Successful entrepreneur and consultant with
25 years of industry experience looking to be a key contributor in the digital transformation
journey of a company by introducing DevOps strategies in culture, process, and technology" or
"I am a forward-thinking, business-centric, DevOps engineer and cloud architect looking to be
challenged in a high paced environment and to build solutions that deliver high business value"
A bad example is "Excited to find a DevOps role where I can use my skills." This statement will
be the first thing that people read on your resume, so put some serious thought into it. You want
to create a personal connection by describing what motivates you and communicating what you
want out of a job. More examples can be found in the appendix.

The education and certifications section should list your highest level of education received, as
well as the month and year you received it. Also, list any certifications that you have attained
which are currently active. Try to minimize white space in this section as much as possible. If
you have multiple certifications, use a comma-delimited list instead of bullets. Put cloud platform
certifications first.

The skills section lists the relevant soft and hard skills you possess. These should be broken
down into the following categories: Cloud Providers, Infrastructure as Code, CICD,
Containers/Serverless, Observability/Monitoring, Scripting/Programming Languages, Operating
Systems, and Configuration Management. If you don't have skills in one of these areas, you can
remove it. But you must include Infrastructure as Code and CICD, as these are the foundational
concepts of DevOps. If you lack those skills, take an online course so you can list them
honestly. In later chapters, we will talk about how to respond to questions regarding your lack of
experience with certain technologies.

If there are other major areas that you think are relevant and in which you have experience,
then add them. But these are the main areas that recruiters will be seeking. Format this section
into two columns to condense the white space. Use bold type for the category names. Limit
each section to no more than three items. Those items should be the skills with which you have
the highest level of mastery unless you are applying to a company in your Top Ten list. In that
situation, list the required skills from the job description that you possess at the top of the list in
each category, regardless of your mastery level. Listing it first is interpreted by the reader as
being the most proficient.

There is only so much you can do to get a job requiring extensive Python knowledge if you've
never written a line of Python. I do not recommend lying on your resume or listing technologies
that you have never used. But that is not to say that you can't list a technology with which you
only have limited experience. In the research you did earlier in the chapter "Make Your Top Ten
List," you likely came across a pattern of specific technologies that most companies were asking
for. If you don't have experience with them, you should sign up for a training course or get a
certification. Once you have done that, feel free to list them on your resume in the skills section,
but be prepared to answer the question, "Why do I not see XXX listed anywhere in your
experience?". We will talk about how to answer that question in the "Interviewing" chapter.

Ideally, the objective, education, and skill sections should take up no more than two-thirds of the
page. This should leave enough room for you to display the first item of your experience section
entirely on the first page. Don't worry if it runs onto the second page.

The experience section is simply a list of your previous jobs and a description of the solutions
you have built to deliver business value. List the company name in bold and all caps, followed
by a comma and then your job title. The duration of your time with the company in a three-letter
month and full-year format should be on the same line, aligned to the right. A full example would
be:

ACME INC, Senior DevOps Engineer Nov 2018 - Aug 2021

Most resumes you see will have a bulleted list of accomplishments you achieved or
responsibilities you had at the job, but I am going to break from the pack on this one. Let me tell
you why. Most recruiters stop after the skills section to determine if you are a potential fit. At the
most, they look at the start date of the oldest job listed in the experience section to understand
how long you've been in the workforce. But the people that actually read your experience
section are going to be more thorough and will likely be conducting a phone screen or interview.
Bullets do not read naturally to a human. A standard paragraph with full sentences is easier to
read, consume, and understand. I recommend that you write a one to two-paragraph story using
thoughtful sentences. Highlight the specific technologies from the skills sections by making them
bold. This ties the skill in the reader's brain back to what they saw in the skills section. This is a
psychological tool called "priming," and it will imprint on their brain that you know the skills they
are looking for. Bold font to call out specific skills, along with the paragraph style format, will
make your resume unforgettable to the reader. Let's talk about what you should say in those
paragraphs.
Content
There are three kinds of resume readers: a person with little technical experience that is trained
to find candidates through keywords and phrases (a "Keyword Screener"), a person with
technical experience whose job it is to determine if a candidate is worthy of an interview (a
"Technical Screener"), and a "Hiring Manager." Each of these people reads your resume
differently. You will encounter varying combinations of these types of people depending on the
size of the company you are pursuing. For example, in a small company, the Hiring Manager
may screen all the resumes, conduct all of the phone screens and interviews, and make the
final hiring decision. In a large company, however, there may be one person doing the keyword
screening, one doing the phone screen, four conducting interviews, and a hiring manager
making the final decision. Your resume has to function properly in any of these scenarios.

Keyword screeners search for keywords. They may possibly float down into the experience
section, but it will only be to scan for keywords. The keywords they are interested in are simply
the technologies or languages that the company lists in the job description requirements. The
"Skills" section of your resume contains all the keywords that these screeners will need to
determine if you are a match. By highlighting those same skills in the experience section, you
make it easy for them to see that you have the necessary skills and experience using them.

Technical screeners want to understand how you have implemented a specific technology at a
previous employer. They want to see enough detail in your resume demonstrating your skill
knowledge. To do this, you need to tell them the whole story but in a concise way. An example
of this would be:

“Acme, Inc wanted to automate the deployment process of their application on

Kubernetes. I recommended the use of ArgoCD and built a proof of concept in two
weeks that used a GitOps style approach to manage Helm values files for various
environments, then deployed simple applications into a development environment.”

There are multiple things happening in this example. First, Kubernetes is highlighted as the
primary technology being implemented. Second, ArgoCD, GitOps, and Helm are listed as
supporting technologies or processes. This lets the technical screener know that you have used
the primary technology in conjunction with other, more specific supporting technologies. Third,
language like "I recommended" and "proof of concept" demonstrate a connection to business
concepts. You want to convey that you are not just someone who types on a keyboard but
someone who understands how to apply technology to achieve a business outcome. A technical
screener will likely be working with you on the same team if you are hired. They want to know if
you will make their life easier. The words "I recommended" mean that you took the initiative to
improve something and applied your knowledge to make it better. The words "proof of concept"
show that you know how to conduct an experiment in a controlled way to validate your
recommendation. Both of these things demonstrate your independence and your desire to
improve existing solutions.

Hiring Managers are the final gatekeepers to getting an offer. They will only make you an offer if
they think that you will make their life easier or you will make them look better by producing
results. If a Hiring Manager thinks that you will in any way fail to deliver on one of those two
things, you will be passed over for the opportunity.

To make their lives easier, you must demonstrate that you can independently operate with little
input. Using our previous example, the words "I recommended" send a powerful message that
you took the initiative to make a change to something that you determined was suboptimal. The
words "built a proof of concept in two weeks" let the Hiring Manager know you understand the
value of small, controlled experiments and how to organize and execute an experiment.
Carefully chosen phrases like "I recommended," "demonstrated through data," and "took a day
to research alternatives" shows that you know how to operate independently. They also show
your desire to improve existing technical solutions and day-to-day operations. Other phrases I
recommend using are "I initiated a SPIKE," "I defined an experiment to measure the potential,"
"I turned a process into a mechanism," and "I integrated a solution into the overall business
strategy."

Above all else, Hiring Managers are most interested in business outcomes, which makes them
look better to their managers. To accomplish this, you have to demonstrate that you have
delivered tangible business outcomes and that you can articulate those business outcomes with
data. Going back to our example, there is no definition or measurement of the business impact.
It only says that the proof of concept was completed by deploying some applications into a
development environment. Even if this proof of concept never made it to production, a number
could still be used to define the potential for improvement. Start with the DORA metrics and drill
down into low-level metrics where appropriate. The candidate could say, "This solution proved
to be faster than the previously used manual process and reduced total deployment time by
93%," or "This solution took total deployment time from hours to minutes." The first is better
because it is a specific number, but the second still has a substantial impact. When using
specific numbers, be prepared to defend the math that was used to calculate them. But let's not
stop at that. There are other metrics that were potentially improved in our example, such as
change failure rate. You could add "and also reduced change failure rate by 57%". Use bold font
to highlight the metrics "total deployment time" and "change failure rate" to further drive the point
home. The whole example then becomes:

"Acme, Inc wanted to automate the deployment process of their application on

Kubernetes. I recommended the use of ArgoCD and built a proof of concept in two
weeks that used a GitOps-style approach to manage Helm values files for various
environments, then deployed simple applications into a development environment. The
solution proved to be faster than the previously used manual process and reduced total
deployment time by 93%. It also reduced change failure rate by 57%."

These two final sentences are exactly what hiring managers are looking for in a resume. They
demonstrate measurable results and showcase the candidate’s ability to think in business
terms. Hiring managers will read this and immediately think about how they can leverage you to
get the same kinds of results in their business, which is exactly what you want.

I cannot stress the importance of good content enough. The language that you employ in your
experience section is crucial to getting a phone screen or first interview. You must use
terminology that showcases your ability to use technology and how to use it to deliver business
value. After all, we do not implement technology for the sake of implementing technology; we
implement it to deliver business value that the company uses to grow.

Summary
The order of the information presented on your resume is extremely important. Format your
resume into four sections: objective, education, skills, and experience. Clearly articulate your
objective as a DevOps engineer in one to two sentences. List your highest level of education
and any active certifications. Organize your skills section into the following categories: Cloud
Providers, Infrastructure as Code, CICD, Containers/Serverless, Observability/Monitoring,
Scripting/Programming Languages, Operating Systems, and Configuration Management. List
your top three skills in each category in order of proficiency.

In the experience section, use paragraph style to describe how you applied your skills to build
technical solutions that delivered business value. Tell a story to the reader. Use bold to highlight
the relevant skills and technologies. Describe the positive impact that your solutions had using
the DORA DevOps metrics or other low-level metrics.

Actions
This entire chapter is a list of actions. Follow them to build your resume.

Bring the Opportunities to You

Life has a funny way of tossing things in your lap from time to time. If I look back at my career, I
can trace many events to something completely out of my control and entirely by chance. There
is a famous quip "Luck is when preparation meets opportunity." This section is about being
prepared for when that opportunity comes along, and you get "lucky."

Despite what most people think, there are other ways to find jobs without spending countless
hours applying on job posting sites. Several of the positions I have had over the years fell into
my lap through referrals from friends or colleagues, recruitment from LinkedIn, matches from job
posting sites, and even from my contributions to open-source projects on GitHub. This is the art
of passive job acquisition.

I will show you three specific ways to bring the opportunities to you. The first is to build your
network and skills on LinkedIn. The second is to game the job posting sites so that they will
work for you instead of the other way around. The third, public GitHub contributions, is the most
commonly overlooked way to get attention while also building your skills. These three areas not
only help bring you potential job opportunities but can also be used when actively seeking a
specific role. Lastly, I will talk about training and certification. While not a direct way to passively
acquire jobs, it is an enabling property that will bolster your resume.

LinkedIn
The statistics on LinkedIn are mind-boggling. It is by far the most useful tool for professionals
looking to interact with other professionals. It provides a way for you to build your brand
because, ultimately, getting a job is about selling yourself. Tens of thousands of recruiters are
searching for candidates on LinkedIn on a daily basis. If you do not already have a free LinkedIn
account, create one immediately. Follow the instructions to build your profile. Once completed,
begin to build your network by sending invitations to all the people you have previously worked
with. Don't go too crazy here yet; just get 20 or more people in your network, then move on to
the refinement sections below. LinkedIn offers a paid service, which is not required for the tasks
I will lay out in this section. If you choose to pursue the paid service, it is entirely up to you.

Let's talk about brand management for a second. Selling yourself is about crafting a story that
people can easily consume to learn about you. LinkedIn breaks this down into three categories:
experience, skills, and recommendations. The experience section is a listing of your previous
work experience. The skills section lists acquired skills and has a feature allowing others to
endorse you for those skills. Recommendations are free-form endorsements that are authored
by customers or previous managers. Let's talk through each.
The experience section is a condensed version of your resume. Each company where you
worked and each position you've had is listed in chronological order. Your title at each and the
skills you used are displayed for others to see. You should keep each description concise but
provide enough detail to be meaningful. Start with the description you put in your resume, then
pair it with my recommendations below. The goal is to grab a recruiter's interest so that they will
send you a connection request and ask you for your updated resume. This will build your
network and allow you to follow up directly with recruiters actively searching for candidates that
match your skill set.

An example of a bad job summary:

Responsible for writing Terraform to deploy infrastructure on AWS.

An example of a good job summary:

Used Infrastructure as Code to deploy ephemeral cloud test environments, which
increased development velocity.

The difference with a good example is that we used ambiguous terms like "Infrastructure as
Code" instead of Terraform and "cloud" instead of AWS. Recruiters know that "infrastructure as
code" could mean Terraform, CloudFormation, or another IaC framework. They also know that
"cloud" could mean AWS, GCP, or Azure. You want to use words, phrases, and data that
resonate with recruiters and hiring managers. The last sentence used a DevOps metric,
"development velocity," and a modifier, "increased," to demonstrate the delivered business
value. Unlike in resumes, I do not recommend using numbers on LinkedIn summaries. In fact,
you want the summaries to be as concise and easy to read as possible. Numbers invoke a
higher brain function. This requires recruiters to slow down to understand, which is not
desirable. You want them to come to the conclusion that you are a strong candidate without
even having to think about it. This is not a trick or a fallacy; it is simply a method of presenting
your skills in a way that catches their attention easily.

You can also add skills directly to a job role in the experience section or enumerate them in the
skills section of your LinkedIn profile. I recommend that you cast a wide net with skills, but this
comes with a caveat. If you have so many skills that a recruiter cannot easily find the ones they
are looking for, then they will move on to the next profile quickly. Skill keywords are the most
common way that recruiters search for profiles, so be sure to include the major keywords like
"DevOps," "SRE (Site Reliability Engineer)," and "CICD (Continuous Integration, Continuous
Delivery)." Use the research you did in the "Make Your Top Ten List" chapter and the next
section about Job Posting Sites to identify skills that are common across many of the job
descriptions you found. If you possess those skills, make sure to include them on your LinkedIn
profile. In addition, add skills directly to your previous job roles in the experience section.
Choose the top three skills you used in each previous position and add them to that role by
editing the entry directly. Do not add more than three. It will make your experience section too
busy and overwhelming. Humans are inherently lazy, and if your profile looks like a lot of work to
consume and digest, recruiters will skip it.

Once you are satisfied with your skill list, the real work begins. In the "Build an Unforgettable
Resume" chapter, we discussed using a skills section to quickly highlight the skills you have.
The recommended categories are Cloud Providers, Infrastructure as Code, CICD,
Containers/Serverless, Observability/Monitoring, Scripting/Programming Languages, Operating
Systems, and Configuration Management. You will need to get skill endorsements for at least
one skill under each of these categories. The easiest way to do this is to ask people in your
network that you know and have worked with to endorse a specific skill. In return, offer to
endorse their skills. Ideally, you want people that are "highly skilled" to endorse you for the same
skill, which carries more weight. But if you don't have highly skilled people in your network, then
just focus on getting the endorsements. Ideally, you want 10 endorsements for one skill under
each category, which comes out to 80 total endorsements. This will take some time, but don't
consider it a blocker to move on to the next sections. Make a goal to get one skill endorsement
every day.

The last section of LinkedIn is the recommendations section. These are freestyle endorsements
written by other people about you. They can be about anything, but you want them to be
specific. Do not collect recommendations from your peers. Your peers should endorse your
skills. Recommendations should come from previous managers or customers you worked with
directly. Customers can also be other internal parts of a large organization. The point is to not
collect recommendations from peers you worked with directly on a regular basis. To help people
write recommendations on your profile, you should suggest a situation where you went above
and beyond to deliver business value through DevOps. For example, you can message your
previous manager and ask, "Could you please write a recommendation for me on LinkedIn? I
can remember a time when I delivered a solution that improved the development team's velocity
by automating their functional testing in the code pipeline and reducing their defect escape rate.
You could write about that or another DevOps solution I delivered while working for you." This is
a simple request and reminds them of a specific action that you took and a specific outcome,
along with a DevOps metric. The person only has to write a couple of sentences, and you just
gave them one they can pretty much copy and paste. I recommend a minimum of three
recommendations, but the more you have, the better.

To recap, the purpose of your profile on LinkedIn is twofold. First, you want to show up in
keyword searches from recruiters. Second, you want to provide enough information to entice a
recruiter to request a connection and ask for your updated resume, where you can control the
delivery of the content more meaningfully. You accomplish both of these things by building your
skillset and collecting endorsements from your peers, writing meaningful descriptions of your
role that include the delivered business value, and collecting recommendations from your
previous managers and customers to drive your value home. Lastly, when applying directly for a
position, your LinkedIn profile will validate what is on your resume and show to a hiring manager
that you have a large, healthy network and are endorsed by others. Most of the time, this is all
they need to give a thumbs up to a phone screen, which is your chance to really control the
narrative in your favor.

Job Posting Sites

This might sound funny, but I recommend using job posting sites primarily as data sources.
Secondarily, they can be used for passive job opportunity acquisition. These sites are nothing
more than giant keyword and metadata-matching engines. But this correlative action allows you
to see what companies are asking for and stay aware of how the job landscape changes.
Because DevOps is evolving on a daily basis, it is important to keep up with all the new trends
in the industry. One great way to do that is to see what companies are asking for in the desired
skills section of their job descriptions.

Just as with LinkedIn, recruiters are constantly trawling job posting sites for candidates. I
recommend that you have an account with an updated resume on Indeed and ZipRecruiter.
Both of these sites have automated resume parsing software that will take your resume in either
PDF or Word doc format and attempt to parse the content to streamline the resume ingestion
process. Upload your newly created resume. Then follow their step-by-step process to make
sure all the sections get parsed correctly and that all your skills are represented accurately.
Each site has an additional refinement step that allows you to convert your resume to its specific
format. You must complete this step on both sites to maximize the job suggestions that match
your skill set. It may seem like a long and tedious process, as well as feeling like writing your
resume twice, but the return on investment is well worth it. Job posting sites value some
keywords over others. They use trend analysis to provide suggestions to recruiters when
building job posts to increase the number of strongly correlated matches. Using their format will
leverage their preferred keywords and matching algorithms. It will also bring you loosely
correlated recommendations based on trends for similar jobs. This is the data that we want.

These action items should take you less than a day to complete. You will begin getting
numerous emails from these sites when you are done. You may also notice that you start
receiving marketing emails from other job posting sites, as well. This is a good thing, but be
aware that you are now being watched very closely. Each job posting email that you receive will
have links that these companies use to "learn" more about you and to expand your job search
preferences. When you click on a link for a specific job, they record this action and refine your
preferences accordingly. I do recommend that you click on jobs that look interesting to you. Just
be aware that these companies are slowly building matching profiles for you. Finally, when you
log into any job posting site, you should be able to see your search preferences. Check on
these once a week to see how things have changed and to make sure you are not getting too
much "noise." If the matches you are getting are not relevant or interesting to you, adjust the
match settings accordingly.

GitHub Contributions
I cannot stress how valuable it is to share code you have written with a potential employer. As I
stated in the "Build an Unforgettable Resume" chapter, having your GitHub profile in the header
of your resume says a lot about you without having to read another line. Some companies do
live coding exercises as part of the interview process. I have found these to be incredibly
inaccurate in determining a person's development capabilities. In fact, I have personally failed
several coding exercises in interviews but still got the job because I was able to provide public
code examples that demonstrated my abilities. That experience is why I strongly recommend
that you have an active GitHub profile.

The actions here are going to be more difficult for some than others. It is important to be
extremely selective of the code that you share with the public. It should be pristine in every way.
This means that you want to follow all the best styling practices, have extensive READMEs,
have integrations with free CICD systems like TravisCI, build robust tests, use repo badges to
display test status, and use trunk-based development methodologies (i.e., don't push your
changes directly to master/main branches). Just as if you were a photographer wanting to
showcase your best work on your website, your GitHub profile should be a representation of
only your best work.

Another thing I look for in a GitHub profile is how long someone has been contributing to the
open-source community. If you have never contributed to a single public project before, there's
only one thing you can do about this: start now. But don't worry if you do not have a long history
of GitHub contributions. Use this opportunity to begin the process.

Your action here is to find some open-source projects you have used and look through their
GitHub issues lists. Think of the tools that you use on a regular basis. Almost anything in the
Apache family, Hashicorp product line, or open-source CICD frameworks are good choices. Any
open-source project that is relatively known in the DevOps world will suffice. Most of the
READMEs in an open-source code repo have a "Contributing" section with details on how to
help the project. Different projects handle things in different ways, so you may want to reach out
to one of the project owners and ask for guidance. Find one that allows you to select an open
issue that is ready for development and assign the issue to yourself. Complete the feature or
task in the issue, then submit a PR for review. Start with small undertakings and then move to
more complicated issues. As you become more familiar with the code base, the development
will go faster, and you'll have more complex code commits to showcasing your skills.

GitHub contributions are also a great way to gain experience in a language or technology that
you don't have from previous work experience. This is the path I recommend for building skills
you do not possess but are being requested by your Top Ten List companies. It will also help
you build your network on LinkedIn. After you get a few PRs successfully merged, send a
connection request to some of the project owners and ask them to endorse the skills you used
to contribute. Open-source project owners typically have very high standings on LinkedIn, so
their endorsements go a long way. Be sure to point out these specific endorsements during your
interview process.

Training and Certifications

If you are new to the DevOps scene and are just getting started in your career, I recommend
pursuing a certification. There are a couple of reasons to do this. First, it's a great way to
become educated about a technology you lack experience with. While memorizing facts is no
substitute for experience, these facts expose you to a wide range of capabilities for a given
technology. By knowing these capabilities, you will be able to quickly apply these technologies
without extensive trial and error in your next role. You will be able to identify use cases and
integration points that you would not be able to do without that foundational knowledge. And
let's face it, you're going to be looking things up with a search engine anyways, so assembling
the keywords to find what you need is the most important skill.

The second reason to have a certification is for individuals that are seeking jobs at consulting,
professional services, or managed services providers. These companies form strategic
partnerships with cloud providers and software vendors as a way to get plugged into their sales
funnels and generate work contracts. Those preferred partnerships have certification
requirements, which means they must meet a certification quota to access certain clients from
that cloud provider. Every single one of those companies takes certifications very seriously,
often completely reimbursing their employees for these very expensive certifications. If you
currently work at one of these companies, you should take advantage of this perk before
departing. If you want to join one of these companies and don't have a certification, immediately
get one from one of the three major cloud providers. When it comes down to making a decision
on a candidate with similar skills, these companies will always choose the candidate with the
cloud certification first.

Summary
You don't have to actively search for and apply for jobs to secure one. There are multiple ways
to expand your network and have job opportunities come to you directly. Building your profile
through social networks like LinkedIn, collecting endorsements, and requesting
recommendations can be beneficial. Recruiters use LinkedIn daily to find potential candidates,
so having a well-developed profile increases the likelihood of being discovered.
Job posting sites offer another avenue to passively find job opportunities. By uploading your
resume to platforms such as Indeed and ZipRecruiter, and refining the content according to their
preferred layout and structure, you can expose yourself to numerous opportunities without
exerting much effort. Additionally, these services provide valuable insights into the skills
companies are seeking through their recommendations and matching engines. You can use this
data to enhance your resume, prepare for interview questions, and stay updated on the latest
technology trends.

Strengthen your contributions to open-source projects on GitHub. Providing code examples to

potential employers is invaluable and can spare you from the burdensome coding exercises that
some companies impose. Having this as a backup plan can actually improve your performance
during live coding exercises by reducing your stress levels. GitHub contributions also offer an
opportunity to learn new languages and technologies even without prior experience. If you come
across highly sought-after technologies during your job search that you haven't used before,
contributing to open-source projects is an excellent way to learn and showcase them on your
resume. Moreover, you'll have the added advantage of expanding your LinkedIn network by
connecting with esteemed open-source project owners and receiving their endorsements for
your LinkedIn skills.

Actions
● Create a free LinkedIn account if you don’t already have one.
● Complete your LinkedIn profile by completing the skills and experience sections.
● Request skills endorsements from peers and colleagues.
● Request recommendations from previous managers and customers.
● Post your resume on Indeed and ZipRecruiter.
● Polish the Indeed and ZipRecruiter resumes by following their format and suggestions.
● Sign up for job recommendation emails from Indeed and ZipRecruiter. Click on ones that
look interesting in their recommendation emails to train their algorithms to find other
similar jobs.
● Create a GitHub account if you don't already have one.
● Find an open-source project to which you want to contribute.
● Read the contributions section of the open-source project README and follow the
instructions to begin contributing.

Mission: Land a DevOps Job

You are now ready to actively apply for job postings. You should have a solid resume, a
LinkedIn profile with endorsed skills and recommendations, some recent contributions to some
GitHub open-source projects, one or more certifications, and a positive attitude.

Where to Start
Most people assume that their technical skills and experience will secure them a job. While
these factors do play a crucial role, what ultimately lands you a job is your interviewing skills.
Just like the skills listed on your resume, you can develop interviewing experience through
practice. Unfortunately, many people only practice this skill a few times in their lives, and worse,
they only do it when they are in a desperate position of needing a job.

I make it a point to stay informed about current job postings. Before I became heavily involved in
hiring processes, I used to apply for interesting jobs at least two to three times a year,
regardless of my satisfaction in my current position. You would be amazed at how much better
you become at interviewing when you don't desperately need the job. It completely changes
your demeanor and allows you to genuinely enjoy the interview process. I recommend this to
everyone, regardless of their current job status, as it is the best way to practice interviewing
skills in a low-stress manner.

However, you are most likely reading this book because you are in need of a job. So, for
practice, I suggest completing at least one official interview at another company before applying
for your dream job. In the chapter "Make Your Top Ten List," we created a "Practice List" of
companies that may not be ideal but still meet your criteria. Retrieve that list and identify some
companies that currently have job openings. Start by applying to these companies. This
exercise serves two purposes: first, it provides you with interview practice, and second, it gives
you an actual job offer. Receiving an offer will have a significant positive psychological impact
on your job search for the Top Ten List. It will demonstrate the effectiveness of your process and
serve as a fallback option if you are unable to immediately secure your ideal job. If you are in a
challenging financial situation, I recommend accepting an offer from a lower-paying position or a
less-than-ideal company. This will alleviate any financial stress that might hinder your
performance in interviews for your perfect role.

There are two types of jobs for which I recommend applying. Jobs below your experience level
are more likely to grant you practice interviews. They provide an opportunity to test your
prepared answers and gauge the kind of responses or questions you receive. While these
interviews are valuable, they won't give you practice in dealing with discomfort or adjusting your
answers quickly to address questions about your lack of specific skills. Jobs that are slightly
above or beyond your experience level should make you feel uncomfortable and anxious.
Practicing these situations will help you learn to control your emotions and become accustomed
to performing under pressure. Interviewers are also likely to challenge your experience level and
ask more difficult questions, which will strengthen your responses and provide you with
examples to prepare for. If you go too far beyond this range, it is unlikely that you will receive a
phone screen or an interview.

Start applying for one or more available positions at the non-ideal companies you identified
while creating your Top Ten List, and observe the responses you receive. As I mentioned earlier,
I recommend completing at least one interview before moving on to your Top Ten List, but the
more interviews you undertake, the better prepared you will be for the pivotal moment.

Lastly, some employers may notice the quick transitions you have made or the fact that you
recently started a new role. If this question arises, I suggest being completely honest. Explain
that you were in a challenging financial situation and needed a job quickly. Share your reasons
for appreciating your current company but express your longstanding aspiration to work for the
new company. When you saw an opportunity had opened up, you eagerly pursued it. This
genuine and compelling story is something that any recruiter or hiring manager would
appreciate hearing.

When to Apply at Your Top Ten List

You may think you are ready to start applying to your Top Ten List if you have completed a
practice interview. You may feel completely comfortable doing interviews. You may have already
written an amazing cover letter. You may think that your Top Ten List companies are just sitting
there, waiting to beg you to join them. You may be right about all of these things, but I have one
last task before you apply to your Top Ten List: get a job. Wait, what? You're probably saying, "I
thought the whole point of this book was to get a job on my Top Ten List?". And you would be
right. But, the single most attractive thing you can put on your resume is that you are already
employed. This is psychological on both sides of the interviewing table. For the hiring company,
it makes you look extremely desirable. It puts you in the position of not actually needing a job,
which has a huge calming effect on your mind during an interview. You will perform better as a
result. It will also disarm your interviewer. Being an interviewer is a tough job. You hold people's
lives at your fingertips, and there is no more awful experience than feeling like a job candidate is
begging for a job that you are denying them. Knowing that you are already employed puts the
interviewer's mind at ease, which actually makes them more receptive to you.

What to Do Differently
Before applying to a Top Ten List company, there are some adjustments I recommend you make
to your resume. First, review the job description and make a note of the required skills and their
order in the list. As I said before, you should have relevant experience with at least half of the
required skills. Using the same order as they are listed in the job description, rearrange the
order of your resume's skills section to match. For example, if the first required skill on the job
description is Terraform, then put the "Infrastructure as Code" category first and list Terraform as
the first skill in that category, regardless of your experience. Again, do not lie. If you do not have
experience with the first three required skills in the job description, you either need to acquire
that experience or reconsider submitting to that particular job. Repeat the reordering process on
your resume for the remaining skills from the job description.

Second, either confirm that you have stories in your experience section that highlight those
specific technologies or write new stories. Every required skill from the job description that you
have experience with should have at least one story in the experience section. Ideally, the
majority of those skills should be present in your most recent job. Just make sure you have
solid, compelling stories for each of your required skills. Refer to the "Content" section of the
"Build an Unforgettable Resume" chapter for instructions on writing resume stories.

Last, write a cover letter. If you are applying for a position at a company in your Top Ten List,
you must absolutely submit a cover letter with your resume. I dedicate an entire chapter to cover
letters that you should read before applying for any jobs on your Top Ten List. The details on
why cover letters are so important will be explained there.

Summary
Landing a DevOps job is only partially dependent on your DevOps skills. While those are
important, the skill that will get you a job is interview proficiency. You have to be able to sell
yourself and your skills. To learn how to do this, you have to practice. Find some suitable
positions that were close contenders for your Top Ten List. Aim for right above and right below
your experience or skill level. Get out there and start interviewing. You must become
comfortable with being uncomfortable. Put yourself in as many difficult interview situations as
possible. When you feel you are ready, you can begin tailoring your resume for a targeted attack
on your Top Ten List.

Actions
● Use the "Practice List" from your Top Ten List research to find some non-ideal jobs and
apply to open positions.
● Get a phone screen and an interview so you can practice your skills.
● Repeat the interview process as many times as possible to get an offer.
 ● Tailor your resume for a targeted attack on your Top Ten List. Follow the specific actions
in the section.

Personal Connection through Cover Letters

When to Use One

Should you use a cover letter? I get this question a lot. And the answer is: it depends. A cover
letter sets you apart from all the other faceless resumes. It provides you an opportunity to make
a personal connection with the decision-makers at the hiring company. It is specific to the
company you are applying to and should only ever be used once. You can create different
variations of the same cover letter, but if you try and build a template where you just <insert
company name here>, it will actually decrease your chances of being hired because you will be
viewed as a phony. Humans are incredibly adept at recognizing a disingenuous cover letter, so
my recommendation to you is to only use them when you feel overwhelmingly moved to do so.
In searching for your Top Ten List, I hope you came across some companies that gave you this
feeling.

Cover letters take time and effort, so you should be judicious in their use. Save them for your
Top Ten List applications. You should expect to spend 1-2 days writing a cover letter, which is a
substantial amount of time. But there is going to be an exception to this rule. I want you to
practice writing some cover letters for job applications where you do not expect to receive an
offer. I know this sounds odd, but before going after your prized Top Ten List, you need to get
some practice and some feedback.

As I said before, the purpose of a cover letter is to create a personal connection with the reader.
By doing this, you humanize yourself and your resume. You will no longer be just a "candidate."
You will be a name with a story that hopefully resonates with the hiring company. You have to be
able to project your personality into your writing through a personal story. You should be able to
do this if you feel a deep connection to the hiring company or not. Of course, for your Top Ten
List, this should come easier, but I want you to start with one of the companies that you do not
expect to actually hire you. The lack of expectation of hiring will allow you to focus entirely on
the cover letter and dismiss any feelings of disappointment that will cloud your thoughts. This is
an exercise in mental discipline and psychological priming.

How to Write One

Begin with one of the companies on your "Practice List." Visit their website and navigate to their
"About Us" page or equivalent. Read through all the content and take note of any aspects that
resonate with you on a personal level. It could be their approach to conducting business with
others, their compassion towards customers, their commitment to combating climate change, or
their refusal to succumb to political pressures. Look for something that goes beyond DevOps or
engineering and strikes a chord with you. If you can't find anything on their website, consider
checking their LinkedIn or Facebook profiles. Read through their posts and see if anything
resonates there. If you still can't find a meaningful connection, remove the company from your
list and move on to the next one. Don't force a connection; keep searching until you find
something that truly clicks.

Once you have identified a company that meets your criteria, it's time to take action. Creating a
personal connection can be accomplished through a story that forms an emotional bond with the
values of the hiring company. For instance, let's say you discovered a company that makes
annual donations or runs a volunteer program with a charity dedicated to feeding the homeless.
As a young child, you encountered a homeless person on the street and asked your parents
why they were in that situation. As your parents explained the concept of "homelessness," you
were deeply saddened by the existence of such circumstances in the world. That moment
stayed with you throughout your life. Whenever you encounter a homeless individual, you greet
them with a compassionate smile, engage in conversation, treat them with dignity, and offer
support in the form of money or assistance. You may even volunteer with organizations that aid
the homeless or make regular donations to relevant causes. Regardless of your actions, you
feel a profound connection to helping those facing adversity and you seek to work for a
company that shares the same values and takes meaningful action.

This story paints a vivid picture of your character as a human being. It showcases your
alignment with the company's culture, something that a sterile resume cannot achieve. It
establishes a personal connection with the reader at the hiring company and leaves a lasting
impression. When they proceed to review your resume, it will be viewed through a different lens.
They will see you as a potential fit for the role, and they may be willing to overlook a lack of
experience. They will explore creative ways to bridge any skill gaps by leveraging your other
relevant experiences instead of dismissing you outright. When wielded effectively, a well-crafted
cover letter possesses great power.

Summary
Cover letters provide an opportunity to make a personal connection with the hiring company.
That connection will make up for any technical skill shortcomings you may have. It will attach a
human emotion to your resume so that the reader and interviewer see you as a person and not
just a candidate. I recommend using one whenever you apply at a Top Ten List company.

Actions
● Practice writing some cover letters for companies where you feel a personal connection
to their values or ideals.
● Tell a personal story that connects you to those values.
● Write a real cover letter for one of your Top Ten List companies.
● Have someone you trust proofread the cover letter.

How to Nail the Phone Screen

The first thing that an interested employer will do after finding a resume that fits their job posting
reaches out to the candidate to request a phone screen. This is the first opportunity you will
have to make a big splash, so it's vitally important that you get it right. Phone screens are
designed to do one thing: quickly determine if the candidate is worth the cost of valuable
employee time for full interviews. Some companies use recruiters for this task, while others use
a rotation of technical resources. You need to know which type of person you are speaking to
and adjust your answers accordingly. I'm also going to share a few strategies and tips that will
give you an advantage by helping you leverage some psychological tools to soften the screener
and put yourself in the right mindset.
Scheduling and Reconnaissance
When you receive a request for a phone screen, make every effort to schedule it between 9 AM
and 10 AM in the local time zone of the interviewer. I realize this may sound unusual, but
numerous studies have concluded that a person's mental sharpness and energy levels are
highest during this time of day. As the day progresses, most individuals become increasingly
overwhelmed and experience frequent context switches that lead to mental exhaustion. The
later in the day you engage with them, the more likely they are to feel impatient, frustrated, and
generally annoyed. Phone screens are seen as distractions from the "real work" that everyone
needs to accomplish. Therefore, minimizing the disruption to their workday is crucial for
success.

Having the first phone screen in the morning also offers a significant advantage. Humans are
greatly influenced by psychological phenomena known as "priming" and "anchoring," which can
profoundly impact a person's perception of their performance. If you are unfamiliar with these
terms, I encourage you to research them. In essence, being the first phone screen of the day
means there is no mental basis for comparison. Even if the interviewer has conducted other
phone screens for the same job posting, the mental proximity of those interactions is too distant
to yield substantial priming and anchoring effects. The key takeaway is to be the first person the
phone screener engages with on that day.

Another important aspect is to familiarize yourself with the phone screener. When you receive a
request to schedule a time, it is crucial to ask for the full name of the person who will be
conducting the screen. While employers may provide this information in some cases, there are
instances where they do not. You should explicitly request the full name of the individual. In the
IT industry, professionals come from diverse backgrounds, and names can sometimes be
challenging to pronounce. I have found that a respectful approach to asking for the screener's
name is to say, "Out of courtesy to the phone screener, I always want to ensure that I pronounce
their name correctly, so as not to offend them. Could you please state and spell their full name,
so I can avoid stumbling and embarrassing myself?" This approach serves two purposes.
Firstly, it demonstrates your consideration to avoid causing offense, and secondly, it showcases
your humanity by acknowledging the fear of embarrassment—a sentiment with which almost
every person can relate. However, the primary reason for obtaining the name is to gather as
much information as possible about the screener, enabling you to prepare and respond to their
questions in the most impactful way.

Preparing for the Phone Screen

Passing a phone screen is entirely about preparation. Most phone screens are only 30 minutes
long, so it’s not possible to get into extreme technical depth. In fact, you don’t want to ramble on
about technical details too much. The goal of the screener is to verbally verify that you have the
requisite skill set to move to a full interview. The approach we will take for this is to prepare solid
answers for all the required skills and to use the screener’s personality in our favor.

Know Your Screener

Remember the phone screener name we collected in the previous section? Now it's time to put
that information to work. You need to know the job role of this person so that you can tailor your
responses to their personality and technical capability. A non-technical screener will not
appreciate you rambling on about technical details. In fact, they will become impatient and even
tune out your answer, waiting for their opportunity to interrupt you and ask the next question. On
the other hand, a technical screener will appreciate a higher level of technical detail but not so
much that it derails their line of questioning. For this reason, you must know your phone
screener. Look up the person on LinkedIn and review their work history. It should be
immediately apparent, either by their current job title or past experience, what kind of role they
have with the company. They are either in the technical camp or non-technical camp.

Next, review their LinkedIn posts for any personality information. See what groups or other
topics they follow. If you have any similar interests, make a note of them. See if they have
posted anything on LinkedIn that is of interest to you, and make a note of those specific posts.
Venture onto other social media sites and see if you can find the same person. You want to
know what kind of person they are and what interests them. This may sound creepy, but it is no
different than if you were having a conversation with a new co-worker on your first day. You are
simply getting to know them. People post on social media to be seen, not to be secretive. Use
this information to determine if you have any similar interests that could be used to create a
personal connection during the interview.

Make a note of three subjects where you have shared interests with the screener. Don't worry if
you can't find three. You really only need one, but having more is better. Prepare a story for
each shared subject. For example, if you are both foodies, make a note of some foodie things
you recently did or plan to do in the near future. If you both like hiking, make a note of an epic
hike that you just did or plan to do in the future. Later, we will work these into the "Passing the
Phone Screen" section.

I want to emphasize that you should absolutely not use this information to lie. You should not
pretend to be a dog lover if your phone screener is also a dog lover or pretend to be a foodie if
you are not a foodie. The goal is to find genuinely shared interests between you and the phone
screener. It's entirely possible that you may end up working with this person. It will end badly if
they discover that you are disingenuous either during the phone screen or after you are hired.
Honesty will get you further in life than anything else. Trust me.

Prepare Your Answers

The day before the phone screen, review the job description. For each bullet in the required
skills section, I recommend that you write a one or two-paragraph description of how you have
used that technology in the last year. Write the answer using a pen and paper. Do not type it.
The act of writing will commit the answer to memory. Provide sufficient detail but not so much
that you take up too much time talking. You should be able to recite your answer in under two
minutes. For example, if Terraform is a required skill, your answer could be:

In my current role at Acme Co, I developed a Terraform module using version 1.1 of
Terraform to deploy and manage S3 buckets on AWS. This module managed object
versioning, configured default bucket access policies, explicitly disabled public access,
configured bucket replication to the DR region, encrypted the contents using
customer-managed KMS keys, and configured lifecycle policies to automatically rotate
objects to lower-tiered storage. Each of these were customizable using variables while
still enforcing Acme Co's security requirements and best practices. Documentation was
automatically generated using Terradoc. The module was versioned using git tags and
used standard SDLC best practices for testing by running a mock "terraform plan" and
linting with the "terraform format" command.

This example demonstrates several things. First, you developed a Terraform module which
means you know how to create reusable code. Second, you mentioned a specific version of
Terraform, which means you know that there are significant differences between the versions to
specifically call it out. This detail will catch the attention of a technical engineer, which will likely
lead to other questions or comments about those differences, which further demonstrates your
deep knowledge of the subject. Third, you provided details of specific configuration settings,
which demonstrates your deep knowledge of S3 bucket configuration. Fourth, you mentioned
the use of customizability with variables, which shows that you know how to build reusable code
that can be customized to fit the use case, but most importantly, you can do it in a way that still
enforces compliance with security and best practices. Fifth, you stressed the importance of
documentation; even better, you did it with automation to save time. Lastly, you demonstrated
knowledge of the Terraform module software development lifecycle (SDLC), the importance of
automated testing, and the importance of code styling.

You should not recite your written answer word for word. It will sound too robotic. The purpose is
to hit the highlights as you state them verbally. Don't worry if you don't remember every single
word, but be sure what you say conveys all the main points I mentioned above and emphasizes
the "DevOps-ness" of your abilities. Pause and take a deep breath before you start your answer.
Speak slowly and deliberately. If you are on video, look up and to the right when you are
answering (this should occur naturally), which signifies you are accessing the memory parts of
your brain and not just reading a script. Return to making eye contact when not reaching for
details from your memory. Try to speak in a conversational manner. The words should flow out
of you naturally, just as if you had thought of the answer when the question was posed.

Each bullet in the required skills section should have an answer prepared. However, it is
possible that there are some required skills with which you have no experience. This is OK.
Prepare an answer for a related technology or language. Be even more detailed with this
answer and prepare one to two sentences that describe why this experience is relevant to the
required skill. I will explain how to word this in the “Passing the Phone Screen” section.

If there are "nice to have" skills listed, you should try and come up with answers for those as
well. Quickly providing detailed answers to questions from the screener will demonstrate your
mental acuity. The screener will have asked these same questions to potentially dozens of other
people. This repetition will bias the screener into thinking that they are “dead simple” questions
that should elicit immediate and simple responses from anyone who is remotely capable of
doing the job. You can exploit this bias to your advantage by immediately launching into
prepared answers that do not sound prepared. This promptness may even bring a smile to your
screener’s face during the interview. If you see that smile, you know you are on the right track,
but don’t be discouraged if you don’t. Some people just don’t smile much.

Do this task the day before the phone screen and no sooner. Give yourself one to two hours to
prepare the answers. You want them to be fresh in your head when you do the phone screen
the following day. Keep your sentences short and simple so they are easy to remember. You
want to convey to the screener that you know the technology, how to wield it, and have
experience working with it in a production environment. If you do happen to glance at your notes
while answering, and it's obvious that the screener sees you doing this because you fumble or
forget, it's entirely OK. Tell them that you are so excited about the job that you wanted to write
down a couple of notes because you were nervous about the interview, all of which is true and
honest. This will disarm almost any screener and will get remembered with a positive mental
note because it shows that you actually care enough to prepare.

20 Minute Countdown
We live in a world of constant distraction. Between your phone and computer, it’s impossible to
hold a thought for very long in your head without getting interrupted. Twenty minutes (preferably
30 minutes) before your phone screen, turn off all your devices except the computer you will use
for the phone screen. If the phone screen uses an actual phone, turn off all notifications on your
phone except your ringer. If on your computer, close every single app except the video
conferencing software. You must remove everything else from your brain and load only the
information you need for the interview. Fifteen minutes is the minimum amount of time your
brain needs in order to unload everything else you have been doing. I recommend you join the
call five minutes early, so you need twenty minutes total to prepare. If you can take a walk
outside in a quiet area 30 mins before, I completely recommend it.

During the 15-minute preparation time, read the job description twice from beginning to end.
Review your notes on the phone screener. Remind yourself of the stories or points of your
shared interests. Review the stories you wrote for each of the required and "nice to have" skills
from the job description. Recite each story out loud, slowly, and clearly. If you finish early, take
the extra moments to just breathe and meditate if that's your thing. Under no circumstances
should you check your email, texts, instant messaging, or social media accounts. Stay focused
on the job at hand. This may be the hardest task I ask of you.

Passing the Phone Screen

You have two goals for the phone screen. The first is to form a personal connection with the
screener. The second is to demonstrate your experience with the required skills. With the
preparation you have done up to this point, the task will be straightforward.

Join the phone screen bridge five minutes early. You absolutely cannot be late to the call by as
much as a single second. If the screener is waiting on you to join, you are already setting a bad
example. If they joined early, you joined earlier by being there five minutes ahead of time. This
demonstrates eagerness and courtesy right out of the gate.

When the phone screener joins, smile as big as you can and say, "Hello, XXX. It's a pleasure to
meet you. Thank you so much for taking the time to meet with me today." It doesn't matter if you
are on video or not. People can "hear" you smile, and by smiling, you project happiness
outward, which is immediately disarming to almost everyone. The screener will likely reciprocate
and ask you how you are doing today. This is your chance to leverage your shared interests with
the screener to form a personal connection. For example, if you are both foodies, say something
like, "I'm doing well. Thanks for asking. I'm actually already starting to get hungry. I made this
awesome dish last night <insert a quick food description> and have leftovers for lunch that I
can't wait to dig into." If you both like hiking and the outdoors, say something like, "I'm doing
well. Thanks for asking. I just saw that the weather will be clear this weekend for a big hike I
have planned. It was supposed to rain, and I thought I would have to cancel, so I'm super
excited to get to go now." At this point, most people will engage and begin a personal
conversation with you. If they don't or if there is an awkward silence, you can quickly fill it with a
question such as "Are you a foodie?" or "Do you enjoy the outdoors?" If they don't engage after
that, then you should immediately say, "Well, I know your time is valuable, and I want to be
respectful of that, so I'm ready to begin whenever you are. I'm really excited about this
opportunity. What questions can I answer for you about my experience?" Do not be discouraged
or concerned if they do not engage in small talk. You will still have made a personal connection
with the phone screener that will encourage them to favor you. If they do respond and stay
engaged, allow the personal conversation to keep going, but don't start telling them your whole
life story. The rule of thumb here is to keep your answers to one or two sentences. If they come
back with a response or, even better, a question, continue to answer in one to two-sentence
responses. If you hit the ten-minute mark, you need to be respectful and say, "Wow, it sounds
like we have a lot in common. I'd love to continue the conversation, but I want to be respectful of
your time. Regardless of what happens, we should definitely connect on LinkedIn." This shows
that you are enjoying the engagement but still want to respect their time. You've done your job of
creating a personal connection and need to move on to the next goal.

It is possible that the screener may use this as an opportunity to allow you to ask questions
about the job description. If they do, simply say, "Not at this time. It seems to be a really strong
match with my skills. I'm sure I will have more questions during the full interview process, but I
want to save enough time to show you why I think I'm such a good fit." This will keep moving
things along and also show you are confident that your skills fulfill the requirements. This
projection of confidence will further influence the screener’s opinion in a positive way, just as
your personal connection did.

When the screener begins their questioning, your responses should follow a pattern. First, write
down the question. If you are on video, make a point to let the screener see you do this. On the
first question, as you are writing, apologize to the screener and say, "Sorry, I like to write down
the questions to make sure I am answering them fully." Once done, state the prepared answer
you have for the related skill that the question was about. Answer any questions that the
screener interjects, but always come back to where you left off in your prepared answer. Be sure
to state the complete answer. When done, pause briefly and ask, "Does that answer your
question?" Repeat this process for each question from the screener.

When a question comes up about a skill with which you do not have experience, you need to
use specific wording to introduce your prepared answer for a related technology. What I have
found to be most effective is: "Yes. I saw <XXX technology/language> in the job description.
While I don't have a lot of previous work experience with that technology/language, I do have a
lot of experience with <XXX related technology/language>. I think it is relevant because <insert
your relevant answer>. In my career, I've had to learn so many new technologies that I actually
feel the skill of learning new technologies quickly is almost as important as knowing a specific
technology. Can I share my experience with <related technology>?". A good recruiter or
technical screener will allow you to provide your related experience. If they cut you off, don't be
discouraged. You still made the point about your ability to learn new technologies quickly, which
is just as important.

Towards the end, if there is any time left, the screener may ask if you have any questions. You
should ask the following: "What is your most favorite and least favorite thing about working at
XXX?" This will likely take them slightly off guard, as it is an uncommonly asked question and
forces them into "honest mode." Their answer is extremely important because it will give you
information that you can use during the full interview process. Take notes on the specifics of
their answer. The main point is to leave the call with them in a state of mind that is creative and
open, and this question accomplishes that.

Thank the screener for their time. Tell them that it sounds like a really interesting job and that
you look forward to hearing back from them soon. Smile. Smile. Smile. It doesn't matter if you
are on video or not. The act of smiling will always help you come across as a friendly person.
Don't ask them about the next steps. Don't ask them about how you did. Leave the call with
them answering the last question and you thanking them for their time.
Summary
Schedule your phone screen between 9 AM and 10 AM in the local time zone of the phone
screener. Numerous studies have demonstrated that this timeframe is when people are most
receptive to suggestions, and their minds are at their clearest.

Ensure that you obtain the name of your phone screener. I have provided an example of how to
ask, but try to come up with a couple more variations and rotate them to see which one you feel
most comfortable with. Research the phone screener and gather information about them from
social media. Look for common non-work-related interests and prepare personal stories to
share during the initial small talk on the call. Funny anecdotes or stories where you reveal an
awkward or embarrassing moment tend to have the greatest impact and are more likely to be
remembered.

Prepare answers for all the required skills mentioned in the job description. For skills in which
you have little to no experience, formulate responses that involve related technologies and
provide strong reasons for their relevance. Highlight how you have built your career by quickly
learning new technologies. It will resonate even more if you can incorporate instances where
you rapidly acquired related skills while delivering exceptional business value.

Allocate yourself 20 to 30 minutes to prepare before the phone screen. Take a walk or find a
quiet place to meditate, and then spend 15 minutes reviewing your answers to keep them fresh
in your mind. Join the call five minutes early and never keep the screener waiting, regardless of
the circumstances.

During the phone screen, aim to be personable and authentic. Utilize your prepared stories
about common interests to break the ice. Try to establish a connection with the screener before
delving into the technical experience questions, but keep the small talk to a maximum of ten
minutes. Respect their time. Use your prepared answers to promptly respond to inquiries about
your experience. Make note of the questions they ask and ensure you provide comprehensive
answers. Always conclude your responses with "Did that answer your question?"

If time allows at the end of the phone screen, the screener may ask if you have any questions.
Take this opportunity to inquire about their favorite and least favorite aspects of working for the
company. Wrap up the call by expressing gratitude for their time and conveying your anticipation
of hearing from them soon.

Actions
● Get the full name of your phone screener. Perform research on them by viewing their
LinkedIn and other social media profiles. Find common interests and make a note of
them. Pretend they are someone you will be working with closely and prepare to form a
friendship with them.
● Prepare answers to all of the required skills in the job description. Use the
recommendations I provided to build your answers. For skills that you do not possess,
follow my recommendations for a related technology answer.
● Practice speaking your answers out loud. Use short, simple sentences. Avoid rambling.
● Have fun with your phone screener. Treat it like a friendly conversation, but be courteous
and respectful.
Interviewing
Congratulations! You have made it to the interview process. Your preparation and hard work up
to this point will make this section relatively painless. In the phone screen chapter, we
introduced many of the concepts that will also be applied during the interview preparation and
execution. We will expand on these to drive the message home that you are an experienced
DevOps engineer and that you understand how to wield technology to the benefit of the
business. We will approach the process the exact same way regardless if this is a practice
interview or one from your Top Ten List. I will teach you some of the common conversation flows
of interviews, how to recognize them, and then how to exploit them in your favor. You will learn
to ask meaningful questions and gather data that will help you understand how to tailor your
responses in a way that resonates with your interviewer. Finally, you will learn how to take notes
that you can use to improve your interviewing skills, then apply those skills to your Top Ten List
interviews.

Know Your Interviewer

Just as with the phone screen, you need to know the person or people that will be conducting
your interview. When you are contacted to set up your interview(s), I recommend that you ask
the same question in the same way to get the full names of your interviewers. It is also
acceptable to ask about the interviewer's job role. Your answers should be adjusted based on
the person's level of technical understanding, as well as putting emphasis on certain parts of the
answer, expanding on those parts to drive your value home. You should expect all of your
interviewers to have a basic understanding of DevOps, and you should use that shared
understanding to communicate ideas that demonstrate your experience.

Follow the same instructions that were provided in the “Know Your Screener” section of the
“How to Nail Your Phone Screen” chapter. Research your interviewers and find common
interests that you can use to form a personal connection during the interview process. Refer to
that section again for details.

Culture Fit
Full interviews are where you can expect to see cultural questions get introduced. It is important
to put some thought into your answers ahead of time so you don't stumble when asked. While
you will likely not have a list of cultural questions they will ask, there are still things you can do
to prepare. First, make a list of all your personality strengths. These should include things such
as having attention to detail, being very sociable, enjoying working with others, enjoying
brainstorming sessions, having a hard work ethic, being a good listener, and being confident.
These will only be for yourself, so don't be afraid to list anything you consider a strength. Now
write one bullet for each strength and connect it to why it makes you better at DevOps. For
example, "enjoying working with others" could be linked to sprint planning sessions. If you thrive
on that type of interaction, then you likely enjoy sprint planning sessions. Think of the last time
you did a sprint planning session and see it through the lens of that strength. How did it drive
you to participate more than others? How did it make the work rewarding? How did you feel
about your contribution when the planning session concluded? How did your strength make it a
more productive planning session? How would the planning session have gone without you
there? Go through each strength and perform the same exercise. This will prepare you for
almost any cultural question that comes along. Interviewers are not expecting immediate
answers to these questions because they are intended to force the candidate to think. Take the
opportunity to review your notes in your head before answering. If you are open and honest, you
will find that the answers come naturally.

In addition to your strengths, you will need to make a list of all your weaknesses. This should
include things such as forgetfulness, trouble balancing multiple tasks simultaneously, difficulty
with social interaction, impatience, and analysis paralysis. But for your weaknesses, I want you
to write one bullet about how DevOps has helped you compensate for these weaknesses. For
example, if you are forgetful, you use tasks in your issue management system to keep track of
what you are working on and to record ideas as they come to you. You keep copious notes on
the issues you are working on to remind yourself of what you did and why you did it a certain
way. If you have difficulty with social interaction, you leverage sprint planning with virtual or
physical sticky notes to be able to record your thoughts and ideas without having to state them
in front of the team. If you suffer from analysis paralysis, you use Agile methodology to
deconstruct large projects into thoughtful experiments that can guide your choices with data.
Even if you are not currently doing these things, I challenge you to see DevOps through the lens
of your own self-improvement. Ask yourself how DevOps can turn your weaknesses into
strengths, then make personal goals to put this into action.

When it comes to answering specific culture questions, you want to be as honest as possible,
but I will share some secrets I have found to be helpful when answering some of the “trick”
questions.

How do you deal with high-stress situations?

This is absolutely a trick question, and I dislike it when it is phrased this way. What the
interviewer is really saying is, "This company struggles to reduce stress in the workplace
through proper planning and strong culture mechanisms. How will you help us with that?". In
your answer, you need to emphasize how you embrace Agile methodology in all aspects of
planning. You hold leaders accountable for their decisions and prevent scope creep by allowing
priorities to shift but within the confines of the process. Talk about the differences between
sprint-based planning versus Kanban execution and how companies that struggle with
competing priorities and scope creep benefit from the Kanban execution style.

Tell me about a time you made a mistake and how you dealt with it.

What the interviewer is really asking is, "Are you humble enough to admit mistakes when you
make them, and what mechanisms have you built to prevent yourself from making the same or
similar mistakes in the future?" There are two kinds of mistakes that I recommend using to
answer this question. The first is a technical mistake. I recommend using an example where you
were writing some kind of code, and you introduced a defect. The defect escaped into
production, and you caused service disruption. Fill in the technical details, but you should make
a few specific points after you explain the mistake. First, you want to admit that you did not write
a test (unit, smoke, functional, etc.) that would have caught this defect. Second, you want to
state that this was a pivotal learning experience for you about the importance of automated
testing that occurs as part of code pipelines. Third, you hopefully had to participate in the root
cause analysis (RCA) process associated with the service disruption. If that did not occur, say
that in retrospect, an RCA should have been conducted, but the company did not enforce their
use (something you would like to see done in all the companies you work for because of this
specific incident). Fourth, as a result of the RCA or your own investigation, you hopefully
developed a test to cover the use case in the future. If you did not, you would want to say that
you advocated for more extensive use of testing in the CICD pipeline to prevent incidents from
occurring in the future. Your goal should be to stress that you "learned the importance of testing
as far left in the development process as possible" and that you are now an advocate of
automated testing.

Describe the traits of a good boss and a bad boss.

Companies sometimes ask this question as a way to gauge what you need from a leader to be
successful. It is also helpful for them to understand if you will have a conflict with the leader they
are expecting to assign you to. Depending on the level of seniority for the job you are trying to
get, this answer will differ slightly. Good boss traits include providing clear direction and goal
setting, career coaching, helping to navigate the company, someone who identifies your
strengths and helps you leverage them, being a mentor that shares valuable experience, and
someone who sets reasonable expectations, and is supportive and friendly. Bad boss traits
include: being overly demanding and aggressive, does not trust their employees, does not take
responsibility for the failures of the team and blames individual team members instead, being
consistently unavailable for consultation, does not provide clear direction, and makes belittling
comments like "Why is this taking you so long?" or "this should be easy." If you are trying to
attain a more senior role, you will want to demonstrate that you are a self-starter, which means
you can take ambiguous direction and turn it into specific action that benefits the company. In
this scenario, a good boss is someone who provides constructive feedback on your ideas and
recommendations. A bad boss would be someone who constantly tries to micromanage you.

STAR Method
STAR stands for situation, task, action, and result. This is a very effective way to structure your
answers to broad technical questions like "Tell me about your Terraform experience" or "What
was the most complicated application you ever had to deploy." These are typically referred to as
situational or behavioral-based questions, and they are my recommended way of providing
answers. I will show you in the next section how to steer the conversation in a way that allows
you to use these types of answers. But for now, let's talk about the structure of a STAR answer
and provide some examples.

The answers you prepared for your phone screen need some updating to fit into this format.
Since full interviews typically last an hour or more, you can expand on details and change the
format to focus not only on what you did but why it was important to the business. I sometimes
refer to the STAR method as "storytelling." You are telling a story where you describe the scene,
bring that scene to life by illustrating what was done through actions, and then describe the
effect that it had on the world.

Let's focus on the "R" in STAR first, then work backward from there. Remember the DORA
metrics we discussed in the "What is DevOps?" chapter? It's time to put those to good use.
Every answer you prepare should demonstrate your knowledge of a required skill and should be
associated with improving or attempting to improve one of the DORA metrics. It is even better if
you can identify a low-level metric that rolls up to a DORA metric. Once you have identified the
DORA metric, you need to identify if your example impacts the top or bottom line of the
business. Affecting the top line would mean generating new revenue through customer
acquisition, selling more products, or charging existing customers more. Affecting the bottom
line would mean reducing the cost required to deliver products or services to the customers.
Being able to identify the business outcome is essential. Being able to quantify it is even better.
You may not have access to this type of information, so don't worry if you don't know. But if you
can get it, the impact on your interviewer will be more profound.
Let’s use an example to illustrate what I mean. Our example answer for the phone screen was
the following:

In my current role at Acme Co, I developed a Terraform module using version v1.1 of
Terraform to deploy and manage S3 buckets on AWS. This module managed object
versioning, configured default bucket access policies, explicitly disabled public access,
configured bucket replication to the DR region, encrypted the contents using
customer-managed KMS keys, and configured lifecycle policies to rotate objects to
lower-tiered storage automatically. Each of these were customizable using variables
while still enforcing Acme Co's security requirements and best practices. Documentation
was automatically generated using Terradoc. The module was versioned using git tags
and used standard SDLC best practices for testing by running a mock "terraform plan"
and linting with the "terraform format" command.

What's missing here is how this resulted in a positive impact on the business. Since DevOps
focuses primarily on the speed of delivery, I can see this example as having the effect of
increasing the development velocity of other teams that reused the Terraform module. This
reduces the time and effort of those teams to develop their own Terraform code, which
translates to reduced cost or an improvement to the business’s bottom line. This example could
also have the effect of faster "time to market" for other products that used this module, which
could generate new revenue via new features or increase customer "stickiness" and make them
less likely to leave. Both outcomes positively affect top-line revenue. You have to be able to
speak using this language to drive home the results of your work. Thinking in these terms will
also change the way you do your work going forward. Putting your technical solutions in a
business context is essential to passing an interview. I have even seen hiring managers
overrule their technical team members for candidates that think and talk this way. So if you
didn’t perform well or had a difficult person for your technical interview, answers like this will
save you.

Let's jump back to the "S" in STAR now. There was a reason that you were asked to develop
that Terraform module, and that reason describes the Situation. Most likely, the business had
already concluded that they needed S3 buckets for lots of different reasons, so it made sense to
develop something that could be reused. But it also made sense to define some guardrails and
parameters for that module, such as hardcoding a no public access policy so that an S3 bucket
could never be deployed that was publicly accessible. The situation could then be summarized
as "The business needed a way to deploy S3 buckets with customizable options in a consistent
and repeatable way using guardrails to prevent security incidents and data breaches.".

Task and Action are closely related, but be sure not to confuse the two or repeat yourself. The
task should be generic and simple, whereas the action has more technical detail as well as the
process that you followed to complete the task. For example, the task would simply be "Develop
a Terraform module to safely and securely deploy S3 buckets". But the action would be much
more in-depth. Think of it as a step-by-step guide that you would give to someone else if you
wanted them to do the task for you. For example,

"Using the mono repo methodology that Acme Co preferred, I first created a feature
branch for my new module. I then created the corresponding sub-directory in the
terraform modules parent directory. I began by collecting all the variables I knew I would
need for the Terraform resource parameters by looking up the s3_bucket resource in the
Terraform docs and going through each parameter. I made a note of the ones that
needed to be hard coded for security, then wrote out the variable declarations and
descriptions for the ones that should be configurable, setting sane defaults and marking
 some as required where appropriate. Once I had the full list of parameters and the
variables.tf file written, I created the main.tf file and declared the s3_bucket resource,
enumerating all of the parameters with hardcoded values first, then the customizable
parameters second. I put each list in alphabetical order because the parameters were so
numerous, and I wanted to make it easy to find what you were looking for. Once I had
something that looked ready, I ran the "terraform format" command to autocorrect any
linting mistakes, then ran a local security linter called "tfsec" to make sure I had not
inserted any security violations. Once those had passed, I did a test run with the
"terraform plan" command. I had a few syntax errors that needed to be corrected, then I
ran the plan again. Once I got a successful plan, I ran an application in our development
environment. Unfortunately, I received an AWS API error because two of the parameters
I provided were creating a conflict. I had to research how to deal with this and ended up
having to create a “locals” section that would check the provided variable values and
throw an error if a user tried to provide a configuration that was not possible to apply.
This ended up happening with several of the parameters, but I eventually got a
successful terraform run. Now that I had a functional module, I created a PR from my
feature branch to the master branch in the mono repo. Since I had already run all my
linting and functional tests locally, all the tests that were executed as part of the PR
pipeline were successful, and I was able to get a peer review shortly after that."

As you can see, this answer has a lot of detail in it. What's most important to convey is your
execution process and behavior. You practiced good DevOps hygiene by creating a feature
branch, running local tests, validating functionality as you wrote your code, and following the PR
process to merge your changes into the main branch. Your detailed answer provides insight into
common problems that occur using Terraform and how you elegantly dealt with those. You also
made a point to prevent a user from providing a configuration that you knew would throw an
error when attempting to apply, saving valuable troubleshooting time for others. All of these
points demonstrate that you have the knowledge and know how to apply it.

Feel free to write very long answers for these. You will never be able to memorize them word for
word, but the act of writing them down will make you more likely to remember all the major
points that you want to make. Make a bulleted list of the DevOps points you want to be sure to
convey so you can glance quickly at them and remind yourself during the interview. You want
these answers to spark conversations with the interviewer, but after answering any of their
interjected questions, always return to where you left off.

Interview Conversation Flow

Throughout my experience, I have observed two types of interview methods. Certain companies
employ a rigorous hiring process developed collaboratively by individuals from human
resources, technical engineering, and managerial positions. They utilize predefined sets of
questions tailored to different job roles. Multiple interviewers, who have received training and
calibration, participate in the process. These interviews are well-defined and structured, with
extensive note-taking throughout. It is easy to recognize this method as the interviewers are
prepared and courteous. Their questions may sound rehearsed, as if they are reading them
verbatim from a document (which they often are). You may notice the interviewers pausing after
your answers to take notes. I refer to the individuals who conduct this type of interview as
"objective interviewers."

On the other hand, some companies rely on nothing more than one or two phone calls with
technical engineers who approach the interview unprepared and employ entirely subjective
evaluation techniques. They may use questions they have personally used throughout their
careers or invent questions on the spot. It is possible that the interviewer has not thoroughly
reviewed your resume, as they might say something like "Let me quickly pull up your resume"
and take a moment to scan through it. Both styles have their pros and cons, but it is crucial to
be especially mindful of the second type of interviewer. By doing so, you can actively steer the
conversation in the desired direction. I refer to individuals who conduct these types of interviews
as "subjective interviewers." It is important to note that this term is not meant to be derogatory,
but rather highlights that they do not rely on established mechanisms to compare candidates.
However, you can leverage this fact to your advantage.

Dealing with Direct Technical Questions

Some interviewers like to test your experience by asking very specific technical questions like
"Can you construct a Linux find command to locate files that are older than 3 days and then
delete them?" or "What version of Terraform introduced the "for_each" loop functionality?"
These questions don't test your technical capability but rather how good your memory is. If you
have an excellent memory, kudos to you. But if you are like me and have to use the
documentation for specifics that you do not use on a regular basis, then these types of
questions can be very difficult to answer. You do not want to end up looking like you don't know
the technology because you don't know some obscure command argument or haven't used
some uncommon module. What I recommend in these situations is to steer the conversation
back to a question where you can use your prepared STAR format answers to demonstrate your
knowledge.

The most effective and courteous way to do this without sounding like you are dodging the
question is to state something like this: “Hrm, that’s a great question. Unfortunately, I don’t
remember specific things like that. I rely a lot on documentation and search engines for those
types of details because my brain works more on a higher level where I see the big picture of
what I’m trying to do. Then I fill in the details as I work through the solution. But I do have a lot of
experience with XXX. Can I share a problem I solved with it recently instead? We can dive into
more details as I talk through it because they will be much more fresh in my memory.”

I have never had an interviewer push back on this request. But be prepared to answer very
specific technical questions as you go through your answer. For some reason, these types of
interviewers put a heavy emphasis on technical details as a gauge of your experience. While I
disagree with the effectiveness of this strategy, you still need to be prepared for it. If you feel
that you pivoted to the STAR format effectively and had a good conversation about the situation
you described, then you can preempt the next line of questioning by saying, "I feel like I was
able to answer your questions much better when we used a situation. If you are OK with it, I'd
like to keep answering like that." The interviewer may or may not agree to do this, so do not be
alarmed if they revert back to their direct line of questioning. If you cannot answer the direct
questions, propose another answer you have in STAR format that aligns with the question. Don't
ever say the words "I don't know" or "I don't have experience with that." If you cannot pivot to
your STAR answers, then ask a question like this "Hrm, I've not used XXX technology like that
before. Can you tell me what technical or business problem you were trying to solve? Maybe I
can provide an answer with a different technology I’ve used to solve a similar problem."

It is important to note that if you can answer their direct questions, you should do so. Only use
these methods if you do not know the answer. Regardless of how good you are, some
interviewers will be stubborn and become frustrated, thinking that you are dodging their
questions because you don't have the right skills. If you sense that this is happening, stop trying
to manipulate the conversation flow and allow the interviewer to ask their questions. When you
do not know the answer, simply say, "I'd have to look that up. I can't recall off the top of my
head." You can allow the interviewer to complete their questions and, in doing so, get an idea of
how they are using technology at their company. Wait for them to complete their questioning,
and then say this: "I feel like there were a lot of specific questions that I wasn't able to provide a
good answer to, but I do know the technologies very well. Would it be OK if we talked through
some of the ways I have used these technologies in my last role?" If there is enough time left,
you should be able to talk through your prepared answers on the relevant technologies. This
tactic usually disarms the interviewer because they feel they completed the task of asking their
list of questions and are now "just talking" to you. But what ends up happening is that you
provide evidence that you do have the required experience. These interviewers will leave the
conversation feeling that you are a strong candidate, regardless of how you performed on their
questions. Keep in mind that most interviewers just provide a "yes" or a "no" as the result of
your interview with their manager. To get a yes answer from an interviewer, all you have to do is
demonstrate your ability to do the job, and steering the conversation back to one of your
prepared STAR answers achieves that.

Subjective interviewers
It is impossible to tell what kind of method will be used until you are in the interview. I have
worked at some of the largest companies in the world that have horrible and non-existent
interview processes. I have also worked at small companies that have such amazing interview
processes that they actually train larger companies how to mimic them. Do not assume that you
will be able to tell what kind of method will be used from the outside looking in.

I want to talk about subjective interviewers first because you will have to work harder to control
the conversation flow with a subjective interviewer. These types of interviews have a tendency
to jump around a lot. The interviewer will ask follow-up questions based on your answers and
will drill down into details that were not listed in the job description. When this begins to happen,
you need to start asking pointed questions to return the interview back to the required skills so
you can leverage your prepared answers as much as possible. The easiest way to do this is to
say, "I didn't see XXX technology in the job description. I'm really curious to understand how you
use it at Acme Co. and how it's related to XXX technology," where XXX technology is a required
skill that started the line of questioning. This will either snap the interviewer back to the relevant
line of questioning or prompt them to provide an answer that helps you understand how the
technology or tangential question is related to a skill for which you have a prepared answer. You
may have to provide an unprepared answer to bridge things back to the required skills
conversation. You need to do this in a way that makes you sound genuinely curious rather than
threatened. A great way to do this is to say, "I've been dying to get experience using that
technology and have some related experience with XXX, so I'm curious how Acme Co is using it
to deliver DevOps."

Remain enthusiastic and inquisitive throughout the interview. Subjective interviewers use
internal heuristics to determine if you will be a good fit. Much of this is dependent on the simple
questions "Is this someone I'd like to work with?" and "Will they make my job easier or harder?".
You want to project the friendly demeanor of someone who loves to figure out problems by
researching technology and solutions independently. When you answer their questions, add
details about how you make your own discovery through trial and error. Emphasize how you
enjoy the learning process as much as the completion of the solution. This point will resonate
with subjective interviewers because it will appeal to their “this candidate will make my job
easier” sensibilities.
A good final or closing question to ask subjective interviewers is, "You seem like you know these
technologies really well and are a lot of fun to talk to. Are you on the team that I would be on?".
This should solidify any personal connection that occurred during the interview and potentially
start a conversation that gives you more information about the company or other interviewers.
You can then take that information into consideration when making your decision about
accepting an offer.

Objective Interviewers
Once you recognize that you are in an objective interview, things should go fairly smoothly due
to all your preparation. These types of interviews tend to have well-established questions that
have been used to consistently determine ideal candidates. You can expect simple questions
like "Tell me about your Python experience" or complex ones like "Tell me how you would
approach designing the cloud infrastructure for a web application that is expected to serve
millions of customers with a global reach." Regardless, your goal is to associate the question
with one or more of your prepared answers on the required skills. If it is not immediately clear to
you, ask your own questions until you tie their question back to a required skill. If you are still
unclear on the connection, you can bluntly ask them, "I want to provide an answer that
demonstrates how my skills are relevant. Can you help me understand which of the required
skills apply to this question so that I can answer appropriately?" You should only use this if you
are thoroughly confused, but it is better than providing an answer that leaves the interviewer not
understanding how you thought what you said was relevant.

When answering questions, try to use the STAR method as much as possible. You won't be able
to do this with direct technical questions, but if those are the only questions that the interviewer
is using, you have to create an opportunity to share your STAR-based answers. My
recommendation is dependent on how you are doing with the direct technical questions. If you
are having no problems answering those questions, then allow it to continue. The general rule of
thumb is that you should not miss more than three questions in a row but also answer more
than 80% of the questions correctly. If you cross any of these thresholds, you need to stop the
interviewer by saying, "Can I ask a question real quick?" then use the opportunity to say, "I'm
missing some of the questions on technologies that I actually know fairly well. I don't feel like I'm
doing the best job at representing how familiar I am with these skills. Can we take a slightly
different approach where I talk through some of the experiences I have had with these
technologies using lots of details? I would welcome you to interrupt me at any time with
questions if further details are needed, but I think this would better demonstrate my knowledge
of these skills". It may feel awkward and uncomfortable to say this, but think of it this way: if you
don't interrupt and continue answering questions incorrectly or with "I don't know," then you will
likely fail the interview. Take a chance that will play out in your favor. At the same time, you may
end up teaching the interviewer that their questions are not effective at evaluating a candidate.

Asking Questions
Both subjective and objective interviewers may ask behavioral or situational-based questions.
These are ambiguous questions like "How would you approach designing the infrastructure for
an application that serves millions of users?". These questions are meant to test your
problem-solving skills and determine how you approach the solutioning process. The best way
to demonstrate your exceptional problem-solving skills is to ask questions. If you immediately
start launching into describing a solution, you would be doing so using assumptions. Start by
asking about constraints such as cost and time. Ask about where the end users are located. Ask
if the application is expected to have a consistent load all day long or if spikes will come and go.
If there are spikes, do they happen on a consistent schedule, or are they unpredictable? What
kind of data will the application store about the users? Are there any regulatory or compliance
requirements? What data will the app serve? How often is data updated?

Drill into as many details as you can. Every time the interviewer provides you with a new detail,
write it down and make a show of doing so. Demonstrate your meticulous nature and attention
to detail. Ask more follow-up questions. An important part of any engineer's role is requirements
gathering, which is just a fancy way of saying, "Ask as many questions as possible."

When I conduct interviews, I absolutely love when people ask me questions. I believe that being
inquisitive is heavily associated with good engineering. Most good engineers that I have met are
naturally curious and have the desire to learn new things on a daily basis. Learning always
starts with asking questions, and asking questions during an interview demonstrates your desire
to learn, how you think, your attention to detail, and your ability to seek out requirements when
you are given ambiguous tasks.

In addition to technical followup questions, there are some specific questions that will tell you
how the company operates. I recommend that everyone ask these questions of their interviewer
once the interview has concluded and they open things to questions. If you have multiple
interviews, ask each interviewer and then compare the answers. You will be surprised to learn
that the same question will get different answers from different people.
● How does this company use DevOps to deliver business value?
● On a scale of 1 to 10, how mature are this company’s DevOps capabilities?
● What is the biggest DevOps problem that this company faces?
● How much emphasis does this company put on automated testing as a control gate to
releasing code?
● How often is code released to production?
● How does the company deal with competing priorities and scope creep?
● Do the development teams measure sprint velocity? If so, how consistent is that
velocity?
You may not be able to ask all of these, but the first three are really important, so try to get
answers for those. If you have additional time, the remaining questions are nice to have. If the
hiring company does something better or worse than your current or previous company, make a
point of saying so. Finding similarities in your previous or current role is a great way to have a
more personal conversation with your interviewer. "Comparing notes" about what you like and
dislike about companies brings the conversation to a more personal level and leaves the
interview with a more friendly tone. If you feel comfortable doing this, I highly recommend it.

Practicing
I cannot stress the importance of practicing interview techniques. You can do this by yourself or
with another person. The point is to become comfortable stating your answers out loud. When
you are talking, it should sound natural and fluid. Humans can see through someone who is
reading a script. You want to be as genuine as possible. Lean into your personality, and don't try
to act like someone you are not. Most of us engineers are naturally introverted. Putting two
introverted people on a phone call and asking them to talk for an hour is a tall order. This is the
main reason I recommend that you research your interviewer ahead of time so that you can
break the ice with common interests.

Find a friend from a previous company that you can recruit for practice. If they have experience
with interviewing, that’s great, but it’s not required. If you are in a relationship, use your
significant other. It doesn’t matter if they know anything about DevOps or technology. In fact,
practicing with someone who doesn’t know anything about DevOps can actually be helpful. If
you can’t explain what you do and how you do it in simple enough terms for a layman to
understand, then you likely can’t articulate business value.

The goal of practice is to recite your answers aloud as frequently as possible, enabling you to
become comfortable with the language you use. Transform your practice interview into a
conversation rather than a one-sided monologue. Instruct your practice partner to ask questions
and provide them with a list of potential questions that may arise during your interview.
Encourage them to interrupt you with these questions at various points, allowing you to practice
resuming from where you left off. You will be surprised to discover that practicing will generate
new ideas and help you recall important details to incorporate into your responses. Keep a
notepad handy to jot down any ideas that arise during practice.

Furthermore, several websites and public communities offer interview practice sessions. Some
may require payment, while others are free. If you're pressed for time and need to practice
quickly, using a paid site may be advisable. However, if you have some flexibility, consider
joining a local DevOps community and attending meetups. Approach fellow members and
inquire whether they would be willing to engage in practice interviews with you. You'll be
surprised by people's willingness to help. Remember to reciprocate their kindness, and always
request to connect on LinkedIn.

Summary
Just as with your phone screener, you need to know your interviewer. Collect the names of all
the people that will interview you, then research them on social media. Make a note of your
common interests and prepare some stories around those common interests so you have
something to talk about at the beginning of your interview.

Prepare for culture questions. Associate your strengths and weaknesses to a DevOps principle
so you can tell a story about how your character is intertwined with DevOps. You should have a
firm understanding of yourself so that you can describe what you want and need in a job. The
last thing you want is to get what you think is the perfect role, only to find out that you don’t like
anyone at the company because they have an awful culture.

Practice using the situation, task, action, and result (STAR) method to prepare answers for your
interview. Emphasize the business impact of what you have done in your previous roles. Use
meaningful details when describing the action in your answer. Walk through the process you
employed to build your solution and highlight the steps that aligned with good DevOps practices.
Leverage the DORA metrics and other DevOps metrics in the descriptions of your results.

Most interviews follow either a subjective or objective process. Subjective interviews will feel
very ad hoc, whereas objective interviews will feel structured and prepared. Steer the
conversation to your STAR-based answers as much as possible. Answer direct technical
questions if you can, but if you start missing them or don't know them, interrupt the interview
process and pivot to your STAR answers using premade phrases and suggestions. Use active
questioning to control the conversation flow when appropriate.

Practice interviewing as much as possible. Use your friends, significant others, and peers at
work. Find paid services and use them if you don’t have people that can practice with you. Join
local DevOps communities and gain more connections while practicing your interview skills.
Actions
● Research your interviewers on social media. Find common interests and develop stories
for you to talk about at the beginning of the interview.
● Make a list of your strengths and weaknesses. Correlate each to a DevOps principle so
you can show how DevOps is something you personally practice to manage your own
skills.
● Practice using the STAR method by writing out answers to questions about your
experience.
● Prepare a STAR answer for each required skill in the job description and as many of the
optional skills as possible.
● Prepare a list of questions about the company and how they use the technologies listed
in the job description.
● Practice interviewing with friends and family. Sign up for a paid service if necessary.

Conclusion
Finding the perfect job is a lifelong pursuit. What may be good for you when you are 25 could be
bad for you when you are 35. Knowing yourself is the key to finding a role where you will thrive.
You should strive to know what you want and what kind of people you work best with. Don't be
afraid to search for what makes you happy. We all have a right to be content and secure in our
lives.

The culture of DevOps is not all that different from the culture of life. We pace our personal lives
so as not to overwhelm ourselves. DevOps uses sprints to break apart large projects into
smaller chunks that don't overwhelm developers with unrealistic goals. We watch a show or
movie in a single sitting so we can enjoy the end. DevOps plans work with milestones so the
business can enjoy the value of a completed feature. We treat our friends and family with
respect and dignity to deepen our relationships and increase our feelings of worth. DevOps
focuses on the well-being of developers by encouraging interactions with others that make their
work easier and more satisfying. It is not surprising to me that many DevOps engineers are
well-rounded individuals with high-skill proficiencies both in their jobs and in their personal lives.
The goal of this book was to help you see the world through the lens of DevOps. You are
already doing great work; you just have to articulate it in a way that resonates with employers.
My hope is that you are now able to describe how your work aligns with business value. In doing
so, you should be able to derive more satisfaction from what you do because you understand
how it positively impacts the business. Having a connection to the business is a vital part of
extracting satisfaction from your job, and I hope that my explanations throughout these chapters
have given you a better understanding of that connection. Going forward, I challenge you to
think about your job as if you own the company. From how much is being spent printing
needless copies of color presentations to failing to meet revenue growth targets, you should
care about every part of the business. You may not have visibility into every detail, but for the
ones that you can see, it should bother you when you see waste and excite you when you see
results. While I cannot promise that you will get a certain job, I can promise you that if you
exhibit this behavior while employed, it will be noticed by those that are important to the
business. You should never be afraid to ask how the work you are being asked to do aligns to
value for the business. If the requester cannot answer this simple question, then you should
push back on them to get an answer.

I have personally used the strategies outlined in this book and have mentored others to do the
same. These are the most effective mechanisms I have found to take an experienced DevOps
engineer as input and then generate outputs of a well-articulated resume, personalized cover
letters for job applications, and interview preparation. After completing this book and the actions
within it, you should be better positioned to define the types of companies that best align with
your personal values and to articulate the business value that your past technical contributions
have had for the companies where you worked. The former comes more naturally, and the latter
requires practice and experience. This is the reason why I stress that you should analyze
everything being done around you and perform the thought exercise of aligning it to business
value for practice.

I wish you the best of luck in your job hunting!

Appendix

Objective Statements
This appendix provides examples of well crafted objective statements. I would not recommend
copying these directly, but rather using them as inspiration for creating your own.

Play an active role as a catalyst for digital transformation in an organization that desires to adopt
DevOps best practices to drive innovation and value delivery.

Act as a thought leader to drive efficiency to operational processes through the adoption of
DevOps practices and methodologies.

Increase the speed at which an organization delivers value to customers through optimization of
the software development lifecycle.

Improve the reliability of infrastructure and applications by implementing DevOps strategies that
bring consistency to operational and development processes.

Empower organizations to embrace Devops methodologies that provide measurable

improvements to business KPIs.

Experience Stories
In this appendix, I provide a number of poorly worded experience stories and then rewrite them
in a more meaningful way. Remember to use numbers wherever possible, as they are much
more powerful than words. If you don't have exact numbers, then use more generic terms like
"increased from days to hours." Try to avoid terms like "dramatically increased" or "substantially
decreased." Be as specific as possible. If you can't be specific, just use "increased" or
"improved."

Example 1
● Bad Example
○ Architecture, implementation, and management of environments in the AWS
cloud
■ AWS compute: EKS, EB, ECS, EC2
■ IaaC: Terraform, AWS Cloudformation
○ Production monitoring/profiling
■ Design and implementation of better processes for the deployment and
management of environments
■ Continual improvement of architecture, processes, and skills
■ Work with Developers and Project Managers
● Good Example
○ At Acme Co, I architected, implemented, and managed production AWS cloud
environments that the company used to deliver e-commerce solutions to its
customers. I developed Terraform and Cloudformation patterns to deploy
everything from single EC2 compute instances to complex containerized
applications on EKS and ECS. These patterns reduced the change failure rate
of our application deployments by increasing the consistency between non prod
 and production environments. I was also able to implement advanced
deployment techniques that leveraged these infrastructure patterns to further
reduce the change failure rate.
○ Through my additional efforts in implementing observability, I decreased the
defect escape rate by catching bugs earlier in the development process and
providing fast feedback to developers for resolution. I forged deep relationships
with the development teams and project managers so that I could properly gather
acceptance criteria for their infrastructure and CICD requirements. I then
implemented solutions that reduced the development lead time for features by
enhancing the CICD process for applications and infrastructure.

A paragraph style was used to convey an easily understandable story about what was
implemented. Short, simple sentences written in an active voice made the content easy to
consume. The bold type was used to highlight technologies and DevOps metrics to emphasize
their importance and to draw attention to the eye.

There is still no quantifiable data from the descriptions of the results. It is better to provide a
measurement like "decreased defect escape rate by 50%," "reduced change failure rate by
halt," or "decreased development lead time by 10%". The specific advanced deployment
technique (i.e., blue/green or canary deployments) was not mentioned. Many companies are
looking to implement one or more of these, and by not referencing one specifically, the author
missed an opportunity for a connection.

Example 2
● Bad Example
○ Technical Lead (STSM) and architect. Design and implement automation to
deploy and manage services for customer Servers running SAP applications on
the IBM Hybrid Cloud.
○ Design automated delivery infrastructure for managed services on IBM Hybrid
Cloud hosting customer Servers running SAP applications. Areas of expertise
include High Availability (HA), Disaster Recovery (DR), Operation Portals, and
Application Monitoring.
○ IBM Hybrid Cloud core competencies: Specialized in designing High Availability
(HA) and Disaster Recovery (DR) infrastructure solutions and automated
recovery processes. Architect, design, and drive implementation of HA & DR
automated solutions on the IBM (shares) Hybrid Cloud and Private/In-Premise
Cloud implementations.
● Good Example
○ Through consistently delivering high-quality solutions to the largest enterprise
customers, I attained the position of Senior Technical Staff Member (STSM) and
architect, a feat that less than 1% of all engineers in the company achieve. I
focused on designing and implementing high availability and disaster recovery
automation solutions for SAP and Oracle that increased service availability and
reduced mean time to recover (MTTR) from incidents. The automation delivered
configuration management solutions to prevent configuration drift and decrease
infrastructure deployment lead time, placing servers into customers' hands faster
so they can begin using them.

A paragraph style was used to convey an easily understandable story about what was
implemented. Short, simple sentences written in an active voice made the content easy to
consume. The bold type was used to highlight technologies and DevOps metrics to emphasize
their importance and to draw attention to the eye.

While the number "1%" was used, it was only for personal achievement and had nothing to do
with the business results. While SAP and Oracle were mentioned, no other specific technologies
are listed as being used. Only generic terms like "configuration management" and "disaster
recovery” were used, instead of the underlying technology. The term “faster” was used, but there
was not quantifiable data to help the reader understand the magnitude of the impact.
Resume Critiques

Example 1
Ebony Moore
Portland, OR | (123) 456-7891 | emoore@email.com

Summary

Skilled DevOps Engineer with 3+ years of hands-on experience supporting, automating, and
optimizing mission critical deployments in AWS, leveraging configuration management, CI/CD,
and DevOps processes.

Education

NORTHWEST VERMONT UNIVERSITY Aug '12 - May '14

Bachelor of Science in Computer Information Systems

Experience

TRADELOT, DevOps Engineer Jul '19 - Current

● Create and maintain fully automated CI/CD pipelines for code deployment using Octopus
Deploy and PowerShell
● Actively manage, improve, and monitor cloud infrastructure on AWS, EC2, S3, and RDS,
including backups, patches, and scaling
● Reduced costs by ~$3,000 each month by eliminating unnecessary servers and
consolidating databases
● Built and deployed Docker containers to break up monolithic app into microservices,
improving developer workflow, increasing scalability, and optimizing speed

CLOUD CLEARWATER, DevOps Engineer Aug '15 - Jul '19

● Wrote Puppet manifests and modules to deploy, configure, and manage servers
● Automated build and deployment using Jenkins to reduce human error and speed up
production processes
● Reduced deployment time for critical agile project infrastructure from ~1 month to 2 days
● Installed and configured Nagios to constantly monitor network bandwidth, memory
usage, and hard drive status
● Managed GitHub repositories and permissions, including branching and tagging

Skills

● Configuration management using Puppet, Ansible, and Chef

● Knowledge of Python, C/C++, and Java
● Version control systems: Git, Subversion, and Perforce
Critique

The summary is too generic and doesn’t provide a personal connection to the candidate. I would
not recommend putting the low number of years of experience in the objective statement, and
instead allow the experience section to speak for itself. The summary is so generic, in fact, that
it could describe almost any DevOps engineer. Provide a description of what you want to do and
the identity you want to achieve. Provide a personal goal such as “provide thought leadership to
a large DevOps organization” or “drive cost reductions through process improvements and
automation”. Consider adding stretch goals as well such as “become a trusted advisor to the
business stakeholders through consistently delivering business value through DevOps
methodologies”.

The experience section is light on business results. There are a lot of tasks, but only a few
examples of positive business impact. Each bullet should be rewritten or consolidated into a
paragraph style story. Business metrics should be added, preferably with quantitative evidence
of the impact. For example the “manage, improve, and monitor cloud infrastructure” bullet
should mention Mean Time To Resolve (MTTR) as the metric to demonstrate business value.
The candidate should indicate that they either improved or maintained the MTTR through their
efforts, and why that was important for the business. Another bullet mentions “reduced costs by
$3000 each month”, but there is no mention of implementing governance processes to prevent
unnecessary cloud spend in the future. This would have resonated more with the reader.

Using configuration management to deploy, configure, and manage servers needs to reference
some metrics such as “Change Failure Rate”, “Mean Time To Resolve”, or “Service Level
Objectives”. Emphasize how the use of Puppet manifests improved the stability or reliability of
the environment as a whole. The reduction of the deployment time for critical agile infrastructure
is a great point! The management of GitHub repos, specifically the branching and tagging is a
very solid DevOps domain. More detail should be used on this point, preferably about how the
candidate provided thought leadership on branching/merging strategies for developers to use,
even calling out common patterns such as Gitflow or trunk-based strategies. This should tie in to
general CICD efforts and metrics such as “Deployment Frequency” or “Mean time to provide
feedback” with automated testing in the build system. I cannot stress how important this last
bullet is to demonstrate the candidate’s level of maturity with DevOps methodologies and
strategies. An entire story should be written to dive deep into the detail about how the candidate
implemented or evangelized these strategies within the organization and the positive impact it
had on key business metrics.

This resume demonstrates the ability to use common DevOps tools and strategies, but
completely misses the mark on why they are important. A resume should always answer the “So
what?” question. The interviewer should understand that the candidate knows how to implement
technology but more importantly that they know why to implement technology.
Example 2
Malik Rabb
Seattle, WA | (123) 456-7891 | mrabb@email.com

Summary

Innovative Senior DevOps Engineer with a strong Linux background and 15+ years of
experience designing, implementing, and managing cutting-edge deployment automation of
cloud resources.

Education

GREEN VALLEY STATE Aug '99-May '03

Bachelor of Science in Computer Science

Experience

CRANE & JENKINS, Senior DevOps Engineer Jul '19 - Current

● Automated deployments for 200+ cloud servers using Python and Bash
● Manage 50+ total AWS, Jenkins, and Chef accounts to more effectively control access to
resources and increase security
● Maintain build profiles in Team Foundation Server and Jenkins for CI/CD pipeline
● Spearheaded migration from Puppet environment to Docker-based service architecture

RIVER TECH, Senior DevOps Engineer Aug '15 - Jul '19

● Designed, rolled out, and managed 5,000+ hosts with Puppet Enterprise infrastructure
● Rewrote shell deploy scripts, reducing deployment times from 5+ hours to less than 2
minutes
● Wrote and tested Chef cookbooks with Ruby and Vagrant to configure and perform tasks
on remote nodes

RETAIL OCEAN, DevOps Engineer Jan '13 - Aug '15

● Implemented CI/CD process using TeamCity for global development team, allowing for
dozens of code updates per hour with zero downtime
● Automated build and deployment process with Jenkins and Maven, eliminating 80% of
manual work
● Drove strategy for migrating from Perforce to GitHub, including branching, merging, and
tagging

Skills

● Docker, Chef, Puppet, Ansible, Python, Ruby, TeamCity

● AWS services (EC2, S3, Route53, SQS, IAM, CloudWatch, CloudFormation)
Critique

This summary is fairly standard. It is only impressive because the candidate has 15+ years of
experience. It doesn’t convey any objectives or personal goals of the candidate. Given the
extensive experience with deploying and managing large scale infrastructure, I would have liked
to have seen more emphasis put on a desire to work with large enterprises that have expansive
infrastructure needs that must scale to meet the demands of the business. There is a missed
opportunity here to express how the candidate can help scale operational processes through
the use of technology to reduce overhead and improve infrastructure governance. Many
companies would find that appealing without having to read anything more.

My first question is why Python and Bash were used to deploy 200+ cloud servers. That seems
like a job for a tool like Cloudformation or Terraform. It would also be helpful to understand if an
improvement of some kind was made by the candidate. Were all the servers the same? Did they
create server roles or functions that made them use case specific? Was that role taken into
account in the deployment process? As a seasoned DevOps engineer, I can write about five
lines of Bash script to deploy 1000 servers in a few minutes. It would be more impressive if
details were provided on the business impact of those large scale deployments.

How were the 50+ AWS, Jenkins, and Chef accounts managed? Was automation used? Include
a metric to more adequately describe “increase security”. Were there security events before the
candidate started managing these accounts and were they reduced as a result of that
management? Emphasize how build profiles created consistency in the build process and
increased the velocity at which developers could push code updates to production.
“Spearheaded migration” does not provide enough detail into the kind of thought leadership that
the candidate provided. If they initiated the project, it should be stated as such. If they led a
team of two or more engineers to accomplish the goal, then that information should be added.
More emphasis should be placed on the outcome instead of the technology. How did moving
from Puppet to Docker benefit the business? Plus, the statement does not make sense. Puppet
is a configuration management framework and Docker is a container runtime technology.

The reduction of deployment time is a great example, but I would like to see it taken one step
further. Did this also increase deployment frequency so that value could be delivered to
customers faster? State the tasks that were performed using Chef cookbooks and why it was
important to the business. Did it reduce the time to resolve service disruptions? Did it increase
the efficiency of the operations teams and their ability to affect changes in the environment?

The “Implemented CICD process using TeamCity…with zero downtime” bullet is the best point
in the entire resume! The “Automated build…with Jenkins and Maven” is the second best bullet
point. I would like to know more about how the candidate drove the strategy for migrating from
Perforce to GitHub and how it positively impacted the business. This would be an excellent
opportunity to demonstrate how the candidate provided thought leadership in the organization
and how that created positive results for the company.

This resume is only good as an outline for having a conversation about the high level bullets.
While there are many good talking points in the bullets, it is unlikely that this resume would get
the candidate to the interview process for a highly competitive job. The bullets are too high level
without enough detail to make this a great resume. Despite the 15+ years of experience, it’s
unclear the impact that the candidate had on any of the companies. With that much experience,
the candidate should have been exposed to enough business processes to be able to articulate
that impact clearly.