I'm a developer not a compiler

Hiring practices for software engineers often overemphasize trivia-style questions about syntax, type sizes, or terminology, even though many experienced developers see these as poor indicators of real-world ability. Commenters argue that strong candidates are better evaluated on how they debug, reason about systems, communicate trade-offs, and solve ill-defined problems, suggesting prompts like “tell me about a memorable bug you fixed” or “what are your language’s weaknesses” as richer signals. The debate highlights tensions between filtering out unqualified applicants, avoiding interviewer bias, and designing interviews that reflect the actual skills needed in day-to-day engineering work.

Focus of Interviews: Syntax vs. Problem-Solving

  • Many argue that memorizing syntax, APIs, or standard-library minutiae is a poor signal; “plausible” code and reasoning matter more than exact method signatures.
  • Syntax recall is seen more as evidence of recent use in a language than of capability.
  • Several contrast this with ML interviews that overemphasize precise math or library usage, instead of assumptions, trade-offs, and behavior changes when parameters vary.

Preferred Interview Signals

  • Strong support for testing “detective work”: debugging skill, ability to read unfamiliar code, handle underspecified problems, and reason through systems.
  • Examples include:
    • Walking through real-world debugging scenarios (e.g., curated Stack Overflow questions).
    • High-level problem-solving and system design discussions.
    • Probing experience with debuggers, profilers, tracing tools, build systems, version control, and testing strategies.
  • Several note the rest of the SDLC (tooling, configuration, deployments) is harder and more predictive than raw coding trivia.

Story-Based Questions: Bugs and Opinions

  • Popular questions: “favorite/most memorable bug you’ve fixed” and “strongest opinion in tech.”
  • Proponents like them as conversation starters that reveal passion, debugging process, maturity, autonomy, and communication skills.
  • Follow-up questions (how you found/fixed it, impact on your practice) are seen as where the real signal lies.
  • Critics say these can:
    • Overweight memory, storytelling, and “being in the right mental state.”
    • Penalize people who don’t romanticize bugs or have few “strong” opinions.
    • Amplify interviewer bias and “cultural fit” filtering.
  • There is debate over claims like “there are no wrong answers”; some call that misleading, others frame evaluation as a spectrum rather than binary.

Trivia and “Nano Questions”

  • Some see tiny fact questions (primitive sizes, exact type lists, definitions of strong/weak typing) as gatekeeping or ego displays; answers are easily googled and rarely matter.
  • Others insist such details are a proxy for deep understanding and for separating true practitioners from pattern-matchers or outright frauds.
  • One subthread highlights that terms like “strong vs. weak typing” lack universally agreed definitions; a “good interviewer” would accept any answer that shows conceptual grasp rather than a specific canned definition.