Box interview questions & answers

Model answer

Situation

In a previous role, my team owned a cross-functional launch with a committed date tied to a customer rollout. Midway through delivery, integration testing exposed a dependency failure, and the remaining work was larger than our original estimate. The date was at risk, and product, sales, and a partner engineering team all needed a credible update.

Task

I owned establishing what had changed, protecting customer outcomes, and communicating a recommendation early enough for stakeholders to make decisions. I needed to avoid both false reassurance and an unnecessary schedule reset based on incomplete evidence.

Action

• Re-establish facts and uncertainty. I asked the technical lead to break the remaining work into deliverables, identify the dependency and its owner, and separate known tasks from unknowns. We reviewed the critical path, test evidence, staffing constraints, and the assumptions behind the original estimate.
• Create options, not just a problem report. I compared a full launch on a later date with a smaller, safe launch on the original date and a phased rollout. For each, I documented customer impact, risk, dependencies, and confidence. We did not solve a date problem by quietly dropping security or quality criteria.
• Align the team on a forecast. I held a short cross-functional review and assigned owners to close the largest uncertainties. I used a confidence range and explicit decision date rather than presenting a single date as guaranteed.
• Communicate directly and promptly. I told stakeholders what we knew, what we did not know, the impact if the risk materialized, and my recommendation. I named the next update time and the decision needed from each group.
• Manage the recovery. We tracked critical-path work daily, escalated the dependency with a clear ask, and agreed on launch guardrails, including rollback criteria and customer support readiness.

Result

We chose a phased rollout that delivered the core customer value on the planned date while moving lower-priority capabilities into a later release. The team avoided a risky all-or-nothing launch, and stakeholders had time to adjust customer commitments. The experience reinforced that a delay is best managed as a decision about scope, risk, and customer value—not as a status-reporting exercise.

What interviewers listen for

• Early, transparent communication without blame or false precision.
• A fact-based forecast, options, and a clear recommendation.
• Protection of quality and customer trust while managing scope and commitments.

Model answer

Situation

I managed a team that had grown from a small group into multiple workstreams. People were delivering within their own areas, but dependencies were being discovered late, and engineers described the team as a collection of projects rather than a group with shared goals. That fragmentation was beginning to affect delivery and morale.

Task

I wanted to strengthen trust and shared ownership without relying on social events or forcing everyone into the same working style. The goal was a team that could disagree productively, understand one another’s work, and coordinate around outcomes.

Action

• I made the team’s purpose and priorities explicit. We connected quarterly goals to customer and business outcomes, then clarified ownership and dependencies so each person could see how their work contributed.
• I introduced lightweight cross-team rituals with a clear purpose: a weekly dependency and risk review, regular design reviews, and a monthly retrospective. I removed status meetings where information could be shared asynchronously.
• I created opportunities for people to work together on meaningful problems, including rotating incident roles and pairing across areas for selected design or reliability work. I was careful not to create unnecessary handoffs just for the sake of collaboration.
• I set expectations for healthy disagreement: critique ideas with evidence, surface risks early, and commit once a decision is made. When conflict became personal or repetitive, I facilitated a direct conversation and clarified decision rights.
• I made recognition specific and shared. In team updates, I called out not only individual delivery but also mentoring, unblocking, operational work, and collaboration that enabled others to succeed.
• I monitored team-health feedback, regretted attrition, dependency-related delays, and incidents. I discussed the trends with the team, protected confidentiality, and changed rituals that were not producing value.

Result

Over the following two quarters, the team surfaced dependency risks earlier, reduced cross-team delivery delays, and improved its pulse-survey scores on trust and clarity. We also saw more engineers volunteer to lead shared work. I learned that cohesion is built through consistent purpose, fair participation, and reliable follow-through—not through mandatory togetherness.

What interviewers listen for

• You connect cohesion to mission, trust, and execution.
• You create inclusive ways to collaborate without over-meeting.
• You use feedback and delivery signals, then adapt the team’s practices.

Model answer

Situation

On a 10-person engineering team supporting a growing product, I found that one-on-ones were happening inconsistently and often turned into status updates. That meant I was missing early signals about workload, growth goals, and team friction—especially from people who were less likely to raise concerns in a group setting.

Task

I wanted to make one-on-ones a reliable space for each person’s priorities and development, while protecting enough team time for delivery. I also needed a format flexible enough to work for different people and circumstances.

Action

• I set a regular cadence—typically 30 minutes every other week, weekly for new hires or during a significant transition—and treated cancellations as something to reschedule, not silently drop.
• I agreed with each person on how to use the time. I brought a light agenda, but asked them to own the topics; common prompts included “What’s taking more energy than it should?” and “What would you like to be doing more of?”
• I separated status reporting from the meeting. Project updates went into team channels, leaving the conversation for feedback, decisions, coaching, and personal context the employee chose to share.
• I kept a private notes-and-actions log, with care not to record sensitive personal detail unnecessarily. I began each meeting by closing the loop on prior commitments so people could see that raising an issue led to follow-through.
• I adapted the conversation to the person: sometimes coaching with questions, sometimes giving direct feedback, and sometimes simply listening before trying to solve the problem. For example, when an engineer said interruptions were blocking deep work, we agreed on a two-week experiment with protected focus blocks and reviewed the impact together.
• I periodically asked whether the cadence and format were working, and changed them rather than treating my template as universal.

Result

Over the next quarter, the team had clearer follow-through on individual actions, and I learned about workload and role concerns earlier—before they became delivery or retention risks. The focus-block experiment reduced interruptions reported in our check-ins, while project status remained visible through team updates. I learned that consistency builds trust, but the meeting only works when it serves the person, not the manager’s checklist.

What interviewers listen for

• A dependable cadence with employee ownership and flexibility.
• Listening, confidentiality, and follow-through—not just a meeting template.
• A link between individual support and team outcomes.

Model answer

Situation

In a previous role, I managed a team of engineers working on a customer-facing platform where reliability, delivery speed, and team growth all mattered. As the organization grew, I saw that my management approach needed to create clarity without turning me into the decision-maker for every detail.

