Intuit interview questions & answers

Model answer

Situation

At a company building a self-service analytics product, a product manager wanted to launch a new reporting workflow before a major customer event. Two senior engineers disagreed: one favored extending our existing service to meet the date, while the other argued that the design would compound reliability and maintenance problems. The disagreement had become personal, and the team was losing time debating solutions rather than clarifying the customer need.

Task

I needed to help the group reach a decision that protected the customer outcome without dismissing the engineers’ technical concerns. I also wanted a decision process the team could reuse, rather than having me simply pick a side.

Action

• I met with the PM and engineers individually first, then brought them together. I asked each person to state the customer problem, their assumptions, and the risk they were most concerned about.
• I reframed the discussion around the shared goal: deliver a useful workflow for the event, with an acceptable reliability and support burden. We separated non-negotiable requirements from preferences.
• I asked the engineers to estimate two options against the same criteria: delivery time, operational risk, future migration cost, and reversibility. The PM clarified that the event required a narrow set of reporting capabilities, not the full long-term vision.
• I facilitated a short design review and proposed a thin vertical slice using the existing service, with explicit limits on scope, instrumentation, and a removal or migration plan. The senior engineer concerned about reliability owned the safeguards; the other owned delivery and documented the follow-up architecture work.
• I made the decision and rationale visible in a short decision record, including a date to revisit the approach and metrics that would trigger that review.

Result

We launched the scoped workflow before the event, with no material reliability incidents, and customers used it to complete the target reporting task. The team avoided an open-ended architecture debate and completed the planned follow-up without treating the temporary design as permanent. I learned that alignment comes less from finding a perfect compromise and more from making the goal, constraints, and decision criteria explicit. I would adapt the scope and metrics to the interviewer’s own context.

What interviewers listen for

• You respect technical expertise while staying accountable for the decision.
• You connect trade-offs to customer and business outcomes.
• You make ownership, guardrails, and follow-up explicit.

Model answer

Situation

I led a team of [N] engineers across [locations, disciplines, and experience levels] responsible for [product or platform]. We had strong individual contributors, but uneven participation, unclear ownership, and too many late surprises were making delivery unpredictable. This mattered because our work affected [customers, revenue, reliability, or a major company commitment].

Task

I needed to improve delivery and team health without treating “high performance” as simply working more hours. The challenge was to create shared expectations while making room for different communication styles, perspectives, and career goals.

Action

• I started by listening: I held one-on-ones and a team retrospective, reviewed delivery and on-call data, and asked where people felt blocked or unheard. I used the same questions across the team so quieter voices were not dependent on speaking up in a large meeting.
• I worked with the team to define a small set of operating agreements: what “done” means, how we make decisions, how quickly we review work, and when to escalate risk. I clarified decision owners while keeping technical input open to everyone.
• I made work and trade-offs visible with a shared roadmap and regular demos. For example, when a deadline threatened quality, I presented options—reduce scope, move the date, or accept specific risk—and asked product and engineering to decide together rather than silently shifting pressure to the team.
• I adapted my management to individuals: coaching some people through larger ownership, creating written context for distributed teammates, and inviting input asynchronously before contentious decisions.
• I reinforced the culture through my own behavior: I welcomed dissent, gave specific and timely feedback, recognized collaborative work, and treated incidents as opportunities to improve systems rather than assign blame.

Result

Over [time period], [delivery predictability, engagement, quality, or retention] improved from [baseline] to [result]; for example, [on-time commitments increased from X% to Y%] while [defects or after-hours incidents] fell by [Z%]. The team also became more effective at raising risks early and making decisions across disciplines. I learned that a diverse, high-performing culture is built through fair operating practices and psychological safety—not by expecting everyone to work or communicate in the same way.

What interviewers listen for

• Specific team context and measurable outcomes.
• Inclusion as deliberate management practice, not a slogan.
• High standards balanced with sustainable pace.

Model answer

Situation

On a cross-team platform migration, Product wanted to meet a customer launch date, while the platform team was concerned that migrating every service at once created unacceptable reliability risk. Several teams had dependencies, and stakeholders were receiving different versions of the schedule. As the Engineering Manager, I was responsible for aligning the groups and making sure the decision was based on shared facts rather than escalation alone.

Task

I needed to establish a credible plan that protected customers while preserving the most valuable part of the launch. The constraint was real: we could not eliminate all risk or add unlimited capacity, so we had to make scope, timing, and rollout risk explicit.

Action

• I met with Product, technical leads, and Operations to clarify the customer outcome, non-negotiable requirements, and the cost of delaying each capability. I documented assumptions and surfaced where teams disagreed.
• I asked the leads to estimate two options: a full migration before launch, and a smaller first release with a staged migration. We compared customer value, delivery confidence, operational risk, and rollback complexity—not just engineering effort.
• I recommended the staged option: launch the critical path first, keep the old path available during validation, and gate expansion on agreed health signals. I made the trade-off clear: less scope on day one in exchange for a safer launch and faster learning.
• I created one shared plan with named owners, dependency dates, decision records, and weekly risk reviews. When a dependency slipped, I brought stakeholders a concrete choice—adjust scope, move the date, or accept a specific risk—instead of hiding the schedule impact.
• I agreed on launch criteria and an escalation path with Operations, then communicated progress and changes consistently to all stakeholders.

Result

We delivered the first customer capability on the agreed date and expanded only after the health checks passed. In a real example, I would quantify the verified outcome—for instance, customer adoption, incident rate, or time saved—and state the measurement period. The experience reinforced for me that stakeholder management is not simply keeping everyone updated: it is creating shared facts, making trade-offs visible, and following through on decisions.

What interviewers listen for

• You tailor communication to stakeholder needs while maintaining one source of truth.
• You surface disagreement and risk early, then offer credible options.
• You connect delivery trade-offs to customer and business outcomes.
• You influence across teams without relying only on authority.

Model answer

Situation

On [team or project], a disagreement emerged between [engineering/product/another stakeholder group] about [scope, reliability, a launch date, or technical direction]. Each side had a reasonable concern: [for example, customer urgency] versus [operational or technical risk]. The disagreement was beginning to slow decisions and erode trust, so I treated it as a shared problem rather than a personality conflict.

