Managing Ambiguity, Assumptions, and Data Gaps Questions

Practice working with incomplete requirements, missing data, and ambiguous scenarios. Develop frameworks for identifying gaps, making reasonable assumptions, sanity-checking your assumptions against business logic, and adjusting assumptions when new information emerges. Learn to communicate assumptions clearly to stakeholders and discuss confidence in your modeling.

MediumTechnical

42 practiced

Implement in JavaScript a utility mergeDatasets(a, b) that merges two arrays of objects by 'id'. Rules: prefer non-null values from b over a; for timestamp fields choose the latest; produce per-record metadata listing assumptions applied (e.g., 'preferred non-null from b for name'). Provide a small input example and expected merged output structure.

Sample Answer

Approach: Build a map of records by id from array a, then iterate b to merge or create records. For each field, prefer non-null/undefined values from b; if both present and field looks like a timestamp (ISO string or numeric), pick the latest. Track per-record metadata messages describing assumptions applied.

javascript

// mergeDatasets.js
function isTimestamp(val) {
  if (val == null) return false;
  // numeric timestamps or ISO strings
  return typeof val === 'number' || (typeof val === 'string' && !isNaN(Date.parse(val)));
}

function toMillis(val) {
  if (typeof val === 'number') return val;
  return Date.parse(val);
}

function mergeDatasets(a = [], b = []) {
  const outMap = new Map();

  // initialize from a
  for (const r of a) {
    outMap.set(r.id, { record: { ...r }, meta: [] });
  }

  // merge/override with b
  for (const rb of b) {
    const id = rb.id;
    const entry = outMap.get(id) || { record: {}, meta: [] };
    const ra = entry.record;

    // union of keys
    const keys = new Set([...Object.keys(ra), ...Object.keys(rb)]);
    for (const k of keys) {
      const va = ra[k];
      const vb = rb[k];

      // preserve id
      if (k === 'id') {
        ra.id = id;
        continue;
      }

      // prefer non-null from b
      const bHas = vb !== null && vb !== undefined;
      const aHas = va !== null && va !== undefined;

      if (isTimestamp(va) || isTimestamp(vb)) {
        if (bHas && aHas) {
          const ma = toMillis(va), mb = toMillis(vb);
          if (mb >= ma) {
            ra[k] = vb;
            entry.meta.push(`chose latest timestamp from b for ${k}`);
          } else {
            ra[k] = va;
            entry.meta.push(`kept latest timestamp from a for ${k}`);
          }
        } else if (bHas) {
          ra[k] = vb;
          entry.meta.push(`preferred non-null timestamp from b for ${k}`);
        } else if (aHas) {
          ra[k] = va;
        }
      } else {
        if (bHas && (!aHas || vb !== va)) {
          ra[k] = vb;
          entry.meta.push(`preferred non-null from b for ${k}`);
        } else if (aHas) {
          ra[k] = va;
        } else if (bHas) {
          ra[k] = vb;
        }
      }
    }

    outMap.set(id, entry);
  }

  // convert to array
  return Array.from(outMap.values()).map(e => ({
    ...e.record,
    _meta: e.meta
  }));
}

Example input:

javascript

const a = [{id:1,name:'Alice',updated:'2023-01-01T10:00:00Z',score:10}];
const b = [{id:1,name:null,updated:'2023-01-02T09:00:00Z',score:12},{id:2,name:'Bob',updated:1672531200000}];

Expected output:[ { id:1, name:'Alice', updated:'2023-01-02T09:00:00Z', score:12, _meta:[ "chose latest timestamp from b for updated", "preferred non-null from b for score" ] }, { id:2, name:'Bob', updated:1672531200000, _meta:[ "preferred non-null timestamp from b for updated", "preferred non-null from b for name" ] }]

Complexity: O(n+m) time, O(n+m) space. Edge cases: null/undefined fields, mixed timestamp formats, nested objects (requires deep-merge extension). Alternative: use schema to mark timestamp fields explicitly for more robust behavior.

HardTechnical

35 practiced

Discuss legal and ethical implications of imputing or inferring sensitive user attributes (age, gender, ethnicity) to fill data gaps. How would you assess risk, mitigate bias, ensure transparency, and comply with relevant regulations like GDPR when considering such imputation?

Sample Answer

Start by framing the problem: imputing or inferring sensitive attributes (age, gender, ethnicity) fills data gaps but raises legal, privacy, and ethical risks—misclassification harms individuals, perpetuates bias, and may violate laws (GDPR, anti‑discrimination statutes). Treat inferred sensitive attributes as high-risk: they can be personal data or special-category data under GDPR depending on context and the ability to identify individuals.

