Problem Solving and Structured Thinking Questions

Focuses on the general capacity to approach an unfamiliar or ambiguous problem in a disciplined way, independent of the underlying domain. Core skills include clarifying the actual problem and its constraints before acting, decomposing it into smaller subproblems, recognizing patterns from prior experience, choosing among competing approaches, developing and testing a solution incrementally, weighing trade offs such as cost, risk, effort and correctness, reasoning about edge cases and failure modes, and communicating the thought process clearly to others. In technical roles this often shows up as algorithmic reasoning (selecting data structures, estimating time and space complexity) and systematic debugging. In non-technical roles it shows up as issue-tree style decomposition, hypothesis-driven analysis, and structured decision frameworks under ambiguity. The topic is about the reasoning process itself, not any single domain's toolkit.

MediumTechnical

54 practiced

A product manager requests an offline-first notes app with attachments and conflict resolution. Outline a roll-out plan: break the project into milestones (MVP and subsequent phases), provide rough complexity estimates per milestone, list clarifying questions and unknowns you would ask the PM, and explain how you'd validate each milestone with metrics or user testing.

Sample Answer

**Situation & Goal**Build an offline-first notes web app (attachments + conflict resolution). I’ll break into milestones, rough frontend complexity, questions, and validation.

**Milestones & Complexity**1. MVP — Create/edit notes, local persistence (IndexedDB), basic sync (push/pull), UI for attachments upload (store blobs locally, lazy upload). - Frontend effort: 3–4 weeks. Complexity: medium (IndexedDB + sync state).2. Background sync & retry — Service Worker sync, queueing, optimistic UI, conflict flagging. - 2–3 weeks. Complexity: medium-high.3. Attachments sync & dedupe — Chunking, resumable upload, preview, storage metadata. - 2–3 weeks. Complexity: high.4. Conflict resolution UI & merge heuristics — Visual merge UI, field-level merges, auto-merge rules. - 2 weeks. Complexity: high (UX + state).5. Polishing & accessibility, cross-browser testing, telemetry, metrics. - 1–2 weeks. Complexity: low-medium.

**Key clarifying questions / unknowns**- Platform targets (desktop web, mobile PWA, browsers to support)? - Backend guarantees: CRDTs, OT, or last-write-wins? APIs for attachment chunking? - Expected attachment size & types? Retention and storage limits? - Security: encryption at rest / in transit? Authentication/authorization flows? - Offline duration requirements and conflict frequency expectations?

**Validation / Metrics**- MVP: success = local create/edit persistence + sync success rate >95% in tests. Validate with automated e2e (Cypress) and 20 beta users in varying network conditions. - Background sync: metric = queued items drained within X seconds after reconnect; test with network throttling and Service Worker logs. - Attachments: metric = percent of resuming uploads succeeding; user test for upload UX. - Conflict UI: metric = reduction in user-reported data loss; usability test (5–10 users) to complete merge tasks within set time and low error rate. - Overall: monitor crash rate, sync error rate, Time-to-ready after reconnect, and NPS from pilot.

This plan focuses on frontend responsibilities (IndexedDB, Service Worker, optimistic UI, accessibility, performance) and surfaces backend dependencies to resolve before dev.

HardTechnical

78 practiced

Describe and implement in clear pseudocode a simplified virtual DOM diffing algorithm: given two keyed trees (oldTree and newTree), produce a sequence of operations (insert, delete, move, update) to transform oldTree into newTree. Explain optimizations for common UI patterns (append-only updates), expected time complexity, and memory trade-offs.

Sample Answer

**Approach (brief)** Use keyed tree diffing: compare roots, then reconcile children lists by keys to emit insert/delete/move/update ops. Optimize common append-only case by fast path.

**Pseudocode**

javascript

// nodes: { key, type, props, children[] }
// ops: { type: 'insert'|'delete'|'move'|'update', node, toIndex?, fromIndex?, parentKey? }