Task

I owned getting the people aligned on a decision and a workable path forward. I also needed to protect the relationship, make the trade-offs explicit, and ensure the team did not absorb unspoken commitments or risk.

Action

• I spoke with the people involved individually first. I asked what outcome they were optimizing for, what evidence they had, and what they feared would happen if we chose the other option. This helped separate underlying interests from stated positions.
• I brought the discussion back to a shared goal and made the constraints visible: customer impact, deadline, capacity, failure modes, and reversibility. I checked that we were debating the same facts rather than different assumptions.
• I framed concrete options, such as a narrower launch with a feature flag, a delayed launch to close a reliability gap, or a time-boxed experiment. For each, I documented benefits, risks, and the decision owner.
• I facilitated the decision with the right people in the room. I invited dissent before closing, summarized the rationale, and made clear whether the decision was mine, the product owner’s, or a joint call. When escalation was necessary, I escalated the decision and evidence—not blame.
• I recorded the decision, owners, and revisit conditions. For example, we could proceed with a limited rollout if error rates stayed below [threshold], and pause automatically if they exceeded it.

Result

We agreed on [decision] within [time], avoided [specific cost or risk], and delivered [business outcome]. Afterward, [stakeholder/team] reported better clarity, and we used the same decision format to resolve similar disagreements more quickly. I learned that healthy conflict is useful when people can challenge ideas safely and still leave with clear ownership and commitment.

What interviewers listen for

• Listening and curiosity before advocating a position.
• Explicit trade-offs, decision rights, and escalation judgment.
• A concrete resolution and evidence that trust was preserved.

Model answer

Situation

In one example I would use in an interview, a team is facing a high-priority customer issue while also carrying a committed roadmap. The immediate symptom is visible, but the root cause is uncertain and different partners have competing views about whether to pause delivery, add people, or ship a quick fix. As the manager, I am responsible both for making progress on the issue and for maintaining a healthy, focused team.

Task

My job is to create clarity quickly, make a reversible decision where possible, and ensure the team handles the situation without sacrificing customer trust or sustainable execution. I want to address the underlying cause, not just optimize for appearing busy.

Action

• I first establish the facts: customer impact, affected segments, severity, frequency, and what we know versus what we are assuming. I ask an engineer to lead technical diagnosis while I coordinate communication and make sure ownership is explicit.
• I agree on an immediate mitigation and a time-boxed investigation. For example, if a new workflow is causing elevated failures, I would consider disabling it behind a feature flag while we inspect traces and compare error rates before and after release.
• I bring product, support, and engineering together around a decision log: options, customer impact, risk, reversibility, and the evidence needed to proceed. I make trade-offs visible rather than letting the loudest stakeholder define priority.
• I protect the team from uncoordinated requests, set a communication cadence, and ask for dissent before a decision is final. If the evidence changes, I update the plan and explain why.
• After containment, I lead a blameless review focused on contributing conditions—such as missing alerts, unclear ownership, or an untested dependency—and assign follow-up actions with owners and due dates.

Result

The immediate customer impact was contained, the team restored service without introducing a second failure, and stakeholders had a clear, evidence-based update rather than conflicting status reports. We then improved the relevant alerting and release checks, reducing repeat incidents and making future diagnosis faster. What I take from this is that my management approach is consistent—clarify impact, create ownership, and learn—but the response should vary with urgency: in a crisis I make a fast, reversible call; in longer-term work I create broader alignment and give the team space to reason through options.

What interviewers listen for

• A repeatable approach, not a one-size-fits-all reaction.
• Clear ownership, judgment under uncertainty, and thoughtful trade-offs.
• Measurable outcomes and learning that improves the organization.

Model answer

I’d interpret “balancing parentheses” as determining whether every opening parenthesis has a matching closing parenthesis in the correct order. For an expression, other characters are ignored.

function areParenthesesBalanced(input) {
  if (typeof input !== "string") return false;

  let openCount = 0;

  for (const character of input) {
    if (character === "(") {
      openCount++;
    } else if (character === ")") {
      // A close parenthesis cannot match any earlier opening parenthesis.
      if (openCount === 0) return false;
      openCount--;
    }
  }

  return openCount === 0;
}

// Examples:
console.log(areParenthesesBalanced("a * (b + c)")); // true
console.log(areParenthesesBalanced("())("));         // false
console.log(areParenthesesBalanced("((x)"));          // false

• Scan once, incrementing for ( and decrementing for ); reject if the count becomes negative.
• At the end, the count must be zero. This works for one bracket type; multiple bracket types require a stack.

Complexity: O(n) time, O(1) space.

Model answer

function balanceParentheses(input) {
  let open = 0;
  let result = "";

  for (const char of input) {
    if (char === "(") {
      open++;
      result += char;
    } else if (char === ")") {
      if (open === 0) {
        // Insert the missing opener before this closer.
        result += "(";
      } else {
        open--;
      }
      result += char;
    } else {
      // Preserve non-parenthesis characters.
      result += char;
    }
  }

  // Close any remaining unmatched open parentheses.
  result += ")".repeat(open);
  return result;
}

console.log(balanceParentheses("a)b(c")); // "a()b(c)"

• Scan once, inserting an opener when a closer has no matching opener; append remaining closers at the end.
• This produces a balanced string with the minimum number of inserted parentheses. Assumes parentheses are the only characters that affect balance.

Complexity: O(n) time and O(n) space for the returned string.

Model answer

The repository itself is not included here, so I would not claim to have identified or fixed a specific defect. I would first reproduce the failure, narrow it to the smallest failing test or input, then make the smallest targeted change and run relevant regression checks.

Here is a Node.js triage helper for a JavaScript repository. It runs available test, build, and lint scripts in order and stops at the first failure:

// Usage: node triage.js [repository-directory]
// Requires a Node.js project with package.json.

const fs = require("node:fs");
const path = require("node:path");
const { spawnSync } = require("node:child_process");

const repo = path.resolve(process.argv[2] || process.cwd());
const packageJsonPath = path.join(repo, "package.json");

if (!fs.existsSync(packageJsonPath)) {
  console.error(`No package.json found in ${repo}`);
  process.exit(1);
}

