Technical Requirements and Specifications Questions

Covers the end to end practice of translating product vision and business goals into clear, actionable technical requirements and specifications that engineering teams can implement. Includes writing product requirement documents and technical specifications with problem statements, success metrics, user and developer personas, API contracts and interfaces, data and schema considerations, functional requirements, and non functional requirements such as performance targets, latency and throughput expectations, scalability goals, reliability targets and service level objectives, security and privacy constraints, backward compatibility, and rollout and migration strategies. Encompasses requirements gathering techniques such as stakeholder identification, discovery conversations, clarifying questions, scoping, constraint identification for budget and timeline, defining measurable acceptance criteria, traceability to business objectives, and documenting assumptions and open questions. Also covers communicating requirements effectively to engineering and cross functional partners, knowing how to be specific without over constraining implementation, iterating requirements as learning emerges, and involving engineers early so they provide technical input and ownership.

MediumTechnical

23 practiced

Define three developer personas for a public developer portal (e.g., hobbyist, backend engineer at a mid-sized startup, enterprise systems integrator). For each persona list goals, skills, typical pain points, and two concrete acceptance criteria you would use to measure onboarding success (examples: time-to-first-call, percent of successful calls within first 24 hours).

HardTechnical

30 practiced

Your service relies on a third-party payments API. Specify SLIs and SLOs you would set for that dependency and describe resilience requirements to include in your technical spec: circuit breakers, retry/backoff policies, fallback behavior, and quota isolation. Also propose monitoring signals and escalation steps when the third party breaches its SLO.

Sample Answer

**SLIs & SLOs (for third‑party payments API)** - Availability (successful auth + capture responses / total requests) — SLO: 99.95% monthly. - Latency (p95 end‑to‑end to authorization) — SLO: <= 300ms. - Error rate (4xx/5xx from provider) — SLO: <= 0.5% of payment flows. - Partial failures (timeouts/retries) — SLO: <= 0.1% requiring manual reconciliation.

**Resilience requirements (to include in technical spec)** - Circuit breaker: open after 5 consecutive 5xx or timeouts in 1 minute; cooldown 2 minutes; half‑open probe single request. Rationale: prevent cascading failures and protect downstream systems. - Retry & backoff: idempotent requests retried up to 2 times with exponential backoff (100ms, 500ms) only on network/timeouts or 429; do NOT retry on 4xx (invalid card). Include idempotency keys for safe retries. - Fallback behavior: for non‑critical flows allow queued offline capture with guaranteed-at‑least‑once semantics and user notification; for checkout critical paths surface graceful error page and alternative payment methods. - Quota isolation: per-tenant and per-service rate limits and token bucket shaping; enforce priority lanes for high‑value transactions to avoid noisy neighbors.

**Monitoring signals** - Real‑time dashboards: SLI trends, circuit breaker state, retry counts, 429/5xx breakdown, p50/p95/p99 latencies, queue depth for offline captures. - Alerts: SLO burn rate alert (e.g., 50% burn in 1 hour), circuit breaker open > 2 mins, retry rate spike > 3x baseline, queued captures > threshold.

**Escalation & runbook** - Pager on high burn rate or persistent circuit breaker: on‑call SRE -> escalate to Payments PM and vendor support within 15 mins. - If vendor SLO breach confirmed: enable degraded mode (disable noncritical payments, route to alternative gateway if available), notify customers/merchants with ETA, open incident in status page. - Post‑incident: RCA with vendor, contract SLR review, consider SLA credits, increase isolation or add secondary provider.

This spec balances customer experience, operational safety, and measurable accountability with concrete thresholds and recovery actions.

MediumTechnical

33 practiced

Write a concise technical requirements section (200–400 words) for a paginated product search API used by internal and external clients. Specify supported filters, pagination strategy (cursor vs page), max page size, sorting guarantees, expected throughput and latency with SLOs, error handling, authentication, and acceptance criteria including performance tests. Assume a 10k QPS peak and mixed read/write workload.

HardTechnical

27 practiced

Draft an API contract and schema-evolution policy for an event-driven system using Avro/Protobuf over Kafka. Explain additive vs breaking changes, compatibility modes (backward, forward, full), how to use a schema registry, and provide a migration plan for a breaking change example (e.g., changing a field type) that affects multiple downstream consumers. Include monitoring and rollback steps.

Sample Answer

**Context & goal**As a Technical PM I’d define a clear API contract and schema-evolution policy so producers and consumers using Avro/Protobuf over Kafka can evolve safely with predictable migrations and SLAs.

**API contract (summary)**- Transport: Kafka topics per logical event.- Schema: Avro or Protobuf stored in Schema Registry. Each event has a canonical subject: <namespace>.<eventName>-value.- Contract fields: name, version, owner, lifecycle (deprecated/removed), required consumers, SLAs for changes (e.g., 2-week deprecation notice), test harness link.

