LeetCode 스타일 인터뷰에 질린 사람들

• Robinhood를 2023년 11월 말 건강 문제로 퇴사한 뒤 여러 채용 과정을 거치며, LeetCode식 평가가 실제 소프트웨어 엔지니어링 업무와 어긋난다고 느낌
• 많은 회사가 Google, Facebook/Meta, Amazon 같은 대형 기술 회사의 방식을 따라 하면서 비슷한 인터뷰를 반복하는 것으로 봄
• 엔지니어들은 검색 가능한 지식을 외울 필요가 없다고 말하지만, 인터뷰에서는 바로 떠올리기 어려운 검색 가능한 지식을 퀴즈처럼 묻는다고 비판함
• 이런 인터뷰에서 성공과 실패를 모두 겪었고, 불만의 근거는 실패 경험보다 이전 실무 경험에 가까움
• AWS, Kubernetes, Ruby on Rails 경험이 있는 엔지니어를 찾으면서 쓸데없는 퀴즈를 하지 않는 회사라면 연락해도 된다고 덧붙임

---

LeetCode식 인터뷰가 실제 업무와 어긋나는 지점

• 2023년 11월 말 Robinhood를 건강상의 이유로 퇴사한 뒤 여러 회사와 인터뷰를 진행함
• 채용 과정은 여러 이유로 이어지지 않았지만, 반복되는 LeetCode 스타일 인터뷰 자체에 피로감을 느낌
• 이런 인터뷰는 실제 소프트웨어 엔지니어링 책임을 충분히 반영하지 못한다고 봄
• 많은 회사가 Google, Facebook/Meta, Amazon 같은 대형 회사들이 쓰는 방식이라는 이유로 같은 평가 방식을 채택하는 것으로 보임

퀴즈식 평가와 실무 경험의 충돌

• 평소에는 쉽게 Google로 찾을 수 있는 지식을 외울 필요가 없다고 말하는 엔지니어들이 있음
• 하지만 인터뷰에서는 검색하면 알 수 있어도 즉석에서 떠올리기 어려운 내용을 묻는 경우가 있어 모순적이라고 느낌
• 이 문제에 대한 뚜렷한 해결책은 없지만, 문제 자체는 분명하다고 봄
• 이런 유형의 인터뷰에서 성공과 실패를 모두 경험했으며, 이 견해는 실패율보다 이전 전문 경험의 영향을 더 크게 받음
• AWS, Kubernetes, Ruby on Rails 경험을 갖춘 소프트웨어 엔지니어가 필요하고 퀴즈식 인터뷰를 하지 않는 회사라면 연락해도 된다고 함
• 함께 볼 글로 Re-imagining Technical Interviews: Valuing Experience Over Exam Skills를 제시함

[GN⁺]

Hacker News 의견들

