Interrogate the Init System: What to Ask Before You Inherit Someone Else's Daemon Graveyard

Three years ago I sat in a glass-walled conference room in Austin, nodded along to a pitch about "modern cloud-native tooling," and accepted a job offer without asking a single question about the infrastructure I'd be inheriting.

Fourteen months later, I could restart a 2011-era Python daemon from muscle memory. Not because I'd practiced — because I'd done it at 2:47 a.m. every single week. The "modern cloud-native tooling" was three bash scripts named start.sh, start2.sh, and start_FINAL.sh.

This is the guide I wish someone had handed me. You spend 2,000 hours a year at a job; treat the interview like due diligence, not a first date.

The Interview Is a Two-Way Street, and You're the One Without a Map

Here's the thing most candidates miss: interviewers expect technical questions. Asking about their stack isn't rude — it signals seniority. A hiring manager who gets defensive when you ask about their on-call rotation is telling you something, and that something is "run."

Start every technical conversation the same way: "Walk me through what happens when a service goes down at 3 a.m. Who gets called, and what do they see?"

The answer to that one question will teach you more than four rounds of whiteboarding.

Five Questions That Reveal Everything

1. "How many long-running services does the team own, and how many are documented?"

Every company has daemon sprawl. The healthy ones know their numbers. If the answer is a shrug, or "depends what you count," you're not joining a team — you're joining an archaeological dig. One interviewer once told me, with a straight face, "there's a Java process on the old rack, we don't know what it does, but things get weird when it stops." I declined the offer. Things get weird when it stops.

2. "What's your on-call rotation like — frequency, compensation, and post-incident process?"

Listen for three things: a rotation length (weekly or longer means more context, daily means death by a thousand pages), whether on-call is compensated or at least rostered fairly, and whether they do blameless postmortems or perform rituals of public shaming. If they say "we don't really have pages anymore," ask what replaced them. Silence is not an architecture.

3. "How do you deploy config changes?"

This sounds boring and is secretly devastating. If the answer involves SSHing into boxes and editing files by hand, congratulations — you've found a snowflake farm, and every snowflake is yours now. You want to hear words like "reviewed," "versioned," and "rolled back last Tuesday and it was fine." You do not want to hear "we have a wiki page for that."

4. "Tell me about your oldest service."

Great teams talk about their legacy systems with something like affection — they know why the crusty old thing exists and what it would cost to replace. Bad teams talk about theirs like a haunted relative in the attic. The answer tells you whether you'll be a maintainer or an exorcist.

5. "When was the last incident, and what changed afterward?"

Everyone has incidents. The question is whether anything changes. If they can name a recent incident and a concrete fix — a new alert, a timeout added, a runbook written — that's a team that learns. If they say "we haven't had a real incident in years," they either aren't monitoring or aren't telling you. Both are bad, one is worse.

Red Flags I Have Personally Witnessed

Consider this a field guide, compiled from my own scars and those of every sysadmin I've ever bought a beer:

• A hand-rolled init system. If someone wrote their own process supervisor in 2019 because "systemd was overkill," that person is still there, and their code is now load-bearing.
• "We don't really use monitoring." Translation: you are the monitoring.
• The previous admin left "suddenly." Ask what happened. Watch their faces.
• A staging environment that's "basically the same as prod." It is not, and you will find out how it's not during business hours, on a Tuesday, in front of the VP of Sales.
• Tribal knowledge held by one person. Ask how many people can restart the billing pipeline. If the answer is one and that person is "on sabbatical," update your resume.

Green flags exist too: runbooks that were updated last month, a rotation schedule pinned in a public channel, and anyone who says "that's on our tech debt list" without flinching. Teams that name their problems out loud are teams that fix them.

The Checklist: Print This, Bring It to Every Final Round

• Rotation length and on-call compensation confirmed in writing
• Number of owned services, documented vs. undocumented
• Deployment story: reviewed, versioned, rollback tested
• Oldest service: known purpose, replacement plan (or loving tolerance)
• Last incident: what broke, what changed afterward
• Monitoring exists, alerts are tuned, pages are rare and real
• No hand-rolled init system (or at least the author has left the building)
• More than one person can operate every critical service
• You met a future teammate and they seemed... okay. Not fine. Okay.

Score it however you like. If you're checking fewer than six boxes, ask yourself whether the salary premium covers the 2:47 a.m. restarts. It never does. It never has.

I stayed at that Austin job too long because I liked the people and ignored the pager. The people were great. The pager was not. These days I ask about init systems in the first phone screen, and I've never once been sorry.

Your future self, awake at 3 a.m. with a laptop balanced on a chest of drawers, would want you to ask the questions. Ask them.