Hire DevOps Engineers in India

One Title, Four Different Jobs

Nobody agrees what a DevOps engineer is. The phrase started life as a description of how teams should work together and ended up as a title on a requisition form, which means it now covers at least four separate trades with different daily habits, different failure modes, and different people doing them well.

Build and release engineering

This person owns everything between a developer pressing merge and the change being live. Pipeline definitions, build caching, artefact registries, versioning, environment promotion, database migrations, rollback. Their day goes on making a slow pipeline fast and a flaky pipeline trustworthy, which sounds unglamorous until you count what a twenty-minute build costs across forty engineers waiting on it.

You want this hire when the complaint in your retros is about shipping. Deploys happen on Thursday because nobody trusts Friday. The test suite fails at random and everyone just re-runs it. Nobody can say with confidence which commit is in production. There is a release checklist in a shared document and it has eleven manual steps in it. None of that is a cloud problem or a Kubernetes problem, and hiring a cluster specialist to fix it wastes both of you.

Platform engineering

A platform engineer builds the thing your developers use, and their success is measured by how rarely anyone has to ask them for help. Golden paths, service templates, a way to get a new service into staging without raising a ticket, sensible defaults for logging and metrics, documentation that is actually current. The customer here is another engineer, so product sense matters as much as infrastructure skill, and that combination is genuinely rare.

The signal that you need this role is drift between teams. Five services, five different ways of building a container image, five interpretations of what a health check should mean. Every new starter spends their first fortnight learning conventions that exist only in somebody's head. That is a platform problem, and pointing a cloud engineer at it produces more infrastructure rather than less confusion.

Cloud infrastructure engineering

Accounts, networks, identity, storage, DNS, cost. This is the person who decides how many cloud accounts you have and why, what your VPC and subnet layout looks like, how roles get granted, where state lives, and what happens when the monthly bill doubles. They spend their time in Terraform or OpenTofu, they read provider changelogs for fun, and they think in terms of what a mistake can reach.

Hire this role when the estate underneath is the problem. Everything runs in one account on one flat network. Nobody knows who created the load balancer that has been quietly billing since last year. There are identity users holding access keys older than the current CTO. Half the infrastructure was clicked into existence and is not described anywhere, so no environment can be rebuilt from a repository.

Site reliability engineering

An SRE treats reliability as a measured quantity rather than an aspiration. Service level objectives, error budgets, incident command, blameless review, and the uncomfortable conversation about whether this sprint goes to features or to stability. The practice came out of Google and it works best when you have enough traffic that the numbers mean something.

The tell for this hire is that you cannot answer simple questions. What was your availability last quarter? What counts as down? How long does an incident take to detect, as against how long it takes to fix? If nobody owns those numbers, an SRE is often worth more than another pair of hands on the infrastructure, because they change what the team argues about.

How to work out which one you need

Take your last five painful weeks and write down where the pain actually was. Not where you assume it was. If four of the five were release days, you have a build and release problem. If four were other teams sitting blocked waiting on you, you have a platform problem. If four were the cloud account behaving in ways nobody predicted, you have an infrastructure problem. And if you cannot categorise them at all because there is no record of what happened, that finding is itself the answer, and reliability is where to start.

In a company under about thirty engineers, one good generalist covers all four and it works fine. It stops working somewhere in the forties, and the symptom is always identical: the person hired to build the platform spends every day unblocking other people and never builds anything. If you recognise that, the fix is a second person and a written split of who owns what, not a more senior single hire.

One more honest note before you write a job description. If what you have is a bounded project rather than a continuous job, hiring is the wrong instrument entirely. We come back to that further down and it is worth reading first.

How Do You Screen a DevOps Engineer in an Hour?

Do not ask what tools they know. Hand them a broken system and make them debug it out loud. You are not looking for the right answer, because you have deliberately not given them enough information to have one. You are watching how they narrow the space: what they ask first, what they rule out, and whether they reach for evidence or for a guess.

A pod has been stuck in Pending for ten minutes

