Writing engineering-owned KRs for engagement

WHAT THIS TESTS The interviewer is checking that you understand the difference between outputs and outcomes and can translate a fuzzy objective into KRs that are specific, measurable, and time-bound, and that engineering can actually move.

A GOOD ANSWER COVERS First pick levers engineering controls that plausibly drive engagement. Performance, reliability, and activation are classic ones. Then phrase each KR with a baseline, a target, and a date. For example: reduce median feed load time from 1.8s to under 1s by end of Q3; increase day-one onboarding completion from 60 to 75 percent by end of quarter; cut the crash-free-session rate gap by lowering crashes from 2 percent to under 0.5 percent in eight weeks. Each is measurable, bounded in time, and owned by engineering, while clearly laddering up to engagement.

COMMON WRONG ANSWERS Writing output KRs like ship the redesign or deploy three features, which measure activity not impact. Choosing metrics engineering cannot influence directly, such as total revenue or marketing-driven signups. Omitting baselines or deadlines so success is unfalsifiable. Picking a vanity metric like raw time-on-page that can rise even as satisfaction falls.

LIKELY FOLLOW-UPS How would you guard against gaming these KRs? Which KR would you drop if forced? How do these connect to the objective causally rather than by assertion?

ONE CONCRETE EXAMPLE For 'improve user engagement,' three engineering-owned KRs might be: cut p95 API latency on the core flow from 900ms to 400ms by quarter end; raise first-week return rate from 30 to 40 percent by improving notification reliability; and reduce error rate on the primary action from 1.5 percent to under 0.3 percent within six weeks. Each has a number, a target, and a clock, and each is something engineering can directly affect.