Task

I wanted to build a team that could deliver meaningful outcomes sustainably, while making sure people understood the context behind decisions and had room to do their best work.

Action

• Start with outcomes and context. I translate company goals into a small number of team priorities, explain why they matter, and make constraints explicit. For example, when we had to choose between a feature and reliability work, I framed the decision around customer impact and operational risk rather than which stakeholder had asked most recently.
• Create ownership with clear boundaries. I agree on the desired outcome, decision owner, and escalation points, then let engineers shape the solution. I stay involved where decisions cross teams, carry significant risk, or affect commitments.
• Treat people with empathy and candor. I give timely, specific feedback, ask what support someone needs, and address difficult performance or collaboration issues directly rather than allowing surprises to accumulate.
• Use evidence, not certainty theater. I encourage teams to state assumptions, measure results, and revisit decisions when new information arrives. I distinguish reversible choices, which we can test quickly, from decisions that deserve deeper review.
• Build a healthy operating system. I use regular one-on-ones, retrospectives, and lightweight delivery and reliability measures to surface problems early. I also protect focus time and sustainable on-call practices because burnout is not a delivery strategy.

Result

This approach helped my teams make decisions closer to the work, raise risks earlier, and connect engineering effort to customer and business outcomes. In one team, clearer ownership and prioritization improved predictability while preserving time for reliability improvements. I have learned that good management is not choosing between high standards and psychological safety; it is creating both through clarity, fairness, and follow-through.

What interviewers listen for

• A coherent, actionable leadership philosophy—not just a list of virtues.
• How you balance autonomy, accountability, delivery, and team health.
• Evidence that your approach improves outcomes beyond your own output.

Model answer

Situation

On one team I led, we were hiring quickly and had a mix of backgrounds, locations, and levels of experience. I noticed that a few people were doing most of the talking in design discussions, while newer engineers and colleagues outside the main office were less likely to challenge assumptions. I did not want to assume that good intent alone meant everyone had an equal chance to contribute.

Task

My responsibility was to build a team environment where people could contribute, grow, and disagree respectfully, while ensuring inclusion was part of how we hired, planned, and delivered—not a separate initiative owned by one person.

Action

• I started by looking at team signals and listening: participation in reviews, promotion and project opportunities, onboarding feedback, and confidential one-on-ones. I treated these as prompts for inquiry, not as proof about any individual.
• I changed meeting practices so proposals were circulated in advance, attendees had time to write thoughts before discussion, and I invited input from people who had not yet spoken without putting them on the spot.
• I made expectations for hiring more consistent. Interviewers used shared rubrics, calibrated on evidence rather than “culture fit,” and reviewed the candidate experience for avoidable barriers.
• I checked how work and visibility were distributed. I rotated ownership of high-impact projects, gave clear sponsorship and feedback, and made sure credit followed the people who did the work.
• When someone raised a concern about a dismissive interaction, I addressed the behavior directly and privately, clarified the impact and expectation, and followed up with the affected person rather than asking them to carry the burden of fixing it.
• I reviewed progress with the team using a few indicators—such as belonging feedback, opportunity distribution, and retention—while protecting individual privacy and avoiding simplistic demographic quotas.

Result

Over two review cycles, more team members reported feeling heard, and participation in design reviews became less concentrated. We also improved consistency in hiring feedback and expanded the pool of engineers taking on visible project leadership. I learned that inclusion requires both everyday habits and accountability; it is not achieved by a single training session.

What interviewers listen for

• Concrete changes to team systems, not just stated values.
• Psychological safety paired with clear accountability.
• Careful use of data, without reducing people to metrics.

Model answer

Situation

On a team of about a dozen engineers, a strong performer became unusually quiet in planning and started missing a few commitments. The immediate temptation was to treat it as a performance problem, but I knew there could be context I did not understand, and that my response would affect both the individual and the team’s trust.

Task

I needed to understand what was happening, support the person appropriately, and address any impact on delivery without making assumptions or lowering expectations for the rest of the team.

Action

• I asked for a private conversation and started with specific observations: “I noticed you’ve been quieter in design reviews and the last two milestones slipped. How are things going?” I avoided diagnosing their motivation or asking them to disclose personal information.
• I listened without rushing to prescribe a fix. I reflected back what I heard and checked that I understood. The engineer explained that priorities had changed repeatedly and they were reluctant to challenge a senior stakeholder in public.
• I acknowledged the impact on them and on the team, while separating empathy from agreement that the situation could continue unchanged. We identified which issues I could address as their manager and what they wanted to own themselves.
• I worked with the product partner to clarify priorities and created a safer path for design concerns: pre-reads, explicit decision owners, and a chance to raise objections before the review. I coached the engineer on how to frame a concise trade-off and offered to help escalate if needed.
• I agreed on a short follow-up period with clear expectations for commitments and check-ins. I shared only the minimum necessary context with others, focusing on work changes rather than private details.
• I also looked for systemic causes. If changing priorities affected one person, they might be affecting the rest of the team too, so I reviewed how scope changes were being communicated.

Result

The engineer re-engaged in design discussions and delivered the next milestone after priorities were stabilized. The team adopted the pre-read and decision-owner practice, which made disagreement more constructive and reduced late design changes. I learned that empathy is not avoiding hard conversations: it helps me understand the real problem, respond fairly, and maintain clear expectations.

What interviewers listen for

• Curiosity and emotional self-awareness rather than assumptions.
• Compassion paired with accountability and sound boundaries.
• Discretion, fair treatment, and attention to systemic causes.

Model answer

Situation

In a previous role, I managed an engineer whose delivery and follow-through had become inconsistent over several months. Work was repeatedly slipping, and teammates were stepping in late to unblock dependencies. I also knew that the engineer had recently taken on a new area of responsibility, so I did not want to assume the issue was simply lack of effort.

Task

My responsibility was to understand the gap, give the person a fair opportunity to improve, and protect the team’s commitments and workload. I needed to be direct while preserving dignity and following the organization’s performance process.