• 답답함은 이해하지만, 결국 이런 면접도 목적은 있다고 봄. 잘하진 못해도 충분히 쓸 만하고, 보통은 거짓 양성보다 거짓 음성을 더 많이 만든다는 점에서 회사 입장에서는 말이 됨
  똑똑한 사람이 떨어지는 비용은 낮지만, 엉뚱한 사람을 뽑으면 몇 달 동안 확인하고 해고하고 다시 채용해야 하니 비용이 큼. 다만 지원자에게는 극도로 고통스러운 과정이고, 훌륭한 소프트웨어 엔지니어라도 긴장하거나 놓치거나 운 나쁜 날이 있어 몇 번은 떨어질 수 있음. 면접은 인생 가치의 최종 평가가 아니라 둔탁한 도구일 뿐이니 그냥 넘기면 됨

  • 내가 운영한 회사들에서는 그래서 간단한 화이트보드 예제를 썼음. 오타는 신경 쓰지 않고, 사람이 어떻게 생각하는지를 봄
    “함정” 질문은 멍청하지만, 후보자가 기본을 아는지 보고 동시에 우리 회사가 어떤 곳인지도 보여줘야 함. 예를 들어 “인자를 수정해도 되나요?”라고 묻거나 “strlen이 0 바이트를 포함하는지 기억이 안 나니 1을 더하겠습니다, 평소엔 찾아볼 겁니다”라고 말하는 건 좋은 신호임. 문제는 atoi나 “카드 한 벌 섞기”처럼 기본적이지만 fizzbuzz만큼 완전 사소하진 않은 수준이었음. 가장 잘 뽑은 사람 중 하나는 근본적인 실수를 했지만, 의도대로 동작하겠냐고 묻자 “내가 빌어먹을 바보네요”라고 하고 바로 고쳤음. 면접에서 그런 말투가 적절하진 않겠지만, 우리는 강한 긍정 신호로 봤음. 반대로 문자열을 파싱해 정수를 반환하는 질문이 이미 라이브러리 함수가 있으니 부당하다고 끝까지 주장한 후보도 있었고, 실제로 우리 시스템 일부는 라이브러리 없는 임베디드 환경이었음
  • 퀴즈를 내더라도 사람들에게 검색은 하게 해줘야 함. 소프트웨어 엔지니어는 실제로 그렇게 일하지, 이걸 시험처럼 만들면 안 됨
    학교와 대학의 끔찍한 시험처럼 기억력을 먼저 테스트하는 방식을 흉내 내지 않았으면 함. 나는 필요할 때 즉석에서 떠올리는 걸 못해서 정말 힘들었고, 나만 그런 건 아닐 것임. Android 개발자 면접을 볼 때는 질문을 던지고 생각하는 방식을 봤고, 모든 답이 정확하길 기대하지 않았음. Android의 기본 이해가 있는지 본 뒤, 작은 앱을 집에서 만들어 보게 했음
  • “똑똑한 사람은 떨어지고 바보를 뽑는 경우는 적다”는 논리는 봤지만, 실제로 맞는지는 의문임. 특히 “지원자 대부분은 자격이 없다”는 채용 쪽의 다른 통념도 믿는다면 더 그렇다
    결국 자리를 채워야 하는 채용에서는 거짓 음성이 늘수록 거짓 양성을 뽑을 확률도 올라감. 극단적으로 지구상에 그 일에 적합한 사람이 한 명뿐인데 그 사람을 거짓 음성으로 떨어뜨리면, 남는 선택지는 엉뚱한 사람을 뽑는 것뿐임
  • 이런 면접은 거짓 양성도 많이 만듦. 다만 “바보를 뽑는다”가 아니라, 실제 일에는 전혀 맞지 않지만 LeetCode를 잘하는 사람을 뽑는 형태임
    지능 부족이 문제가 아니라, 알고리즘 문제는 잘 풀어도 소프트웨어 엔지니어가 아니거나 그 포지션이 요구하는 능력이 부족한 게 문제임. 퍼즐류 면접으로 많이 뽑힌 팀에서 일하는데, 다들 똑똑하지만 소프트웨어 엔지니어는 아니고 그 차이가 크게 드러남
  • 어려운 LeetCode 문제는 생각하는 사람이 아니라 반복 훈련한 사람을 뽑음. 그런 문제들 중 상당수는 수십 년 전 처음 풀렸을 때 논문감이었고, 매우 똑똑한 사람도 수십 분 안에 비슷한 결과를 처음부터 도출하기는 어려움
    누군가 풀었다면 정말 최적해를 새로 유도했다기보다 연습 문제를 돌리다 같거나 비슷한 문제를 봤을 가능성이 훨씬 큼

