Why DevOps Engineers Who Ask Questions Back Impress Me Most

Interview Insights · DevOps Engineer

Why DevOps Engineers Who Ask Questions Back Impress Me Most

SECTION 01Why I keep the scenario vague on purpose

When I give a DevOps scenario, I leave out details on purpose. In a real job, nobody hands you a complete specification. A product team says 'we need faster releases' and you have to work out what that means. I want to see whether a candidate notices the missing information and goes looking for it.

Candidates who start designing immediately often build something reasonable for a situation that is not the one I had in mind. Then I have to stop them and explain, and the round loses time. Candidates who ask first usually end up much closer to a good answer.

Interviewer: Set up CI/CD for this Node.js service.

Candidate: I will use Jenkins with eight stages: checkout,
install, lint, unit test, integration test, SonarQube,
Docker build, security scan, deploy to dev, QA, staging
and prod with manual approval at each step...

Interviewer: The team releases several times a day from
main. Would this work for them?

Candidate: ...maybe we can remove some approvals.

Interviewer: Set up CI/CD for this Node.js service.

Candidate: A few quick questions first.
How often does the team release, and from which branch?
Where does it run: Kubernetes, VMs, serverless?
Does it have its own database?
What CI tool does the team already use?

Interviewer: Several times a day from main, on
Kubernetes, own Postgres database, GitHub Actions.

Candidate: Then I want fast PR checks, an image built
once per commit, automatic deploy to staging, and a
progressive rollout to production with automatic
rollback, rather than manual approvals.

The second candidate is not smarter. They simply refused to design for an imaginary team. The design that follows fits the answers, and the interviewer can see why each choice was made.

SECTION 02How one answer changes the deployment strategy

The clearest example is deployment strategy. If I ask for zero-downtime deployments, a candidate who asks 'how risky are your releases and do you have good metrics?' can choose between a rolling update, a blue-green switch or a canary release with reason. Without that question, they usually pick whichever one they last read about.

Kubernetes makes this concrete. A rolling update is built in, and its behaviour is controlled by maxSurge and maxUnavailable. Readiness probes decide when a new pod receives traffic. Canary releases usually need extra tooling, such as a service mesh or Argo Rollouts, so asking whether those tools exist is itself a good question.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # at most 1 extra pod during rollout
      maxUnavailable: 0  # never drop below 4 ready pods
  selector:
    matchLabels:
      app: orders
  template:
    metadata:
      labels:
        app: orders
    spec:
      containers:
        - name: orders
          image: registry.example.com/orders:3f2c1ab
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

# Update the image and watch the rollout
kubectl set image deployment/orders orders=registry.example.com/orders:9d8e7f0
kubectl rollout status deployment/orders

# See revision history
kubectl rollout history deployment/orders

# Roll back to the previous revision
kubectl rollout undo deployment/orders

# Pause a rollout if metrics look bad
kubectl rollout pause deployment/orders
kubectl rollout resume deployment/orders

With maxUnavailable: 0, Kubernetes only removes an old pod after a new one passes its readiness probe. That is the key to zero downtime in a rolling update, and saying it clearly is a strong moment in any interview.

But notice what this configuration cannot do: it cannot send only a small share of users to the new version and wait. If the interviewer's answers suggested risky releases, you would explain why you would add a canary tool instead.

SECTION 03Asking well: how many questions and when to stop

There is a wrong way to ask questions too. Some candidates ask ten questions in a row, or ask things that do not change the design, and the interviewer starts to feel interrogated. The goal is a few questions whose answers would actually change what you build, then a clear move to a proposal.

A useful rule: before asking, check whether different answers would lead you to different designs. If not, make an assumption, say it aloud and move on. In Uncodemy mock interviews we often stop candidates after their questions and ask 'which answer changed your plan?' If they cannot say, the question was not needed.

CI/CD SCENARIOS
- How often do you release, from which branch?
- What runs the app: Kubernetes, VMs, serverless?
- What CI tool is already in use?

DEPLOYMENT SCENARIOS
- Can users tolerate any downtime?
- Do releases include database schema changes?
- Do you have metrics to judge a release?

SCALING SCENARIOS
- What does the traffic pattern look like?
- Is the app stateless?

INCIDENT SCENARIOS
- What changed recently?
- Is it affecting all users or some?

When a detail would not change your design:

"I will assume the service is stateless and keeps
sessions in Redis. If that is wrong, the main change
would be sticky sessions or moving state out first."

Then continue with the design.

After proposing, close the loop:
"Does this fit what you had in mind, or should I go
deeper into the rollout or the pipeline stages?"

The closing question in the second tab is important. It hands control back to the interviewer and lets them steer toward the area they actually want to test, which saves you from going deep in the wrong place.

SECTION 04Clarifying-question worksheet for DevOps scenarios

Practise with these tabs until asking good questions becomes a reflex. A friend can play the interviewer and answer your questions in different ways, so you see how the design should change.

PRACTISE EACH PROMPT

1. Set up CI/CD for a Python API.
2. Deploy without downtime.
3. Our builds take too long.
4. The app falls over on sale days.
5. Production errors started an hour ago.
6. Developers want their own test environments.

For each: write 3 questions whose answers would
change your design. Then write two designs for two
different sets of answers.

ANSWER FLIP DRILL (with a partner)

Prompt: "Deploy without downtime."

Round A answers: small releases, good metrics,
                 no schema changes.
  -> Your design: ______________________

Round B answers: risky releases, weak metrics,
                 frequent schema changes.
  -> Your design: ______________________

If both designs are the same, your questions
were not the right ones.

AFTER EACH PRACTICE SCENARIO

[ ] I asked before designing
[ ] Each question changed something in my plan
[ ] I stated assumptions for missing details
[ ] I named the trade-off of my chosen approach
[ ] I asked if the design fit before going deeper
[ ] I asked no more than four questions up front

SECTION 05Tips for asking questions back without losing time

Good questions are short, relevant and followed by a decision. These tips keep them that way.

• Say why you are asking — A short 'because that decides the rollout strategy' tells the interviewer your question has a purpose.
• Group your questions — Ask two or three together instead of one at a time, so the conversation keeps moving.
• Use their answers visibly — Refer back to their answers when you choose a design, such as 'since you release several times a day...'.
• Assume when it does not matter — For details that would not change the design, state an assumption and move on.
• Close with a check — End with 'does this fit, or should I go deeper anywhere?' to hand the steering back.

SECTION 06Interview Q&A — Clarifying questions

SECTION 07Test yourself — Clarifying questions quiz

SECTION 08Frequently asked questions

SECTION 09Related reads