Structured Problem Solving and Frameworks Questions

Assessment of a candidate's ability to apply repeatable, logical frameworks to break ambiguous problems into manageable components, identify root causes, weigh options, and recommend a defensible solution with an implementation plan. Topics include defining the problem and success criteria, gathering context and constraints, decomposing the problem using mutually exclusive collectively exhaustive thinking, generating alternatives, evaluating trade offs by impact and effort, and sequencing execution. Interviewers will look for clear narration of the thinking process, use of data and evidence, awareness of assumptions, and the ability to adapt a framework to different domains such as product, operations, or analytics. This canonical topic also covers systematic analysis techniques, methodological rigor, and presentation of conclusions so others can follow and act on them.

HardTechnical

46 practiced

You are asked to present a recommendation to deprecate a widely-used internal library. Draft an outline of a convincing one-slide summary and a one-page technical appendix that covers problem statement, evidence (metrics, incidents), alternatives evaluated, recommended timeline, migration plan, risk mitigation, and KPIs to track post-deprecation.

Sample Answer

One-slide summary (title + 6 bullets — aim for visual clarity)Title: Recommendation to Deprecate Internal Library "LibX" — Risk-First Migration- Problem (1 line): LibX shows rising maintenance cost, security vulnerabilities, and blocks feature velocity.- Evidence (1 line): 18 incidents in 12 months; 45% of failures trace to LibX; >3x maintenance effort since v2.0.- Recommendation (1 line): Deprecate LibX over 9 months; adopt supported alternatives (A: StandardLib, B: OpenAdapter).- Key timeline (visual): Month 0: Announcement → Month 1–3: Dual-support & tooling → Month 4–8: Migration sprints → Month 9: Remove LibX.- Migration ask (one line): 3 cross-team engineers, automated compatibility tooling, and 12-week migration sprint cadence.- KPIs & risks (icons): Track % apps migrated, incident rate, dev lead time; mitigate via fallback, canary releases, clear SLAs.

One-page technical appendix (concise sections)

Problem statement- LibX is a home-grown utility used by ~120 services. Codebase is 7k LOC, last major refactor 4 years ago. Increasing fragility: ABI breaks, poor test coverage, and unmaintained third-party deps.

Evidence (metrics & incidents)- Incidents: 18 P2/P3 outages in last 12 months; mean time to recovery (MTTR) for LibX-related incidents = 3.2 hours vs platform average 0.9h.- Error amplification: 45% of cascading failures in release logs reference LibX exceptions.- Engineering cost: Quarterly maintenance tickets rose from 6→20; average PR review time for LibX changes = 5 days.- Security: Two CVEs in transitive deps; no maintainer response in 90 days.

Alternatives evaluated- Continue maintaining LibX: Pros—no migration; Cons—rising cost, security risk, single-team bottleneck.- StandardLib (internal supported library): Pros—active maintainers, better API, backwards compatibility tools; Cons—API mismatch for 30% of callers.- OpenAdapter (community OSS + wrapper): Pros—large community, frequent updates; Cons—requires adapter layer, licensing review.- Hybrid: Encourage StandardLib for new work; provide adapter for legacy patterns to reduce refactor surface.

Recommendation & timeline- Decision: Deprecate LibX; primary migration target = StandardLib, fallback OpenAdapter where needed.- Timeline (9 months): - Month 0: Executive approval + deprecation notice + create migration repo - Month 1–3: Provide automated compatibility shim, linters, and codemods; dual-support (LibX & shim) - Month 4–7: Prioritized migrations (top-20% high-risk services first) with 2-week sprint goals - Month 8: Final freeze; stop non-security LibX changes - Month 9: Remove LibX from central artifact repo; enable emergency rollback policy for 30 days

Migration plan (concrete steps)- Inventory & prioritize: Auto-scan repos to list callers; tag by risk (prod traffic, incident history).- Tooling: Provide codemods (Python/JS/Java), IDE snippets, and breakage detectors in CI.- Support: Assign 3 rotating migration engineers (2 FTE-equivalent), weekly office hours, Slack channel and PR review SLA 48h.- Pilot: Migrate 3 critical services in Month 2–3 to validate codemods and rollback flows.- Rollback strategy: Feature-flagged release + canary at 1%→10%→50%→100%; immediate revert plan if error rate > SLO.