The weak answer restarts it. The next weakest blames the image, which is wrong, because Pending means the pod has not been scheduled or bound yet and an image problem surfaces later as ContainerCreating or ImagePullBackOff. Somebody with real exposure goes to the scheduler events and reads them, then works through the short list of reasons a scheduler declines: no node carrying enough allocatable memory or CPU, a taint that nothing on offer tolerates, a selector or affinity rule matching nothing, a PersistentVolumeClaim that never bound because there is no volume in that availability zone, or a topology spread constraint nothing can satisfy.

The detail that tells you somebody has operated a real cluster is the case where there is no pod at all. A namespace quota rejects the object at admission, so the failure shows on the ReplicaSet rather than anywhere you would think to look. Listen too for whether they mention the autoscaler, and whether they know it can decline to add a node because of an instance limit rather than because of anything to do with the pod. Anyone who gets through that in five minutes with structure has answered your Kubernetes questions and you can move on.

The pipeline that got slower every month

Frame it plainly. Eighteen months ago the build took six minutes. It now takes thirty-one, nobody changed anything deliberately, and the team has stopped noticing. How would they find out where the time went?

The instinct you want is measurement before theory. Break the build into stages and time each one across the last hundred runs rather than the last one, because a single run tells you nothing about variance. Common findings, roughly in the order they turn up: a cache key that stopped matching so the dependency install went cold, a test suite that grew for two years without ever being parallelised, image layers ordered so a one-line source change invalidates everything after it, runners contended at exactly the times everybody merges, and a step pulling from a registry with rate limits that quietly retries. A candidate who only says add more runners is treating a symptom, and has told you they have never had to defend the bill afterwards.

terraform plan shows changes nobody made

My favourite question in the set, because it separates people who use Terraform from people who understand what it is doing. Drift means reality and recorded state no longer agree, and the useful first move is working out which side moved.

Good answers separate the causes rather than lumping them together. Somebody changed a resource in the console, which happens most often during an incident and is not automatically wrong. A provider version changed and now reports a field it used to ignore, or defaults it differently. The cloud service set something server side, with tags applied by an organisation policy being the classic. Or the resource was never properly managed here at all and two configurations are quietly fighting over it. Then ask what they would do next, and listen for reading the plan output carefully, checking the provider changelog, and reaching for targeted imports or moved blocks rather than the answer that destroys and recreates a database to make the plan look clean. Ask them as well what they made of the licence change HashiCorp announced in August 2023 and the OpenTofu fork that followed. It is not a trick. It tells you whether they follow the ecosystem they work in.

You are paged at 03:00 for disk pressure on a node

Ask what they do in the first two minutes, then separate that from what they do the next morning. In the first two minutes the aim is stopping the bleeding without destroying the evidence, so you want to hear about finding what is consuming space before anything gets deleted. Logs that never rotated. Image layers accumulating because nothing prunes them. A core dump directory. A database temp file left by a query that went wrong. An application writing to a path that was never meant to persist.

The second half of the answer matters more. A senior engineer treats the page as evidence that monitoring failed, not as evidence that a disk filled. Disk usage grows predictably, so an alert should have fired on the trend days earlier, at a threshold that gave somebody a working day to react. A candidate satisfied with having cleared the disk and gone back to bed will be clearing that disk again next month.

A certificate expired in production on a Sunday

Everyone has lived this one, which is why it works. Let us Encrypt issues certificates with a ninety day lifetime, so the renewal cadence is short by design and automation is not optional. The interesting part is why the automation did not work, and the honest answers are specific. Renewal ran but the reload did not, so the process is still holding the old certificate in memory. It renewed on one node and not the other. The challenge failed silently for weeks because a DNS record moved. An intermediate changed and the chain the server now sends is incomplete, which some clients tolerate and others reject outright.

Push once more and ask how they would prove the fix. You want inspection of the chain a server actually presents rather than the file sitting on disk, a check from outside your own network, and an alert on days remaining rather than on the renewal job failing. Anyone who says the word monitoring without naming a threshold has not done this.

What you are actually listening for

Across all five, depth shows in the narrowing, not in the naming. Do they ask what changed recently before they theorise? Do they distinguish out loud between what they know and what they are assuming? Do they say at what point they would stop debugging and roll back? Are they comfortable saying they do not know, and then describing how they would find out? A candidate who produces a confident answer to every question with no uncertainty anywhere has generally read about these problems rather than had them.

