I have interviewed 100s of candidates for software engineering positions
Hiring practices for software engineers are under fire, with many arguing that whiteboard puzzles and LeetCode-style challenges are stressful, low-signal, and often fail to predict real-world performance. Commenters debate alternatives such as conversational interviews, simple coding tasks, take‑home assignments, portfolio reviews, and structured behavioral questions, while also noting the lack of baseline competence in the field and the risk of bias when relying on “culture fit” or tech-news enthusiasm. Several voices stress that interviewer skill, clarity on what is being evaluated, and respect for candidates’ time and dignity are at least as important as the specific format used.
Limits of Coding Challenges and Whiteboards
- Many report that take‑home tests, live coding, and puzzles are unpleasant for both sides and rarely reveal issues that wouldn’t appear in conversation.
- Others argue strongly that without live coding, many hires would be unable to write even basic loops or simple algorithms despite strong résumés and communication.
- Standard “LeetCode”/algorithm puzzles are criticized as selecting for test prep and pressure tolerance, not job-relevant skills.
Need for Basic Skill Verification
- Several interviewers insist on very simple coding checks (e.g., loops, list operations, basic data transformations) to catch applicants who “talk a good game” but can’t code.
- There’s disagreement on how much pressure is fair: some want low‑stress, trivial tasks; others accept moderate pressure as unavoidable.
Interview Goals: Problem-Solving, Communication, Fit
- Many prefer conversational interviews: walk through past projects, system designs, code samples, or candidate‑provided code, probing depth of understanding.
- Desirable signals: systematic approach, ability to explain trade‑offs, willingness to say “I don’t know,” and constructive collaboration.
- Some expect seniors to articulate approach and design before coding; others note that real design usually happens over hours, not five minutes on a whiteboard.
Culture, Personality, and Bias
- “Culture fit” is seen as both necessary and risky: it can ensure smooth collaboration but can also encode bias and reduce diversity.
- Questions about “tech news,” “new technologies,” or social activities (e.g., parties, drinks) can implicitly filter by social bubble, lifestyle, or personality.
- Several note that many good developers dislike high-pressure tests or forced socializing, and that filtering them out may be counterproductive.
Lack of Standards and Baseline Competence
- A recurring complaint: candidate skill levels vary wildly, and résumés are poor predictors.
- Some suggest a lightweight, industry‑wide “programmer’s bar exam” to guarantee minimal proficiency (loops, conditionals, basic reasoning); others worry this would recreate expensive credential barriers.
Process Design and Evidence from Research
- Suggested improvements: fewer rounds, clear plans for what to evaluate, and structured behavioral interviews (“tell me about a time when…”) with consistent rubrics.
- One commenter cites industrial/organizational psychology: work‑sample tests and structured interviews are among the most predictive; unstructured chats are more biased and lower signal.
- There’s also concern that many interviewers themselves are poor at assessing skills or setting accurate expectations.