• 한 번은 꽤 마음에 든 면접을 봤는데, 은행이었음. 급하게 작성된 지저분한 코드, 다만 일부러 난독화한 건 아닌 코드를 주고 가능한 한 잘 리팩터링하라고 했음
  면접관은 옆에 앉아 전 과정에서 대화했고, 사실상 후보자가 주도하는 페어 프로그래밍에 가까웠음. LeetCode 면접들 뒤라 신선했음. 물론 그 은행은 쓰는 기술을 정확히 알고 있었고 새 기술 학습 능력을 측정할 필요가 적었기에 가능한 방식이었음. 그들에게는 유지보수 가능한 코드를 만들 수 있는지, 이름을 제대로 짓는지, 동료와 소통하는지가 더 중요했음

  • LeetCode 면접도 후보자의 새 기술 학습 능력을 측정하진 않지 않나
  • 나도 이런 면접 방식을 자주 씀. 처음은 아주 기본적인 내용이고, 주로 데이터베이스 일을 하다 보니 그다음은 코드 리뷰 구간으로 감
    흥미로운 건 기본 질문에서 거의 실패한 사람이 코드 리뷰에서는 깊은 전문성이 드러날 정도로 잘하는 경우가 있었음. 면접은 사람의 업무 능력을 보여주기엔 꽤 나쁜 도구지만, 문제를 넓게도 좁게도 볼 수 있고 코딩도 충분히 해내면 대체로 성공이라고 봄

• LeetCode식 면접은 아마 두 가지 기능을 함. 첫째, 소프트웨어 엔지니어의 임금과 이직성을 억누르는 수단임. 이직하려면 한두 달 공부해야 하는데 누가 쉽게 옮기겠나
  운 나쁘게 열심히 준비한 면접관이 LeetCode hard급 폭탄을 던지면 1년 동안 그 회사에 다시 지원하기도 어려움. 둘째, 모두에게 비슷하고 명확한 목표를 줬다고 주장하면서 과정의 편향을 가리는 수단이 됨. 같은 학교, 성별, 인종이면 같은 문제를 주더라도 힌트를 주고 문법 오류를 봐주고, 최적 접근을 못 해도 “소통”으로 강한 채용 판정을 줄 수 있음. 마음에 안 드는 사람이면 어려운 문제를 던지고 면접 내내 침묵하면 됨. 회사에는 허용 가능한 잡음이지만 개인에게는 수십만 달러 보상의 기회를 잃는 일임. FAANG 면접을 봤고 면접관도 해봤는데, 낮은 기준으로 채용된 사람들을 보면서 동시에 사분트리나 정수론 같은 터무니없는 질문 때문에 훌륭한 엔지니어가 기회를 놓치는 걸 봤음

  • 어떤 과정이든 작정하면 불공정하게 행동할 수는 있지만, 표준화된 시험이 있으면 오히려 과정이 훨씬 공정해진다고 봄
    공정한 면접관이라는 전제가 있으면, 이 방식은 이력서에 유명한 이름이 적지 않은 후보자도 실력을 보여줄 기회를 줌. 컴퓨터공학 학위가 없는 내가 얻었던 기회 중 일부는 화이트보드 면접이 아니었다면 절대 없었을 것임. 면접관이 친구를 뽑으려고 일부러 절차를 뒤집는 걸 막을 수 있는 방법은 상상하기 어려움
  • 여기서 묘사한 문제는 LeetCode 자체가 아니라 면접 편차와 채용 편향임. 어떤 면접 형식에서도 생김
    많은 회사는 공정하고 어느 정도 현실 문제와 관련 있게 설계한 문제 은행을 갖고 있음. 내가 면접 본 회사들도 대체로 그랬고, 실제 LeetCode 문제 그대로가 아니어도 결국 고립된 코딩 문제라 LeetCode식이라고 봄. 이 방식을 잘 운영하는 회사의 면접은 꽤 괜찮았음. 좋은 회사와 면접관은 최종 코드만이 아니라 더 많은 것을 보고, 채용 평점도 스케일로 매겨 이분법을 줄임
  • 문제는 30~50분짜리 간단한 코딩과 자료구조·알고리즘 면접 형식 자체가 아니라 난이도의 상승임
    현실적으로 fizzbuzz만으로도 75%는 걸러졌음. 압박을 받으면 코드를 못 쓰는 사람이 많고, 복사·붙여넣기로 억지로 버티는 사람도 있음. 이런 사람은 아무 일도 못 하는 게 아니라 느리고 이상한 추상화를 내놓고, 쓸 만한 결과를 얻기까지 많은 시간을 잡아먹음. 그리고 그 사람들도 돈이 수십만 달러 걸려 있으니 똑같이 반박함
  • 이 방식은 아이, 노부모 부양, 건강 문제 같은 시간 제약이 있는 사람을 걸러내는 데도 아주 좋음
    회사 입장에서는 합리적임. 산만하지 않고 초과근무할 수 있는 직원을 원하니까
  • 최고 보상을 원한다면 그 게임을 해야 함. 어느 직업이든 마찬가지고, 최고 로펌에 가려는 변호사들이 더 쉽다고 생각하나
    오늘날 기술 채용 관행에는 타당한 비판이 많지만, “영혼을 팔지 않고 엄청나게 부자가 될 수 없다”는 불평은 그다지 설득력 있지 않음