const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, "utf8"));
const scripts = packageJson.scripts || {};
const manager = fs.existsSync(path.join(repo, "pnpm-lock.yaml"))
  ? "pnpm"
  : fs.existsSync(path.join(repo, "yarn.lock"))
    ? "yarn"
    : "npm";

const checks = ["test", "build", "lint"].filter((name) => scripts[name]);
if (checks.length === 0) {
  console.error("No test, build, or lint scripts are defined in package.json.");
  process.exit(1);
}

for (const script of checks) {
  console.log(`\n=== Running ${manager} ${manager === "npm" ? "run " : ""}${script} ===`);
  const args = manager === "npm" ? ["run", script] : [script];
  const result = spawnSync(manager, args, {
    cwd: repo,
    encoding: "utf8",
    stdio: "inherit",
  });

  if (result.error) {
    console.error(`Could not start ${manager}: ${result.error.message}`);
    process.exit(1);
  }
  if (result.status !== 0) {
    console.error(`\nStopped: '${script}' failed with exit code ${result.status}.`);
    process.exit(result.status || 1);
  }
}

console.log("\nAll available checks passed.");

• I would inspect the failing test and recent changes, then reproduce the issue with the narrowest reliable command or input.
• I would trace the failure to its owning component, form a testable hypothesis, and add a regression test before changing behavior.
• After the fix, I would run focused tests first, then the full suite; I would also review compatibility, observability, and rollback risk.
• To make an actual fix, I need the repository and the observed failure, including the command, output, and expected behavior.

Complexity: The helper's own work is O(S) script checks; total runtime is determined by the repository's checks.

Model answer

I’d make the assumptions explicit: since no application domain is specified, I’ll present a reusable, low-level module that is useful in many systems—a bounded LRU cache. It gives predictable memory use and O(1) reads and writes. In a real interview, I’d first confirm the expected API, concurrency model, and eviction requirements.

class Node {
  constructor(key = undefined, value = undefined) {
    this.key = key;
    this.value = value;
    this.prev = null;
    this.next = null;
  }
}

class LRUCache {
  constructor(capacity) {
    if (!Number.isInteger(capacity) || capacity < 0) {
      throw new TypeError("capacity must be a non-negative integer");
    }

    this.capacity = capacity;
    this.entries = new Map();
    // Sentinels make moving and removing nodes less error-prone.
    this.head = new Node();
    this.tail = new Node();
    this.head.next = this.tail;
    this.tail.prev = this.head;
  }

  get(key) {
    const node = this.entries.get(key);
    if (!node) return undefined;
    this.#moveToFront(node);
    return node.value;
  }

  put(key, value) {
    if (this.capacity === 0) return;

    const existing = this.entries.get(key);
    if (existing) {
      existing.value = value;
      this.#moveToFront(existing);
      return;
    }

    const node = new Node(key, value);
    this.entries.set(key, node);
    this.#addAfterHead(node);

    if (this.entries.size > this.capacity) {
      const leastRecent = this.tail.prev;
      this.#remove(leastRecent);
      this.entries.delete(leastRecent.key);
    }
  }

  delete(key) {
    const node = this.entries.get(key);
    if (!node) return false;
    this.#remove(node);
    this.entries.delete(key);
    return true;
  }

  #moveToFront(node) {
    this.#remove(node);
    this.#addAfterHead(node);
  }

  #addAfterHead(node) {
    node.prev = this.head;
    node.next = this.head.next;
    this.head.next.prev = node;
    this.head.next = node;
  }

  #remove(node) {
    node.prev.next = node.next;
    node.next.prev = node.prev;
  }
}

// Example usage
const cache = new LRUCache(2);
cache.put("a", 1);
cache.put("b", 2);
cache.get("a"); // 1; "a" becomes most recently used
cache.put("c", 3); // evicts "b"
console.log(cache.get("b")); // undefined

• Map provides direct key lookup; the doubly linked list tracks recency without scanning entries.
• get and put are O(1); storage is O(capacity). I’d add tests for updates, capacity zero, eviction order, and arbitrary key types.

Complexity: O(1) average time per operation; O(capacity) space.

Model answer

Assumption: “Top K” means the K most frequent numbers. The comparator keeps the worst retained candidate at the root of a size-K min-heap, so each new candidate can be checked in O(1) and heap updates take O(log K). Ties favor the smaller number.

function topKFrequent(numbers, k) {
  if (!Number.isInteger(k) || k < 0) {
    throw new Error("k must be a non-negative integer");
  }
  if (k === 0 || numbers.length === 0) return [];

  const frequency = new Map();
  for (const value of numbers) {
    frequency.set(value, (frequency.get(value) || 0) + 1);
  }

  const candidates = [...frequency].map(([value, count]) => ({ value, count }));

  // Negative means a is closer to the root (worse): lower count,
  // or on a tie, larger value.
  const compareWorstFirst = (a, b) =>
    a.count - b.count || b.value - a.value;

  const heap = [];

  function siftUp(index) {
    while (index > 0) {
      const parent = Math.floor((index - 1) / 2);
      if (compareWorstFirst(heap[index], heap[parent]) >= 0) break;
      [heap[index], heap[parent]] = [heap[parent], heap[index]];
      index = parent;
    }
  }

  function siftDown(index) {
    while (true) {
      let worst = index;
      const left = 2 * index + 1;
      const right = left + 1;

      if (left < heap.length && compareWorstFirst(heap[left], heap[worst]) < 0) {
        worst = left;
      }
      if (right < heap.length && compareWorstFirst(heap[right], heap[worst]) < 0) {
        worst = right;
      }
      if (worst === index) break;
      [heap[index], heap[worst]] = [heap[worst], heap[index]];
      index = worst;
    }
  }

  for (const candidate of candidates) {
    if (heap.length < k) {
      heap.push(candidate);
      siftUp(heap.length - 1);
    } else if (compareWorstFirst(candidate, heap[0]) > 0) {
      // Candidate ranks better than the current worst retained item.
      heap[0] = candidate;
      siftDown(0);
    }
  }

  // Return best first: frequency descending, then value ascending.
  return heap
    .sort((a, b) => b.count - a.count || a.value - b.value)
    .map(({ value }) => value);
}

