Coding interviews are stupid (ish)

Example interview problem (infinite stream)

• Thread opens with a concurrency question about printing an “infinite unordered stream” in order.
• Several commenters note that as stated it’s unsolvable; clarifying assumptions (monotonic timestamps, no gaps, starting at zero) turn it into “merge k sorted streams” solvable with a heap.
• Some argue the real test is whether candidates ask clarifying questions and reason about edge cases/impossibility.

Licensure analogy and standardization

• Many compare coding interviews to professional licensure (bar exam, medical boards, FE/PE).
• Pro-licensure arguments: fairer, standardized first filter; removes repeated basic screening; easier for experienced but non-degreed devs.
• Counterpoints: software has far more tooling, subfields, and churn than traditional engineering; licensure only enforces a minimum and interviews would still exist; risk of guild-like gatekeeping.

Value and limits of coding / LeetCode-style interviews

• Broad agreement that some coding screen is useful to filter out people who cannot code at all; “FizzBuzz still filters a lot.”
• Strong criticism of hard DSA / “aha” puzzles: encourage memorization, select for test-taking not product skills, feel like hazing, and often correlate weakly with actual job work.
• Defenders say live coding gives fast, strong signal under time constraints and is acceptable because companies care more about avoiding bad hires than missing good ones.
• Several note stress and whiteboard format cause false negatives, especially for otherwise strong but anxious candidates.

Alternative interview approaches

• Suggested methods:
  • Simple, realistic tasks (parse a file, filter/sum data, small web component).
  • Code review of obviously bad or real legacy code; bug reports and patch review.
  • Asking candidates to explain past projects in depth, draw architectures, and justify decisions.
  • Take‑home exercises (controversial: scope, unpaid time, review burden).
  • Trial/contract-to-hire stints, though hard for employed candidates.

Senior candidates, experience, and portfolios

• Some senior devs refuse coding tests on principle, expecting CV, GitHub, and conversation to suffice; claim good companies “sell” the role and minimize hoops.
• Others argue resumes and talk are easy to fake; they report many “smooth talkers” who fail trivial coding or design tasks, so a minimal code screen remains necessary.
• Debate over using public GitHub as a primary filter: praised as strong signal by some, criticized as unfair to those without OSS/side projects.

Market dynamics and compensation context

• Long subthread on high FAANG/Bay Area compensation (up to $400k+), with disagreement on how common it is.
• Noted that such salaries are rare globally; most devs make far less, so the LeetCode grind mainly targets a small slice of roles.

Bias, stress, and human factors

• Concerns about arbitrary filters (resume formatting, school prestige), inconsistent interviewers, and “culture fit” bias.
• Several emphasize that interviews should discover what candidates can do, adapt difficulty dynamically, and treat failure on a single puzzle as low-information rather than dispositive.