DevOps or Just Dressed-Up IT Support? How to Spot Fake Engineering Roles in 10 Minutes

Introduction: The Problem with Titles

The tech industry loves titles. Especially shiny ones: DevOps Engineer, Cloud Platform Architect, Site Reliability Hero. But behind these buzzwords, many companies are still running traditional IT operations—complete with legacy systems, chaotic tickets, and late-night incident firefights.

For candidates coming from real DevOps backgrounds, infrastructure automation, or cloud-native environments, walking into a mislabelled job is more than just disappointing—it’s a career detour.

This guide is for anyone tired of being baited with modern job descriptions, only to find out they’re being hired as an all-purpose incident janitor.

Why This Matters

  • Time is limited. Every misstep delays your growth.
  • Some environments will burn you out fast.
  • Not every company deserves your experience.
  • The earlier you spot the mismatch, the more power you keep.

Red Flags in Disguise

It’s rarely obvious. These jobs don’t say “Helpdesk” or “Legacy Operations” anymore. Instead, they hide behind:

  • “Cloud Engineer” roles that never touch the cloud
  • “DevOps” titles in teams with zero CI/CD ownership
  • Kubernetes being used… but only to babysit what developers no longer want to manage
  • Environments where you „have responsibility“ but no control

The 10-Minute Litmus Test: Ask These Questions in the Technical Interview

These aren’t aggressive. They’re professional. But they cut straight through the fog. You don’t need to interrogate — just observe how clearly and confidently your counterpart answers.

1. “What ticketing system do you use — and how do you classify incidents vs. service requests?”

Why ask:
A mature Ops environment distinguishes reactive firefighting (incidents) from planned work (requests). If they can’t explain this, you’re probably walking into a support mess.

Green light answers:

  • “We use Jira Service Management with ITIL-style workflows.”
  • “We classify everything on intake — incident, request, change — and have SLAs defined.”

Red flags:

  • “Uhh, we use Jira… but we don’t really make that distinction.”
  • “Everything’s just a ticket
 it depends.”
  • “Störungsarten… I mean, we kind of call everything a disruption.”

2. “Roughly what percentage of the role is reactive support versus project-based engineering?”

Why ask:
This reveals whether you’re joining a team that builds and improves systems, or one that constantly chases after broken ones.

Green light:

  • “20-30% is support rotation; the rest is focused on building CI/CD, improving infra, etc.”
  • “We rotate weekly on incidents, but most time is spent building.”

Red flag:

  • “It depends. Some days it’s all issues.”
  • “You’ll get tickets passed from dev when stuff breaks.”
  • “50% troubleshooting is probably fair.”

3. “Are Dev and Ops integrated, or do they ‘hand off’ responsibilities?”

Why ask:
True DevOps cultures don’t just assign blame — they own the system end-to-end. If developers throw code over the wall and Ops cleans it up, you’re not joining a DevOps team. You’re joining a cleanup crew.

Green light:

  • “We build together. Infra as Code is owned by both Dev and Ops.”
  • “Developers are on-call too, depending on the service.”

Red flag:

  • “Well, Dev owns the code, but once it’s deployed, it’s Ops’ problem.”
  • “Developers manage Kubernetes now, but we want to offload that to Support.”

4. “Can you walk me through a recent incident and how it was handled?”

Why ask:
This shows you whether their operational maturity is real or theater. The answer will reveal clarity, tooling, culture — or chaos.

Green light:

  • “We have runbooks, dashboards, and postmortems. Everyone learns from failures.”
  • “We identified a failing deployment, rolled back via ArgoCD, wrote an RCA.”

Red flag:

  • “Well, someone just got called
 I think we restarted something.”
  • “We had to VPN into a customer’s box and fix the firewall rule manually.”

5. “What percentage of the infrastructure is cloud-native vs. on-prem?”

Why ask:
Many “cloud” roles are 90% on-prem with a sprinkle of AWS S3 to make the job posting look fancy.

Green light:

  • “Most of our infra is containerized and runs in AWS/GCP.”
  • “We have a few legacy systems, but the focus is migrating them.”

Red flag:

  • “We use Kubernetes… on-prem… single-node… with Windows containers.”
  • “We have hybrid cloud, but you’ll mostly deal with customer firewalls and VPN issues.”

Bonus Signal: The Interview Tone

In real DevOps interviews:

  • You’re treated as a thought partner, not a problem-sponge
  • You’re asked about your engineering mindset, not how good you are at “jumping on issues”
  • The team sells you on the environment — not the other way around

If it feels defensive, vague, or like a support handoff — walk.

Closing Thoughts

You’ve done the hours. You’ve seen the fires. You’ve kept systems alive when no one else could. Now it’s time to protect that experience and aim higher.

Every company wants “DevOps” — until they see what it actually takes.
Your job is to separate the real from the roleplay — in minutes, not months.

Because you’re not just looking for a title.
You’re looking for a team that deserves you.