function diff(oldNode, newNode, parentKey = null, index = 0, ops = []){
  if (!oldNode) { ops.push({type:'insert', node:newNode, toIndex:index, parentKey}); return ops }
  if (!newNode) { ops.push({type:'delete', node:oldNode, fromIndex:index, parentKey}); return ops }
  if (oldNode.type !== newNode.type) {
    ops.push({type:'delete', node:oldNode, fromIndex:index, parentKey});
    ops.push({type:'insert', node:newNode, toIndex:index, parentKey});
    return ops
  }
  if (shallowDiffProps(oldNode.props, newNode.props)) ops.push({type:'update', node:newNode, fromIndex:index, parentKey});

  // fast path: append-only (old children are prefix of new children)
  if (isPrefix(oldNode.children, newNode.children, c => c.key)) {
    for (let i = 0; i < oldNode.children.length; i++) diff(oldNode.children[i], newNode.children[i], newNode.key, i, ops);
    for (let i = oldNode.children.length; i < newNode.children.length; i++)
      ops.push({type:'insert', node:newNode.children[i], toIndex:i, parentKey:newNode.key});
    return ops
  }

  // generic keyed reconciliation using index map
  const oldIndexByKey = mapKeys(oldNode.children);
  let lastIndex = 0;
  for (let i = 0; i < newNode.children.length; i++){
    const k = newNode.children[i].key;
    const oldIndex = oldIndexByKey[k];
    if (oldIndex === undefined) {
      ops.push({type:'insert', node:newNode.children[i], toIndex:i, parentKey:newNode.key});
    } else {
      diff(oldNode.children[oldIndex], newNode.children[i], newNode.key, i, ops);
      if (oldIndex < lastIndex) ops.push({type:'move', node:newNode.children[i], fromIndex:oldIndex, toIndex:i, parentKey:newNode.key});
      lastIndex = Math.max(lastIndex, oldIndex);
      delete oldIndexByKey[k];
    }
  }
  // remaining old keys -> deletes
  for (let k in oldIndexByKey) ops.push({type:'delete', node: oldNode.children[oldIndexByKey[k]], fromIndex: oldIndexByKey[k], parentKey:newNode.key});
  return ops
}

**Optimizations & patterns**- Append-only fast path: O(min(n,m)) checks then O(k) inserts — common for feeds.- Use index map for O(n + m) matching; optionally compute Longest Increasing Subsequence (LIS) on matched oldIndices to minimize moves (LIS → keep nodes, move others).- Shallow prop diffing and key-stable components reduce unnecessary updates.

**Complexity & memory**- Worst-case time: O(n + m) for matching + O(r log r) for LIS (r = matched count) → overall ~O(n + m + r log r).- Space: O(n) for key maps and LIS arrays.- Trade-offs: LIS reduces DOM operations but adds CPU and memory; choose based on UI update frequency.

HardTechnical

59 practiced

An SPA's memory usage steadily increases during regular use; you suspect detached DOM nodes and retained closures. Outline a systematic approach to find the leak: how to instrument, capture and compare heap snapshots, identify detached DOM trees, reproduce scenarios, hypothesize leak sources, and validate fixes. Include specific Chrome DevTools steps and a plan to prevent regressions.

Sample Answer

**Approach overview**I would treat this as an instrumentation + hypothesis-driven debugging cycle: reproduce reliably, capture baseline, exercise features, compare heap snapshots, identify retained objects (detached DOM / closures), patch, and validate with regression tests.

**Reproduce & instrument**- Reproduce the leak with a repeatable user-flow (e.g., open/close modal 50×).- Open Chrome DevTools → Performance and enable Memory checkbox to record allocations while running the flow.- Keep DevTools undocked to avoid altering layout.

**Capture & compare heap snapshots (DevTools steps)**- DevTools → Memory → take a *Heap snapshot* (baseline).- Run the flow, then take another snapshot; repeat after more iterations.- Use “Comparison” view: select two snapshots and choose “Comparison” to see growth by constructor.- Filter by “Object type” = HTML (e.g., HTMLDivElement) and “(system) Detached” to find detached nodes.

**Identify detached DOM trees & retained closures**- In snapshot, inspect objects with high retained size; click “Retainers” to follow paths keeping them alive.- Look for event listeners, closures capturing element references, framework internal maps (e.g., Map/WeakMap entries), or timers.- Use Console: $0 to inspect elements, getEventListeners($0) to see attached listeners.- Use Performance → Allocation instrumentation timeline to identify when allocations happen.

