처음 면접관 역할을 맡았을 때 떨렸다. 면접 보는 것도 긴장되는데, 면접관은 다른 종류의 긴장이었다. 이 사람의 합불을 내가 판단해야 한다는 책임감. 좋은 사람을 떨어뜨리면? 부족한 사람을 통과시키면?

면접을 몇 번 진행하고 나서야 깨달은 게 있다. 면접관이 보는 것은 내가 지원자일 때 생각했던 것과 꽤 달랐다.

정답을 맞히는 게 중요한 게 아니다#

지원자일 때는 "정답을 모르면 떨어진다"고 생각했다. 면접관이 되어보니, 정답 자체보다 정답에 도달하는 과정이 훨씬 중요했다.

"클로저가 뭔가요?"라고 물었을 때, 교과서적 정의를 외워서 말하는 사람과 "이런 상황에서 이렇게 쓰이는데, 내부적으로는 이런 원리로 동작한다"고 자기 언어로 설명하는 사람이 있다. 정의는 검색하면 되지만, 자기 경험과 연결 지어 설명할 수 있는 건 실제로 이해하고 있다는 증거다.

모르는 질문이 나왔을 때의 반응도 본다. "모르겠습니다"로 끝내는 사람과, "정확히는 모르지만 이런 것과 관련이 있을 것 같고, 이런 방향으로 추론해보면..."이라고 시도하는 사람. 현업에서 모르는 문제를 만났을 때 어떻게 접근할지가 보인다.

기술보다 커뮤니케이션#

기술 면접인데 커뮤니케이션을 본다니 아이러니하지만, 실무에서 개발은 혼자 하는 일이 아니다. 요구사항을 이해하고, 기술적 판단을 설명하고, 동료와 합의하는 능력이 코딩 실력만큼 중요하다.

면접에서 이게 드러나는 순간은 몇 가지 있다.

질문을 명확히 하는 사람. "사용자가 많은 환경인가요?", "모바일도 고려해야 하나요?" — 문제를 풀기 전에 범위를 확인하는 사람은 실무에서도 요구사항을 꼼꼼히 파악할 가능성이 높다. 반면 질문 없이 바로 코드를 쓰기 시작하는 사람은 가정을 많이 한다는 뜻이다.

트레이드오프를 말하는 사람. "이 방법은 이런 장점이 있지만 이런 단점이 있어서, 이 상황에서는 이걸 선택하겠다." 정답이 하나가 아니라는 걸 아는 사람이다.

모르는 걸 인정하는 사람. "그 부분은 경험이 없어서 잘 모르겠습니다"라고 솔직하게 말하는 사람이 오히려 신뢰가 간다. 아는 척하다가 꼬리 질문에서 무너지는 것보다 낫다.

포트폴리오에서 보는 것#

이력서에 "React, TypeScript, Next.js"라고 써놓은 건 의미가 없다. 누구나 쓸 수 있으니까. 포트폴리오에서 진짜 보는 건 "왜 이 기술을 선택했는지", "어떤 문제를 어떻게 해결했는지"다.

블로그에 트러블슈팅 기록이 있으면 반가웠다. "배포했더니 이런 에러가 나서, 원인을 분석해보니 이거였고, 이렇게 해결했다." 이런 글은 이 사람이 실제로 문제를 해결해본 경험이 있다는 걸 보여준다.

깃허브 커밋 히스토리도 본다. 한 번에 수천 줄을 커밋하는 사람과, 의미 단위로 나눠서 커밋하는 사람의 차이. 커밋 메시지에 "fix", "update"만 쓰는 사람과 변경 이유를 적는 사람의 차이.

면접관도 긴장한다#

이건 지원자일 때 몰랐다. 면접관도 좋은 질문을 해야 한다는 부담이 있다. 이 질문이 이 사람의 실력을 제대로 평가하는 질문인가? 너무 어렵거나 너무 쉽지는 않은가?

지원자가 긴장해서 평소 실력을 못 보여주는 것 같으면 면접관도 마음이 불편하다. 편한 분위기를 만들려고 시도하지만 한계가 있다. 1시간 안에 서로를 파악해야 하는 구조 자체가 완벽할 수 없다.

불합격 결정을 내릴 때가 가장 어렵다. "이 사람이 우리 팀에서 성장할 수 있을까?"를 판단하는 건, 1시간의 대화로는 불완전하다는 걸 안다. 그래도 판단해야 한다. 그래서 면접은 완벽한 평가 시스템이 아니라, 불완전하지만 현실적인 방법일 뿐이라는 것도 이제는 안다.

지원자분들에게 하고 싶은 말이 있다면 — 면접에서 떨어졌다고 해서 실력이 부족한 게 아니다. 면접은 "이 팀에 이 시점에 맞는 사람인가"를 보는 거지, 개발자로서의 가치를 평가하는 게 아니다. 면접관 쪽에서 보면 그게 더 명확하게 보인다.