Operations
42 bites tagged Operations — interview questions with model answers, and 60-second explainers.
Distinguishing toil from necessary ops work
Toil is manual, repetitive, automatable, tactical, and scales with growth; engineering and judgment-heavy work is not toil. Defining toil precisely. calling all ops work toil, or thinking toil means unimportant work.
SRE vs traditional ops on a recurring alert?
Traditional ops repeatedly handles the alert manually and scales by adding people; SRE treats it as a bug, automates or eliminates the root cause, and scales sublinearly. whether you grasp the software-engineering mindset of SRE.
What defines toil, with an example?
Define toil as manual, repetitive, automatable, tactical, no-enduring-value, scaling-with-growth work; distinguish it from overhead; give a concrete example. whether you can identify operational work worth automating away.
Hiring for SRE
Hiring for SRE seeks engineers who blend software-development skill with systems and operations depth, plus strong debugging and incident temperament. The hardest part is finding people who can both write automation and reason about failure at scale under…
Runbooks
A runbook is a documented, step-by-step procedure for handling a specific operational task or known failure, such as responding to an alert. It captures expert knowledge so any on-call engineer can act quickly and consistently, reducing reliance on tribal…
Managed RDS vs self-managed DB on EC2
Managed RDS offloads patching, backups, failover, and replication, freeing the team to build product; self-managed EC2 means you own all that toil. build-vs-buy operations. dismissing the hidden operational burden of DIY.
Least privilege for database service accounts
Grant each account only the minimum rights its job needs; for an app service account, scope grants to specific tables and verbs, never use the superuser. secure access design.
Full, differential, and incremental backups
Full copies everything; differential copies all changes since the last full; incremental copies changes since the last backup of any type. backup-strategy tradeoffs.
Automate patching across a VM fleet
Use a patch or config tool to target by tag, roll out in canaried waves with health checks, and prefer immutable golden images long term. fleet configuration management. SSHing into each of 100 boxes by hand.
etcd as the cluster source of truth
Etcd is the consistent key-value store holding all cluster state, accessed only via the apiserver, and uses Raft needing a quorum. understanding the cluster state store.
Explain blue-green deployment, its prerequisites, and how it reduces deployment risk.
Tests operational maturity for zero-downtime cutover. Great answers: parallel environments, load balancer switching, backward-compatible schemas, externalized state, and instant rollback vs partial in-place failure.
Describe a workflow to automate a 50-person diary study
Tests operational UX research automation and API integration. A strong answer maps a pipeline of calendar APIs, email triggers, and reminder bots with no-show fallbacks. Red flag: manual spreadsheets or survey tools lacking scheduling logic.
The 8 Pillars of ResearchOps
ResearchOps is the operating system behind scalable user research, not just scheduling. The 8 pillars map ops gaps like governance or tools. The footgun is treating it as a checklist to implement all at once rather than a diagnostic for triaging pain.
No-Show Management: Research Calendar Insurance
No-show management treats research calendars like airline seats: you expect flakes and overbook so one absence doesn't ground your sprint. It is vital for moderated sessions with hard-to-recruit users.
ResearchOps Maturity Matrix: Built for Operations
UX maturity scores insights; ResearchOps maturity scores the factory producing them. Use it to audit governance, participant pipelines, and tooling strategy. The mistake is judging research quality instead of operational infrastructure.
ResearchOps: The Pit Crew for User Research
ResearchOps is the backstage crew that makes user research scale. It provides roles, tools, and processes so researchers focus on insights, not logistics. Teams often assume researchers self-manage operations, which bottlenecks research as companies grow.
DevOps Is Culture, SRE Is Engineering
DevOps is a cultural philosophy for fast, safe delivery; SRE is the engineering discipline that implements it with error budgets and SLOs. They are complementary, not rival job titles. The footgun is hiring SREs and declaring DevOps done.
Design a scalable documentation system for three engineering teams
Tests prioritization and process design for a sole writer supporting three engineering teams. Strong answers use tiered intake with SLAs, a public Kanban board, and async status updates. Red flag: ad-hoc prioritization through Slack DMs with no queue.
Customer Success Playbooks: Standardize Your Team's Responses
A Customer Success playbook is a recipe for handling key customer moments. It defines a standard workflow for events like onboarding or a drop in usage, ensuring every CSM follows the same proven process. Without them, customer experience is inconsistent.
Post-Incident Review: Learning from Failure, Blamelessly
A Post-Incident Review (PIR) is a blameless process to learn from an outage, not to assign blame. Use it after a production incident to identify systemic flaws and create action items to prevent repeats.
Shared Ownership Model: Bridging the Dev/Ops Divide
The shared ownership model ends the tug-of-war between developers wanting to ship and operations teams wanting stability. Both teams share responsibility for service quality, using SLOs as a common language.
SRE Office Hours: Scaling Expertise Through Consultation
SRE Office Hours are a scheduled time for development teams to get expert advice from SREs, scaling reliability knowledge without embedding them everywhere. Use them to review designs or define SLOs. The footgun is treating them as on-call support.
The SRE Mandate: Breaking the Dev vs. Ops Cycle
SRE breaks the classic conflict between developers who want to ship fast and operations teams who want stability. It treats operations as a software problem, not a human one. The footgun is creating a rebranded sysadmin team that still does manual work.
Game Days: Practice Breaking Your System Before It Breaks Itself
A Game Day is a live fire drill for your systems. You intentionally inject failure—like shutting down a service—to see how your team and automation respond, finding weaknesses before a real outage does.
Get Operations bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.