Best engineering interview question I've gotten

Original Article ↗ Hacker News Discussion ↗

An interview exercise that asks candidates to add a `mult` (multiply) command to the memcached codebase is prompting debate over what software engineering interviews should measure. Supporters like that it mirrors real work—navigating an unfamiliar C codebase, reusing existing patterns (e.g., `incr/decr`), and wiring in tests—rather than solving abstract LeetCode puzzles. Critics question the three‑hour unpaid task, worry it encourages copy‑paste over thoughtful design (e.g., overflow, concurrency, API semantics), and argue that lengthy coding assignments can unfairly exclude otherwise strong candidates with limited free time.

Overall view of the memcached “Mult” interview task

  • Many see it as a solid, realistic engineering exercise: modify a real C codebase, add a feature similar to an existing one, and show you can read and extend production-style code.
  • Others think it’s underwhelming technically (“milquetoast”) and mostly a copy‑paste of incr with + → *, offering little “insight.”

What the question actually tests

  • Supporters say it tests:
    • Navigating an unfamiliar codebase quickly.
    • Reusing existing patterns instead of overdesigning.
    • Writing code that compiles, runs, and fits the surrounding style.
  • Critics argue it also implicitly tests:
    • Environment setup skills (C toolchain, build system).
    • Ability to ignore legitimate concerns (locking, overflow, performance) in favor of speed.
  • Some emphasize that many candidates can’t even deliver the “bare minimum,” so this is a good filter.

Overengineering vs pragmatism (“Type 1 vs Type 2”)

  • One camp views “Type 1” (deeply analyzing locks, races, design) as good engineering and “copy‑paste and tweak” as poor practice, especially in a high‑performance system like memcached.
  • The opposing camp sees “Type 1” as analysis paralysis and “Type 2” (clone incr/decr, change operators, add tests) as the practical, senior‑engineer behavior.
  • Disputes arise over issues like overflow and non‑commutativity; some insist they must be addressed, others reply that add/sub/append/set/delete already have similar caveats and the task’s scope is intentionally narrow.

Time, pressure, and compensation

  • The “three hours” figure is heavily debated:
    • Some say it’s a 30–60 minute task and three hours is generous.
    • Others won’t do any 3‑hour+ unpaid exercise, especially when applying to multiple companies.
  • There are calls to pay candidates for this kind of deep‑work assessment; others respond that as long as enough people accept it, companies won’t change.

Comparisons to other interview styles and professions

  • Widely preferred over LeetCode/brainteasers by those who like realistic work samples.
  • Critics note it still amplifies interview pressure and may filter out good engineers who don’t perform well in timed solo tasks.
  • Some compare to other professions: many of them use degrees, licensing, or practical demos instead of ad‑hoc coding tests; software lacks standardized certification, so companies lean on exercises like this.