Risk mitigation- Maintain LibX security patch window for critical fixes until Month 9.- Staged removals and canarying minimize blast radius.- Emergency-fastlane: team that can re-publish LibX for critical rollbacks within 24h.- Legal/licensing review complete before OpenAdapter use.

KPIs to track post-deprecation (targets)- % services migrated: target 100% by Month 9 (interim: 50% by Month 4)- Incident rate for migrated services: ≤ baseline platform incident rate- MTTR for related incidents: reduce to platform average within 3 months post-migration- Developer lead time for changes previously touching LibX: improve by 20% within 6 months- PR review SLA for migrations: 48h

Appendix: Quick migration checklist for teams- Run repo scanner → identify calls- Run codemod locally → run tests- Open migration PR with feature flag and rollout plan- Request migration-row review from Migration Team- Canary, monitor, promote, then remove LibX dependency in build

Contact & next steps- Approve timeline and resource ask (3 engineers + tooling budget)- Kickoff: Week 1 alignment meeting with platform, security, and legal.

HardTechnical

39 practiced

Given limited telemetry budget (cost caps on metric cardinality and logs retention), propose a methodology to choose which metrics and logs to collect for a high-traffic e-commerce checkout. Discuss trade-offs between cardinality, cost, observability value, and the steps to revise the set over time.

Sample Answer

Approach: treat telemetry as a scarce resource — optimize for highest-observability ROI per byte. Define goals, rank signals by impact, apply cardinality and retention controls, then iterate with data-driven feedback.

1) Clarify goals & SLOs- Business: conversion rate, payment success, revenue per session.- Reliability: checkout latency, error rate, third-party timeouts.Prioritize metrics/logs that directly map to these goals.

2) Choose high-value metrics (low-cardinality first)- Essential aggregate metrics: checkout_attempts, checkout_success_rate, total_revenue, payment_provider_latency_p50/p95/p99, payment_failures.- Instrument error counts by class (payment_error, validation_error) rather than by full stack trace.

3) Cardinality controls & strategies- Avoid user_id/session_id as metric labels; use them only in traces/logs with sampling.- Use coarse enums (payment_provider=A|B|C, region=US|EU|APAC).- Use histogram/percentile summaries for latency instead of per-endpoint high-cardinality labels.- For high-cardinality needs, use cardinality bucketing (e.g., map client_version to major.minor) or top-k tagging.

4) Logs & traces policy- Retain structured logs for errors and business failures; drop or sample verbose debug logs.- Apply adaptive sampling: keep 100% of error logs, 10% of successful checkout logs, and 100% of requests that violate SLOs or match anomaly patterns.- Trace all requests at low rate (1%), sample 100% for failed flows.

5) Cost vs observability trade-offs- Finer cardinality enables root-cause and segmentation but multiplies metric series cost. Favor aggregation + targeted drill-downs.- Longer retention helps postmortems but costs more; keep short retention for raw logs, longer for aggregates/metrics.- Traces are expensive but high-value for failures; control via sampling and on-demand increased sampling during incidents.

6) Revision lifecycle- Weekly/monthly review of alert noise, query frequency, and top cost contributors.- Create a telemetry change pipeline: propose new labels/retention, stage in dev with cost estimate, A/B test for 2–4 weeks.- Use telemetry telemetry: monitor which metrics/logs are queried/alerted; retire unused series.- Post-incident add targeted high-cardinality captures (e.g., capture full context for a subset of failing sessions) and then remove after root cause.

7) Automation & guardrails- Enforce label whitelists and cardinality limits in CI/CD.- Cost budget alerts when metric series or log ingestion approaches threshold.- Playbook: when approaching cap, throttle verbose sources, increase sampling, or convert metrics to derived aggregates.

Example: start with checkout_success_rate, p99 latency, payment_failure_count (by provider), error_rate. If a spike appears and you need user-level debugging, temporarily enable higher sampling for that payment provider or specific error code, capture traces, then revert.

This methodology balances cost and observability by focusing on business-impacting signals, controlling label cardinality, using sampling for expensive data, and continuously pruning/adjusting based on actual usage and incidents.

