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.

EasyTechnical

30 practiced

Given this orders table schema:

orders(order_id PK, user_id, status, total_amount decimal, metadata jsonb, created_at timestamp, updated_at timestamp)

Identify data and schema considerations you would include in a technical specification before adding a new analytics-only field 'source_channel' used by downstream pipelines. Address backward compatibility, nullability, indexing, storage impact, and migration approach.

Sample Answer

Situation: Adding an analytics-only field source_channel to orders for downstream pipelines requires careful schema and data planning to avoid breaking producers/consumers, control storage cost, and ensure reliable backfill.

Key schema decisions- Column vs metadata: Prefer a native column (VARCHAR/ENUM) for query speed, type safety, and indexability. Use jsonb only if channels are highly variable or multi-attribute.- Type: VARCHAR(50) or a small enum/check constraint if channels are known (web, mobile, partner, api).- Nullability & default: NULLABLE initially to avoid forcing immediate producer changes. Consider default 'unknown' for analytics consumers but avoid hiding missing data semantics.- Constraint example:

sql

ALTER TABLE orders ADD COLUMN source_channel varchar(50);
-- or with constraint:
ALTER TABLE orders ADD COLUMN source_channel varchar(20);
ALTER TABLE orders ADD CONSTRAINT chk_source_channel CHECK (source_channel IN ('web','mobile','partner','api') OR source_channel IS NULL);

Indexing & performance- Avoid creating a wide index on the new column unless queries filter by it frequently. If analytics will aggregate by source_channel, create a partial/materialized view or a b-tree index:

sql

CREATE INDEX idx_orders_source_channel ON orders(source_channel) WHERE source_channel IS NOT NULL;

- Consider composite indexes only if used with created_at or status in filters.

Storage impact- Estimate row-size increase: varchar small; measure row count and growth to calculate added disk and replication costs.- For partitioned tables, ensure the column appears in partition pruning keys if needed.

Backward compatibility & ingestion- Producers: keep current write paths intact; add field to new writes optionally.- Consumers: downstream pipelines should tolerate NULL/unknown values; update schemas in data catalog (e.g., Glue, BigQuery) and notify consumers.

Migration approach1. Add column nullable with no default (fast, metadata-only DDL for most DBs).2. Deploy producers to write the field (can be phased by service).3. Backfill existing rows: - Small dataset: single UPDATE in a maintenance window. - Large dataset: chunked backfill in batches to avoid locking:

sql

-- pseudocode batch
UPDATE orders SET source_channel = derived_value FROM (...) WHERE orders.order_id BETWEEN x AND y;

- Or populate analytics stores (ETL) rather than updating OLTP if high-volume.4. Validate backfill with counts, histograms, null checks.5. Add index or constraint once backfill and producer coverage reach target.6. If using enum/check, only add after backfill to avoid failures.

Testing, monitoring, rollback- Unit/integration tests for writes/reads and pipelines.- Monitor write error rates, increased replication lag, query latency, storage growth.- Rollback: producers can stop writing; drop column if safe (requires careful planning).

Data governance- Update data catalog, downstream schemas, retention and PII considerations (if channel contains sensitive partner ids).- Document source of truth and transformation rules for derived source_channel values.

This phased, low-risk approach balances backward compatibility, minimal downtime, and clear operational steps for stakeholders.

MediumTechnical

24 practiced

How should you document assumptions and open questions in a technical specification so they are visible, actionable, and tracked to resolution? Provide an example template entry for an assumption and one for an open question, and describe the lifecycle from discovery to closure.

Sample Answer

Make assumptions and open questions first-class artifacts in the spec: record them where reviewers expect to look, give each item metadata so it’s actionable, assign ownership and priority, link to related requirements/designs, and track status until verified/closed.

Essential fields (visible & actionable):- ID, Type (Assumption/OpenQuestion), Title- Statement (concise)- Impact / Consequence if wrong- Confidence / Likelihood- Owner (person/team)- Priority / Blocker flag- Linked artifacts (requirements, diagrams, tickets)- Proposed verification or mitigation- Status (New, In progress, Verified, Rejected)- Dates (created, target resolution, closed)- Resolution notes

Example templates (YAML-style):

yaml