Action

• Gather specific evidence. I reviewed agreed goals, delivery examples, quality issues, and feedback from relevant collaborators. I separated observable behavior—such as missed updates or incomplete handoffs—from interpretations about motivation.
• Start a private, candid conversation. I described the pattern and its impact, then asked for the engineer’s perspective. I listened for context such as unclear expectations, workload, skill gaps, personal constraints, or dependencies before deciding what support was appropriate.
• Agree on a measurable plan. Together, we selected a small number of expectations for the next several weeks—for example, breaking work into reviewable milestones, raising blockers within one business day, and meeting agreed quality standards. I made clear what success looked like and when we would review it.
• Provide targeted support. Depending on the gap, I paired the engineer with a mentor, clarified priorities, reduced competing work, or arranged technical coaching. I scheduled regular check-ins and documented commitments so there were no surprises.
• Be fair and accountable. I recognized improvements as they happened, but did not lower the role’s standards or shift the impact onto teammates indefinitely. If progress had not met the agreed bar, I would involve HR and follow the formal process respectfully.

Result

In this example, clearer priorities and more frequent feedback helped the engineer improve communication and complete work more predictably over the following review period. The team also had fewer last-minute handoffs. I learned to combine empathy with clarity: support should address a real barrier, while accountability makes expectations and consequences understandable.

What interviewers listen for

• Specific, behavior-based feedback rather than labels or assumptions.
• Curiosity, support, measurable expectations, and follow-through.
• Fairness to both the individual and the rest of the team.

Model answer

Situation — I managed a relationship with an external provider that supplied a critical component of our customer workflow. The provider offered specialized capability we did not want to build immediately, but outages or slow support could affect our own service commitments. We needed to get value from the partnership without treating the vendor as a substitute for internal ownership.

Task — I was accountable for aligning the provider’s work with our technical and business needs, maintaining a productive relationship, and managing operational, security, and continuity risks.

Action

• I established the outcomes and boundaries up front: what we expected the service to do, service-level targets, support response times, security requirements, data handling, and who had authority to make decisions on each side.
• I created a shared operating rhythm: regular reviews of service health, incidents, roadmap changes, open risks, and actions. I kept the conversation evidence-based using agreed metrics such as availability, latency, incident response time, and unresolved defects.
• I built a direct relationship with both the provider’s account lead and technical escalation contact. When an incident occurred, I focused first on customer impact and recovery, then held a blameless review with clear owners and dates for corrective actions.
• I made trade-offs explicit. For example, when the provider proposed a change that could improve capability but required migration work, I asked for a test environment, compatibility plan, rollback path, and a cost-and-risk estimate before committing.
• I protected our leverage and resilience by documenting integrations, keeping internal ownership of architecture and customer data, reviewing access regularly, and maintaining a practical exit or fallback plan. I also involved procurement, security, and legal partners for contractual and compliance decisions.

Result — The partnership delivered the needed capability with clearer escalation and fewer surprises. When service issues arose, both teams could quickly identify impact, responsibilities, and next steps. I learned that a strong vendor relationship combines trust and collaboration with measurable expectations, independent verification, and a credible plan for failure.

What interviewers listen for

• You treat the provider as a partner while retaining internal accountability.
• You manage SLAs, security, escalation, cost, and continuity risks.
• You handle incidents and roadmap changes with evidence and clear ownership.

Model answer

This implementation supports on, once, off/removeListener, emit, removeAllListeners, listeners, and listenerCount. Listeners run synchronously in registration order. emit returns false when there are no listeners, and an unhandled error event throws, following the familiar Node.js convention.

class EventEmitter {
  constructor() {
    this.events = new Map();
  }

  on(event, listener) {
    this._validateListener(listener);
    const entries = this.events.get(event) || [];
    entries.push({ listener, once: false });
    this.events.set(event, entries);
    return this;
  }

  once(event, listener) {
    this._validateListener(listener);
    const entries = this.events.get(event) || [];
    entries.push({ listener, once: true });
    this.events.set(event, entries);
    return this;
  }

  off(event, listener) {
    const entries = this.events.get(event);
    if (!entries) return this;

    // Remove the most recently registered matching listener.
    const index = entries.findLastIndex(entry => entry.listener === listener);
    if (index !== -1) entries.splice(index, 1);
    if (entries.length === 0) this.events.delete(event);
    return this;
  }

  removeListener(event, listener) {
    return this.off(event, listener);
  }

  emit(event, ...args) {
    const entries = this.events.get(event);
    if (!entries || entries.length === 0) {
      if (event === 'error') {
        const error = args[0] instanceof Error
          ? args[0]
          : new Error('Unhandled error event');
        throw error;
      }
      return false;
    }

    // Snapshot iteration means mutations during emit affect later emits.
    for (const entry of [...entries]) {
      if (entry.once) this._removeEntry(event, entry);
      entry.listener.apply(this, args);
    }
    return true;
  }

  removeAllListeners(event) {
    if (event === undefined) this.events.clear();
    else this.events.delete(event);
    return this;
  }

  listeners(event) {
    return (this.events.get(event) || []).map(entry => entry.listener);
  }

  listenerCount(event) {
    return (this.events.get(event) || []).length;
  }

  _removeEntry(event, target) {
    const entries = this.events.get(event);
    if (!entries) return;
    const index = entries.indexOf(target);
    if (index !== -1) entries.splice(index, 1);
    if (entries.length === 0) this.events.delete(event);
  }

  _validateListener(listener) {
    if (typeof listener !== 'function') {
      throw new TypeError('listener must be a function');
    }
  }
}

const emitter = new EventEmitter();
const onReady = value => console.log(`ready: ${value}`);
emitter.on('ready', onReady);
emitter.once('ready', value => console.log(`one time: ${value}`));
emitter.emit('ready', 1);
emitter.off('ready', onReady);

• A once listener is removed before invocation, so a recursive emit cannot invoke it twice. Listener exceptions propagate to the caller.
• Complexity: Registration and emit are O(L) for L listeners (including snapshot creation); removal is O(L).

