Technical Interviews Reject the Wrong Engineers

Original Article ↗ Hacker News Discussion ↗

Technical hiring processes in software are widely seen as poor at identifying who can actually do the job, often favoring candidates who perform well under artificial time pressure or “hoop-jumping” rather than those who build and maintain real systems. Commenters debate leetcode-style coding tests, multi‑round loops, take‑home projects and experience‑based interviews, noting each selects for different traits (speed, diligence, communication, or prior track record) and carries its own biases and failure modes. With AI tools further changing how code is written and evaluated, many argue companies should simplify interviews, focus more on past accomplishments and collaboration, and accept that every method is a tradeoff in what kinds of engineers it filters in or out.

Tacit Knowledge, Reasoning, and Communication

  • Several comments stress that much engineering skill is tacit: recognizing patterns, sensing problems, and maintaining situational awareness.
  • Disagreement on whether “articulating on the spot” is the job:
    • One side: communicating technical reasoning in real time is core to the role.
    • Other side: clear articulation follows from deep understanding; forcing instant explanation in high-pressure settings mismeasures real ability.
  • Some argue good engineers often need time alone to think and return later with solid plans, not instant solutions.

Interview Formats and Tone

  • Proposed “experienced” interview: candidate gets time to present how they’d advance the company’s goals, followed by technical probing.
  • Pushback that adversarial framing (“we’ll judge you”, “as we see fit”) increases anxiety and harms signal; suggestions to reframe as collaborative scrutiny of tradeoffs.
  • System design and take-home exercises are widely known:
    • Supporters say they map better to real work and can emphasize collaboration and communication.
    • Critics note candidates often complain about long take-homes as “free work,” and interviewers become over-familiar with problems, misjudging how “obvious” solutions really are.

Length, Bureaucracy, and What Interviews Select For

  • One camp argues 2–3 hours and multiple rounds are reasonable, especially for highly paid roles; effort filters for motivated candidates.
  • Another camp sees long, multi-step processes as “hoop-jumping” that:
    • Filters out strong but non-desperate engineers.
    • Signals organizational slowness and bureaucracy.
  • View that interview design inherently selects for certain attributes (tolerance for bureaucracy, stress performance, etc.) rather than pure competence.

Experience-Based vs Coding Challenges

  • Many advocate deep dives into past projects: role, decisions, tradeoffs, business impact, and architecture.
  • Others warn this overweights “failed up” candidates and smooth talkers; interviewers can’t reliably validate claimed contributions.
  • Coding/whiteboard interviews are criticized as low-correlation with job performance, yet defended as one of the few tools to detect basic skill when credentials and tenure aren’t trustworthy.

AI’s Influence

  • Some interviewers report candidates struggle with complex problems without LLMs.
  • Suggestions include:
    • Letting candidates use AI and evaluating problem decomposition, requirement analysis, and code review.
    • Emphasizing verification, testing, and tooling over raw manual coding.
  • Unclear consensus on how much AI assistance should be part of evaluation.