Prompt and context
You maintain a cross-language observability contract used by SDKs, collectors, dashboards, and alerts. The team wants to move conventions from development to stable so downstream users can depend on them; the platform team fears unresolved meaning, dual writes, and high-cardinality cost. Assume three months of real telemetry and two pilot services are available.
What the interviewer evaluates
The interviewer is testing whether you explain “stable” as a compatibility promise rather than documentation completeness. A strong answer checks names, types, units, requirement levels, enums, and privacy boundaries; measures adoption, query correctness, cardinality, and migration cost; and preserves a transition path for incompatible changes.
Clarifications to ask first
- Which downstream alerts, billing reports, or compliance reports already depend on the fields? More dependencies require a stronger stability bar.
- Which signals and languages are covered? Defaults must agree across SDKs.
- Are there high-cardinality values, sensitive data, or ambiguous enums? Resolve these before stabilization.
- How long must compatibility last? Existing collectors may require version selection or opt-in migration.
- Is success adoption, reusable queries, or fewer custom fields? The goal changes the pilot metrics.
30-second answer framework
“I would not promote a convention because it has enough fields. I would audit semantics, types, units, requirement levels, enums, privacy, and cross-SDK behavior, then validate real downstream queries. I would promote only after pilot services use the stable version, compatibility tests pass, cardinality and cost stay within guardrails, and migration and deprecation paths are explicit. Otherwise I would keep development or alpha and record the next decision gate.”
Step-by-step deep answer
- Define the promise. OpenTelemetry conventions use development, alpha, beta, release candidate, and stable levels. Stable means downstream users can rely on compatibility guarantees.
- Audit semantics. Check names, value types, units, requirement levels, enums, and examples for consistency. Return attributes with useful-sounding but unclear use cases to discussion.
- Validate real usage. Sample three months of data and replay dashboards, alerts, log correlations, and cross-language queries. Record missing and unknown values.
- Control cost and privacy. Measure cardinality, storage, and query cost from new attributes. Never put user identifiers, raw content, or secrets in attributes; use hashing or controlled categories when appropriate.
- Design versioning. Keep experimental conventions in a development namespace. During stabilization, provide version selection or opt-in, compare old and new results during dual write, and publish a deprecation date.
- Set gates and rollback. Promote only after two pilot services meet compatibility tests, 99.9% query correctness, missing rate below 1%, and cardinality growth below 20% for two release cycles. Any breach returns to opt-in.
Alternatives include releasing beta first, stabilizing only a core attribute set, versioning each signal separately, or mapping old fields in a collector transform. Stabilization must not hide unresolved sampling, authorization, or data-quality problems.
Model answer
“I treat stable as a compatibility product promise. First I inventory alerts, reports, collectors, and SDKs that depend on the convention, then audit names, types, units, requirement levels, enums, and privacy. I replay critical queries against three months of real telemetry and compare missing values, unknown values, cardinality, and cost across two services in different languages. I would require 99.9% query correctness, missing rate below 1%, cardinality growth below 20% for two release cycles, plus a deprecation date, dual-write plan, and rollback path before marking it stable. If meaning is still disputed, I keep development or beta and state the evidence required for the next review.”
Common mistakes
- Mistake: Use adoption or field count as proof of stability → Why it fails: Stability is a compatibility promise → Fix: Add cross-SDK, query, and migration tests.
- Mistake: Put every business field into the convention → Why it fails: Cardinality and privacy risk grow quickly → Fix: Keep only attributes with clear use cases and bounded cost.
- Mistake: Replace old fields immediately → Why it fails: Downstream queries can silently change meaning → Fix: Provide version selection, dual write, comparison, and deprecation.
- Mistake: Ignore unknown and missing values → Why it fails: Dashboards look complete while conclusions are unreliable → Fix: Make data quality a stabilization gate.
Follow-up questions and responses
Can a stable convention keep a renamed core field?
If the rename changes downstream query semantics, keep the old field, add a version, publish a mapping, and set a deprecation window. Consider a compatibility alias only when semantic equivalence and migration cost are demonstrated.
How do you handle different SDK defaults?
Build cross-language contract tests with the same inputs and verify field names, types, units, and requirement levels. Do not widen stable scope while defaults disagree.
What if cardinality rises but business queries become more accurate?
Evaluate accuracy gains with storage, query latency, and cost ceilings together. Opt in high-value services first and add sampling, aggregation, or dimensionality reduction.
When should stabilization stop?
Stop and return to development or beta when semantic disputes remain, missing rate or cardinality breaches guardrails, privacy review fails, or pilot queries cannot be reproduced. Record the evidence gap.