Linux and Networking Are What Actually Separate Seniority Here

Tooling knowledge dates. The layer underneath does not, and it is where the difficult incidents live, because every abstraction you run eventually leaks onto it. If I had twenty minutes with a candidate and nothing else, this is the section I would protect.

DNS, which is the answer more often than anyone expects

Ask somebody to walk you through what happens between an application calling a hostname and a connection opening. You are listening for resolver configuration, the search domain list, the difference between a cached answer and a fresh one, and what a negative answer does. In a Kubernetes context, the specific worth hearing is the ndots setting in the generated resolv.conf, which is why a lookup for an external hostname can fire several failed queries against internal search domains before the real one succeeds. That one detail has explained more mysterious latency than any profiler I have watched anyone run.

The other DNS answer that marks experience is the incident where the record was correct and the problem was cache. A short time to live is what makes a failover possible, and nobody thinks about it until the day they need to move traffic and discover the value is 86400.

TLS, beyond knowing it means encrypted

The useful questions here are about the chain. Which certificate does the server send, in what order, and does it include the intermediate? Why does one client accept a connection another rejects? What does the Server Name Indication field do when several sites share an address, and what breaks when it is absent? TLS 1.3 was published as RFC 8446 in 2018 and cut the handshake to a single round trip, which matters when your traffic crosses oceans. Anyone who can talk about handshake cost and session resumption has thought about performance, not just about the padlock in the address bar.

Certificate rotation belongs here too, and it joins up with the Sunday outage question above. Knowing how to inspect what a live endpoint presents, rather than what is written on disk, is a small skill that rescues entire evenings.

Routing and the path a packet takes

Connectivity failures divide neatly once you know where to look. Is it name resolution, routing, a filter, or the application refusing the connection? Each leaves a different signature, and somebody who knows the difference between a connection refused, a connection timed out and a connection reset is already ahead of the field. Ask about MTU while you are there. Overlay networking adds header overhead, with VXLAN encapsulation costing fifty bytes a packet, and a mismatched MTU produces the nastiest class of bug there is: small requests work perfectly, large ones hang, and everybody blames the application.

Two more separate people who have run busy systems from people who have not. Ephemeral port exhaustion, where a service making many short outbound connections runs out of source ports and everything fails at once. And connection tracking tables filling on a gateway, which drops packets and writes a log line most people have never read. Neither is exotic. Both are invisible if you have only ever worked above the load balancer.

systemd, because processes still have to be supervised

Containers did not remove the need for this. Ask what happens when a service configured to restart always crashes repeatedly, and whether they know about the start rate limiting that eventually gives up trying. Ask where the logs went and how they would query them for a specific time window. Ask about ordering and dependency directives, and what a unit does when the machine is short of memory. Deeply unfashionable knowledge, and it surfaces on your worst day.

File descriptors and the wall you hit at scale

Every socket, every open file, every pipe consumes a descriptor, and there is a ceiling. When you reach it the error surfaces as something unhelpful in an application log and the service starts refusing connections while looking perfectly healthy on CPU and memory. So ask what they would check when a process refuses new connections but is not busy. You want counting the open descriptors for that process, comparing against the applicable limit, and knowing that the limit configured in a systemd unit is what actually governs the service rather than whatever an interactive shell reports.

The follow-up is the one that matters: is the limit too low, or is something leaking? Raising a limit on a leak buys you a few hours and a worse outage later. A senior answer says that unprompted.

cgroups, and why the container was killed

Memory limits are enforced by the kernel, and when a container exceeds its limit the kernel kills a process inside it. The application log usually shows nothing at all, because the process never got the chance to write anything. Ask how they would confirm that is what happened rather than assuming it. Ask about the difference between a limit and a request, and what oversubscription does to a node when several workloads decide to grow at the same time.

Current distributions including Ubuntu 22.04 and RHEL 9 default to cgroup v2, which reorganised how controllers are arranged and how memory pressure is reported. Somebody who knows there are two versions and can say why the difference matters has been close to the kernel side of container behaviour. Somebody who thinks a memory limit is a suggestion has not.