console.log(topKFrequent([1, 1, 1, 2, 2, 3], 2)); // [1, 2]

• Count frequencies in a map, then maintain only K candidates in the heap.
• The comparator defines deterministic tie-breaking; I would clarify the tie contract if the prompt specifies a different one.
• Complexity: O(N + U log K + K log K) time and O(U + K) space, where U is the number of distinct values.

Model answer

Clarify & scope

One product I admire is Google Maps because it turns a complicated, changing real-world environment into a useful decision in a few seconds. I’d focus my improvement on the “arrival” part of a trip: directions can get me to a street, but the last few minutes—where to park, which entrance to use, or how to find the right building—can still be uncertain.

User segments & pain points

The clearest segment is someone visiting an unfamiliar, multi-tenant destination: a medical clinic, office campus, or large venue. The trip may be technically complete when the driver reaches the address, but the user still has to search for parking, an accessible entrance, or the correct building. That creates stress and late arrivals, especially for people with mobility constraints or tight appointments.

Goals & success metrics

I’d measure successful arrivals: the share of trips where users reach the intended entrance or parking area and do not immediately reroute. Supporting metrics could include arrival-related searches, time from reaching the address to ending navigation, and user-reported confidence. Guardrails: wrong-entrance reports, privacy concerns, map clutter, and distraction while driving.

Solutions

I’d consider three options: destination-specific entrance and parking guidance; user-submitted arrival tips; or better handoff from driving navigation to walking directions. I’d begin with verified entrance and parking information for high-volume destinations, then make walking guidance available once parked.

flowchart LR
  A[Choose destination] --> B[Drive to recommended entrance]
  B --> C[Park or stop safely]
  C --> D[Continue with walking directions]
  D --> E[Confirm arrival]

Recommendation: improve verified arrival guidance for complex destinations rather than adding a general-purpose notes feature. Show it only when it is likely to help, distinguish verified data from user tips, and let users report outdated information.

Prioritization & trade-offs

I’d prioritize destinations with frequent visits and clear arrival ambiguity, where better data can benefit many users. Coverage and freshness are the main trade-offs: a thin, unreliable feature could reduce trust. I’d launch in a limited set of cities and destination types before expanding.

MVP, measurement & rollout

I’d test the experience with users visiting selected clinics or campuses, then run a geographic or destination-level experiment. I’d compare successful-arrival rates and post-address navigation time against a control, while monitoring error reports and safe-use signals. I’d expand only if the improvement is meaningful and the data can stay current.

Model answer

Clarify & scope

I’d explain the segment choice in terms of a specific job to be done, not just a demographic. For example, for an Instacart for Business launch, I’d start with office managers at small and midsize businesses who regularly buy snacks, drinks, and basic supplies. The initial goal would be to test whether a simpler business purchasing workflow drives repeat orders—not to solve every enterprise procurement need.

User segments & pain points

I’d compare office managers, restaurant operators, and large-enterprise procurement teams. I’d choose office managers as the initial segment because the buyer is identifiable, ordering is recurring, and the current workaround—personal cards, reimbursement, or ad hoc shopping—is plausibly painful. Restaurant operators may have more complex quality and timing requirements; large enterprises often require longer sales cycles and integrations. I’d validate these assumptions through interviews and behavioral data before treating them as facts.

Goals & success metrics

The North Star would be businesses that complete a repeat order within a defined period. I’d also track time to first order, second-order conversion, order frequency, average order value, contribution margin, and retention. Guardrails would include delivery reliability, substitution/refund rate, support burden, and buyer satisfaction.

Solutions

I’d explore a business account with team permissions, business-friendly receipts and payment, and saved or recurring baskets. I’d avoid starting with advanced approval chains or accounting integrations unless discovery shows they block adoption.

Recommendation: start with a focused SMB pilot and a low-friction, self-serve workflow. This approach tests the most important uncertainty—whether businesses value the convenience enough to reorder—while keeping implementation and sales complexity manageable. I’d choose the segment based on pain frequency, reachable buyers, fit with existing fulfillment, and the speed at which we can learn.

Prioritization & trade-offs

I’d prioritize features by expected customer impact, confidence, effort, and learning value. I’d accept a narrower initial market in exchange for faster validation and a clearer product experience. The risk is that a segment may be easy to reach but not economically attractive, so I’d measure margin and retention—not just sign-ups.

MVP, measurement & rollout

I’d recruit a small cohort, instrument the order and repeat-purchase funnel, and compare outcomes with a suitable control or baseline. I’d interview buyers who reorder and those who abandon after one purchase. I’d expand to adjacent segments only when repeat behavior, unit economics, and service quality meet agreed thresholds; otherwise, I’d revisit the pain point, product approach, or segment.

Model answer

1. Requirements & scale

Functional requirements

• Let taxpayers securely check a refund’s current status, expected next step, and last-updated time.
• Support agency status ingestion, history, notifications, and clear explanations of common delays.
• Support authorized representatives and multiple filings without exposing another taxpayer’s data.

Non-functional requirements

• Protect highly sensitive identity and financial data; meet applicable tax, privacy, retention, and audit requirements.
• Be available during tax season, with a target of 99.95% availability and p95 status reads under 500 ms.
• Show only authoritative agency status; make freshness explicit rather than implying real-time data.

Back-of-the-envelope: Assume 10M active taxpayers, 3 checks/week for 12 weeks: 360M reads per season. At roughly 10M seconds, that is 36 average QPS; use 10× peak headroom, or about 360 QPS (design for 1K). At 2 KB per status record, current records take ~20 GB; 100M 1-KB history events add ~100 GB before indexes and replication. At 1K reads/s and 2 KB responses, egress is ~2 MB/s.

2. High-level architecture