Risk assessment- Purpose & necessity: is inference strictly necessary to achieve a lawful, proportionate business objective? Apply data minimization.- Harm analysis: map potential harms (wrong decisions, profiling, discrimination, reputational/legal exposure).- Re-identification & linkage risk: assess whether inference increases identifiability.- DPIA: perform a Data Protection Impact Assessment for high‑risk uses (document rationale, mitigations, residual risk).

Mitigate bias and harm- Avoidance first: prefer non-sensitive proxies or redesign product so inference isn’t needed.- If necessary, constrain use: only use coarse/aggregated categories; avoid individual-level automated decisions based on inferred sensitive attributes.- Robust model design: balance training data, use fairness-aware algorithms, calibrate and model uncertainty (return confidence intervals or abstain when uncertain).- Testing: run disparate impact and subgroup performance evaluations; use metrics (false positive/negative rates by group, calibration, demographic parity where appropriate).- Human-in-loop: require human review for high-impact cases; log decisions and rationales.

Transparency and accountability- Consent & notice: under GDPR, obtain lawful basis (explicit consent may be required for special-category inferences) and provide clear notices about inference, purpose, retention, and opt-out options.- Explainability: provide user-facing explanations and ability to correct or contest inferred attributes.- Documentation: maintain Model Cards, Data Sheets, and Records of Processing Activities (RoPA) describing purpose, accuracy, testing, and limitations.- Monitoring & remediation: continuous monitoring for drift and bias, regular audits, and an incident response plan.

Technical controls- Differential privacy or synthetic data for training to reduce re-identification.- Access controls and encryption for inferred attributes; minimize retention.- Confidence thresholds and rejection options to avoid acting on low-confidence inferences.

Regulatory compliance (GDPR highlights)- Lawful basis: identify legal basis (consent, contract, legitimate interest with careful balancing). For special-category data, rely on explicit consent or another strict exception.- DPIA: required for systematic profiling or large-scale inference.- Data subject rights: enable access, rectification, erasure, objection to profiling, and human review for automated decisions.- Purpose limitation & minimization: restrict downstream use; delete when no longer necessary.

Operationalize via governance- Approval workflows, cross-functional reviews (legal, privacy, ethics), logging, and periodic external audits. Favor safer alternatives; if inference used, document decisions, expose uncertainty, and ensure human oversight.

This approach balances engineering practicality with legal and ethical constraints: avoid inference where possible, require strong justification and controls where not, and operationalize transparency, testing, and compliance.

MediumTechnical

41 practiced

As a senior engineer, propose an onboarding checklist for new projects that guarantees capture of assumptions and data gaps and includes a validation plan within the first two sprints. Include stakeholders, spike tasks, instrumentation, and sign-off criteria.

Sample Answer

Situation: When starting new projects, teams often miss implicit assumptions and data gaps that later cause rework. The checklist below is designed to be executed during sprint-0 and validated across the first two sprints so assumptions are explicit, data gaps identified, and validated quickly.

Onboarding checklist (ordered, owner):1. Kickoff alignment (PM, Eng Lead, Product Designer, QA, Data Engineer, Security) — owner: PM - Deliverable: one-page goal, success metrics, out-of-scope list.2. Assumptions register — owner: Eng Lead - Capture functional, non-functional, user, data, and third-party assumptions (who, why, risk, confidence level).3. Data-gap inventory — owner: Data Engineer - List required datasets, schema, SLOs, access, freshness; mark missing or low-confidence items.4. Spike tasks (timeboxed 1–3 days each) — owners: assigned engineers - API contract spike: validate third-party and internal API behaviors. - Data validation spike: sample ETL + schema checks, edge-case coverage. - Performance/security spike: lightweight load test and threat checklist. - Integration spike: end-to-end minimal flow to reveal hidden dependencies.5. Instrumentation plan — owner: SRE/Data Engineer - Define telemetry: key metrics, traces, logs, data-quality checks, alert thresholds; implement lightweight dashboards.6. Validation plan (first two sprints) — owner: Eng Lead + QA - Sprint 1: complete spikes, produce evidence (API responses, sample data, test runs), update assumptions confidence. - Sprint 2: implement a thin vertical slice with full telemetry; run data-quality checks and automated tests; perform acceptance criteria checks.7. Communication & stakeholder checkpoints — owner: PM - Daily standups, mid-sprint demo for PM/Data, end-of-sprint demo for stakeholders.8. Sign-off criteria (must be met before full backlog work continues) - Assumptions: all high-risk assumptions either validated or have mitigation plans. - Data: required data sources accessible or documented workarounds; data-quality checks pass on sample. - Spikes: artifacts submitted (notes, scripts, test logs) and reviewed. - Instrumentation: baseline metrics and alerts in place for the vertical slice. - Security/Compliance: required approvals or documented exceptions. - Stakeholder agreement: PM, Eng Lead, Data Engineer, QA sign-off recorded.

Result: This checklist makes assumptions and data gaps visible early, provides concrete spike outcomes, and enforces an evidence-based sign-off so the team can safely move from discovery to delivery.