On-Call, and the One Genuine Advantage of an India Team

Most offshore pages either avoid the timezone question or dress it up. Here is the arithmetic, then the part that is honestly good, then what it costs.

The arithmetic, done properly

India runs on IST, which is UTC+5:30, and there is no daylight saving, so the offset never moves. Take the Indian working day most teams run, 09:30 through 18:30 IST. In UTC that is 04:00 to 13:00, and it stays those same nine hours every day of the year. Everything below follows from that one line.

Read those last three rows slowly, because they are the ones vendors skip past. On standard hours, both American coasts get no overlap at all with a normal Indian day. Not a little. None. Anybody telling you otherwise is either shifting somebody's schedule without mentioning it to you, or counting a five-minute boundary as collaboration.

So a US engagement means an Indian working day that begins in the afternoon. Three hours of live overlap with a New York morning puts the engineer at their desk until around 21:30 IST. That is a real evening belonging to a real person, and it holds up only when it is agreed openly and staffed as the norm, rather than discovered as a surprise in week six. Arrangements people never consented to do not last, and the way they end is a resignation rather than a complaint.

Where the offset genuinely pays

Now the good part, and it is specific to infrastructure work rather than a general offshore benefit. Incidents ignore office hours, and the shift nobody wants is the overnight one.

Work it through. A US Eastern night of 22:00 to 06:00 is 03:00 to 11:00 UTC, which is 08:30 to 16:30 IST. A US Pacific night of 22:00 to 06:00 is 06:00 to 14:00 UTC, which is 11:30 to 19:30 IST. Your most dreaded shift is, seen from India, an ordinary working day. The person picking up that page is awake, at a desk, with the runbook open and a colleague two seats away to argue with. Set that against the same page waking somebody at home at 3am, alone, thirty seconds away from a decision about your production database.

That is a structural advantage and it is the honest reason to consider an Indian team for operations specifically. It is not a slogan, it is the clock.

What a real rotation costs, stated plainly

Here is the part that does not appear on sales pages. Covering the American night from India does not give you round-the-clock cover. It covers one window well. Somebody still has to hold the Indian night, and that is another person, not a bonus.

A rotation that survives needs enough people that no individual is permanently on. One person carrying every page has no holiday, no sick day and no evening, and the reliable outcome is that they resign inside a year and take the only copy of how the system works with them. Two is the floor. Three is where it stops being punishing. Genuine cover around the clock is headcount you are buying. It is perfectly fair to want it, and it belongs in your plan as a cost rather than as something the timezone hands you free.

What makes rotation gaps hard to solve is timing. You notice one because somebody is already carrying too much, so the need is urgent by definition, and recruiting into it in your own market puts a start date months out. We keep engineers on the bench rather than beginning a search when a brief arrives, which is what makes matching within 48 hours and a start inside 7 days achievable. That is the specific reason to talk to us about a rotation gap. It does not alter the arithmetic above, and it does not make the second person free.

There is a second cost that is easy to miss. Handover between windows only works when it is written. A rotation with no written handover produces the same incident investigated twice by two people who never spoke, which is worse than having no rotation. Who is on the rota, what the handover format is, and where escalation goes are agreed with you before anybody carries a pager, and written down rather than assumed.

What to settle before anyone gets production access

Independent of timezone, decide these in advance and put them in writing with us. Which environments the engineer can reach and by what route. Whether access is standing or requested per task. Where the log of their activity goes and who reviews it. What device and network policy applies. What happens to access on the day the engagement ends. Who your named escalation contact is, and who theirs is. None of it is unusual, and every hour spent on it before day one is an hour you do not spend arguing during an incident.

Four Situations Where Teams Come to Us

These are patterns rather than accounts of particular clients, composites drawn from the briefs that reach us most often. If one of them describes your week, the recommended first move is in the last line.

How Hiring a DevOps Engineer in India Works With Us

We keep engineers on the bench instead of recruiting against each brief, so the shortlist reaches you within 48 hours of the first conversation and a start inside 7 days is realistic. Here is what happens in between.

Flag a bad match and someone else is in front of you inside 48 hours, and the seat is filled from our bench of engineers rather than by whichever single name we happened to send first.