• 소프트웨어 엔지니어를 선별할 때 중요한 건 지식이 아니라 문제 해결력과 문제의 정신적 모델을 세우는 능력임
  후보자가 그 문제를 전에 본 적 없고 면접관이 무엇을 봐야 하는지 이해한다면, 화이트보드 면접은 이 능력을 평가하는 좋은 방법임. 하지만 굿하트의 법칙처럼 측정값이 목표가 되면 더 이상 좋은 지표가 아니게 됨. 문제 해결력이나 모델링 능력이 약한 사람도 높은 연봉의 소프트웨어 직무를 원하니 LeetCode를 갈아넣고, 시간이 지나 그 사람들이 면접관이 되면 본인에게 그랬듯 기억력 시험처럼 면접을 진행함. 그래도 회사가 가진 제약, 후보자의 시간 낭비를 줄이고 HR이 좋아하는 일관된 평가표를 유지해야 하는 조건에서는 더 나은 면접 방식이 제안된 걸 아직 못 봤고, 당분간 계속 쓰게 될 것임

  • 더 나은 방식은 쉽게 접근 가능함. 후보자에게 계산기나 달력 같은 알려진 것을 만들게 하거나, 코드 묶음을 주고 수정하거나 버그를 찾게 하면 됨
    소프트웨어를 만드는 일에 더 가까움. LeetCode는 실제 업무와 너무 멀고, 성과도 실제 적합성과 상관관계가 너무 약함
  • LeetCode 점수가 높을수록 LLM으로 대체될 사람을 잘 가리키는 지표라는 결론도 가능함
  • “A급은 B급을 뽑고 B급은 C급을 뽑는다”고 하는데, 그걸 막겠다고 면접 과정에 LeetCode를 더 넣은 셈임
  • 회사가 왜 이 문제를 진심으로 신경 쓰고 채용 절차를 덜 적대적으로 만들려고 노력하겠나. 어떤 시험이 나오든 기꺼이 통과하려는 후보자가 여전히 많음
    물 새는 양동이지만 회사는 현 상태에 만족하고, 개발자들은 계속 LeetCode를 갈아넣음. 곧 바뀔 것 같지는 않지만, 새 직장을 구할 때 이런 면접은 거절할 수 있는 상황이라 다행임