EasyTechnical

40 practiced

When asked to 'improve page load latency by 30% for the homepage', how would you define success criteria and key performance indicators (KPIs)? List at least 4 measurable criteria (including user-facing and technical metrics), explain target thresholds, and describe how you'd instrument them to collect reliable data.

Sample Answer

Success criteria: measurable improvement vs baseline (last 30 days). "Improve page load latency by 30%" means hitting a 30% reduction in key user-facing metrics for target percentiles (median and tail) without regressing errors or bandwidth.

Four measurable KPIs (with targets and instrumentation):

1) Largest Contentful Paint (LCP) — user-facing- Target: median LCP ≤ 0.7 × baseline and 75th/90th percentile ≤ 0.8 × baseline- Instrument: Real User Monitoring (RUM) using browser PerformancePaintTiming (Paint API) + send LCP events via PerformanceObserver to backend telemetry (sampled) tagged by URL, device, network.

2) Time to Interactive (TTI) / Total Blocking Time (TBT) — interactivity- Target: median TBT reduced by 30%; 95th percentile TTI improved proportionally- Instrument: RUM + Performance API + Lighthouse for synthetic checks. Collect TBT via PerformanceObserver and aggregate by percentile.

3) Time to First Byte (TTFB) / server latency — technical backend- Target: reduce median TTFB by 30% (or to ≤ 200ms depending on baseline)- Instrument: server-side request tracing (APM — e.g., OpenTelemetry): record TTFB, backend processing time, DB query times; correlate with RUM by trace-id headers.

4) Page weight and request count (network efficiency)- Target: total bytes transferred and number of requests reduced by ≥30% (or to thresholds like <500KB/30 req)- Instrument: Synthetic monitoring (headless browsers) and RUM Resource Timing API to capture actual bytes, caching status, gzip/brotli, and number of requests per session.

Additional guardrails:- Conversion / bounce rate (business metric): ensure no >2% negative impact; instrument via analytics events.- Error rate: front-end JS exceptions and HTTP 5xx must not increase; instrument via Sentry/APM.

Data reliability & rollout:- Collect both RUM (real users, geo/device/network breakdowns) and synthetic (controlled baselines) daily.- Tag data by version/deployment, region, device, connection type. Use percentile aggregation (p50/p75/p90/p95).- Establish dashboards and alerts (e.g., p90 LCP > target → page-performance alert).- Run A/B rollout, compare control vs. treatment with statistical significance before full release.

HardTechnical

44 practiced

A third-party payments API intermittently fails (~0.5% of transactions), impacting customer checkout. Provide a structured remediation plan that balances short-term mitigations (retries, fallbacks) with long-term fixes (alternative providers, SLA negotiation). Include monitoring, rollback strategies, customer communication templates, and decision criteria for switching providers.

Sample Answer

Scope & goals:- Restore checkout reliability quickly, protect revenue, preserve UX while designing durable fixes and contractual protections.

Immediate (hours) — short-term mitigations1. Circuit breaker + rate limiter: stop calling provider when error spike > threshold (e.g., 1% failure over 5m).2. Retry with idempotency and exponential backoff (max 2 retries, jitter). Ensure transactions are idempotent to avoid double-charges.3. Fallback: route eligible traffic to fallback path (local tokenization / queued offline processing / alternate provider) for low-risk payments.4. Feature-flag deployment for toggling retries/fallbacks quickly.

Example retry pseudocode:

python

# idempotent retry with exponential backoff
def call_payment(payload, idempotency_key):
    for attempt in range(3):
        resp = provider.charge(payload, idempotency_key)
        if resp.success: return resp
        if not transient_error(resp): break
        sleep((2**attempt) * 0.2 + random_jitter())
    raise PaymentError(resp)

Medium-term (days–weeks)1. Root-cause analysis: collect request traces, provider logs, HTTP codes, latency, geographic patterns, and payload shapes.2. Harden integration: strict validation, timeout tuning, improved error classification (4xx vs 5xx vs network).3. Automated canaries & synthetic transactions exercising edge cases.