Model answer

Define the counter as exact hits per page in a trailing time window. This implementation uses millisecond timestamps, a configurable window, and assumes calls for each page arrive with nondecreasing timestamps. count returns hits in (now - windowMs, now]; expired hits are removed lazily. For lifetime counts instead, a per-page integer map is sufficient.

class PageHitCounter {
  constructor(windowMs = 5 * 60 * 1000) {
    if (!Number.isFinite(windowMs) || windowMs <= 0) {
      throw new Error('windowMs must be positive');
    }
    this.windowMs = windowMs;
    this.pages = new Map();
  }

  hit(page, timestamp = Date.now()) {
    this._validate(page, timestamp);
    const state = this._stateFor(page);
    this._checkOrder(state, timestamp);
    this._expire(state, timestamp);
    state.timestamps.push(timestamp);
    state.lastTimestamp = timestamp;
    return state.timestamps.length - state.head;
  }

  count(page, timestamp = Date.now()) {
    this._validate(page, timestamp);
    const state = this.pages.get(page);
    if (!state) return 0;
    this._checkOrder(state, timestamp);
    this._expire(state, timestamp);
    state.lastTimestamp = timestamp;
    return state.timestamps.length - state.head;
  }

  _stateFor(page) {
    let state = this.pages.get(page);
    if (!state) {
      state = { timestamps: [], head: 0, lastTimestamp: -Infinity };
      this.pages.set(page, state);
    }
    return state;
  }

  _expire(state, now) {
    const cutoff = now - this.windowMs;
    while (
      state.head < state.timestamps.length &&
      state.timestamps[state.head] <= cutoff
    ) {
      state.head += 1;
    }

    // Occasionally compact so old entries do not accumulate in the array.
    if (state.head > 1024 && state.head * 2 > state.timestamps.length) {
      state.timestamps = state.timestamps.slice(state.head);
      state.head = 0;
    }
  }

  _checkOrder(state, timestamp) {
    if (timestamp < state.lastTimestamp) {
      throw new Error('timestamps must be nondecreasing per page');
    }
  }

  _validate(page, timestamp) {
    if (typeof page !== 'string' || page.length === 0) {
      throw new Error('page must be a non-empty string');
    }
    if (!Number.isFinite(timestamp)) {
      throw new Error('timestamp must be finite');
    }
  }
}

const counter = new PageHitCounter(60_000);
counter.hit('/home', 1_000);
counter.hit('/home', 2_000);
console.log(counter.count('/home', 30_000)); // 2
console.log(counter.count('/home', 70_000)); // 0

• Store timestamps in insertion order; the head index avoids the O(n) cost of repeatedly shifting arrays.
• Expiration is amortized O(1) per hit/query; memory is proportional to unexpired hits, plus temporary stale entries before compaction.

Model answer

Assume each regular file contains whitespace-separated integers, duplicates count as separate occurrences, and “top” means largest. Stream files instead of loading the directory contents into memory, and maintain a min-heap of at most K values. The CLI below prints the result in descending order.

const fs = require('node:fs/promises');
const path = require('node:path');
const readline = require('node:readline');
const { createReadStream } = require('node:fs');

class MinHeap {
  constructor() {
    this.items = [];
  }

  push(value) {
    const a = this.items;
    a.push(value);
    let i = a.length - 1;
    while (i > 0) {
      const parent = Math.floor((i - 1) / 2);
      if (a[parent] <= value) break;
      a[i] = a[parent];
      i = parent;
    }
    a[i] = value;
  }

  peek() {
    return this.items[0];
  }

  replaceMin(value) {
    const a = this.items;
    let i = 0;
    while (true) {
      const left = 2 * i + 1;
      const right = left + 1;
      if (left >= a.length) break;
      let child = left;
      if (right < a.length && a[right] < a[left]) child = right;
      if (a[child] >= value) break;
      a[i] = a[child];
      i = child;
    }
    a[i] = value;
  }

  toDescendingArray() {
    return [...this.items].sort((a, b) => b - a);
  }
}

async function topKIntegers(directory, k) {
  if (!Number.isInteger(k) || k < 0) {
    throw new Error('k must be a non-negative integer');
  }
  if (k === 0) return [];

  const heap = new MinHeap();
  const entries = await fs.readdir(directory, { withFileTypes: true });

  for (const entry of entries) {
    if (!entry.isFile()) continue;
    const filePath = path.join(directory, entry.name);
    const lines = readline.createInterface({
      input: createReadStream(filePath),
      crlfDelay: Infinity
    });

    for await (const line of lines) {
      for (const token of line.trim().split(/\s+/)) {
        if (token === '') continue;
        if (!/^[+-]?\d+$/.test(token)) {
          throw new Error(`Invalid integer '${token}' in ${entry.name}`);
        }
        const value = Number(token);
        if (!Number.isSafeInteger(value)) {
          throw new Error(`Integer outside JavaScript safe range in ${entry.name}`);
        }

        if (heap.items.length < k) heap.push(value);
        else if (value > heap.peek()) heap.replaceMin(value);
      }
    }
  }

  return heap.toDescendingArray();
}

const [directory, rawK] = process.argv.slice(2);
if (!directory || rawK === undefined) {
  console.error('Usage: node top-k.js <directory> <k>');
  process.exit(1);
}
topKIntegers(directory, Number(rawK))
  .then(values => console.log(JSON.stringify(values)))
  .catch(error => {
    console.error(error.message);
    process.exitCode = 1;
  });

• Each integer is considered independently, so duplicates are preserved. To return distinct values, track a set or deduplicate before heap insertion.
• Complexity: For N integers, O(N log K) time and O(K) heap space, excluding stream buffers. Output sorting costs O(K log K).

Model answer

Assume the CSV has one numeric value per row, or that the selected column contains a number on every nonblank row. This implementation emits a result for each value, using the available values during the initial partial window. It computes the average with a running sum and the maximum with a max-heap that lazily discards expired entries. Set the optional column index with the third argument.

