Explain the difference between Objectives and Key Results in OKRs

What's really being asked

This question tests whether you understand goal-setting semantics at a senior level. Interviewers want to see that you can separate qualitative vision from quantitative proof, and that you know engineering OKRs focus on technical quality rather than customer value. The distinction between Objectives and Key Results is foundational to outcome-based management, and confusing them leads to teams measuring activity instead of impact.

The full answer

First, define an Objective as an inspirational, qualitative statement of direction that answers what the team wants to achieve. It should be memorable, directional, and free of numbers. Second, define a Key Result as a specific, measurable, time-bound outcome that proves the Objective has been met. Third, clarify that Initiatives are the concrete work done to move Key Results, creating a clean hierarchy of Objective, then Key Result, then Initiative. Fourth, anchor the example in engineering-specific quality dimensions such as reliability, performance, security, or dev speed rather than product functionality or user growth.

The mistakes people make

A major red flag is describing a Key Result as a task, output, or milestone, for example saying the KR is to ship a monitoring dashboard or refactor a service. Those are Initiatives. Another red flag is making the Objective itself numeric or transactional, such as an Objective to reduce latency by fifty percent; that is actually a Key Result. Candidates also stumble by providing a product OKR example focused on customer value instead of an engineering OKR focused on technical work quality.

What usually comes next

The interviewer may ask how you would cascade this OKR to individual contributors without turning it into a performance review. They might probe how you balance pure outcome KRs with pragmatic output KRs for complex infrastructure work. Another common follow-up is how you prevent teams from sandbagging by setting easily achievable Key Results, or how you reconcile engineering OKRs with product OKRs when they overlap.

A concrete example

Objective: Deliver the most reliable payment processing platform in our industry. Key Result one: Reduce critical payment error rate from two point five percent to zero point one percent by end of quarter. Key Result two: Achieve ninety nine point nine nine percent uptime for the payment gateway, measured via synthetic monitoring. Key Result three: Decrease mean time to recovery for payment incidents from forty five minutes to under ten minutes. This example stays in the engineering quality domain by targeting reliability and operational excellence rather than user-facing feature adoption.