• 친구가 기술 면접 도중 갑자기 말을 멈추고 일어나 나간 적이 있음. 회사 사람들이 “왜 그래요, 잘하고 있어요!” 하고 쫓아갔지만, 너무 우울해져서 더 이상 관심 없다고 했음
  대부분에게는 재미있는 직업일 텐데 슬픈 일임

  • 나도 비슷하게 한 적이 있음. 복지로 유명하지만 미친 제작 일정으로도 알려진 게임 회사였고, 처음엔 정말 가고 싶었음
    그런데 면접 중간쯤 화이트보드가 나오고 동료들이 들어와 펜으로 기본적인 것들을 구현하라고 했는데, 진행될수록 점점 더 적대적이고 무례해져서 의식화된 괴롭힘처럼 느껴졌음. 기술적으로 사소한 결과를 내면서도 모욕과 적개심을 견딜 수 있는지 시험하는 것 같았고, 결국 면접을 멈추고 “어떻게 일하는지 봤으니 여기서 일하고 싶지 않다고 결정했습니다. 기회는 고맙고 서로 시간 낭비해 죄송합니다”라고 말하고 나왔음. CEO가 주차장까지 쫓아와 왜 그렇게 됐는지 물었고, 면접 도중 지원자가 결정을 내릴 수 있다는 사실에 정말 충격받은 것 같았음. 직무 면접은 양방향이라는 걸 사람들이 잊음. 그날 이후 내가 일할 수도 있는 회사의 모든 면을 살펴볼 권리가 있고, 과정에서 부정적인 것을 보면 타협하지 않아도 된다는 걸 깨달음. 다음 날 경쟁사에서 지금까지도 좋은 친구이자 동료인 사람들을 만났으니 올바른 결정이었음. 이 직업은 재미있지만, 그 재미가 농장처럼 수확되고 착취되면 다른 노예화와 다를 바 없음
  • Zoom 면접에서 비슷한 일을 했음. 어려운 LeetCode hard 문제를 받았고 완전히 막혔는데, 면접관들도 도와줄 생각이 없어 보였음
    “오늘은 제 날이 아닌 것 같고 면접을 그만하고 싶습니다”라고 말하자, 그때부터 남은 시간 동안 머물게 하려고 꽤 애썼음. 후보자가 나가고 싶어 하면 보내줘야 한다고 봄

• 5년이 지난 지금도 이런 면접을 거부하고, 다시는 그 과정을 겪고 싶지 않음. 사람을 한 시간짜리 발길질 게임처럼 다루는 사람들에게 괴롭힘과 조롱을 당했고, 더 이상 상대하고 싶지 않음
  예고 없는 LeetCode 면접이 많았기 때문에 LinkedIn [1]과 GitHub [2] 프로필에 어떤 것이 허용되고 아닌지 명확히 적어둠. “면접 중 모든 형태의 라이브 코딩이나 온라인 코딩 테스트에 반대하는 개인 정책이 있으며, 경쟁 프로그래밍을 즐기거나 참여하지 않습니다. 대신 합리적인 목표와 기한이 있는 오프라인 코딩 과제, 소프트웨어 아키텍처와 설계 및 관련 기술에 대한 깊은 기술 토론은 기꺼이 합니다.”
  [1] https://www.linkedin.com/in/mtodor
  [2] https://github.com/mihaitodor

  • 개발자를 찾는 사람들이 함께 이용 약관 같은 걸 만들 수도 있겠음. HR이 그걸 숙지하고 자기 방식도 재고하게 만들 수 있음
  • 접근 방식이 마음에 듦. 실제로 얼마나 잘 통했는지 공유할 수 있나
    다만 과제형 면접에서 부정행위가 만연하다는 이야기가 있어, 이를 쓰려는 고용주 수가 급격히 줄어들까 걱정됨