- id: A-001
  type: Assumption
  title: "Customer will provide VPC CIDR ranges"
  statement: "Customer will allocate non-overlapping /16 CIDRs for prod and preprod by kickoff."
  impact: "If not provided, cross-account peering and CI/CD will be delayed."
  confidence: medium
  owner: Solutions Architect (alice@example.com)
  priority: high
  linked: [REQ-12, Diagram-Network]
  verification: "Confirm CIDRs in kickoff meeting; create ticket to request allocation."
  status: New
  created: 2025-05-01
  target_resolution: 2025-05-05

yaml

- id: Q-002
  type: OpenQuestion
  title: "Auth provider for partner API calls"
  question: "Should we use OAuth2 client credentials or mTLS for partner-to-partner API authentication?"
  impact: "Changes certificate management, latency, and operational burden."
  owner: Security Lead (bob@example.com)
  priority: blocker
  linked: [SEC-Policy, ARCH-API-GW]
  proposed_action: "Evaluate both options in a 1-week spike and recommend with cost/ops trade-offs."
  status: In progress
  created: 2025-05-02
  target_resolution: 2025-05-09

Lifecycle from discovery to closure:1. Discover & capture: Log item in spec immediately with required fields and link context.2. Triage: Owner assigned, priority set, and impact assessed in review meeting.3. Mitigate / Investigate: Owner performs verification steps (spike, customer ask, PoC) and records findings; create follow-up tickets if required.4. Decide & act: Based on evidence, accept assumption (mark Verified), update spec, or convert into a requirement/design change; for questions, choose option and document rationale.5. Close: Record resolution, update linked artifacts, change status to Closed/Verified/Rejected, and note lessons learned.6. Audit: At milestone gates, run a checklist to ensure no unresolved blockers remain.

Best practices:- Surface items in a one-page Risks & Assumptions dashboard at top of spec and in proposal decks.- Use a tracker (Jira/GitHub issues) mirroring spec IDs so progress is visible in workflows.- Make owners accountable: tie resolution into milestones and demos.

EasyTechnical

29 practiced

Role-play: You're on a discovery call and the customer says 'we need it fast'. Provide a prioritized list of clarifying questions you would ask live to translate 'fast' into technical requirements, and explain how you'd capture timelines, risks, assumptions, and minimum viable scope in the notes to be turned into the PRD.

HardTechnical

29 practiced

You must support customers on multiple major API versions concurrently for three years. Define lifecycle policies, deprecation notice templates, compatibility tests, SDK management policies, and spec guidelines to minimize engineering maintenance burden while meeting customer needs.

Sample Answer

Situation: As a Solutions Architect charged with minimizing engineering burden while supporting multiple major API versions for three years, I’d establish clear lifecycle policies, communication templates, automated compatibility testing, SDK management rules, and spec standards so product, sales, and engineering align.

Lifecycle policy (policy + timeline)- Supported: Current major (M) + previous two majors (M, M-1, M-2) for 36 months from a major’s GA.- Maintenance windows: only critical/security fixes for M-2 after month 18; feature/backward-incompatible changes only on M.- End-of-Life (EOL): announce 6 months before EOL; hard EOL at 36 months.- Emergency exceptions require cross-functional approval and documented migration path.

Deprecation notice template (short, actionable)- Subject: API v{major} deprecation notice — EOL {date}- Body: - What: endpoints/features deprecated - Why: business/technical reason - When: timeline (deprecated now; sunset {date}) - Impact: exact breaking changes and affected SDKs - Action: migration steps + code snippets + compatibility matrix - Contact & support SLAProvide this as email + dashboard banner + API response header (Deprecation: true; Sunset: date).

Compatibility testing strategy- Contract-first OpenAPI specs + Consumer-Driven Contract (Pact) tests stored per consumer.- CI gates: Every PR must run: - Schema diff (openapi-diff) to detect breaking changes - Contract tests against latest consumer pacts - End-to-end smoke tests in a staging preview environment that hosts active majors - Backwards-compatibility fuzzing for schema evolution- Nightly matrix: run cross-version integration tests between M, M-1, M-2 to catch regressions.

SDK management policy- Auto-generate SDKs from OpenAPI with per-major branches/tags.- Release cadence: SDK patch/security updates on all supported majors; feature releases only for current major.- Backport policy: critical bug/security patches backported to M-1 and M-2; non-critical only on M.- Maintain a migration guide in each SDK repo and sample apps showing multi-version flows.- Use semantic versioning: major matches API major; publish deprecation metadata in SDK release notes and runtime logs.

