Airbnb Frontend Engineer Interview Preparation Guide - Mid Level (2-5 Years)

Direct answer

A strong answer here is a specific, honest story, not a general statement about valuing feedback: name the situation, the person, the actual content of what was heard, including if it stung a little, and then show a concrete, lasting change in either the work or the habit of asking, not just a one-time fix.

Structured elaboration

• Context. Pick a moment early enough in your career that asking took some initiative or nerve, since that's what this question is really probing: not "have you ever gotten feedback," but "did you go get it rather than wait for it."
• Who you asked, and why them. Name a specific person and why you chose them, a manager, a senior peer, someone whose judgment you specifically trusted, since the choice itself shows some intentionality.
• What you heard. Be specific and honest, including if the feedback was uncomfortable; a vague or safely-positive answer here reads as either not remembering it or not having really asked for anything real.
• What changed, and how you ask now. This is the part that separates a strong answer from a shallow one. Point to something concrete that's different in how you work now, or specifically in how you ask for feedback since then, more often, more specifically, from a wider set of people, not just "I took it to heart."

Worked example

Early in a first cross-functional project, for example a junior analyst's first project working directly with a business team outside their usual reporting line, the candidate proactively asks a more senior colleague on the project, "was there anything about how I presented this that made it harder to land with the business team?" The senior colleague says the analysis was technically solid, but it was presented with all the caveats and methodology up front, so by the time the actual finding showed up, the audience had already tuned out. That's specific, and a little uncomfortable to hear. The concrete change: since then, the candidate leads with the finding and the recommendation first, and puts methodology in an appendix or offers it only if asked. They also developed the habit of asking that same specific "what made this harder to land" question after every stakeholder-facing piece of work, not just waiting for a scheduled review.

Trade-offs and pitfalls

Choosing an example where the feedback was trivially positive doesn't actually demonstrate coachability. Describing what you heard but not what changed leaves the interviewer to guess whether it actually stuck. Over-dramatizing the feedback as devastating can read as performative rather than genuine. And describing only a one-time fix to that specific piece of work, instead of a durable change to how you work or ask for feedback afterward, undersells the point of the story.

Explanation (high level)

The event loop continuously takes one macrotask (task) from the task queue, runs it to completion, then drains the microtask queue (all microtasks) before rendering and moving to the next macrotask. Microtasks run immediately after the currently running script or macrotask and before the browser may paint.

Macrotasks vs Microtasks

• Macrotasks (tasks): setTimeout, setInterval, I/O, UI events.
• Microtasks: Promise callbacks (.then/.catch/finally), queueMicrotask, async function continuations (the part after await).

Microtasks have priority: all queued microtasks finish before the next macrotask or paint.

Example and execution order

Code:

console.log('script start');

setTimeout(() => console.log('timeout'), 0);

Promise.resolve().then(() => console.log('promise then 1'))
  .then(() => console.log('promise then 2'));

(async function() {
  console.log('async start');
  await null;
  console.log('async after await');
})();

console.log('script end');

Order:

1. script start
2. async start
3. script end
4. promise then 1
5. promise then 2
6. async after await
7. timeout

Why: the main script is a macrotask. During it, await schedules the continuation as a microtask. After the script finishes, the microtask queue runs (all Promise thens and async continuations), then the event loop processes the next macrotask (the setTimeout callback).

Practical implications for DOM updates in event handlers

• If you update the DOM inside a Promise.then or after await, the DOM mutation occurs as a microtask—before paint—so multiple microtask mutations get batched into one paint (good for performance).
• If you use setTimeout(..., 0) to update the DOM, the update happens in a later macrotask and will occur after microtasks and an intervening paint, which can cause flicker or extra layout paints.
• To ensure DOM reads reflect the latest writes, do writes in microtasks and limit synchronous reads (avoid layout thrashing). If you need the browser to paint before continuing (e.g., show a loader), use requestAnimationFrame or setTimeout to defer to the next frame.

Best practices for frontend devs

