An engineer's perspective on hiring

Engineer fungibility, replaceability, and “bus factor”

• Some argue many developers (CRUD, web apps) are largely fungible and readily replaceable; companies inevitably refill roles after attrition.
• Others counter that domain knowledge and deep system understanding make certain people “difficult to replace” and that true innovation requires non‑interchangeable experts.
• There’s disagreement on risk: one side prioritizes designing organizations where everyone can be swapped out; the other says the real risk is falling behind, and mitigations should be overlapping expertise rather than full fungibility.

Interviewing employers and cultural fit

• Several comments stress “interviewing the employer”: scrutinizing future managers, benefits that seem too good, weird vibes, fearful or silent interviewers, or being the only person of a given demographic/attitude as red flags.
• Others note that expecting demographic or lifestyle similarity is unrealistic in small companies and prefer to keep many personal attributes out of the workplace entirely.

Application volume, filtering, and AI

• Hiring managers describe being overwhelmed by applicants (hundreds to thousands per role) and needing harsh or arbitrary filters to protect engineering time.
• There’s concern AI will further flood pipelines with automated applications, escalating an “arms race” of filtering that hurts genuine candidates, especially those without strong networks.

Leetcode, live coding, and take‑homes

• One camp defends live coding as the strongest signal of core CS skills, problem decomposition, and coachability; they distinguish it from extreme leetcode and set a low bar for correctness with probing follow‑ups.
• Others criticize leetcode‑style rounds as high‑stress memory tests mismatched to actual work, rewarding grinders and disadvantaging people with anxiety or family obligations.
• Take‑homes:
  • Proponents like their realism, low immediate pressure, and ability to show real work style.
  • Opponents see them as disrespectful unpaid labor, biased against busy candidates, easy to cheat on, and often poor predictors; some argue companies should pay honoraria.

Alternative interview structures and probation

• Popular alternatives include: code review of real or sample code, debugging broken code (“uno reverse”), pair‑coding on small features, and in‑depth conversations about past projects and tradeoffs.
• Some report success with very short interviews plus a probationary/contract‑to‑hire period, or multi‑day “work together and ship something” trials.

Exams, licensing, and professionalism

• A long subthread frames current processes as serial “exams” unlike other professions with standardized licensing.
• There’s debate over whether software should move toward formal engineering licensure; obstacles cited include broad, fast‑changing scope and the fact that most failures are merely inconvenient, not catastrophic.

Passion, tenure, and compensation

• Some hiring philosophies look for “passion” and cultural/taste alignment; others explicitly treat the job as a professional, transactional exchange and warn against exploiting passion.
• There’s skepticism about multi‑hour, multi‑stage processes when tenure is short and compensation is comparable to less onerous roles.