Spec guidelines- Strict OpenAPI v3.1 with JSON Schema draft: explicit request/response schemas; avoid permissive "additionalProperties": true.- Add stable, required fields; make new optional fields nullable or additive.- Document idempotency, rate limits, error models and stable headers.- Maintain a machine-readable change log (changelog.json) and compatibility metadata.

Operational practices & governance- API Steering Committee (product + arch + eng + sales) reviews major changes monthly.- Migration playbooks and automated tooling (linting, openapi-diff) enforced in CI.- Telemetry: instrument deprecation headers and SDK versions in logs to measure migration progress; report monthly.- SLAs for customer support: migration assistance slots for high-value customers.

Why this reduces maintenance- Contract-first + automated diff/contract tests prevent regressions early.- Auto-generated SDKs + clear backport rules minimize manual patching.- Clear timelines and templates reduce ad-hoc customer support and set predictable expectations.- Telemetry enables data-driven EOL decisions and targeted outreach.

Example: If removing a field, we mark it deprecated in spec, add Deprecation header, run schema diff (CI blocks break), publish SDK patch that logs deprecation, send template notice at 12/6/24/6-week intervals, and provide migration code sample — all coordinated by steering committee.

MediumTechnical

25 practiced

Design an API versioning strategy and migration plan for a public REST API when you must add a new required field to the response that could break existing clients. Include versioning approach (URI vs header), deprecation timeline, backward compatibility policies, client communication templates, and tests to include in your contract.

Sample Answer

Requirements clarification:- Public REST API must add a new REQUIRED response field without breaking existing clients. Goal: safe rollout, clear migration path, minimal disruption, auditable deprecation.

Versioning approach:- Use explicit versioning in the URI for breaking changes: /v2/resources. Rationale: visible, cache-friendly, easy for clients and proxies. Use header-based negotiation (Accept: application/vnd.myapi.v2+json) for optional advanced flows or clients that prefer header routing; still publish canonical URI versions.

Migration plan (stepwise):1. Design v2 schema (new required field). Implement v2 endpoints behind feature flag.2. Publish v2 in parallel with v1. v1 behavior unchanged.3. Provide an opt-in header on v1 to include the new field as nullable/optional (for testing).4. Encourage early adopters (beta program) to test v2 for 4–8 weeks.5. Announce deprecation: v1 deprecated in 6 months, end-of-life (EOL) in 12 months. During deprecation, continue security fixes only.6. At 11 months, send final reminders; at 12 months, retire v1 and redirect/return 410 with migration guidance.

Backward compatibility policies:- Any change that removes or makes an existing field required is a breaking change → must go to new major version.- Additive, non-required fields: allowed in minor releases.- Maintain separate stable contract per major version. No silent changes to semantics or types.

Client communication templates (short):- Initial announcement (to mailing list/portal): "We’re releasing API v2 which introduces [fieldName] (string, required). v1 remains available until [EOL date]. Start testing v2 at https://api.example.com/v2. See migration guide: [link]."- Migration reminder: "Reminder: v1 EOL on [date]. Please migrate to v2. Key change: [fieldName] added and required. Sample curl and SDK updates: [link]."- Final notice: "Final notice: v1 will be retired on [date]. After that calls to /v1 will return 410. Contact support@ for migration help."

Contract & tests to include:- Schema validation tests (JSON Schema) for v1 and v2 responses.- Consumer-driven contract tests (Pact or equivalent) from major clients to ensure expectations.- Backward-compatibility checks: automated diff between v1 and v2 schemas to detect removals/type changes.- Integration tests: end-to-end tests exercising both v1 and v2.- Golden-record tests: record representative responses and assert presence/format of new field.- Load/regression tests to ensure v2 performance parity.

Rollout and monitoring:- Roll out v2 behind a feature flag to 5–10% traffic, monitor errors, latency, and client 4xx/5xx rates for 72 hours, then increase.- Expose telemetry: per-version traffic, error rates, client IDs using v1.- Provide SDK updates and code snippets for common languages.

Fallback and support:- If critical breakage, rollback v2 or toggle feature flag. Provide migration support via support portal, sample code, and a mapping guide (how to populate fieldName).

Trade-offs:- URI versioning is more visible and cache-friendly but creates URL churn. Header versioning is cleaner URL-wise but harder for caching and discovery—hence hybrid: URI primary, header optional.

This plan ensures zero-surprise for existing clients, a clear migration window, automated contract verification, and measurable, staged rollout.

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.