EasyTechnical

39 practiced

Define what a data contract is and why it matters for producer/consumer teams when data gaps exist. Include a short example schema snippet (e.g., user_event(id, user_id, timestamp, event_type, amount)) and note which fields should include nullability and versioning policies.

Sample Answer

A data contract is an explicit agreement between producer and consumer teams that defines the schema, semantics, validation rules, SLAs, and versioning policy for data exchanged. It makes expectations explicit so consumers know what fields mean, which are stable, and how to handle missing or changed data. When data gaps exist (missing fields, late arrivals, schema drift), a contract reduces ambiguity, prevents silent failures, and enables automated validation, graceful degradation, and coordinated upgrades.

Example schema (event stream/table):

sql

user_event (
  id STRING NOT NULL,            -- stable unique event id (non-null)
  user_id STRING NOT NULL,       -- consumer relies on this for joins (non-null)
  timestamp TIMESTAMP NOT NULL,  -- event time, required
  event_type STRING NOT NULL,    -- enum; producers must document allowed values
  amount DECIMAL(10,2) NULL,     -- nullable: optional monetary value
  metadata JSON NULL,            -- nullable: extensible free-form data
  schema_version INT NOT NULL    -- contract version for compatibility checks
)

Nullability & versioning policy:- Mark required fields as NOT NULL (id, user_id, timestamp, event_type).- Optional/extendable fields (amount, metadata) should be nullable; consumers must handle null safely.- Include schema_version or semantic versioning (major.minor) in metadata; breaking changes bump major, additive changes bump minor.- Maintain backward compatibility where possible; deprecate fields with a defined grace period and clear migration plan.

MediumSystem Design

49 practiced

You inherit a legacy microservice with an unclear data schema and fragile consumers. Outline the steps you'd take to map the current schema, create an incremental migration plan (backwards/forwards compatibility), add compatibility tests, and minimize customer impact during the transition.

Sample Answer

Requirements & constraints:- Confirm functional scope: which consumers (internal/external), SLAs, allowed downtime, data sensitivity, and deployment windows.

1) Discover & map current schema- Inventory endpoints, message topics, DB tables using static analysis, runtime tracing (distributed traces, DB query logging), and API gateway logs.- Capture shapes by sampling payloads; aggregate optional vs required fields, types, enums, and constraints.- Produce canonical documentation: OpenAPI / JSON Schema / Avro for each interface and a migration spreadsheet mapping producers → consumers.

2) Design incremental, compatible schema changes- Follow compatibility rules: additive-only changes first (add optional fields), avoid breaking renames/removes.- Use backward- and forward-compatible patterns: - Add new optional fields with sensible defaults. - Deprecate fields (mark in docs) but keep them during transition. - Introduce versioning strategy only if necessary (minor version headers or media types) and prefer progressive compatibility over hard version jumps.- Consider an adapter/facade layer: a translation proxy that can present the new schema to new consumers while translating to legacy for old ones.

3) Data migration patterns- Dual-write or shadow-write: producers write both old and new schemas; read path chooses based on feature flag.- Backfill batch jobs to populate new fields in persistent stores.- Use a feature-flag driven rollout per consumer or per tenant.

4) Compatibility tests & automation- Implement consumer-driven contract tests (e.g., Pact) so each consumer publishes expectations; run contracts in CI against provider changes.- Add schema-validation tests (JSON Schema/Avro) for all endpoints and message topics.- Create end-to-end integration tests in a staging environment that mimic traffic patterns; include mutation tests for missing/extra fields.- Automate gating: failing contract or integration tests blocks deploy.

5) Deployment & minimization of customer impact- Canary/staged rollout: release to internal users or a small percent of traffic; monitor errors and latency.- Maintain backward compatibility during rollout. When removing fields, keep them for a deprecation window and provide migration guides and client libraries.- Observability: add metrics (schema version usage, error rates), structured logs, and alerts for consumer parsing failures.- Communication: notify consumers, provide sample payloads, migration checklist, and an SDK/adapter where feasible.

6) Rollback & remediation- Have trivial rollback path (feature flag off; route to facade).- If incompatibility detected, revert change, triage contract mismatch, and coordinate with consumer owners.

Metrics & success criteria:- Zero or minimal increase in consumer errors- Percentage of traffic on new schema per week- Time-to-fix for contract failures < SLA

Trade-offs:- Adapters add maintenance but reduce consumer impact.- Immediate strict versioning reduces ambiguity but forces coordinated cutovers.

This plan balances safety (contracts, staging, canaries) with velocity (additive changes, dual-write, feature flags) to migrate incrementally with minimal customer disruption.

Unlock Full Question Bank

Get access to hundreds of Managing Ambiguity, Assumptions, and Data Gaps interview questions and detailed answers.

Join thousands of developers preparing for their dream job.