const fs = require('node:fs');
const readline = require('node:readline');

class MaxHeap {
  constructor() {
    this.items = [];
  }

  push(item) {
    const a = this.items;
    a.push(item);
    let i = a.length - 1;
    while (i > 0) {
      const parent = Math.floor((i - 1) / 2);
      if (a[parent].value >= item.value) break;
      a[i] = a[parent];
      i = parent;
    }
    a[i] = item;
  }

  peek() {
    return this.items[0];
  }

  pop() {
    const a = this.items;
    if (a.length === 0) return undefined;
    const root = a[0];
    const last = a.pop();
    if (a.length > 0) {
      let i = 0;
      while (true) {
        const left = 2 * i + 1;
        const right = left + 1;
        if (left >= a.length) break;
        let child = left;
        if (right < a.length && a[right].value > a[left].value) child = right;
        if (a[child].value <= last.value) break;
        a[i] = a[child];
        i = child;
      }
      a[i] = last;
    }
    return root;
  }
}

async function rollingStats(filePath, windowSize, columnIndex = 0) {
  if (!Number.isInteger(windowSize) || windowSize <= 0) {
    throw new Error('windowSize must be a positive integer');
  }
  if (!Number.isInteger(columnIndex) || columnIndex < 0) {
    throw new Error('columnIndex must be a non-negative integer');
  }

  const input = readline.createInterface({
    input: fs.createReadStream(filePath),
    crlfDelay: Infinity
  });
  const heap = new MaxHeap();
  let sum = 0;
  let index = 0;

  for await (const line of input) {
    if (line.trim() === '') continue;
    const fields = line.split(',');
    if (columnIndex >= fields.length) {
      throw new Error(`Missing column ${columnIndex} at data row ${index + 1}`);
    }
    const value = Number(fields[columnIndex].trim());
    if (!Number.isFinite(value)) {
      throw new Error(`Invalid number at data row ${index + 1}`);
    }

    sum += value;
    heap.push({ value, index });
    const firstInWindow = index - windowSize + 1;
    if (firstInWindow > 0) {
      // Remove the value leaving the window from the running sum.
      // Heap entries are discarded lazily when they reach the top.
      const expiredValue = Number(fields[columnIndex].trim());
      // The outgoing value is read from a ring buffer below instead.
      sum -= ring[firstInWindow % windowSize];
    }
    ring[index % windowSize] = value;
    while (heap.peek().index < firstInWindow) heap.pop();

    const count = Math.min(index + 1, windowSize);
    console.log(`${index},${sum / count},${heap.peek().value}`);
    index += 1;
  }
}

const ring = [];
const [filePath, rawWindow, rawColumn = '0'] = process.argv.slice(2);
if (!filePath || !rawWindow) {
  console.error('Usage: node rolling.js <csv-file> <window-size> [column-index]');
  process.exit(1);
}
rollingStats(filePath, Number(rawWindow), Number(rawColumn)).catch(error => {
  console.error(error.message);
  process.exitCode = 1;
});

• The ring buffer retains only values needed to subtract the item leaving the average window; the heap provides the maximum.
• Complexity: O(n log n) time and O(n) worst-case heap space with lazy deletion; the sum and ring buffer use O(W) space. For O(W) total space, use a monotonic deque for the maximum, which is O(n) time.

Model answer

1. Requirements & scale

I start by clarifying the product, users, core workflows, and service-level objectives. For a concrete baseline, assume a global consumer application with user accounts, a read-heavy feed or catalog, and asynchronous notifications.

• Functional: serve and update user-facing data; authenticate and authorize requests; support search or filtering; notify users of important changes.
• Non-functional: 99.95% availability, p95 reads below 200 ms, durable writes, regional resilience, privacy, and safe deploys.
• Assumptions: 10 million daily active users, 20 requests per user per day, and a 10:1 read-to-write ratio.
• Average traffic is about 2,300 requests/second: 10M × 20 / 86,400. At a 10× peak, plan for about 23,000 requests/second. Roughly 21,000 are reads and 2,000 are writes at peak.
• If each active user creates 1 KB of durable data per day, that is about 10 GB/day or 3.65 TB/year raw, before indexes and replicas. If average responses are 20 KB, peak egress is about 420 MB/s; CDN caching should absorb much of it.

2. High-level architecture

I keep the request path stateless and short; expensive or non-critical work runs asynchronously. The components below are a starting point, not a reason to introduce every technology on day one.

flowchart TD
  subgraph CLIENT[Client]
    App[Web and Mobile]
  end
  subgraph EDGE[Edge CDN]
    CDN[CDN and WAF]
  end
  subgraph LB[Load Balancer]
    ALB[Regional Load Balancer]
  end
  subgraph API[API Services]
    Gateway[API Gateway]
    Auth[Auth Service]
    Feed[Product API]
    Notify[Notification API]
  end
  subgraph CACHE[Cache]
    Redis[Redis Cluster]
  end
  subgraph DATA[Datastores]
    SQL[Sharded SQL Database]
    Search[Search Index]
    Blob[Object Storage S3]
  end
  subgraph MQ[Message Queue]
    Queue[Durable Event Queue]
  end
  subgraph WORKERS[Workers]
    Worker[Async Workers]
  end
  App -->|HTTPS requests| CDN
  CDN -->|cache miss and API traffic| ALB
  ALB -->|routed requests| Gateway
  Gateway -->|identity check| Auth
  Gateway -->|read or write| Feed
  Gateway -->|notification request| Notify
  Feed -->|hot reads| Redis
  Feed -->|durable records| SQL
  Feed -->|search query| Search
  Feed -->|media upload and download| Blob
  Notify -->|events| Queue
  Feed -->|domain events| Queue
  Queue -->|work items| Worker
  Worker -->|update index and deliver messages| Search
  Worker -->|notification delivery| Notify

3. API design

