- [Cameron] Hi, I'm Cameron McKenzie.
I'm the editor in chief over@theserverside.com.
And I wanted to help you answer
10 of the most common DevOps interview questions
you might encounter.
So question number one, named five important DevOps tools.
And I would say if I'm gonna answer this question,
I'm gonna mention the fact
that there's probably five different categories of tools,
configuration management, source code management,
continuous integration, containerization,
and collaboration that we probably want to think about
when we're thinking about DevOps tools.
And there's more categories.
And I even talk about monitoring
and stuff like that.
But I think those are the big ones.
And I would say for configuration management,
I go with chef or Ansible,
I'd say with source code management,
I'd go with Git I'm a big Git fan.
Continuous integration, i like Jenkins containerization.
I like Docker.
And in terms of collaboration, well,
I'm a big fan of using Jira.
For question number two.
What is continuous integration?
I'm gonna answer this question.
I say, you know, continuous integration
is the art of making sure
that the code that you check into
a shared source code repository compiles,
and of course, continuous integration servers
are constantly looking for check-ins.
They're looking for commits.
And if they find commits, they will try
and build the application,
make sure that it compiles.
And if it doesn't compile the build fails.
And that's typically what we talk about
when we talk about continuous integration,
making sure that the Dev team can continuously integrate.
And of course, if there is a build failure,
that means nobody can pull the code.
Nobody can properly update the code
and development in a distributed manner essentially stops.
People can still do isolated development,
but distributed development stops.
And that's a bad, bad thing.
Now why did we shift left in DevOps?
That's something we hear quite often,
shifting left in DevOps.
Simply means taking things
that sort of happen on the right side of a history graph
or a timeline graph of software development
and move them to the left, make them happen earlier.
And that can often mean things like doing deployment.
So get code, get applications in front of your users
earlier in the life cycle.
That's a pretty big agile tenant, right?
Like make, get input from your users
and let them know if what you're developing
is what they want.
But even other tasks such as, I don't know,
maybe something like performance monitoring
and load monitoring, seeing how well
your application does under load,
but stuff that people tend to do
towards the end of the software development lifecycle
shifted, left, do those things earlier.
That's part of the idea of doing DevOps.
Number four, what does CAMS mean?
Typically the CAMS acronym means
Culture, Automation, Measurement, and Sharing,
all which are important in doing DevOps transitions.
And I don't know, I think it's a bit bogus.
I think those are all important, just doing development,
whether you're doing devOps or not,
but it's an acronym we often see in the DevOps world.
Number five is a bit of opinion piece.
Do you think a culture changes requirements
or results of doing DevOps?
The correct answer is that it's a result,
but there are some people
that might argue with me on that point,
but a culture is defined by the processes that you use
and the practices that you use, the processes that you use.
And so what happens in DevOps
is you start introducing new tools.
People use them, people use Jenkins.
People use distributed development.
People use containers
because they start using the containers,
the processes that they go through
and the behavior they have, that changes.
And then in the end, you end up having a culture change.
So does it being a result? It's not the input.
You don't say, Oh, we've got to change our culture.
And then we'll do DevOps .
We start doing DevOps.
And eventually, the culture changes,
especially if you're doing DevOps right.
Now, name three important DevOps, KPIs,
Key Performance Indicators,
there's a number here,
I find that some of the most important ones
are mean time to failure recovery.
That is, if something goes wrong,
how quickly can your team react?
And that involves, you know,
what we treasure, think of both
as developers and operations
'cause it could be a problem in the code.
And it could also be a problem
with maintaining server and services.
That's a big one.
Deployment frequency, so how often are we doing deployments?
That's a key one as well.
It's a key one for agile as well.
And also maybe even taking a look at
the percentage of failed deployments.
So how often do we deploy?
And how often do those deployments fail
and we have to correct something
and redo the deployment again.
So these are all basic KPIs
that we can have for doing DevOps.
Of course, if You're gonna do DevOps,
make sure you baseline these first
'cause you need something to compare to.
So you know, if things were good earlier,
or things are getting better,
or things are getting worse
or if you're progressive.
Number seven, describe three DevOps anti-patterns,
one anti-pattern, I'd say
is to just replace the development
and operations silo with a new DevOps silo.
So that's not gonna work.
Another DevOps anti-pattern
is not involving enough stakeholders.
So if you just get development, just got operations,
you might be excluding,
or I mean, people from the executive team,
you might be excluding people from security,
you might be excluding people
from the hardware provisioning team.
So that's another anti-pattern,
not bringing enough people under the tent,
when you actually go
and embark upon DevOps.
Another DevOps anti-pattern, this goes on to the KPIs.
It's not doing a baseline
at the beginning to know where you are,
where you are at as you embark upon your transition.
And so make sure you do a baseline,
make sure you know where you're at.
'Cause if you don't know where you're at,
you don't know if you're progressing forward,
or if you're moving backwards.
Number eight is a question about
what are the benefits to DevOps automation.
As far as automation goes,
there's a number of benefits.
One is it removes the human aspect,
and it removes the possibility of human error.
So if something's automated, you don't have humans there.
That also means that when something's automated,
that it is repeatable,
and it's also correctable.
So if there's a problem with the automation,
you can go in and change the automation.
And as you constantly refine your opportunities
for automation, your applications get harder.
And that is a good thing, means they're more reliable,
and they're more robust.
I guess another benefit to automating your various processes
is that you can remove manual intervention,
and that removes bottlenecks
from your continuous integration pipeline.
And that should hopefully improve the speed of deployments
and the number of deployments,
all of which are key performance indicators for DevOps.
Number nine name to popular Java Development frameworks
for creating micro services.
I quickly answer that question by saying Spring Boot
and Eclipse micro profile,
those are two of the most popular ones in the Java world.
And I'm a Java developer.
So I'm always Java centric,
you might wanna go
and research some dotnet frameworks
or other languages
or frameworks that organizations may be using
to develop microservices,
especially if you know that
the organization that you're working with
is a dotnet organization
or something along those lines.
And number 10, what is continuous delivery?
Well, continuous delivery,
it expands on the idea of continuous integration,
but it goes one step forward into the idea
that not only is our code compiling
and integrating maybe passing some rudimentary unit tests.
But beyond that,
we are in a situation where there's a main trunk line
that developers are regularly integrating into,
that is always available for delivery,
that is always always ready
to be turned into a deployment artifact packaged up
as a jar file
or packaged up as an executable container.
And put in to deployment Martin Fowler
tends to be a bit of a thought leader.
He says you're doing continuous delivery,
if your software is deployable throughout its lifecycle,
your team prioritizes keeping the software deployable
over the idea of working on new features
that anybody can get fast,
automated feedback on the production
readiness of the system.
And you can perform push button deployments
of any version of the software to any device,
any environment, on demand whenever you want.
So anyways, that's 10 of the most commonly asked DevOps
interview questions with answers.
Hopefully those will help you out.
If you're going on a DevOps interview.
Make sure you can answer those questions.
If you disagree with what I provided,
as some of the answers,
make sure that you can articulate
why it is that you disagree.
And if you do like my answers,
make sure you can put those answers into your own words
because you're not gonna get anywhere, if you just try
and memorize or regurgitate some of those answers.
So be able to put those into your own words.
And if you can do that,
I'm pretty confident
you're gonna land that DevOps engineering job.