flowchart TD
  subgraph Client[Client]
    U[Taxpayer app]
  end
  subgraph Edge[Edge CDN]
    W[WAF and rate limits]
  end
  subgraph LB[Load Balancer]
    L[API load balancer]
  end
  subgraph Services[API / Services]
    A[API gateway]
    I[Identity and consent]
    S[Status API]
    N[Notification service]
  end
  subgraph Cache[Cache]
    C[Redis status cache]
  end
  subgraph Stores[Datastores]
    D[(Status SQL database)]
    H[(Audit event store)]
  end
  subgraph Queue[Message Queue]
    Q[Status update queue]
  end
  subgraph Workers[Workers]
    X[Agency connector]
    P[Status projection worker]
  end
  U -->|HTTPS status request| W
  W -->|filtered request| L
  L --> A
  A --> I
  I -->|authorized request| S
  S -->|read-through lookup| C
  C -->|miss| D
  S -->|audit event| H
  X -->|poll or receive agency update| Q
  Q -->|status event| P
  P -->|update projection| D
  P -->|invalidate cache| C
  P -->|eligible update| N

3. API design

• GET /v1/refunds/{filingId} — return status, asOf, next action, and estimated timing if the agency supplies one.
• GET /v1/refunds/{filingId}/history — paginated, authorized status history.
• POST /v1/notification-preferences — set opted-in channels and preferences.
• POST /v1/agency/status-events — authenticated partner ingestion endpoint; alternatively use a batch connector when an agency has no event API.

4. Data model & storage

• SQL stores the current projection: Refund(filing_id, taxpayer_id, agency, status_code, status_at, source_at, version) and FilingAccess(filing_id, principal_id, role). Index by taxpayer_id; partition by filing year or agency if volume warrants it.
• Store append-only status changes in an audit/event store keyed by filing_id and event time. Keep raw agency payloads separately, encrypted, access-restricted, and subject to a short retention policy.
• Redis caches safe, authorized status projections for a short TTL (for example, 1–5 minutes). Never use a cache hit to bypass authorization.

5. Deep dive

The key design problem is reconciling inconsistent agency feeds while preserving provenance. Each connector maps partner-specific codes to a versioned internal state machine, validates the filing identifier, and emits an idempotent event with event_id, source_at, and ingested_at. The projection worker deduplicates by event ID and rejects stale transitions using source timestamps and a monotonic version. Conflicting or unknown transitions go to a quarantine queue for review; they must not silently overwrite a verified state. The UI reports both the status and its freshness.

Treat agency systems as the source of truth; avoid polling them on every user read. Use partner webhooks where available and bounded, backoff-based polling otherwise. If an agency is unavailable, serve the last known status with a stale indicator and retry ingestion asynchronously. Audit access and status changes, encrypt data in transit and at rest, tokenize identifiers where possible, and use least-privilege service identities.

6. Scale, bottlenecks & trade-offs

• Keep reads stateless and horizontally scalable. Replicate the SQL store for reads; partition only when measured write or index pressure justifies the operational cost.
• Queue-based ingestion absorbs partner bursts and isolates slow agencies. Use retries with jitter, dead-letter queues, and replayable events.
• Choose strong consistency for authorization and writes; eventual consistency is acceptable for a status projection if freshness is visible. Prefer serving a stale known status over failing every read, but never fabricate a status.
• The main risks are agency outages, stale mappings, account takeover, and cross-taxpayer data leakage. Track p95/p99 latency, availability, status age, ingestion lag, mapping errors, cache hit rate, authorization failures, and notification delivery. Roll out new agency mappings by shadow comparison, then a small canary, with a rapid rollback path.

Model answer

1. Requirements & scale

I would start by asking which user flow the demonstrated application supports, whether it is a prototype or production deployment, what regions and availability target are required, and whether traffic or data volume is known. I will illustrate with the task-tracking app from the prototype answer; actual costs depend heavily on provider, region, discounts, and retention.

• Functional: sign in, view a list, create an item, update its state, and receive clear success or failure feedback.
• Non-functional: responsive interaction, durable writes, access control, monitoring, and graceful behavior when a dependency is unavailable.
• Illustrative scale: 10,000 daily active users, 20 requests/user/day = 200,000 requests/day, about 2.3 average QPS. At a 10x peak, that is about 23 QPS. If each request transfers 20 KB, application traffic is about 4 GB/day (200,000 × 20 KB), excluding static assets. At 1 KB of stored task data per user-generated item and 100,000 new items/day, raw growth is about 100 MB/day, or 3 GB/month before indexes, replicas, and backups.

2. High-level architecture

The flow is: authenticate, fetch the user's list, submit a write, persist it, then return the updated state. The browser can serve static assets through a CDN. A load balancer routes API calls to stateless application instances. A managed SQL database handles transactional writes and indexed reads. I would add a queue only for notifications or other non-critical side effects.

flowchart TD
  subgraph Client
    U[User] --> B[Web or mobile app]
  end
  subgraph Edge/CDN
    B --> C[Static CDN and WAF]
  end
  subgraph Load Balancer
    C --> L[HTTPS load balancer]
  end
  subgraph API / Services
    L --> A[Application API]
    A --> I[Identity and authorization]
  end
  subgraph Cache
    I --> K[Optional read cache]
  end
  subgraph Datastores
    I --> D[Managed SQL]
  end
  subgraph Message Queue
    I --> Q[Side-effect queue]
  end
  subgraph Workers
    Q --> W[Notification worker]
  end

3. API design

• GET /api/v1/me — establish the signed-in user's identity and display profile.
• GET /api/v1/tasks?cursor=... — return a page of tasks scoped to that user.
• POST /api/v1/tasks — persist a task and return it; accept an idempotency key for safe retries.
• PATCH /api/v1/tasks/{id} — update status or allowed fields after authorization.
• GET /healthz and GET /readyz — distinguish process health from readiness to serve traffic.

The interface should provide loading, empty, success, and recoverable-error states. A successful write should be confirmed from the server response, not merely displayed optimistically as durable.

4. Data model & storage

Use a users table keyed by stable identity-provider subject and a tasks table keyed by task ID with owner_id, status, and timestamps. Index (owner_id, created_at, id) for the list. Keep static assets in object storage behind a CDN; use SQL for records and transactions. At this scale I would not add a search cluster or distributed cache by default. Backups and restore testing are part of the design, not an optional operational detail.

5. Deep dive