**Compatibility modes (definitions)**- Backward: new schema can read data produced with older schema (consumers using new code can read old events).- Forward: old consumers can read new data (new producers are compatible with old consumers).- Full: both backward and forward (strongest).

**Additive vs breaking changes**- Additive (safe): adding optional field with default, adding enum values (Avro: with default), adding new message. Allowed under backward compatibility.- Breaking: removing field, changing required -> optional vice versa without defaults, renaming, changing field type (e.g., int -> string) — require migration.

**Schema Registry usage**- Enforce chosen compatibility mode per subject.- Validate on schema push; block breaking changes.- Store schema metadata, owners, and description.- CI step: register schema in feature branch, run compatibility check, create migration ticket.

Example Avro additive change:

json

{
  "type":"record","name":"OrderCreated","fields":[
    {"name":"orderId","type":"string"},
    {"name":"amount","type":"double"},
    {"name":"currency","type":["null","string"],"default":"USD"}
  ]
}

**Migration plan for breaking change (change field type: int -> string)**1. Stakeholders: notify consumers + owners; create migration playbook and timeline.2. Dual-write path: - Phase A: Producer writes both old and new fields (keep old int field as legacy_field and add new string_field). Update Avro to include both (backward-compatible).3. Consumer updates: - Consumers update to handle string_field if present; deploy and verify on canary (10% of traffic).4. Data migration: - Run streaming converter job (Kafka Streams/Flink) that reads old events and produces normalized events with string_field for historical topics or into a new topic.5. Switch producer: after all consumers in canary/majority support new field, stop writing legacy_field; set compatibility to backward to allow removal.6. Cleanup: after 30 days and metrics OK, remove legacy_field and set subject to full compatibility if desired.

**Monitoring**- Metrics: consumer error rates, schema registry rejection rate, consumer lag, deserialization exceptions, end-to-end event counts.- Dashboards + alerts: spike in deserialization errors -> page on-call.- Tracing: correlate producer schema version to consumer failures.- Canary logs: observe canary consumer health for 24–72 hours.

**Rollback**- If canary fails: revert producer to previous schema (registry supports previous versions), switch traffic back via feature flag, use consumers’ fallback to legacy_field.- If data corruption: pause producers via orchestrated feature-flag and run corrective converter to reprocess events from checkpoint.

As TPM I’d own timelines, cross-team comms, runbooks, and ensure Schema Registry policies are enforced by CI to prevent accidental breaking changes.

MediumTechnical

39 practiced

Write acceptance criteria and a high-level test plan for an API that supports transactional batch operations and must be idempotent under retries. Cover idempotency key design, duplicate request handling, partial failures, observability (logs/metrics), and integration test cases that prove correctness under retries and concurrent clients.

Sample Answer

**Context & Goal**As a Technical PM, I define acceptance criteria and a test plan to ensure the batch transactional API is idempotent under retries, handles duplicates and partial failures, and is observable and testable under concurrency.

**Acceptance Criteria**- Idempotency key: client-provided opaque string (e.g., UUIDv4); server rejects empty keys. Key stored for 24h (configurable).- Semantics: identical idempotency key + identical request payload => single logical commit; server returns same response and HTTP status for retries.- Duplicate detection: duplicate requests return 200 (or original status) with same response body; non-idempotent changes not applied again.- Partial failures: batch applies atomically per configured unit (either full-batch transaction or per-item transaction with compensating state). If atomic, either all succeed or none. If per-item, partial success must return per-item statuses and be retry-safe.- Concurrency: concurrent requests with same idempotency key must serialize or use compare-and-set to keep single commit.- Observability: logs include idempotency key, request hash, transaction id, outcome. Metrics: idempotent_retries, duplicate_requests, partial_failures, commit_latency, concurrency_conflicts.- Error handling: conflicting payloads with same key => 409 Conflict. Expired/invalid key => 400.

**High-level Test Plan**- Integration tests: - Retry correctness: send request, simulate network drop after server commit, resend same key/payload; assert single commit and identical response. - Payload mutation with same key: send A, then send A' with same key => expect 409. - Concurrent clients: spawn N concurrent identical requests with same key; assert single commit, N-1 responses match original. - Partial failure modes: for per-item transactions, simulate one item failure; assert atomic rollback or per-item statuses and idempotent retries reprocess only failed items.- Load tests: high concurrency with distinct keys to validate throughput and metrics.- Observability tests: validate logs contain key fields; metrics increment appropriately.- Edge cases: long-running transactions, expired key behavior, idempotency key reuse after TTL.

**Success Criteria**All integration tests pass reliably; metrics show expected counts; logs provide traceability; product docs include idempotency guidance and examples for SDKs.

Unlock Full Question Bank

Get access to hundreds of Technical Requirements and Specifications interview questions and detailed answers.

Join thousands of developers preparing for their dream job.