**Hypothesize and validate**- Form hypotheses (e.g., listeners not removed on component unmount; timers not cleared; global caches holding refs).- Modify code to fix (remove listeners in cleanup, use WeakRef/WeakMap, clear timers, null out references).- Validate by repeating flow and checking heap snapshots for no growth; confirm GC frees objects (DevTools → Memory → Collect garbage).

**Prevent regressions**- Add automated integration tests that exercise suspect flows (headless Chrome) and capture heap diff metrics.- Add unit tests ensuring cleanup in lifecycle hooks (e.g., useEffect cleanup).- Codify patterns: prefer WeakMap for caches, centralized event broker, lint rule checklist for cleanup.- Add monitoring: in production, track memory usage per session and alert on steady growth.

This combination of DevTools snapshot comparisons, retainers analysis, targeted code fixes, and automated regression tests reliably finds and prevents detached DOM/closure leaks.

EasyTechnical

67 practiced

You receive a bug report stating that the 'Submit' button intermittently does not respond on iOS Safari when tapped. Describe, step-by-step, how you would investigate and resolve the issue. Include how you'd reproduce the bug across devices, what browser/devtools features and instrumentation you'd use, likely root causes to check (event handling, passive listeners, CSS overlays, z-index, pointer-events, touch-action), how you'd implement and test the fix, and how you'd communicate status and verification to stakeholders.

Sample Answer

**Step 1 — Clarify & reproduce**- Ask reporter for steps, iOS version(s), Safari version, device model, single-page app or form page, and whether using Safari in standalone mode or WebView.- Try to reproduce locally on a physical iPhone/iPad first (most reliable). If not available, use BrowserStack or Sauce Labs with real iOS devices.- Test combinations: iOS 12–17, portrait/landscape, with/without hardware keyboard, and with/without external CSS/JS loaded (ad/network blockers).

**Step 2 — DevTools & instrumentation**- Enable Safari Web Inspector on iOS and connect to macOS Safari. Use: - Console logs and verbose event logging (console.log in handlers). - Event Listener Breakpoints for touchstart/touchend/click in Web Inspector. - Timeline/Performance recording to capture long tasks and input delays. - Layers/paint profiler to spot overlays or repaints.- Add temporary instrumentation: - Attach capture listeners to document for touchstart/touchend/pointerdown/pointerup and log event.target, event.type, event.defaultPrevented. - Overlay a visible border on button and surrounding elements to detect occlusion.- Use remote screen mirroring or video capture to validate finger position vs hit area.

**Step 3 — Likely root causes to check**- Event handling: - Are touch events being prevented or stopped by a parent listener? Check for event.stopPropagation() or return false. - Are click events delayed due to touch -> click conversion? (iOS historically had 300ms issues; modern Safari usually fine.)- Passive listeners: - Non-passive touch listeners can block scrolling/interaction. Verify addEventListener('touchstart', fn, { passive: false }) usage.- CSS overlays / z-index / pointer-events: - Invisible overlay (positioned element) blocking pointer; check z-index stacking and pointer-events: none/auto.- touch-action: - If touch-action is set inappropriately, it can prevent expected gestures.- Fast-click libraries / custom gesture libs: - Libraries that synthesize clicks can mis-handle edge cases on iOS.- Reflow/animation: - Button inside an element that is animating or being removed/added; DOM mutations during tap can cancel event.- Viewport/viewport-fit issues: - Safe area or transform on parent can affect hit testing.

**Step 4 — Isolate & fix**- Narrow to minimal repro: strip CSS/JS until issue disappears.- If overlay blocks: set pointer-events: none on overlay or adjust z-index; ensure button is topmost in stacking context.- If parent stopPropagation: remove or conditionally allow taps to reach button.- If passive listener issue: mark non-blocking listeners as { passive: true } where appropriate; avoid preventing default unless needed.- For gesture libraries: update to latest, or replace with supported pointer events; defer synthetic clicks.- Add ARIA and tabindex so button still actionable via keyboard/accessibility as fallback.