The main user flow should remain understandable when each stage fails. The client obtains a session, requests a cursor-paginated list, and renders either data or an explicit empty state. When creating an item, the API authenticates, checks ownership and schema, commits the row, and responds with the canonical record. Only after the durable write should the UI show it as saved. A notification, if required, can be published asynchronously so a mail-provider outage does not make the core workflow unavailable.

sequenceDiagram
  actor User
  participant UI as Application
  participant API as API service
  participant DB as SQL database
  participant Q as Queue
  User->>UI: Open task list
  UI->>API: GET /api/v1/tasks
  API->>DB: Read tasks scoped to user
  DB-->>API: Task page
  API-->>UI: 200 JSON
  UI-->>User: Render list or empty state
  User->>UI: Create task
  UI->>API: POST /api/v1/tasks
  API->>DB: Validate and commit task
  DB-->>API: Committed task
  API-->>UI: 201 task JSON
  API->>Q: Publish optional notification
  UI-->>User: Show saved task

6. Scale, bottlenecks & trade-offs

For an interview estimate, I would present a range rather than false precision. An illustrative small production deployment might cost roughly $300–$1,500/month: CDN and object storage $20–$150; two or more modest API instances $100–$500; managed SQL with backups and a standby $150–$700; logging, monitoring, network transfer, and queueing $30–$300. These are order-of-magnitude estimates, not a vendor quote. Egress, high availability, observability retention, and managed database sizing can dominate. I would verify them with a cloud pricing calculator using region, instance class, storage, backup retention, and measured egress.

I would begin with a production-like single region and stateless API replicas. Add database read replicas only when read load requires them; writes still go to the primary. A cache can reduce repeated reads but introduces invalidation and stale-data behavior, so I would first measure query latency. Queue retries need idempotent consumers and a dead-letter path. The principal-engineer responsibility is to make the user journey observable end to end, define SLOs and cost ownership, and scale components based on measured bottlenecks rather than adding infrastructure speculatively.

Model answer

1. Requirements & scale

I would clarify whether the demonstrated application is browser-based, mobile, or both; whether it handles sensitive data; and whether users authenticate through a company identity provider. I will assume a browser client and a JSON API.

• Functional: users sign in, receive authorized access to their own resources, and call APIs over an untrusted network.
• Security goals: protect credentials and session tokens, prevent unauthorized access and replay where relevant, validate payloads, and make abuse detectable.
• Illustrative scale: 100,000 daily users, 10 API requests per user per day, or about 1 million requests/day. Average load is roughly 12 QPS (1,000,000 / 86,400); at a 10x peak, plan for about 120 QPS. Security controls should be designed for the real peak and threat model, not just this estimate.

2. High-level architecture

Use TLS end to end from client to the public edge, and keep identity verification and authorization in the API path. Prefer a managed identity provider for authentication rather than implementing password storage and recovery from scratch. The application API remains responsible for resource-level authorization.

flowchart TD
  subgraph Client
    B[Browser] --> T[Token or session]
  end
  subgraph Edge/CDN
    T --> E[WAF and TLS]
  end
  subgraph Load Balancer
    E --> L[HTTPS load balancer]
  end
  subgraph API / Services
    L --> A[API gateway]
    A --> I[Identity validation]
    I --> Z[Authorization and service]
  end
  subgraph Cache
    Z --> C[Rate-limit counters]
  end
  subgraph Datastores
    Z --> D[Encrypted data store]
    I --> S[Identity provider]
  end
  subgraph Message Queue
    Z --> Q[Audit events]
  end
  subgraph Workers
    Q --> W[Audit and detection]
  end

3. API design

• POST /api/v1/session — exchange an identity-provider authorization result for an application session if the architecture requires one.
• DELETE /api/v1/session — revoke the current session.
• GET /api/v1/me — return the authenticated principal and permitted profile fields.
• GET /api/v1/resources — list only resources authorized for the caller.
• POST /api/v1/resources — create a resource after schema validation and authorization.

Use consistent 401 responses for unauthenticated requests and 403 for authenticated users lacking permission. Avoid returning sensitive internals in error messages. Apply CSRF protection when using cookie-based sessions.

4. Data model & storage

Store user identity with a stable provider subject, not an email address that can change. Application records should include an owner_id or tenant identifier, and queries must enforce that scope. Keep tokens and secrets out of application tables and logs. If sessions are server-side, store opaque, revocable session identifiers in a protected session store; store only a hash of the identifier where practical. Encrypt data at rest with managed keys and restrict key access by service identity. Keep audit events separate from mutable business records, with retention and access policies appropriate to the data.

5. Deep dive

For browser login, I would use OpenID Connect authorization-code flow with PKCE through a trusted identity provider. After callback, the server validates issuer, audience, signature, expiry, nonce, and state before establishing a session. A secure, HttpOnly, Secure, appropriately SameSite cookie reduces token exposure to JavaScript. If using bearer tokens in a mobile or service client, keep them in the platform's protected storage and use short-lived access tokens with refresh-token rotation and revocation. I would not put long-lived secrets in browser local storage.

On every API request, authenticate first, then authorize the specific action against the resource and tenant. Never trust a user ID supplied by the client as proof of ownership. Validate payloads against explicit schemas, limit request size and nesting, reject unexpected fields where appropriate, and use parameterized database operations. Add rate limits by principal and IP, abuse detection, and audit logging while redacting credentials, tokens, and sensitive payload fields.

sequenceDiagram
  actor User
  participant B as Browser
  participant IdP as Identity provider
  participant API as Application API
  participant DB as Data store
  User->>B: Start sign-in
  B->>IdP: Authorization code with PKCE
  IdP-->>B: Code after authentication
  B->>API: Callback with code and state
  API->>IdP: Exchange code and validate identity
  IdP-->>API: Verified claims
  API-->>B: Secure session cookie
  B->>API: Request with session
  API->>API: Authenticate and authorize resource
  API->>DB: Scoped query
  DB-->>API: Authorized data
  API-->>B: Response over TLS

6. Scale, bottlenecks & trade-offs

