2 min lesson
Close with the service contract
Take this situation: "You've sketched the full auth flow for the editor. What should an Engineering Manager for Core Services add that a strong IC candidate would likely leave out?" Lead with your decision, then add the reason.
Step 1 of 2
Close with the service contractthis is the EM differentiator
An IC stops at the design. An EM for Core Services closes with the contract: what guarantees this layer exposes to the product teams who build on it and how it changes them without breaking everyone.
- What we expose. A token-verification primitive (local, microsecond-fast), an authz-decision API and a documented claim shape. Product teams never reimplement auth.
- Our guarantees. A stated availability SLO for token issuance, a verification latency budget and a maximum revocation-propagation window so callers know how stale a permission can be.
- How we version. Additive claim changes are backward-compatible; breaking changes ship behind a new claim version with an overlap window and contract tests, the same overlap discipline as key rotation.
"I'll close on the contract, because that's the Core Services job. We expose local token verification, a central authz decision and a stable claim shape, with an SLO on issuance availability and a stated maximum revocation-propagation window. Breaking changes ride a versioned claim with an overlap period and contract tests - so product teams can build on us without auth becoming their problem."
Don't present this as a closed monologue. Cursor's loop rewards spirited, truth-seeking debate, so invite the panel to push: "Where would you push back on the fail-open call?" Defending a trade-off under challenge - and conceding when they're right - shows more than a flawless diagram does.