• 악마의 변호를 해보면, LeetCode는 평균적인 개인 기여자 채용에서 두 가지 중 하나 또는 둘 다를 선별하는 데 쓰임. 열심히 하는가, 즉 많은 문제를 공부하고 해법을 외워 되풀이하는 사람인가. 또는 똑똑한가, 즉 LeetCode를 하지 않아도 기본기를 알고 과거 지식을 합성해 새 질문에 답할 수 있는 사람인가
  아무 정보가 없다면 LeetCode 문제를 통과하지 못한 사람은 둘 중 어느 쪽도 아닐 가능성이 더 높다고 봄. 코딩이 필요한 역할이라면 LeetCode 쉬움~중간 문제 하나 정도는, 면접관의 약간의 방향 제시를 받아서라도 풀 수 있어야 한다고 생각함. 실제로 회사들은 더 시니어가 되거나 더 특수한 역할에 지원할수록 LeetCode 능력 비중을 낮춤. 버그 수정, 시스템 설계, 행동 면접, 과제, 잡학성 질문, 배경 특화 질문 등도 많고, 초급 이상 채용에서는 LeetCode가 전부가 아님. 최고의 엔지니어를 마법처럼 고르는 도구가 아니라 채용위원회가 쓰는 또 하나의 신호일 뿐임

  • 이건 4년제 대학생이 19살쯤 배우고, 이후 50년 동안 실제로 뭔가를 만들면서는 거의 쓰지 않는 기술임
    예산 안에서 끝까지 밀어붙이는 엔지니어링 능력을 보지 못함. 좋게 봐야 주변 곁가지이고, 나쁘게 보면 19살에 가까운 사람을 선호하는 연령차별의 대리 지표임. 그래서 이 업계가 품질 좋은 소프트웨어를 내놓는 데 그렇게 애먹는지도 모름. 더 나은 방법은 깨진 빌드나 크래시 나는 코드 같은 실패 상황을 주고 고치게 하는 것임. 시스템을 탐색하고, 결함을 진단하고, 원인을 찾고, 패치를 제안하고, 코딩·주석 스타일을 맞출 수 있다면 실제로 필요한 선수임. 분기와 이슈 트래커를 두고, 버그 논의가 이미 진행 중일 수도 있고, 댓글에 수동 적용해야 하는 패치 파일이 있을 수도 있음. 패치에 새 버그가 있거나, 비슷하지만 무관한 문제를 건드리는 미끼일 수도 있음. 닫힌 버그의 회귀인데 단위 테스트가 없을 수도 있고, 테스트가 있더라도 후보자가 찾아야 하거나 테스트 자체가 낡고 버그투성이일 수도 있음. 이게 진짜 일임. 끝나고 “단위 테스트가 깨져 있었습니다”라고 말하는 것과 “어떻게 제대로 실행하는지 이해하지 못해서 넘어갔습니다”라고 말하는 건 태도 차이가 크고, 팀 플레이어는 후자임
  • 지원자 대부분은 이미 직장이 있음. 정말 열심히 일하는 사람이라면 본업 옆에서 LeetCode 문제를 풀 에너지가 넉넉한 경우가 오히려 드묾
    그래서 반대로 현재 역할에서 뛰어난 성과를 내지 못하지만 남는 에너지로 LeetCode를 갈아넣은 후보자를 얻을 수도 있음
  • LeetCode 문제는 정의상 실제 문제에 가까울 수 없음. 맥락에서 떨어져 있기 때문임
    프로젝트를 몇 주만 해도 똑똑한 사람은 실제로 필요한 통찰을 얻을 수 있음. LeetCode가 던지는 느닷없는 퍼즐은 예전 잡지의 십자말풀이에 더 가까움
  • 면접에서 원리만으로 Dijkstra 알고리즘을 떠올릴 수 있다고 생각하는 건 엄청난 오만임
    할 수 있는 유일한 이유는 전에 공부했기 때문임
  • 시니어가 되면 LeetCode 비중이 줄어든다는데, 그게 언제 시작되나. 경력 8년이 넘었는데도 30분 안에 NxM 빙고 풀이를 만들라는 말을 듣는 데 지쳤음
    2022년이었다면 LeetCode가 최고의 엔지니어를 고르는 도구가 아니라는 데 동의했겠지만, 2024년에는 문제를 맞혀도 충분히 빠르지 않거나 힌트 없이 못 풀었다고 더 많이 걸러짐. 나는 LeetCode 천재가 아니고 공부할 것도 너무 많으며, 면접 중 LeetCode 비중은 20% 정도인데 2년 전보다 그렇게 나빠졌다고 느끼진 않음. 회사들의 기대치만 하늘로 치솟았고, 15년 이상 경력 역할을 5년차 연봉으로 사려는 분위기임

• LeetCode식 면접에서 잘 언급되지 않는 흥미로운 점은, 일종의 지적 신고식이라는 것임
  입문 의식이 혹독할수록 그 집단에 들어간 사람들의 헌신이 크게 높아진다는 건 여러 번 입증됐음

  • 문제는 패자는 시험을 통과하지 못하지만 승자는 통과한다는 것임
    자본주의 회사가 프로그래머를 뽑을 때 “정답을 믿는 똑똑하고 비슷한 사람들”과 “무작위로 섞인 숙련자들” 중 무엇이 더 낫겠나. 후자라고 답한다면 이상주의적이고, 그런 의견은 실제로 중요하지 않음. 자연은 더 똑똑하고 현실적인 사람으로 대체할 것임

