LLM 시대에 맞는 면접 방식을 여러 차례 바꿔본 끝에 꽤 만족스러운 절차를 만들었음. 먼저 실시간 온라인 코딩 문제를 내는데, 어렵지 않아 대부분의 LLM이 한 번에 풀 수 있는 수준임.
다만 시니어 미만은 LLM 없이 풀어야 하고, 시니어 이상이 LLM을 쓰면 생성된 코드를 자신이 작성한 것처럼 전부 설명해야 하므로 기준이 훨씬 높아짐. 핵심은 완벽한 정답이 아니라 코딩과 문제 해결을 이해하고 작은 기존 코드베이스를 파악할 수 있는지 확인하는 데 있음. 실제 합격자 대부분도 100% 풀지는 못했지만 자신이 넣은 코드는 모두 이해하고 설명했으며, 보통 1시간 30분 정도 걸림. Git 기초를 확인하려고 저장소에 PR도 열게 하는데, 못 하는 지원자가 의외로 많음.
두 번째는 점진적으로 요구사항을 추가하는 아키텍처 면접임. 처음부터 거대한 명세나 Miro 보드를 만들기보다, 간단한 MVP를 어떻게 구현할지 묻고 기능을 하나씩 추가하면서 접근법을 확인함. 중간중간 특정 기술이나 방식을 선택한 이유도 물어봄.
모르면 모른다고 해도 되고 함정 질문은 없다고 미리 알려줌. 실제 지원자들의 피드백에서도 이 덕분에 편안하게 임할 수 있었다고 하며, 전체적으로 큰 도움이 돼 즐겨 사용하는 절차임.
Git 조작 과정은 LLM을 쓰고 알리지 않아도 전혀 신경 쓰지 않는 몇 안 되는 영역임. PR 설명과 커밋 메시지는 사람이 사람을 위해 작성해야 하지만, 원격 저장소 설정이나 커밋 수정·합치기 명령을 몰라 에이전트와 GitHub CLI로 처리한들 무슨 상관인지 모르겠음.
코드 외에 신경 쓰는 것은 커밋 수, 메시지, PR 설명과 댓글, 병합 커밋 유무처럼 장기적으로 남는 결과물이 팀 규칙에 맞는지임. 그것을 만든 과정은 중요하지 않음.
PR 열기는 Git이 아니라 GitHub의 기초임. PR은 열어도 IDE 없이는 커밋하지 못하는 지원자가 있을 수 있고, 반대로 Git에는 능숙하지만 GitHub는 써보지 않은 지원자도 있을 수 있음.
Git은 엔지니어라면 누구나 배울 수 있는 단순한 도구임. 다른 버전 관리 시스템을 쓰던 회사 출신에게 Git 사용법까지 기대하지는 않음. 버전 관리의 일반 개념은 알아야 하지만, 특정 도구는 금방 익히면 됨. 개인적으로 Git은 정말 별로이고 아직도 Mercurial이 그리움.
Git에는 풀 리퀘스트라는 개념 자체가 없는데, PR 열기로 Git 기초를 어떻게 확인하는지 궁금함.
나도 비교적 간단한 실시간 코딩 문제를 내고, 지원자가 LLM을 사용할 것을 명시적으로 전제함. 흥미롭게도 LLM을 쓰게 하니 지원자 평가가 더 쉬워진 느낌임.
시니어는 자신이 무엇을 하는지 정확히 알고 LLM을 주도적으로 이끎. 설계 결정, 주의점, 요구사항을 미리 전달하고, 확인 질문을 많이 하면서 구현 범위를 좁힘. 결국 만들지 않아도 되는 것은 만들지 않는 편이 나음.
경험이 적은 지원자는 바로 구현에 뛰어들어 지나치게 많이 만들고, 핵심적인 사고를 에이전트에 맡겨버려 막히는 경향이 있음. 에이전트의 결과가 자신의 구상에서 벗어나도 다시 통제하지 못하는 경우가 잦음.
그 면접 방식이 효과적이라는 것을 어떻게 아는지 궁금함. 면접 방식과 이유를 설명하는 사람은 많지만, 효과적인 면접에 관한 과학적 연구를 알고 적용하거나 질문이 더 나은 채용에 도움이 되는지 검증한 흔적은 거의 보이지 않음.
이력서를 무작위로 골라 추가 심사 없이 채용해도 결과가 같다고 하면 반박할 수 있을까? 가능하다면 절차 전체를 검증한 것인지, 유용한 단계 하나만 확인하고 나머지는 모르는 것인지도 따져봐야 함.
이 글의 주제는 LLM 시대에 맞춘 면접의 변화임. 면접 기법을 과학적으로 연구하려면 채용된 직원의 업무 성과를 장기간 평가하고 수년간 후향적으로 분석해야 함. 아직 너무 새로운 주제라 그런 연구는 존재하지 않으므로, 이 글에 대한 적절한 비판은 아니라고 봄.
글에 아직 모든 대면 면접에 새 절차를 적용하는 것은 아니며, 방문 전에 무엇을 예상해야 하는지 안내하겠다고 적혀 있음. 기존 절차보다 나은지 시험 중이라는 뜻으로 볼 수 있지만, 과학적으로 엄밀하게 진행하는지는 불분명함.
이런 질문은 훨씬 더 자주 해야 함. 면접관과 지원자 양쪽을 경험해보니, 면접은 주로 면접관의 자존심을 만족시키는 역할을 함.
예전에 면접을 볼 때는 과거에 해결한 문제나 프로젝트, 학교생활에 관해 대화하고 엘리베이터 설계 같은 의사코드 문제를 함께 풀었음. 내가 합격시킨 사람들은 아는 범위에서 모두 순조롭게 경력을 이어감.
지원자에게 제삼자의 화면 접근을 허용하게 하고, AI로 면접 내용을 기록하고, LeetCode 문제를 세 개 이상 풀게 한 뒤 아키텍처·행동 면접까지 몇 시간씩 지켜보는 것은 완전히 어리석고 반사회적으로 느껴짐. 업계 전체가 면접에 대한 자기 확신에 취해 있음.
Steve Yegge조차 자신이 쓰던 절차에서 탈락했거나 거의 탈락할 뻔함. 본인도 모르는 사이 벌어진 일이었음.
채용 담당자가 개인정보를 지운 면접 기록을 주며 평가 기준을 맞추는 연습이라고 했고, 심사팀은 평소처럼 약 3분의 2를 불합격 처리함. 그런데 알고 보니 그 기록은 심사팀 구성원들이 Google에 입사할 당시의 면접 기록이었고, 결국 자기 팀 대부분을 채용하지 않겠다고 결정한 셈임.
출처는 2026년 5월 글인 https://yegge.ai/essays/the-last-technical-interview/임.
최근에는 별로 보지 못했던 Jane Street 관련 글이 이번 주에만 세 번째로 보임. OCaml을 쓰고 HN에서 관심 가질 만한 일도 한다는 것은 알지만, 갑자기 짧은 기간에 너무 많이 등장하는 듯함. 마케팅을 집중적으로 하는 것일까?
Algolia 기준으로 지난 1년간 제목이나 URL에 Jane Street가 들어간 글은 57개로, 주당 하나를 조금 넘는 수준임. 발생률을 57/52로 둔 포아송 분포에서 P(X ≥ 4)는 약 2.5%이므로, 이 비율이라면 평균적으로 4개 이상 올라오는 주가 약 5주는 있어야 함. 아마 무작위 변동일 뿐임.
자기실현적 효과일 가능성이 있음. Jane Street 소식이 몇 번 첫 화면에 올라와 관심을 끌면서 이름을 알아보는 사람이 늘었고, 다른 관련 글에도 추천이 더 붙는 흐름임.
이 글은 내가 올렸으며, Jane Street와 아무 관계 없는 평범한 개발자임. 오히려 조금 경계하는 편이고, 그곳에서 일하는 데 따르는 파우스트적 거래에 관한 Evan Czaplicki의 관점에 공감함. 내가 알기로는 인도에서 활동이 금지됐는데, 이들이 어떤 약탈적 거래를 할 수 있는지 보여주는 예라고 봄.
내 관심사는 LLM 시대에 엔지니어 면접이 어떻게 바뀌는지임. Jane Street는 기술적으로 방향을 제시하는 회사이고, 적어도 자기 견해를 공개하며 이를 우수 인재 채용에 활용함. Oxide도 비슷하다고 생각함. 변화의 시기에 이런 회사가 적극적으로 발신하고 그 내용이 여기까지 퍼지는 것은 자연스러움.
지금 첫 화면에는 이 글과 “Socratic Tutor”, “오작동한 화재경보가 Jane Street의 유일한 뉴욕 데이터센터를 침수시킬 뻔한 사건”까지 세 개가 있음.
꾸준히 글을 올리는 사람의 수는 의외로 적어 이들의 관심사가 과대표집되기 쉬움. 새 글을 살펴보는 사람도 적고, 첫 15분 동안의 추천 3~4개가 첫 화면 진입을 좌우함. 이들이 키워드나 분위기, 회사 이름을 기준으로 추천하면 글 자체의 가치와 무관하게 특정 주제가 유리해짐.
더 넓게 보면 지난 1년간 HN의 주제 다양성이 크게 줄었다고 느낌. 첫 화면 대부분이 AI나 AI 선도 기업과 어떤 식으로든 연결돼 있어, 기술계나 세상에 다른 일은 없는 듯함. 다른 글 모음 사이트에 가면 전혀 다른 풍경을 볼 수 있음.
높은 보수와 기술적 명성을 갖췄고, 흥미로운 기술 문제를 풀며 ‘이달의 문제’ 같은 대외 활동도 잘하고 대규모 정리해고의 영향도 받지 않은 회사임.
이런 회사는 드물며, 규모가 비교적 작은 것도 도움이 될 듯함. 대형 기술기업 7곳에서 일한 지인과 그곳의 좋지 않은 이야기는 흔하지만, Jane Street는 그렇지 않음.
세 글 모두 HN의 목표인 지적 호기심 충족에 부합함. 각각 다른 회사에서 나온 글이거나 회사 이름이 없었다면 첫 화면에 오른 것이 이상했을까? 나는 아닐 것 같음. 회사보다 내용 자체가 흥미로운 글들이기 때문임.
최근 친구가 Meta 등 여러 회사 면접을 거쳐 Google에 합격함. 대부분 면접 방식을 바꾸고 있지만 공통된 패턴 없이 회사마다 다른 접근법을 쓰고 있다고 함.
AI IDE를 자유롭게 쓰게 하는 곳도 있고, 모든 것을 AI에 묻지 못하게 하면서 질문 내용을 살피는 곳도 있음. 한 회사는 일부러 틀린 코드를 내놓는 LLM을 제공해 지원자가 고치게 했다고 함.
솔직히 꽤 모호한 글임. 면접이 바뀌고 있다는 사실 외에는 구체적으로 설명하는 것이 별로 없음.
이번 주 서로 다른 기술 환경에서 일하는 친구들과 점심을 먹으며 각자와 동료들의 작업 방식을 주로 이야기함. 지금은 이 분야에서 일하기 흥미로운 시기임.
작업 방식에 관심을 기울이는 사람들은 여러 도구를 쓰면서 끊임없이 개선함. 같은 팀이 모두 Claude를 쓰더라도, 누군가는 자신의 사용 데이터를 꾸준히 모으며 훨씬 정교한 방식을 발전시킴. 목표도 단순히 속도를 높이는 것이 아니라 더 나은 결과물을 만드는 것임.
이 글이 모호하다기보다, 지금 가장 잘 일하는 지원자를 찾으려면 면접 절차에도 유연성이 필요한 시기라고 봄.
소프트웨어 엔지니어 면접에서 더는 화이트보드에 코드를 쓰지 않게 되면 서운할 듯함. 어쩌면 적응해야 할 시대의 전환일 뿐일 수도 있음. 언젠가는 면접에 자신만의 하네스·프롬프트·스킬·MCP를 가져오라고 할지도 모르겠음.
코딩 면접은 지원자와 고용주 모두에게 큰 시간 낭비임. 사람이 무엇을 기여할 수 있는지 봐야 함.
그렇다면 구체적으로 무엇을 기여할 수 있는지 어떻게 확인할까?
예전에는 면접을 잘 못하는 사람이 저평가되곤 했음. 이제는 면접 문화 자체의 가치가 떨어지고 결국 사라질 것이라고 봄. 실제 기술을 만들고 실제 문제를 해결하는 사람들은 영향을 받지 않겠지만, 면접 실력을 중심으로 떠받들어 온 실리콘밸리의 허상은 쓸모없어질 것임.
이런 낙관은 올해 AI가 정말 어려운 수학 문제를 풀 수 있게 된 데서 나옴. 그 증명이 정확하고 실제 전문가의 독립적인 검증을 통과한다는 전제하에, 9월과 10월은 AI 역사에서 가장 눈부신 두 달로 남을 수도 있음. Lean으로 형식 검증을 마쳐도 전문가의 검토는 여전히 중요함.