**Step 5 — Implement and test fix**- Create targeted unit/integration tests: - Cypress or Playwright run against iOS simulators (or real devices) to simulate touch.- Regression test across iOS versions and other mobile browsers.- Run accessibility checks to ensure semantic button behavior preserved.- Code review and feature-flag rollout if risky, then staged release.

**Step 6 — Communicate status to stakeholders**- Initial reply: confirm receipt, steps you'll take, ETA to reproduce and root-cause (e.g., “I’ll reproduce on device and report back in 4 hours”).- Mid-work update: report reproduction result and suspected cause with screenshots/console snippets.- Final update: PR link, summary of fix, testing performed (devices/versions), rollback plan, and verification steps for QA (how they can reproduce before/after).- After deployment: request QA sign-off and confirm with the original reporter that issue is resolved; include release note entry.

Example short log snippet to add while debugging:

javascript

document.addEventListener('touchstart', e => {
  console.log('touchstart', e.target, e.type, window.getComputedStyle(e.target).pointerEvents);
}, { capture: true });

This structured approach ensures reproducible investigation, minimal-risk fix, cross-device validation, and clear stakeholder communication.

MediumTechnical

69 practiced

A CSS Grid layout looks correct in Chrome but wraps unexpectedly in Safari on iOS. Describe a structured debugging approach: how to bisect CSS rules, create a reduced testcase, check vendor bugs/spec differences, decide whether to apply a polyfill or a fallback, and how to document and test the fix across browser versions.

Sample Answer

**Brief goal**Show a repeatable, minimal path from “works in Chrome, breaks in iOS Safari” to a tested fix and documented rollout.

**1) Reproduce & collect evidence**- Reproduce on the same iOS versions/devices (Safari in iOS Simulator + real device if possible).- Capture screenshots, screen recording, console logs and exact user-agent strings.- Note whether Desktop Safari behaves differently.

**2) Bisect CSS rules (isolate the culprit)**- Start with the full page, then progressively disable groups of rules (container → grid tracks → children).- Use binary search: disable half the CSS; if break persists, re-enable half of that, etc., to find the minimal set that triggers the wrap.- Use browser devtools “Toggle CSS” or temporarily add /* disabled */ blocks in the stylesheet.

**3) Create a reduced test case**- Extract minimal HTML/CSS into a single file (CodePen / JSFiddle / reduced.html) that reproduces the bug.- Keep only the grid container, a few child elements, and the problematic properties (grid-template, grid-auto-flow, min/max widths/heights).- Share the reduced testcase in bug reports and PRs.

**4) Check vendor bugs and spec differences**- Search WebKit bug tracker and MDN for known Grid issues on iOS Safari (e.g., minmax(), auto-fill/fit bugs, subgrid differences).- Compare behavior to spec: does Safari implement a specific part differently (intrinsic sizing, percentage gaps, implicit tracks)?- Test small variations: explicit track sizing vs. min-content, removing auto-placement, using grid-auto-columns/rows.

**5) Decide polyfill vs. fallback**- If change is a bug in Safari with no workaround: consider a targeted workaround (e.g., explicit track sizes, add width:0/min-width:0 to flex/grid items), or use @supports to provide alternate styles: - Example:

css

@supports (display: grid) and (not (grid-template-rows: subgrid)) {
      /* Safari-unsafe rules */
    }
    @supports not (grid-template-rows: subgrid) {
      /* fallback styles for older/broken implementations */
    }

- Polyfill only if many features are missing and no CSS workaround exists. Prefer progressive enhancement and a simple fallback (flexbox alternative) rather than large polyfills that increase bundle size.

**6) Implement and test the fix**- Apply minimal CSS change in reduced testcase and verify on: - iOS Safari versions you target (BrowserStack/Sauce + real device) - Chrome, Firefox, Desktop Safari to ensure no regressions- Add automated visual/regression tests (Percy/Chromatic) for the component.

**7) Document and ship**- In the PR include: reduced testcase link, explanation of root cause (bug/workaround), browsers/versions tested, screenshots before/after.- Add comments near the workaround in CSS referencing the WebKit bug ID and rationale.- Update release notes and shared compatibility docs (wiki).

By following this structured flow you minimize guesswork, provide reproducible evidence for maintainers or browser vendors, and choose the least risky remediation (CSS fallback) before opting for heavier polyfills.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.