• 최근 몇 번 면접에서는 후보자에게 샘플 코드를 보여주고 리뷰하게 했음. 샘플에는 줄마다 최소 하나의 버그나 문제가 들어 있음
  그다음은 모델링 과제, 보통 화이트보드로 진행함. 주니어가 정말 주니어 역할을 할 수 있는지 보기 위한 fizzbuzz식 간단한 연습도 있고, 실행 시간 복잡도나 메모리 배치 같은 주제로 대화를 여는 발판으로 삼음. 후보자의 수행에 따라 매우 상호작용적으로 진행하며, 스크리닝을 어떻게든 통과해 온 가짜를 걸러내고 문화 적합성도 어느 정도 느껴보려는 목적임

  • 후보자에게 깨진 단위 테스트를 주고, 집처럼 편한 환경에서 자기 도구로 1시간 안에 고치게 하는 걸 좋아함
    시간대나 전화번호 검증처럼 지저분한 문제를 만들고, Wikipedia 문서를 명세로 둠. 끝나면 해법을 물어보고 코드 리뷰를 함. 최고의 시니어는 그냥 라이브러리를 씀. 좋은 후보자는 직접 만들지만 절충점을 설명할 수 있음. 주니어는 테스트만 통과시키고 멈춤
  • 즐겨 쓰는 건 이것임
    https://github.com/emilybache/GildedRose-Refactoring-Kata
    후보자가 좋아하는 언어로 하게 했고, 매우 효과적인 필터였음

• 이론은 많이 아는 것처럼 보이지만 막상 코드를 쓰라고 하면 처참히 실패하는 개발자 후보자를 면접한 적이 있음. fizzbuzz도 구현하지 못하고, Senior Java 개발자가 찾아보지 않고는 HashMap을 import하지 못했음
  수학과 비슷함. 562 * 1041은 계산기를 쓰는 게 맞지만, 3 * 7을 알려고 계산기를 꺼내면 전문가인지 의심하게 됨. 많은 회사가 LeetCode 면접을 과하게 하지만, 배열 조작, 흐름 제어, 기본 자료구조 사용을 보여주는 라이브 코딩 면접은 경험에서만 나오는 근육 기억이 있는지 보여줌. 통과하려고 그래프 순회 알고리즘을 공부해야 한다면 아마 너무 LeetCode스러운 것임

  • HashMap 패키지명을 외웠는지 보는 건 내가 들어본 Java 프로그래밍 테스트 중 가장 멍청함
  • HashMap import를 못 한다는 건 그 자체로는 우스운 기준임. Java에서 HashMap 예제를 막 본 대학생이라면 import를 기억할 수도 있음
    하지만 프로그램에는 그런 사소한 요소가 여럿 필요하고, 그 세계관에서는 전부 외워야 함. 562 * 1041은 계산 원리, 즉 어떻게 하는지는 알고 있어야 한다고 기대함. 계산은 틀릴 수 있어도 긴 곱셈의 아이디어는 틀리면 안 됨. 그런 맥락에서는 3 * 7 같은 구구단 한 항목을 잊어버렸어도 괜찮음. 프로그래머는 계산을 조직하는 사람이지 직접 계산하는 사람이 아니고, 그건 컴퓨터가 함. 그래프 순회 알고리즘은 어디서 해법을 찾을지 알면 되지 모든 해법을 손에 들고 있을 필요는 없다는 데 동의함
  • Eclipse는 내가 보지도 않아도 import를 해줌. IntelliJ도 마찬가지임
    어떤 상황에서 이 사람들이 직접 import해야 했나. IDE가 없었나
  • HashMap이 어느 네임스페이스에 있는지 모르는 사람이 3 * 7을 못 하는 사람과 같다는 건가
    면접관 고정관념을 풍자한 건지 잘 모르겠음