It is humiliating to have to do LeetCode grinding for

Original Article ↗ Hacker News Discussion ↗

Many software engineers argue that LeetCode-style algorithm interviews are demoralizing and poorly correlated with real-world work, favoring recent grads and “grinders” over experienced developers with strong track records. Others counter that in a market flooded with applicants and inflated credentials, standardized coding tests are a practical, if imperfect, filter for basic competence and CS fundamentals. Alternative approaches suggested include take‑home tasks closely tied to the job, evaluating open source or prior work, and focusing more on communication, learning ability, and practical impact.

Perceived Problems with LeetCode‑Style Interviews

  • Many see grinding algorithm puzzles as humiliating and disconnected from real work, especially for senior engineers with long track records or open‑source portfolios.
  • Complaints that questions often reward memorization of “obscure” algorithms rather than general problem‑solving or product skills.
  • Some note that success is heavily correlated with recent practice; needing weeks of prep for a job you’re already good at feels wrong.
  • Algorithmic tests are viewed by some as subtly ageist: older engineers never faced these in school and may be filtered out despite experience.
  • For most jobs, actual work is CRUD, systems thinking, communication, and maintainability, not graph algorithms under time pressure.

Defenses and Justifications

  • Others argue basic DS/algorithms are foundational, like scales for musicians or drills for athletes; demonstrating them shouldn’t be considered degrading.
  • Coding screens act as a “stupid test” in a world of inflated resumes and degrees; many applicants cannot solve even FizzBuzz‑level tasks.
  • LeetCode performance is seen by some as correlated with CS fundamentals, grit, and ability to reason from first principles.
  • Top companies and saturated markets can afford to filter on both LeetCode and other dimensions.

Alternatives and Modifications

  • Suggestions:
    • Short, relevant work samples or take‑home tasks with clear rubrics, PRs, linting, and repo usage.
    • Let candidates submit existing public work (OSS, prior projects) plus written context instead of a canned challenge.
    • Lightweight, realistic coding tasks (“type 2” LeetCode: prototype a solution to a real-ish problem) rather than puzzle‑style questions.
  • Some prefer LeetCode over highly stack‑specific grilling or purely subjective “culture fit” chats.

Career Choices and Coping Strategies

  • Several report avoiding or leaving traditional SWE roles because of LeetCode, moving into cybersecurity, data analysis, or ops where tests are more job‑aligned.
  • Others accept the system pragmatically: grind intensely for a period, secure higher‑paying roles, then stop.
  • A minority enjoys LeetCode as a hobby and claims it improved day‑to‑day coding intuition.

Broader Concerns

  • Debate over power imbalance: long multi‑stage processes, unpaid lengthy exams, relocation/probation risks vs. employer flexibility.
  • Tension between wanting more objective hiring and recognizing that narrow proxies can select for “LeetCode engineers” over well‑rounded ones.