Use managed identity to reduce credential-handling risk, trading some provider coupling for mature authentication and recovery. Keep authorization in the service even if a gateway validates tokens; gateway checks alone rarely capture object-level permissions. Cache public keys and provider metadata safely, but honor key rotation and token expiry. Rate-limit with a distributed store if multiple API instances must share counters; define behavior when that store is unavailable, favoring conservative limits on sensitive operations. TLS protects data in transit but does not prevent compromised clients, broken authorization, or unsafe logging. I would threat-model the actual application, run dependency and secret scanning, test authorization boundaries, and stage security changes with monitoring and incident-response ownership.

Model answer

1. Requirements & scale

I’d first confirm what the demonstration is meant to prove. Assuming it is a craft-project app, I’d build a prototype that demonstrates the complete user value loop: browse projects, inspect instructions, sign in, save a project, record progress, and optionally upload a finished-work photo. I’d keep the prototype deliberately small; the goal is to test the journey and core interactions, not to build a production content platform.

• Functional: browse/search a seeded catalog, view project steps and materials, authenticate, save progress, and upload an optional image.
• Non-functional: usable on mobile, accessible, responsive under demo traffic, and safe with test user data. Target p95 API latency below 500 ms and a successful demo flow above 99% in rehearsal.
• Prototype scale: 100 concurrent demo users, about 10,000 API requests per day, 1 GB of images, and a small seeded catalog. This is far below a production launch.
• Back-of-the-envelope: 10,000 requests/day ÷ 86,400 ≈ 0.12 average QPS; even a 20× burst is under 3 QPS. At 1 MB average image size, 1,000 uploads/month add about 1 GB of storage. The prototype does not need distributed databases or custom autoscaling.

2. High-level architecture

I’d use a static web frontend, a small managed API, managed PostgreSQL, and object storage. Use a hosted OIDC provider for authentication so the prototype avoids implementing password handling. A CDN and WAF provide a simple public edge; a queue is optional for image processing, not required to make the core flow work.

flowchart TD
  subgraph Client
    B["Web app"]
  end
  subgraph EdgeCDN["Edge and CDN"]
    C["CDN and WAF"]
  end
  subgraph LoadBalancer["Load Balancer"]
    L["HTTPS ingress"]
  end
  subgraph APIServices["API and Services"]
    A["Craft API"]
    I["OIDC provider"]
  end
  subgraph Cache["Cache"]
    K["Optional response cache"]
  end
  subgraph Datastores["Datastores"]
    D["Managed PostgreSQL"]
    O["Object storage"]
  end
  subgraph MessageQueue["Message Queue"]
    Q["Optional image-job queue"]
  end
  subgraph Workers["Workers"]
    W["Optional thumbnail worker"]
  end
  B -->|"Static assets and HTTPS"| C
  C -->|"API traffic"| L
  L -->|"Route request"| A
  B -->|"Sign in"| I
  A -->|"Verify token"| I
  A -->|"Read catalog"| K
  K -->|"Cache miss"| D
  A -->|"Project and progress data"| D
  A -->|"Signed upload URL"| B
  B -->|"Upload image"| O
  O -->|"Image-created event"| Q
  Q -->|"Optional processing job"| W

3. API design

• GET /v1/projects?query=&difficulty= — browse and filter the catalog.
• GET /v1/projects/{projectId} — retrieve materials and ordered instructions.
• GET /v1/me/projects — list the signed-in user’s saved projects and progress.
• PUT /v1/me/projects/{projectId}/progress — idempotently save step and completion state.
• POST /v1/uploads — authorize an upload and return a short-lived signed URL.
• POST /v1/me/projects/{projectId}/photos — associate an uploaded object with a project.

All user-specific routes require a verified identity token and check ownership server-side. Use request IDs, bounded payloads, and clear validation errors.

4. Data model & storage

PostgreSQL is the simplest fit for relational project, step, and user-progress data. The prototype tables are users(id, oidc_subject, created_at), projects(id, title, difficulty, materials_json), steps(project_id, step_number, instruction), and user_projects(user_id, project_id, current_step, completed_at, updated_at). Enforce a unique (user_id, project_id) key and index (user_id, updated_at) for the user’s project list. Store image bytes in object storage, not in database rows; keep object keys and metadata in a project_photos table. At this scale, a single managed database is sufficient; I would not shard it.

5. Deep dive

The key demo risk is losing user progress or making login interrupt the journey. I’d let the user browse anonymously, then require sign-in only when they save or start a project. The frontend remembers the intended action, completes OIDC authorization, and resumes it. Progress updates use PUT with the current step and an updatedAt or version value; the API checks ownership and writes atomically. If the client retries after a timeout, the same update is safe to apply again.

For photos, the API first authorizes the user and returns a short-lived, content-type-limited upload URL. The browser uploads directly to object storage; the API then records the object association. This keeps large files away from the application server. If image processing is in scope, a queue and worker generate thumbnails asynchronously; a failed thumbnail must not block project completion.

6. Scale, bottlenecks & trade-offs

For a live demo, prioritize operational simplicity over theoretical scale: one region, managed database backups, CDN-hosted assets, and a rehearsal checklist. Cache only public project reads if latency requires it; do not cache private progress without careful user-key isolation. A database outage affects writes, so show a recoverable save error and retain unsent progress locally for retry. Object uploads can fail independently, so preserve the project state and allow retry.

A rough prototype infrastructure budget is $50–$200/month, depending on the provider’s database minimum, API runtime, logging, and image egress. I’d use synthetic data, a demo identity tenant, HTTPS, secrets management, and a short retention policy. Before production, I’d revisit availability targets, privacy, abuse prevention, backups, monitoring, and load requirements rather than implying this prototype is production-ready.

Model answer

1. Model — Domain data and business rules, independent of UI controls where practical. It may include entities, services, and validation rules.
2. View — The UI (for example, WPF XAML). It presents state and forwards user actions through bindings and commands, rather than owning application behavior.
3. ViewModel — UI-facing state and operations. It exposes bindable properties, commands, and presentation-friendly data without depending directly on specific view controls.
4. Data binding — Connects view properties to ViewModel properties. WPF supports one-way, two-way, and one-time bindings, converters, validation, and DataContext inheritance.
5. Change notification — INotifyPropertyChanged lets the view react to property updates; ObservableCollection<T> notifies the view when collection items are added or removed.
6. Commands — ICommand (often async command implementations) represents actions such as Save or Search, including whether an action is currently enabled.
7. Composition and navigation — Dependency injection supplies services to ViewModels; navigation or view resolution selects the appropriate view and ViewModel.