• Prefer Promise/async microtasks for quick, batched DOM work inside event handlers.
• Use requestAnimationFrame for visual updates tied to paint.
• Avoid mixing many sync reads/writes across microtasks to prevent forced reflows.
• Use setTimeout when you intentionally want to yield to the browser (e.g., allow a paint before heavy work).

Brief approach

• Build a curried wrapper that accumulates arguments (including placeholders) until the original function's arity (fn.length) is satisfied.
• Use a unique sentinel curry._ to mark skipped slots.
• When new args arrive, merge them into existing slots left-to-right, filling placeholders.
• Preserve calling this by using normal functions and calling fn.apply(this, finalArgs).

Code

// curry utility with placeholder support and this preservation
function curry(fn) {
  const arity = fn.length;
  const PLACEHOLDER = curry._;

  function mergeArgs(prev, next) {
    const merged = prev.slice();
    let ni = 0;
    for (let i = 0; i < merged.length && ni < next.length; i++) {
      if (merged[i] === PLACEHOLDER) {
        merged[i] = next[ni++];
      }
    }
    // append remaining next args
    while (ni < next.length) merged.push(next[ni++]);
    return merged;
  }

  function curried(prevArgs) {
    return function (...newArgs) {
      const all = mergeArgs(prevArgs, newArgs);
      const filledCount = all.filter(a => a !== PLACEHOLDER).length;
      if (filledCount >= arity) {
        const callArgs = all.slice(0, arity).map(a => a === PLACEHOLDER ? undefined : a);
        return fn.apply(this, callArgs);
      }
      return curried(all);
    };
  }

  return curried([]);
}
curry._ = Symbol('curry placeholder');

Why this works (short)

• Merges partials and placeholders predictably, fills left-to-right.
• Stops when non-placeholder count reaches fn.length, then invokes fn with the original this via apply.
• Uses a Symbol sentinel to avoid collisions with user data.

Approach summary
Describe features-first for modern browsers (progressive enhancement) and provide simple, robust fallbacks for IE11 (graceful degradation). Use feature-detection (@supports / JS) + build-time transpilation (PostCSS/Babel) + polyfills and test across real/virtual legacy browsers.

Feature detection & CSS examples

• Use @supports to gate modern code (Grid, container queries):

/* use Grid when available */
@supports (display: grid) {
  .layout { display: grid; grid-template-columns: 1fr 3fr; gap: 16px; }
}
/* fallback to flex for browsers without grid */
.layout { display: flex; flex-direction: row; }

• CSS variables fallback pattern:

:root { --brand: #0070f3; }
.button { background: var(--brand, #0070f3); } /* second arg is fallback */

Build & transpilation pipeline

• Use Browserslist to target evergreen + IE 11.
• PostCSS with postcss-preset-env (autoprefixer included) to polyfill newer CSS and add vendor prefixes.
• Example PostCSS config snippet:

module.exports = { plugins: [ require('postcss-preset-env')({ stage: 3, browsers: 'defaults, IE 11' }) ] }

• JavaScript: Babel with @babel/preset-env and core-js for polyfills; configure useBuiltIns: 'entry' or 'usage' per project.

Polyfills & JS feature detection

• Provide polyfills only where needed: core-js (Promise, Symbol), fetch polyfill, URLSearchParams if used.
• Use feature detection in JS (or Modernizr) to conditionally load polyfills:

if (!window.Promise) { import('core-js/features/promise'); }

Fallback layouts & UX

• Prefer mobile-first CSS; ensure layout degrades to a single-column for IE11 if Grid features fail.
• Avoid relying on complex interactions that break; provide non-JS accessible alternatives for critical features.
• For CSS gap in flex (unsupported in some legacy), use margin-based fallbacks.

Testing strategy

• Automated: set Browserslist targets in CI and run cross-browser test suites with BrowserStack / Sauce Labs for IE11 and latest Chrome/Firefox/Safari.
• Visual regression (Percy/Chromatic) to catch layout regressions in legacy viewports.
• Manual: smoke-test on a real Windows 7/10 VM or BrowserStack for keyboard navigation, forms, focus styles.
• Performance & audit: run Lighthouse for evergreen; ensure polyfills are conditionally loaded to avoid perf regressions for modern users.

Trade-offs & notes

• Shipping fewer polyfills => better modern perf; rely on feature-detection and targeted polyfills.
• Where parity is impossible or expensive (CSS Grid advanced alignment), accept visual degradation but keep functionality intact.
• Document browser support and known limitations in README so designers and PMs set expectations.

Direct answer

Confirmation bias, anchoring, and sunk-cost fallacy each distort a root-cause investigation in a specific, predictable way: confirmation bias makes you notice evidence supporting your first guess and discount evidence against it; anchoring makes an early, possibly wrong hypothesis dominate the rest of the investigation even after better evidence emerges; and sunk-cost fallacy keeps you investigating a disproven lead because of time already invested in it, rather than switching based on current evidence. Concrete team practices (pair debugging, rotating investigators, hypothesis logs, explicit acceptance criteria) counter each of these by introducing structure that doesn't rely on individual willpower to overcome the bias.

Structured elaboration

Confirmation bias: once you suspect a cause, you unconsciously interpret ambiguous evidence as supporting it and are quicker to dismiss evidence that doesn't fit. In debugging, this looks like reading a log line as "consistent with my theory" when a more neutral read would call it inconclusive, or stopping the investigation the moment ANY supporting evidence appears rather than continuing to look for disconfirming evidence too.

• Mitigation: hypothesis logs. Writing down each hypothesis and what specific evidence would DISCONFIRM it, before looking for evidence, forces a falsifiable framing up front; when you later find evidence, you check it against the pre-written disconfirmation criteria rather than retroactively deciding it "counts" as support.

Anchoring: the first plausible explanation offered (by you, or by someone else on the call) tends to dominate the rest of the investigation's framing, even as better evidence appears, because everyone's mental model has already organized around it.

• Mitigation: rotating investigators / a fresh pair of eyes. Someone joining the investigation LATE, without the accumulated anchor, will naturally form hypotheses from the current evidence rather than the initial framing, and is often the person who notices the anchor was wrong; deliberately bringing in a fresh perspective partway through a long investigation is a structural way to interrupt this.

Sunk-cost fallacy: having spent two hours pursuing one lead makes it psychologically harder to abandon, even once evidence stops supporting it, because abandoning it "wastes" the time already spent (which is, of course, already spent either way, and not actually recoverable by continuing).

• Mitigation: explicit acceptance criteria and timeboxing set in advance. Deciding, BEFORE starting to investigate a specific hypothesis, what evidence would confirm it and how much time is reasonable to spend testing it, makes the "abandon or continue" decision a pre-committed rule rather than an in-the-moment judgment call that sunk cost can distort.

Pair debugging as a mitigation for all three simultaneously: a second person, thinking independently, is less likely to share the exact same anchor or the exact same sunk-cost attachment to a specific lead, and naturally provides a real-time check on confirmation bias by asking "does that evidence actually support that, or are we reading it generously?"

Worked example

A team investigating an intermittent failure anchors early on "it's probably the recent deploy" (a reasonable first guess, given the timing). Two hours in, with the deploy's code reviewed thoroughly and nothing found, sunk cost starts to argue for continuing to scrutinize that same deploy rather than considering it possibly unrelated. A hypothesis log, written at the start, had specified "if the failure recurs on a service instance that predates this deploy, that disconfirms the deploy hypothesis"; checking that specific, pre-committed criterion shows the failure DID recur on an older instance, cleanly disconfirming the deploy theory despite two hours of sunk investigation into it. A rotating fresh investigator, brought in specifically because the original two were stuck, asks a question neither anchored investigator had considered ("what else changed around that time besides the deploy?") and identifies an unrelated infrastructure change that actually explains the failure.

Trade-offs and pitfalls

These practices have a real cost (pairing takes two people's time instead of one; hypothesis logs take a few minutes to write that could otherwise go straight into investigating), and the trade-off is worth it specifically for investigations that are ALREADY taking a long time or where the cost of a wrong conclusion is high; for a five-minute, low-stakes bug, the overhead of formal hypothesis logging isn't proportionate to the risk these biases actually pose in that context.

Brief explanation
Route-based code-splitting defers loading route component code until needed, reducing initial bundle size and improving time-to-interactive. In React you use dynamic import + React.lazy for component splitting and Suspense to show a fallback while the chunk loads.

Example

// lazy route component
const Users = React.lazy(() => import('./Users'));

// usage in router
<Suspense fallback={<Spinner />}>
  <Route path="/users" element={<Users />} />
</Suspense>

Error boundaries
React.lazy throws when loading fails — wrap lazy components in an error boundary to catch and render a recovery UI.

class ErrorBoundary extends React.Component {
  state = { err: null };
  static getDerivedStateFromError(err) { return { err }; }
  render() {
    if (this.state.err) return <RetryUI onRetry={() => this.setState({err:null})} />;
    return this.props.children;
  }
}

Use: <ErrorBoundary><Suspense>…</Suspense></ErrorBoundary>

Preload / prefetch strategies

• import(/* webpackPrefetch: true */ './BigComp') hints browser to fetch during idle time (low priority).
• import(/* webpackPreload: true */ './MainComp') loads with high priority.
• Use <link rel="prefetch"> or rel="preload" for critical chunks or likely next-route assets.
• Programmatic preloading on hover/focus: onMouseEnter={() => import('./Settings')} to improve perceived speed.

SSR pitfalls

• React.lazy + Suspense for code-splitting isn’t SSR-friendly — Suspense for data/hydration differs; can cause mismatches.
• Use SSR-aware libraries (e.g., @loadable/component or react-loadable) which provide server-side chunk extraction and preload support.
• Ensure critical chunks are inlined or preloaded to avoid flash-of-loading and poor SEO.
• Beware chunking too granularly (many small requests) and user bandwidth/HTTP/HTTP2 constraints.

Best practices

• Split by route and by large, rarely used UI.
• Keep chunk sizes reasonable and measure with bundle analyzer.
• Combine ErrorBoundary + Suspense + prefetch for robust UX.

Direct answer
Culture fit asks whether you already share a team's existing norms and behaviors; culture add asks what you would bring that the team does not already have. I would describe myself mostly as a culture add: I share the fundamentals a team needs to trust me (reliability, candor, respect for other people's time), but the useful thing I offer beyond that is a genuinely different working background rather than a mirror of the team that is already there.

Structured elaboration

1. Define both terms precisely before answering for yourself. Culture fit is about alignment on shared behaviors and values: does this person operate the way we already operate. Culture add is about complementary difference: does this person's background, working style, or perspective fill a gap the team doesn't currently have.
2. Explain why the distinction matters, not just define it. A team optimized purely for fit tends toward groupthink: everyone reasons the same way, so blind spots go unchallenged and the same kinds of mistakes recur. A team that only adds without any shared fit becomes uncoordinated: people can't predict each other's reasoning enough to move fast together. The healthy target is fit on a small number of load-bearing behaviors (honesty, follow-through, respect) plus deliberate add on everything else.
3. Give a genuine, specific example of your own add, not a generic trait. Vague claims ("I bring diverse perspectives") are the single most common failure mode here; a strong answer names the concrete gap and the concrete evidence.
4. Anticipate the natural follow-up: how do you know your difference is actually useful, versus just different for its own sake. The answer is to point at a specific decision, disagreement, or piece of feedback that changed because of the difference you brought, not just a credential or background fact.

Worked example
Suppose your last two teams were both product engineering teams building consumer-facing features, and the team you're interviewing for is mostly staffed by engineers with that same background. Your own prior role was on a data-platform team, closer to the systems that feed those consumer features than to the features themselves. A concrete add-story: in a past project, a product team wanted to ship a new recommendation feature quickly; because of your platform background, you asked a question the rest of the team hadn't raised (whether the upstream data pipeline's freshness guarantees actually matched what the feature's UI implied to users), which surfaced a real gap between a 24-hour batch refresh and a UI copy that said "updated just for you." The team fixed the copy and adjusted the refresh cadence before launch rather than after a user complaint. That is a genuine add: a different background produced a question the existing team composition was less likely to ask on its own, and it changed a real outcome.

Trade-offs & pitfalls
The common failure is answering only the definitional half (correctly explaining fit versus add) and then, when asked for a personal example, retreating to generic self-description ("I'm a good communicator", "I care about quality") that any candidate could say and that does not actually demonstrate difference. A second pitfall is overcorrecting into implying you don't fit at all; the strongest answers are explicit that you also share the small set of behaviors every functioning team needs, and that add is about everything on top of that baseline, not a replacement for it.

Mounting (class)

• constructor: init state, refs
• componentDidMount: start subscriptions/fetches, DOM reads after render

Mounting → Hooks

• useState/useRef for state/refs
• useEffect(() => { /* mount logic */ }, []) for componentDidMount
  Example:

useEffect(() => {
  fetchData();
  return () => cleanup();
}, []);

Updating (class)

• componentDidUpdate(prevProps, prevState): react to prop/state changes
• shouldComponentUpdate: control rerendering
• getSnapshotBeforeUpdate: capture DOM before changes

Updating → Hooks

• useEffect with deps for componentDidUpdate:

useEffect(() => { doOnChange(); }, [prop]);

• useRef to hold previous values:

const prev = useRef();
useEffect(() => { prev.current = value; });

• getSnapshotBeforeUpdate maps to useLayoutEffect to read DOM before paint.

Unmounting (class)

• componentWillUnmount: cleanup

Unmounting → Hooks

• return cleanup function from useEffect/useLayoutEffect:

useEffect(() => { const id = subscribe(); return () => unsubscribe(id); }, []);

useEffect vs useLayoutEffect

• useEffect: runs after paint (preferred for async work, network, non-blocking DOM reads)
• useLayoutEffect: runs after DOM mutations but before paint (blocks paint)
  Prefer useLayoutEffect when you must read layout and synchronously make DOM changes to avoid flicker:
• measuring element size and immediately applying styles
• third‑party DOM manipulation that must execute before browser paint

Example where useLayoutEffect is preferable:

useLayoutEffect(() => {
  const rect = ref.current.getBoundingClientRect();
  if (rect.width > threshold) { setState(adjusted); }
}, [deps]);

Notes

• Use React.memo/useCallback/useMemo to replace shouldComponentUpdate patterns.
• Default to useEffect; opt into useLayoutEffect only when preventing visual jank is necessary.

Direct answer
Ramping someone from day one to their first shipped work is a deliberate sequence, not a single onboarding checklist: assess what they actually already know, give them small real tasks with tight review loops before a full feature, gradually widen the scope of ownership, and define upfront what "shipped" and "done" mean so the finish line is unambiguous. The plan should look different depending on who's arriving, not just be a fixed template applied to everyone.

Structured elaboration

The default arc

• First few days: orient and assess. Don't assume a blank slate; find out what they already know so you're not re-teaching things or, worse, skipping things they actually need.
• Early tasks: small, real, low-blast-radius work with fast, close review. The goal here is confidence and calibration to the team's standards, not speed.
• Middle stretch: progressively larger scope with more independence, review shifting from "check everything" to "check the risky parts."
• First real shipped piece: something end-to-end they own, with you available but not doing it alongside them, and a clear definition of "done" agreed before they start, so success isn't a moving target.

Adapting the plan to who's actually arriving

This is where a generic checklist breaks down, and it's the part that separates a senior answer:

• A contractor under least-privilege or compliance constraints: access is scoped down from day one, so the plan has to work around what they legitimately can't see or touch, and documentation often needs to be more explicit since they can't casually ask around as easily as a full-time hire embedded in the org.
• A career-changer from an adjacent discipline (a backend engineer moving into data engineering, a research scientist moving into production ML): they're not a blank slate, they have real transferable skills. The plan should explicitly identify what carries over and target ramp-up specifically at the actual new-domain gaps, not restart from zero the way you would for someone with no relevant background.
• A cohort of remote interns rather than one hire: 1:1 pairing time doesn't scale to a group. The plan shifts toward a shared structured curriculum, peer learning between the interns, and scheduled office hours, with 1:1 time reserved for the things that genuinely need it.
• A remote hire versus a senior IC joining: a remote hire needs more of everything written down explicitly, since the informal hallway learning that fills gaps for an in-person hire doesn't happen by accident. A senior IC's gap is usually organizational context and relationships, not raw skill, so their plan should be lighter on procedural scaffolding and heavier on introductions, context on how decisions get made, and where the landmines are.

Worked example

Situation

I mentored someone joining as an individual contributor with solid general skills but no exposure to our specific stack or codebase, with a goal of them shipping one real, complete piece of work within their first several weeks.

Action

Week one was mostly orientation and a short assessment task to see where they actually stood, not a generic reading list. From there, I gave them a small real bug fix with a tight review loop so they got fast, specific feedback on our conventions early, before those habits calcified the wrong way. Over the following weeks the scope widened: a small self-contained feature with me reviewing closely, then a larger piece with me available but stepping back from line-by-line review, focusing instead on the riskiest parts of the design.

Result

They shipped a real, complete piece of work end-to-end within the target window, with a review pass that looked much closer to how we review any other team member's work by that point, which was the actual signal of readiness, not just that the calendar had passed.

Trade-offs & pitfalls

• Treating every new hire's plan as the same template. A junior mentor runs the same onboarding for a contractor, a career-changer, an intern cohort, and a senior IC. A senior mentor adapts the shape of the plan to who's actually arriving, because the actual gap being closed is different in each case.
• Under-scoping early tasks out of excessive caution, or over-scoping out of impatience. Both undermine the confidence-building purpose of the early stretch: too small and it's condescending or boring; too large too soon and the first review becomes overwhelming and demoralizing.
• Not defining "done" up front. Ambiguity about what counts as finished either causes needless rework or lets something ship that isn't actually ready, and both erode trust in the mentoring relationship.
• Ignoring the constraints a nontraditional hire is actually operating under. Applying a full-access, in-person, junior-IC plan to a least-privilege contractor or a remote hire sets them up to fail on logistics that have nothing to do with their actual skill.

Direct answer

Binary search doesn't require a sorted array; it only requires a monotonic predicate over the answer space, meaning that as candidate answers are scanned in one direction, the predicate flips from false to true (or true to false) exactly once. Once a fast "is this candidate value feasible" check exists with that monotonic property, the search runs directly over the range of possible answers instead of over array indices.

Structured elaboration

Approach

• Recognizing the pattern: look for a question phrased as "find the minimum or maximum value such that some condition holds," where checking the condition for one fixed candidate value is easier than finding the optimal value directly. If increasing the candidate value can only make the condition easier (or only harder) to satisfy, never both, the condition is monotonic and binary search applies.
• Job/server example: minimize the maximum load assigned to any of k identical servers, given a list of job sizes. For a candidate max-load D, checking feasibility means greedily assigning jobs to a server until adding the next job would exceed D, at which point a new server starts; if the assignment finishes using k or fewer servers, D is feasible. Feasibility is monotonic in D: any D' greater than a feasible D is also feasible, since a looser cap can only make greedy assignment use the same number of servers or fewer.
• Marker-placement example: place k markers along a line to maximize the minimum distance between any two chosen markers. For a candidate minimum distance D, checking feasibility means greedily placing markers left to right, always taking the next position at least D away from the last placed marker; if that produces k or more markers, D is feasible. Feasibility is monotonic in the opposite direction here: any D' smaller than a feasible D is also feasible, since a smaller required gap can only let you place the same number of markers or more.
• The same recognize-the-monotonic-property instinct applies to the "find peak element" problem, where the array itself is not sorted at all, but comparing an element to one neighbor still tells you which half must contain a peak; "is there a peak here or to one side" is a property that binary search's halving can still exploit even though nothing about the array is globally ordered.

def max_min_load(job_sizes, num_servers):
    """
    Minimum possible value of the maximum load on any server, splitting the
    jobs (in given order) into num_servers contiguous groups.
    """
    def feasible(max_load):
        servers_used = 1
        current = 0
        for size in job_sizes:
            if current + size > max_load:
                servers_used += 1
                current = size
                if servers_used > num_servers:
                    return False
            else:
                current += size
        return True

    lo, hi = max(job_sizes), sum(job_sizes)
    while lo < hi:
        mid = (lo + hi) // 2
        if feasible(mid):
            hi = mid
        else:
            lo = mid + 1
    return lo


def max_min_distance(positions, k):
    """
    Place k markers among sorted positions to maximize the minimum distance
    between any two adjacent chosen markers.
    """
    positions = sorted(positions)

    def can_place(min_dist):
        count, last = 1, positions[0]
        for p in positions[1:]:
            if p - last >= min_dist:
                count += 1
                last = p
        return count >= k

    lo, hi = 0, positions[-1] - positions[0]
    while lo < hi:
        mid = (lo + hi + 1) // 2  # bias up: looking for the largest feasible D
        if can_place(mid):
            lo = mid
        else:
            hi = mid - 1
    return lo

Key points

• The object binary search operates over is the candidate answer value, not an array index.
• Proving the greedy feasibility check is monotonic, and separately proving that the greedy check itself is correct, are two distinct things to justify in an interview.
• The search range's bounds come from the problem itself, for example [max single job size, sum of all job sizes] for the load-balancing version.

Worked example

job_sizes = [7, 2, 5, 10, 8], num_servers = 2. Binary search bounds: lo = max(job_sizes) = 10, hi = sum(job_sizes) = 32. Checking feasible(18): greedily accumulate 7, 2, 5 (running total 14); adding 10 would make 24 > 18, so a second server starts with 10, then 8 is added (running total 18, exactly at the cap). The assignment finishes using exactly 2 servers, so 18 is feasible. Checking feasible(17): the same greedy walk starts a third server once it reaches 8, exceeding the 2-server budget, so 17 is infeasible. Binary search converges on the smallest feasible value: max_min_load([7, 2, 5, 10, 8], 2) prints 18.

positions = [1, 2, 4, 8, 9], k = 3: max_min_distance prints 3, matching a direct check that placing markers at 1, 4, 8 gives a minimum gap of 3, and no arrangement of 3 markers on these positions can do better than 3.

Trade-offs & pitfalls

Complexity

Time: $O(n \log W)$, where n is the number of jobs or positions (each feasibility check is $O(n)$) and W is the width of the answer search range (sum of job sizes, or the max position minus the min position); $\log W$ is the number of binary-search iterations.
Space: $O(1)$ extra beyond sorting, if sorting is needed (the marker-placement version needs the positions sorted first, a one-time $O(n \log n)$ cost).

Edge cases

• k <= 1 for the marker-placement version: any single marker trivially satisfies any distance requirement, so the answer is unconstrained (commonly defined as 0 or unbounded, depending on the problem statement).
• num_servers >= number of jobs: every job gets its own server, and the answer is just the largest single job.
• All positions or job sizes equal: the feasibility checks degenerate but still behave correctly under the same greedy logic.

The hardest part of this pattern is proving the greedy feasibility check is actually correct, not just monotonic, which usually requires an exchange argument (showing any optimal solution can be rearranged into the greedy one without making it worse); stating "binary search works because the answer space is monotonic" without also justifying the O(n) check itself is an incomplete answer. A second common mistake is getting the search bounds wrong, either missing a valid answer at the boundary or introducing an off-by-one that causes the loop to terminate one step early or loop forever, depending on which bound is biased toward on a tie.