• GET /v1/items?cursor=... — fetch a page; return a stable cursor rather than an offset.
• POST /v1/items — create an item; accept an idempotency key to make retries safe.
• GET /v1/items/{id} — retrieve a single item, with authorization enforced at the service.
• POST /v1/media/uploads — request a short-lived signed upload URL; upload bytes directly to object storage.
• GET /v1/search?q=... — query the search index, with an explicit freshness expectation.

I version breaking changes, set timeouts and payload limits, and define error semantics and rate limits up front.

4. Data model & storage

• Use SQL for authoritative users, permissions, and transactional product data. Example tables: users(user_id, ...), items(item_id, owner_id, created_at, ...), and outbox(event_id, aggregate_id, payload, published_at).
• Partition or shard high-volume item data by item_id or a carefully selected tenant key; avoid a single hot tenant becoming a hotspot. Index common access patterns such as (owner_id, created_at).
• Store media in object storage and keep metadata and object keys in SQL. Use a search index for text search, rebuilt from durable events rather than treated as the source of truth.
• Cache hot, safe-to-cache reads in Redis with bounded TTLs and explicit invalidation where correctness requires it.

5. Deep dive

The core design decision is making database changes and asynchronous side effects reliable. A service should not commit a record and then silently lose the event that updates search or sends a notification. I use the transactional outbox: write the domain row and an outbox row in one SQL transaction; a publisher delivers outbox events to the durable queue; consumers are idempotent and track progress. The queue provides at-least-once delivery, so consumers must tolerate duplicates.

sequenceDiagram
  participant C as Client
  participant A as API Service
  participant D as SQL Database
  participant P as Outbox Publisher
  participant Q as Event Queue
  participant W as Worker
  C->>A: POST item with idempotency key
  A->>D: Transaction: item plus outbox event
  D-->>A: Commit
  A-->>C: 201 Created
  P->>D: Read unpublished outbox rows
  P->>Q: Publish event with event ID
  Q->>W: Deliver at least once
  W->>D: Record processed event ID
  W->>W: Update search or send notification

I would monitor outbox age, queue lag, consumer retries, duplicate rates, and end-to-end event completion time. Poison messages go to a dead-letter queue with an operational replay path.

6. Scale, bottlenecks & trade-offs

• Run stateless API instances across availability zones behind health-checked load balancing; scale horizontally from saturation and latency signals, not CPU alone.
• Use CDN caching for public, immutable assets. Use Redis for hot reads, but protect the database from cache stampedes and never let cache contents become the only copy of data.
• Replicate SQL for read capacity and availability. Keep writes on the primary initially; shard only when measured write, storage, or maintenance limits justify the added operational complexity. Choose consistency per workflow: strong consistency for permissions and financial state, eventual consistency for search and notifications.
• Apply backpressure, bounded retries with jitter, circuit breakers, request budgets, and per-tenant rate limits. A queue smooths bursts, but does not remove capacity limits; autoscale consumers against lag.
• Multi-region active-active

Model answer

1. Start with the contract

• Design around a clear user or service need. Keep endpoints resource-oriented, predictable, and consistent—for example, GET /v1/orders/{orderId}.
• Define request and response schemas, required fields, formats, defaults, and constraints. Use standard HTTP methods and status codes; return a consistent error shape with a stable code, human-readable message, and optional field-level details.
• Make behavior explicit: ordering, pagination, filtering, time zones, partial updates, and whether an operation is synchronous or asynchronous.

2. Make safe behavior the default

• Authenticate and authorize every request; enforce least privilege at the resource level. Validate input server-side and avoid exposing sensitive data in responses or logs.
• Make retry behavior safe. For operations that create or charge resources, support idempotency keys and define their retention and conflict behavior.
• Set timeouts, request-size limits, and rate limits. For long-running work, return 202 Accepted with a status resource rather than holding the connection open.

3. Evolve without surprising clients

• Prefer additive changes. Version only when a breaking change cannot be avoided; publish deprecation timelines and monitor actual usage before removing old behavior.
• Maintain an API specification, such as OpenAPI, and use contract tests between producers and consumers. Keep generated docs and SDKs aligned with the deployed contract.

4. Operate and govern the API

• Instrument latency, error rate, throughput, saturation, and usage by endpoint and client. Avoid high-cardinality or sensitive metric labels.
• Define SLOs, ownership, escalation paths, and a compatibility review process. Review APIs with the teams that build and consume them.

flowchart TD
  C["Client"] -->|"request"| G["Gateway: auth, limits"]
  G -->|"validated request"| A["API service"]
  A -->|"business operation"| D["Data store"]
  D -->|"result"| A
  A -->|"response or standard error"| G
  G -->|"status, headers, body"| C
  G -->|"metrics and traces"| O["Observability"]

Trade-off: Strict validation and consistent contracts reduce ambiguity, but overly rigid schemas can slow evolution. I would enforce correctness and security while allowing safe additive fields, and use versioning only for genuinely incompatible changes.

What interviewers listen for: Client empathy, security, backward compatibility, retry safety, operability, and a governance approach that scales across teams.

Model answer

1. Clarify the decision

• I would start by asking what decision the analysis must support, who will make it, and by when.
• I would clarify the target population, time horizon, constraints, and what action is available. A question such as “Should we invest in onboarding?” needs a decision threshold, not just a dashboard.

2. Define the outcome and success criteria

• I would define a primary business metric, such as incremental retained customers or contribution margin, and supporting metrics that explain the mechanism.
• I would state guardrails up front—for example, support contacts, refunds, or customer complaints—and agree on the minimum effect that would change the decision.

3. Build a causal and analytical plan

• I would draw the path from intervention to customer behavior to business outcome, then identify confounders, selection effects, and data-quality risks.
• If a randomized experiment is feasible, I would estimate the required sample size and duration. Otherwise, I would choose a credible quasi-experimental design and state its assumptions.
• I would predefine the primary analysis, segment cuts, and treatment of missing data to limit post-hoc cherry-picking.

