A mentee sent me his CV last week with “built ChatOps for our platform team” on the second line, and I did him the favour every reviewer eventually does: I started asking questions. What did the bot run? Who approved the dangerous commands? Where did the audit trail live? His answers started strong and faded fast — he had wired a tool, not learned a practice. ChatOps, for anyone meeting it cold, is the working style where operational tasks run through a shared channel: a bot posts events and carries out reviewed commands, keeping the work, its outcomes and the surrounding conversation visible, permissioned and on the record. Wired tools fade from CVs; practices compound. The ten checks below are the questions I asked him, written so you can audit yourself before an interviewer does it for you.
Checks One to Three: The Foundation Questions
Check 1 — Say what the practice is in one honest sentence. If your definition names a product, restart here. The real thing is a pattern: work announced and executed in the open, restricted by permissions, recorded outside the conversation. It is not software you license and not a certificate you hold, which is why interviews probe for understanding rather than vendor names.
Check 2 — Retrace the path from the Enter key to the system it eventually reaches. The request crosses an adapter (translation from platform traffic), a gateway (your policy, deciding), and executors (reviewed programs acting on real systems) — then passes five checks in order: verify the request’s origin, attach it to a permanent user identifier, authorize that identity, collect approvals where required, and write the outcome to an audit store. Candidates who recite the order — and know why the order is fixed — are describing design, not memorizing.
Check 3 — Design a risk ladder on a whiteboard. Every action graded: notes that do nothing but announce; queries that touch nothing; undoable writes restricted to particular roles inside particular channels, with a record kept; high-impact operations that wait for two people; and a break-glass override for emergencies, itself logged and read back in review. If you can draw this in two minutes and say why dual authorization appears in formal security guidance (NIST’s AC-3(2)), you sound like someone who has carried a pager, not someone who has read about one.
Checks Four to Six: The Trust Questions
Check 4 — Explain why identity never rests on display names. Names in chat are costumes, changed in a settings panel, copied without effort. Authorization keys off the platform’s permanent identifier per user, and a map you keep from that identifier to the human behind it. Mention the confused-deputy failure here — privileged intermediaries spending their authority at someone else’s direction, exemplified by automation defaults that ran everything under a single shared account such as StackStorm’s chatops_bot — and you demonstrate threat modelling rather than tool use.
Check 5 — Compare how platforms prove origin. Slack signs its requests; receivers verify the HMAC-SHA256 signature, honour a five-minute replay window, and answer inside the 3,000-millisecond acknowledgement budget. Teams presents verifiable signed JWTs. Mattermost most commonly issues static tokens that leave a request’s contents unchecked, so the body says whatever its sender writes — the weakest of the three, and the one needing compensation. Interviewers love this question because it separates people who read a quickstart from people who implemented a receiver.
Check 6 — Tell the migration story with dates. Platforms retire; Hipchat and Stride shut entirely, Slack retired its original custom-bot framework in March 2025, Microsoft sunsets Teams Connectors in May 2026, and Opsgenie closes its doors on April 5, 2027. The lesson you should be able to tell in first person: logic that lived in your own gateway outlived every one of those events, which is why GitHub’s 2021 relocation of deploy state into a dedicated state machine — chat reduced to the trigger — gets cited so often. A CV that claims channel automation without an adapter-agnostic story is claiming a liability.
Checks Seven and Eight: The Judgment Questions
Check 7 — Read a refusal report and act on it. The gateway declines requests; the weekly review of those refusals is where guardrails get tuned. Can you say what a healthy refusal pattern looks like — enough refusals to prove the fence exists, few enough to show it is aimed well — and what you changed the last time the mix went wrong? Governance habits like this one, along with the quarterly scope audit of commands and credentials, are what “owned the bot” should mean on a CV.
Check 8 — Say where the record lives, and why not in chat. Scrollback edits, expires under retention, and vanishes when platforms retire; the audit log is append-only, externally stored, and written under a stable schema as work happens. Fold in the adjacent rules — commands enumerated on an allow-list, never prose handed to a shell; channels pinned by their immutable IDs rather than by whichever display name happens to sit on them today — and you have covered the failure modes that cost real teams real outages.
Checks Nine and Ten: The Evidence Questions
Check 9 — Quote metrics you moved, not metrics you watched. The vocabulary: audited change coverage (one published worked case runs at 93.9% — the share of production-touching actions on the guarded path), command success (98.1% there), approval latency, the refusal mix, and the actionable share of notifications (23% measured against a 50% target in that case). Personal-brand bonus: publish your own numbers from a lab or employer project. Counts of commands executed impress nobody who has read the field; coverage that improved under your hands impresses everybody.
Check 10 — Tell an AI-era story. Assistants now sit in these channels proposing actions. The rule is directional — they propose, humans approve, and a model never approves its own suggestion — and the evidence is public: the August 2024 PromptArmor disclosure of prompt injection against Slack’s AI, the OWASP LLM catalogue (LLM01, LLM06) describing the class, and defaults like Amazon Q Developer in chat reaching for AdministratorAccess when guardrails go unset. Logging prompts and tool calls is the habit that turns this from an opinion into a practice.
How to Build What You Cannot Yet Claim
Every check above is practicable at lab scale in a fortnight: one platform, one read-only command, origin verification written by hand, an external log file, a two-person rule enforced by a colleague who owes you a favour. The deeper engineering habits — reviewing what you ship, avoiding the classic beginner errors, automating the pipeline that delivers your bot’s code — transfer from adjacent work; readers strengthening those foundations will find the Docker image management practices for engineering teams and the container mistakes beginners should sidestep cover the same discipline from the packaging side, while Docker’s role in CI/CD pipeline automation is where many channel-run actions actually originate.
My mentee rewrote his second line after our conversation — same project, different claim: “reduced untracked production changes to zero by moving deploy actions behind a reviewed, audited channel gateway.” That is a sentence an interviewer can test, and a practice a career can compound on. The reference both versions of the claim rest on is the Ops Atlas ChatOps profile, where every check above traces to its source; audit yourself against it, then write only what survives the audit.