Long-term (weeks–quarters)1. Multi-provider architecture: abstract payment gateway with strategy pattern, dynamic routing, reconciliation, and per-provider feature matrix.2. SLA negotiation & penalties: demand SLOs (availability, P95 latency), credits, and response-time commitments. Add audit/logging access.3. Business continuity: documented runbooks, regular failover tests, and contractual exit clauses.

Monitoring & alerting- Metrics: success rate, error rate by code, latency percentiles, payment throughput, % of retries, fallback usage, reconciliation failures.- Alerts: page on >0.5% failure sustained for 10m or >2% for 2m; escalation for reconciliation mismatches.- Dashboards: real-time flows with drill-down by region, merchant, and payment type.- Logs & traces: include idempotency key, provider request/response IDs, correlation IDs.

Rollback & incident playbook1. Trigger: detection of spike or failed canary.2. Actions: enable circuit breaker → route to fallback/alternate provider → disable nonessential features → notify stakeholders.3. Rollback: revert to previous stable integration code or switch routing to alternate provider via config flag; verify reconciliation.4. Post-incident: blameless postmortem with timeline, RCA, and action items (within 72h).

Customer communication templates- Short outage alert (email/in-app):“We’re aware of an intermittent payment issue affecting checkout for some customers. Our team is applying fixes now; most purchases should succeed with retries. If you experienced a failed charge, please check your bank — we’ll notify you if any duplicate charges are found. Estimated resolution: 2 hours.”- Follow-up/resolution:“The payment issue has been resolved. If you experienced a failed transaction, you may retry or contact support (link). We will proactively refund or reconcile any duplicate charges. We apologize and appreciate your patience.”

Decision criteria for switching providers (quantitative + qualitative)- Quantitative: - Persistent availability < 99.5% over 30 days despite mitigations. - Error rate after retries > 0.5% for key geos or payment types. - Unacceptable MTTR: average incident resolution > 4 hours or > 3 incidents/month. - Business impact: revenue loss or chargeback increase > predefined threshold.- Qualitative: - Poor transparency or lack of logs/traceability. - Uncooperative support or missed SLA commitments. - Incompatibility with required features (3DS, tokenization, fraud tools). - Cost & onboarding complexity vs benefit.If one or more thresholds met and contractual remediation fails, start procurement: RFP, parallel testing, data migration plan, and phased cutover with reconciliation.

Ownership & timeline- Incident lead (on-call SE) for hours; payment product manager for vendor negotiations; engineering to deliver multi-provider abstraction in 4–8 weeks with canary rollouts and reconciliation automation.

This plan balances rapid containment and customer-facing mitigations with engineering investments and contractual risk control to avoid recurring outages.

EasyTechnical

42 practiced

Implement in Python a function prioritize_projects(projects) that accepts a list of dicts with keys: 'id', 'impact' (1-10), 'effort' (1-10), and returns the list sorted by a simple score = impact / effort (highest first). Ensure O(n log n) runtime and stable ordering for ties. Include brief comments explaining complexity.

Sample Answer

To prioritize projects, compute a score = impact / effort for each project and use Python's stable Timsort via sorted() with reverse order. This yields O(n log n) runtime and preserves input order for equal scores.

python

def prioritize_projects(projects):
    """
    projects: list of dicts with keys 'id', 'impact' (1-10), 'effort' (1-10)
    Returns a new list sorted by score = impact / effort (highest first).
    Stable: Python's sorted() is stable, so ties keep original order.
    Time: O(n log n) due to sorting. Space: O(n) for the output list.
    """
    # Defensive: avoid division by zero (effort should be 1-10 per spec)
    def score(p):
        e = p.get('effort', 1) or 1
        return p.get('impact', 0) / e

    # Use sorted with key and reverse=True to get highest scores first.
    # sorted() is stable, so projects with equal scores retain original order.
    return sorted(projects, key=score, reverse=True)

Edge cases:- If effort unexpectedly 0, code treats it as 1 to avoid ZeroDivisionError.- Missing keys default to impact=0, effort=1.Alternative: annotate projects with precomputed scores to avoid recomputing key if score calc is expensive.

Unlock Full Question Bank

Get access to hundreds of Structured Problem Solving and Frameworks interview questions and detailed answers.

Join thousands of developers preparing for their dream job.