flowchart TD
    A[Business question] --> B[Decision and population]
    B --> C[Metric and guardrails]
    C --> D[Data and causal design]
    D --> E[Estimate impact and uncertainty]
    E --> F[Recommendation and monitoring]

4. Validate, analyze, and interpret

• I would audit event definitions, exposure assignment, coverage, and sample balance before interpreting results.
• I would report effect size and uncertainty—not just statistical significance—and test whether results differ meaningfully across pre-specified segments.
• I would distinguish correlation from causal evidence and explain how much the conclusion depends on assumptions.

5. Make the recommendation actionable

• I would present the answer first, then the evidence, caveats, and alternatives. I would recommend launch, iterate, or stop against the agreed threshold.
• I would assign owners for rollout and monitoring, with guardrails and a revisit date. A good analysis ends in a decision and a learning loop, not a slide deck.

What matters at manager level: align stakeholders on the decision, make analytical rigor proportional to the stakes, and ensure the work changes business action.

Model answer

1. Frame the problem and stakes

Use a specific example where the technical issue affected a user or business outcome, not just an interesting piece of engineering. Explain your role, the affected system and teams, the scale, and the measurable impact. For example: a latency regression in a high-traffic checkout path that increased timeouts and threatened conversion.

2. Establish evidence before choosing a fix

• Quantify the baseline and target: p95/p99 latency, error rate, throughput, affected requests, and the relevant SLO or product metric.
• Trace the request across dependencies; inspect recent changes, saturation, queue depth, and representative slow requests. Segment by endpoint, region, client, and time to avoid treating a symptom as a root cause.
• State the root cause and evidence clearly. Distinguish what you knew from what you initially hypothesized.

3. Explain the decision and execution

• Compare plausible options—for example, optimize the hot path, add capacity, cache data, or reduce synchronous dependencies. Discuss latency, consistency, cost, operational complexity, and failure behavior.
• Describe how you brought engineers and partner teams into the investigation, assigned owners, and kept product or support informed about risk and mitigation.
• Prefer a reversible mitigation first if customers are actively affected; then deliver the durable fix behind a canary or staged rollout. Define rollback signals in advance.
• Show the technical detail that demonstrates your contribution, while making clear what the team owned and where you delegated.

flowchart TD
  I["Impact detected"] --> E["Gather traces and metrics"]
  E --> R["Validate root cause"]
  R --> O["Compare mitigation options"]
  O --> M["Stage fix and monitor"]
  M -->|"guardrail breached"| B["Rollback or mitigate"]
  M -->|"healthy"| L["Learn and prevent recurrence"]

4. Close with outcomes and learning

Quantify before and after: latency, errors, SLO attainment, customer impact, or operating cost. Mention how the fix was made durable through tests, alerts, capacity planning, or an architectural change.

What interviewers listen for: A disciplined diagnosis, sound technical trade-offs, collaboration across boundaries, safe execution, measurable impact, and learning without blame. Avoid claiming a team result as a solo achievement.

Model answer

1. Clarify the metric and the change

• I would first confirm the retention definition: logo, user, or revenue retention; the cohort start event; the return event; and the observation window.
• I would check whether the apparent month-to-month movement is a change in cohort behavior or a change in who entered the cohort. Recent cohorts may be immature, so I would compare equivalent lifecycle windows.

2. Decompose the movement

• I would calculate cohort retention curves and compare like-for-like cohorts, then segment by acquisition channel, geography, plan, platform, product use case, and customer tenure.
• I would also inspect related signals: activation, time to first value, usage frequency, cancellations, payment failures, and support contacts.

flowchart TD
    A[Retention moved] --> B{Metric and data valid?}
    B -- No --> C[Check events, joins, maturity]
    B -- Yes --> D[Compare same-age cohorts]
    D --> E[Decompose mix and segments]
    E --> F[Inspect product and external drivers]
    F --> G[Estimate causes and choose action]

3. Test the main hypotheses

• Cohort mix: acquisition shifted toward a lower-retention channel, market, or customer segment.
• Product experience: an onboarding, pricing, or reliability change affected activation or repeat value.
• Seasonality and calendar: holidays, billing cycles, school or work patterns, or industry cycles changed usage.
• External or operational factors: competitor activity, outages, policy changes, payment failures, or support delays.
• Measurement artifacts: event loss, altered definitions, delayed data, duplicate users, or incomplete right-censoring.

4. Establish what is causal

• I would annotate the timeline with launches, campaigns, outages, and pricing changes, then quantify contribution by segment rather than relying on anecdotes.
• If an intervention is suspected, I would use an experiment where feasible. For a past change, I would consider a difference-in-differences or interrupted time-series design, checking pre-trends and alternative explanations.
• I would report both absolute percentage-point change and relative change, with uncertainty and cohort sizes.

5. Decide and monitor

• If the movement is mostly mix, I would revisit acquisition quality and channel economics. If it is a product regression, I would prioritize fixing the affected journey and monitor retention plus guardrails such as conversion and support burden.
• I would avoid reacting to one noisy monthly aggregate. I would define an alert for meaningful, sustained movement and track mature cohorts at consistent windows.

What interviewers listen for: sound metric definitions, cohort maturity, decomposition before explanation, causal caution, and a clear path from diagnosis to action.

Model answer

1. Align priorities to outcomes

• Start with the organization’s goals, customer impact, and committed outcomes—not the loudest request. Make the team’s objectives and constraints visible.
• Compare work using a consistent lens: expected impact, urgency or risk reduction, confidence, effort, dependencies, and strategic fit. Use a lightweight score or impact-versus-effort view to inform judgment, not replace it.
• Reserve explicit capacity for operational work, technical health, and unplanned incidents. The exact allocation should reflect the team’s reliability needs and current commitments.

2. Make trade-offs explicit

• Build a ranked backlog with a clear owner, outcome, estimate range, and dependency. Separate must-do commitments from options that can move.
• When priorities conflict, explain what will be delayed and why. Escalate genuine cross-org trade-offs with options and consequences rather than passing ambiguity to engineers.
• Revisit priorities when customer evidence, risk, or capacity changes; don’t let a quarterly plan become a promise to ignore new information.

