1. Toil and automation

The interviewer says half your team's time goes to manual operations work and asks how you decide what to automate. The first question is whether that work is toil. Toil is operational work done by hand, over and over, that a script or system could do and that leaves the service no better afterwards. On a photo-sharing app, it is an engineer editing one business customer's upload quota for the hundredth time this month.

The principle is to count where the team's hours go, keep toil under a cap (a common rule is at most 50% of the team's time), and automate by hours saved and risk removed. A task climbs from a written runbook to a script to a self-healing system, one that triggers its own fix, only as far as it is safe for the automation to be wrong. Reach for this when tickets and pages grow with the service and nobody has time left for reliability work.

Skip it for a task done a few times a year that needs judgement, where a current runbook is enough. A service with little operational load can write its steps down and revisit when a count shows hours piling up.

This is a common site reliability engineering (SRE) and platform question and takes a few minutes in a general design round. Mid-level candidates define toil and name candidates to automate. Senior candidates rank by payback and risk, choose how far each task climbs, and say how the automation is kept from becoming an outage.