오늘 r/SaaS에서 엔지니어 채용 스크리닝 이야기를 봤는데, 43점에 댓글 40개가 붙은 이유가 꽤 선명했다. 이력서와 시스템 디자인 대화에서는 좋아 보였던 사람이 작은 Node API 하나가 깨진 순간 로그도 안 보고 코드를 찍어 고치기 시작한다는 것. 반대로 평범한 이력서의 후보가 12분 만에 환경변수와 의존성 문제를 찾아내는 장면은 숫자로 남기기 어려운 신호다. 댓글에서도 비슷한 경험이 반복됐다. ‘로그를 먼저 보는지’만 봐도 후보가 갈린다거나, LeetCode보다 20~40분짜리 실제 디버깅 과제가 훨씬 낫다는 말이 이어졌다. 결국 팀들이 원하는 건 거창한 시험 플랫폼보다, 작은 깨진 서비스 안에서 후보가 어떤 순서로 확인하고 질문하고 멈추는지를 조용히 기록해 주는 도구에 가깝다. 채용 담당자가 주 6~7번씩 기술 면접에 끌려 들어가는 상황이라면, 이건 단순한 평가 취향 문제가 아니라 운영 비용이다. 샌드박스 과제 하나에 로그 열람, 로컬 실행, 질문 타이밍, 수정 전 가설 같은 행동 신호를 남겨 주고 면접관이 나중에 5분 안에 훑을 수 있게 해도 바로 써볼 팀이 꽤 있을 것 같다.