3. Delegate outcomes, not just tasks

• Match responsibility to strengths, growth goals, and available capacity. Give a person or small group a clear problem, decision boundaries, expected result, and support—not a prescribed list of keystrokes.
• Keep accountability with the EM for staffing, alignment, and removing blockers. Use milestones and lightweight check-ins to surface risk early, while leaving implementation decisions with the owner.
• For cross-team work, name a directly responsible individual, clarify interfaces, and agree on escalation and communication paths.

flowchart TD
  G["Goals and customer needs"] --> P["Rank by impact, risk, effort"]
  P --> C["Check capacity and dependencies"]
  C --> D["Delegate outcomes and ownership"]
  D --> M["Review progress and evidence"]
  M -->|"new information"| P

Measure: Delivery against outcome milestones, unplanned-work share, lead time, reliability, and whether delegated owners can make decisions without waiting for the manager.

Pitfall: Prioritizing only visible feature work can create reliability and maintenance debt; delegating only low-risk chores can also stunt growth. I balance delivery with sustainable ownership and revisit the allocation as evidence changes.

Model answer

1. Clarify the change and its rationale. I first determine what changed: user need, business priority, regulation, dependency, or a new idea. I ask what outcome the change is expected to improve, who is requesting it, how urgent it is, and whether it is a firm commitment or a proposal. This prevents the team from treating every new request as equally important.
2. Assess impact with the team. I ask the engineering and product leads to estimate the change’s impact on scope, critical path, architecture, quality, staffing, and operational risk. I make dependencies and uncertainty explicit; an estimate should not be presented as a promise. I also check what work would be displaced and whether the change affects other teams or customer commitments.
3. Offer options and trade-offs. I typically frame choices such as: - Add the work and move the date. - Keep the date and remove or defer lower-value scope. - Deliver a smaller, safe version first, then iterate. - Decline or revisit the request if it does not justify the cost or risk.

I recommend an option based on customer and business value, risk, reversibility, and opportunity cost—not simply on who requested the change. I will not trade away security, compliance, or an agreed reliability bar to preserve an arbitrary date.

1. Make the decision and reset the plan. The product or business owner should make product-priority trade-offs; engineering should own technical feasibility and risk; I help the group reach a clear decision and ensure impacts are understood. Once agreed, I update milestones, owners, dependencies, and success measures. If the change affects a committed date, I communicate the new forecast and rationale promptly to stakeholders.
2. Control execution without blocking learning. I use a lightweight change log for material changes, with the decision, owner, rationale, and expected impact. Small, reversible discoveries can be handled within team boundaries; changes to a commitment, architecture, or risk profile require broader review. I revisit assumptions at planning checkpoints rather than allowing scope to grow silently.

flowchart TD
    A[Scope change proposed] --> B[Clarify user and business outcome]
    B --> C[Assess effort, risk, and dependencies]
    C --> D{Value justifies cost?}
    D -->|No| E[Defer or decline with rationale]
    D -->|Yes| F[Compare date, scope, and phased options]
    F --> G[Decision by accountable owners]
    G --> H[Update plan and communicate]
    H --> I[Track outcome and revisit]

Metrics and pitfalls: I track milestone predictability, scope added after commitment, defect and incident rates, and whether the changed work delivered the intended customer or business outcome. The common pitfalls are accepting scope without naming what moves, treating estimates as guarantees, and allowing urgency to bypass quality or risk controls. The management goal is not to prevent change; it is to make change deliberate, visible, and connected to outcomes.

Model answer

I treat code quality as a team-owned system, not a gate delegated to a few senior reviewers. The goal is code that is safe to change, understandable by the people who maintain it, and reliable for users—without slowing delivery through unnecessary process.

1. Set a clear quality bar. Agree on practical standards for readability, testing, security, performance, and API compatibility. Tailor the bar to risk: payment, privacy, and authorization changes need stronger review and validation than a low-risk internal tool. Keep guidance short and discoverable.
2. Build quality into the workflow. Provide fast CI with formatting, linting, type checks where useful, unit and integration tests, dependency/security scanning, and checks for regressions. Make the common path easy: templates, local tooling, reusable libraries, and clear ownership reduce reliance on individual memory.
3. Use tests at the right level. Favor focused unit tests for business rules and integration or contract tests at service and data boundaries. Keep a small, reliable end-to-end suite for critical customer journeys. Track flaky tests and fix or quarantine them quickly; a noisy suite trains engineers to ignore failures.
4. Make review collaborative. Reviewers should focus on correctness, design, security, failure modes, and maintainability—not formatting that automation can handle. Use small pull requests, identify an owner for critical components, and explain the reasoning behind changes. Rotate reviewers and pair on complex work so knowledge is shared rather than trapped with one expert.
5. Learn from production. Track escaped defects, change failure rate, rollback frequency, incident recurrence, and time to restore service alongside delivery lead time. Run blameless reviews for significant incidents, then turn findings into owned changes: a missing test, alert, design constraint, or runbook update. Follow up to verify the fix works.
6. Invest deliberately. Reserve capacity for recurring maintenance and address the biggest sources of change friction. I would prioritize based on customer and operational risk, not a blanket code-coverage target. Coverage can reveal untested areas, but it does not prove tests are meaningful.

flowchart LR
  A[Design and clarify risk] --> B[Implement with team standards]
  B --> C[Automated checks and tests]
  C --> D[Focused peer review]
  D --> E[Canary or staged release]
  E --> F[Production metrics and incidents]
  F --> G[Learning and prioritized improvements]
  G --> A

At EM scope, I would inspect trends by service and team without turning metrics into individual performance targets. If review time or escaped defects rise, I would diagnose root causes—unclear ownership, slow CI, missing test environments, overloaded reviewers—before adding another approval step. The balance is consistent standards with autonomy in implementation.

What interviewers listen for: A sustainable quality culture, effective automation, risk-based judgment, shared ownership, and evidence that quality improves customer outcomes without creating process theater.