flowchart LR
  U[User action] --> V[View]
  V -->|binding or command| M[ViewModel]
  M -->|service call| S[Model or service]
  S -->|result| M
  M -->|property change| V

The main benefits are separation of concerns, testability, and parallel work across UI and domain logic. Common pitfalls are putting business logic in code-behind, creating a “god” ViewModel, and exposing UI controls through the ViewModel. A Principal-level answer should also call out practical boundaries: use MVVM to clarify ownership and enable testing, not as a reason to add needless abstractions.

Model answer

UI virtualization creates visual containers only for items that are visible (and often a small buffer around them), rather than creating one UI element per item in the data source. For a list with 100,000 records, the view may therefore maintain only dozens of item containers at a time.

In WPF, this is commonly provided by VirtualizingStackPanel inside an ItemsControl, such as ListBox or ListView. Recycling virtualization reuses containers as the user scrolls; it reduces allocation and layout work further than creating and discarding containers.

Key distinctions and caveats:

• UI virtualization limits visual elements and layout work. Data virtualization limits how much data is loaded; it is a separate concern and may require paging or incremental loading.
• Virtualization can be disabled by using a non-virtualizing panel, nesting incompatible scroll viewers, or enabling certain layout behaviors. Verify the actual visual tree and profile the application.
• Recycled containers must fully reset visual state, event handlers, and bindings; otherwise, state can appear on the wrong row.
• Variable-height items and complex grouping can complicate virtualization and scrolling. Measure the user experience as well as memory and rendering cost.

The useful metrics are realized container count versus total items, initial render time, scroll-frame rate, UI-thread time, and memory usage. The goal is to keep work proportional to the visible region while preserving correct keyboard navigation, accessibility, and selection behavior.

Model answer

I’d treat authentication and payload protection as separate layers: prove who the user is, then ensure every request is authorized, validated, and protected in transit and at rest. I’d first confirm the app’s identity provider, data sensitivity, and whether it handles uploads or payments; for a typical craft-demo app, I’d use this baseline:

1. Login and session security - Use a trusted OIDC provider rather than storing passwords ourselves. Require MFA for administrators and support account recovery with expiring, single-use tokens. - Use short-lived access tokens and secure, HttpOnly, Secure, SameSite cookies for browser sessions. Rotate refresh tokens and revoke them on logout, password changes, or suspected compromise. - Apply login throttling, bot detection, generic error messages, and alerts for unusual authentication patterns. Never log credentials or tokens.
2. API and payload security - Require TLS 1.2 or later at every public and service boundary; use managed certificates and HSTS. Use mTLS or workload identity for sensitive service-to-service calls. - Validate schema, types, sizes, and allowed fields at the API boundary. Reject unexpected fields, enforce ownership checks on every object, and use parameterized database access to prevent injection. - Apply per-user and per-IP rate limits, request-size limits, and idempotency keys for retryable writes. Treat client input as untrusted even when the user is authenticated. - Encrypt stored data with managed keys, restrict access by least privilege, and avoid placing personal data in logs. Use signed, short-lived upload URLs rather than exposing object-storage credentials.
3. Operational controls - Keep secrets in a secrets manager, rotate them, and scan dependencies and builds. Add audit events for authentication and sensitive changes, with alerts for suspicious activity. - Test authorization boundaries, token expiry/revocation, malformed payloads, and rate limits in CI and staging; run periodic penetration tests.

flowchart LR
  B["Browser"] -->|"TLS login"| I["OIDC provider"]
  B -->|"TLS API request and session cookie"| G["API gateway"]
  G -->|"Validate session, schema, rate limit"| A["Application API"]
  A -->|"Authorized query"| D["Encrypted database"]
  A -->|"Audit event"| L["Security monitoring"]

I’d choose controls proportionate to the data and threat model, then verify them with measurable outcomes: authentication-abuse rates, authorization-test coverage, time to revoke a session, and security findings by severity.

Model answer

A strong example is using operational data to change team behavior, then checking whether the change improved both delivery and team health.

1. Situation: A team was regularly working late to recover from production incidents. In retrospectives, engineers described interruptions and burnout, but we had not established whether the issue was incident frequency, slow diagnosis, or unclear ownership. I was responsible for improving reliability without turning the response into an individual performance problem.
2. Define the baseline: I partnered with engineers to build a shared view of incident count and severity, mean time to acknowledge and recover, repeat incidents, on-call pages per engineer, and planned work displaced by operational work. We segmented by service and incident type, and checked alert coverage and logging quality before trusting the numbers.
3. Find the leverage point: The data showed that a small number of noisy alerts generated many pages, while recurring incidents had no durable follow-up owner. I shared the findings with the team and asked them to validate the interpretation. The key insight was not that people were responding too slowly; it was that our alert thresholds and remediation process were creating avoidable toil.
4. Change the system: We agreed to tune or remove low-actionability alerts, define severity and escalation expectations, and assign an owner and due date to each incident follow-up. I protected a fixed portion of capacity for reliability work and rotated incident-review facilitation so the responsibility did not sit with one person. For example, we replaced a threshold that paged on a brief transient spike with an alert based on sustained customer-impacting errors.
5. Measure and adjust: I reviewed the trend weekly with the team and monthly with product and infrastructure partners. We monitored page volume and recovery time alongside customer error rates, change failure rate, and delivery predictability, so that fewer pages did not come at the cost of missing real incidents.
6. Result and reflection: In this example, noisy pages fell by roughly 40% over a quarter, repeat incidents declined, and engineers reported fewer disruptive on-call weeks. We also made incident follow-up a normal part of planning rather than optional cleanup. I learned that metrics drive cultural change when teams help interpret them and when the intervention fixes the system, not blames individuals.

What interviewers listen for

• You choose meaningful leading and lagging measures and validate data quality.
• You involve the team in interpreting evidence and changing practices.
• You balance reliability, delivery, and sustainable on-call health.