▲

라이브 코딩 인터뷰는 스트레스를 측정할 뿐, 코딩 실력을 평가하지 않음

 (hadid.dev)
2P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • 라이브 코딩 인터뷰가 실제로는 엔지니어의 코딩 능력보다 스트레스 반응을 더 잘 측정함
  • 과학 연구에 따르면 실시간으로 지켜보는 환경에서는 인지 능력 저하와 심한 성과 변동이 나타남
  • 특히 여성 지원자의 경우, 공개 환경에서 전원이 탈락했으나 개인 환경에서는 모두 통과하는 현상도 확인됨
  • 대부분의 기업에서는 스트레스 적응력을 요구하지 않으면서 코딩 테스트로 이를 잘못 평가하는 문제점이 존재함
  • 모의 테스트, 점진적 노출, 그리고 보조 영양소 등이 스트레스 완화에 도움될 수 있음

라이브 코딩 인터뷰에 대한 개인적 경험

  • 일부 사람들은 라이브 코딩 인터뷰를 즐기지만, 필자는 그렇지 않음
  • 필자는 Toptal 지원 과정에서 라이브 코딩 테스트에서는 실패했으나, 혼자 다시 풀었을 때는 금방 해결했음
  • 이 경험으로 실시간 감시 하에서 스트레스로 인해 본래 능력을 발휘하지 못함을 인지하게 됨

스트레스에 반응하는 두뇌

  • 고위험, 시간 압박 상황에서 뇌의 편도체가 활성화되고, 코르티솔 수치가 상승함
  • 이로 인해 복잡한 추론과 기억을 담당하는 전전두엽의 기능이 손상됨
  • 작업 기억력은 새로운 문제 해결 능력을 판단하는 가장 중요한 척도이며, 이는 실시간 코딩 상황에서 크게 줄어듦
  • 가벼운 성과 불안이 있는 경우도 명확한 사고가 거의 불가능해짐
  • 집중이 어려워지고, 여러 단계를 동시에 기억하지 못하며, 본인이 ‘평소보다 한참 못한 사람’처럼 느껴짐

결정적 연구 결과

  • Microsoft 연구진이 수행한 논문에서는 동일한 코딩 문제를 개인 환경과 공개 환경에서 각각 풀려 비교함
  • 개인 환경에서는 혼자 방에서 진행, 공개 환경에서는 감독관 앞에서 사고 과정을 말하며 풀게 함
  • 결과적으로 지켜보는 환경에서는 성적이 절반으로 감소하며, 특히 성적 편차가 커지는 것으로 나타남
  • 남성 지원자와 달리, 공개 환경의 모든 여성 지원자가 불합격했고, 개인 환경에서는 모두 통과함
  • 라이브 코딩 환경이 유능한 엔지니어를 탈락시키는 과학적으로 입증된 배제 필터 역할을 함

스트레스 하 성과의 현실

  • 라이브 코딩은 결국 스트레스 상황에서의 성과를 보는 대리 척도에 불과함
  • 일부 기업은 실제로 스트레스 환경에서 잘 하는 사람을 원하지만, 대다수 기업은 이를 지원서에 명확히 밝히지 않음
  • 대부분의 작업이 실시간 스트레스가 적다는 점을 고려할 때, 라이브 코딩에서 실수했다는 이유로 우수한 엔지니어를 탈락시키는 것은 부적절함
  • 라이브 코딩은 코딩 능력보다는 스트레스 호르몬 수치를 측정한다고 봄이 타당함

스트레스 완화를 위한 방법

  • 라이브 코딩이 업계에서 일반적이므로, 스트레스 적응 훈련이 필요함
  • 실제와 비슷한 환경에서 반복 연습(Pramp, Interviewing.io, LeetCode 모의 테스트 등)으로 두뇌를 스트레스에 익숙하게 할 수 있음
  • 타이머 설정, 자신을 녹화, 친구에게 지켜보게 하는 식으로 점진적으로 압박감 높이는 연습이 효과적임
  • 추가적으로, L-tyrosine(스트레스 하 신경전달물질 보충)과 L-theanine(이완 및 집중 개선) 같은 영양소 섭취도 시도해볼 수 있음
  • 실제 인터뷰 이전에는 본인에게 잘 맞는 방법을 반드시 모의 연습에서 확인해야 함

결론

  • 라이브 코딩에 약하다는 것은 엔지니어로서의 자질 부족이 아닌 인간의 일반적 특성임
▲
GN⁺ 19시간전  [-]
Hacker News 의견

  • 나는 내 사례를 일반화할 생각은 없지만, 개인적인 경험을 공유하고 싶음. 지금은 성공한 자영업 indie developer임. 어려운 시절에도 indie 개발을 포기하지 않은 주요 이유 중 하나는, 사실상 고용될 수 없는 상태가 되었기 때문임. 나는 기술 업계에서 나이 차별이 심한 중년이고, 컴퓨터 사이언스 학위도 없으며, 라이브 코딩 인터뷰에서는 머리가 하얘지는 증상을 경험함. 모든 스트레스가 같은 것이 아니라는 점을 지적하고 싶음. 소방관들은 타는 건물로 뛰어들지만, 낯선 사람들 앞에서 발표하는 일에는 오히려 공포를 느낌. 나 역시 일상적인 업무 스트레스에는 강하지만, 타인이 내 어깨 너머로 감시하며 내 재정적 미래를 결정한다는 점은 소화가 안 될 정도로 부담스러움. 인터뷰가 끝나면 코딩 문제는 곧잘 풀 수 있음. 면접관들은 내가 사기꾼이라 생각할지 몰라도, 20년 가까운 경력이 반박 증거임. 많은 사람들이 "false negative"를 마치 랜덤인 것처럼 여기는 것 같지만, 나처럼 항상 제거되는 사람도 있음. 나는 오디션 스타일 인터뷰에서 항상 떨어지고, 무대 위에서 연기하는 사람은 아님.

    • 타인이 지켜보는 상황에서 심사가 이뤄지면 너무 공감됨. 60대 초반임. 20~30대에는 인터뷰를 그럭저럭 잘 봤지만, 시간이 지날수록 면접 자체가 점점 더 대립적으로 변했다고 느낌. 예전엔 '어떻게든 채용하려는' 분위기였다면, 지금은 '채용하지 않으려는' 이유를 찾는 느낌임. 이는 나이 차별 때문일 수도 있지만 업계 분위기 변화도 있다고 봄. 최근 15년 동안 인터뷰 경험이 점점 불쾌해지고, 인터뷰 중 패닉을 겪기도 했음. 그래도 어찌어찌 채용은 되었고, 참조 경력 덕분에 면접 없는 계약직을 하기도 했음. 마지막으로 다닌 스타트업이 22년 말에 자금이 끊겨서 퇴직을 결심했음. 일 자체는 정말 좋아하고, 최신 기술도 다뤘지만, 더는 인터뷰를 감당할 수 없었다는 점이 가장 큼.

    • 이 구조 자체가 문제라고 생각함. 최근의 코딩 인터뷰는 젊은이들이 CS 자료구조 과제를 했는지 따지려는 용도로 만들어진 것 같음. 2010년대 FAANG 같이 대량 채용하는 곳에서는 나름 의미가 있었겠지만, 중소형 회사에서는 오히려 실제로 코드를 읽거나 edge case를 논의하는 것 등 실무 상황에 집중하는 게 훨씬 나음. 20년 넘게 스타트업에서 일했지만, 이런 테스트는 여전히 못 통과함. 억지로 외우는 것도 거부함. 이게 안 맞는 곳이라면 차라리 안되는 게 맞음. CTO도 하고, 회사 여러 번 론칭했고, 팀 관리도 잘했는데 이번에도 신입처럼 취급받음. 예전에 LRU 캐시를 빠르고 깔끔하게 못 만들어서 탈락했는데, 요즘 스타트업에 이게 얼마나 필요할지 의문임. 최근에 써본 적도 없음. 이런 문제를 바로 못 풀었다고 무능력자처럼 보일 수도 있지만, 실무에서 안 쓰는 걸 굳이 따지는 게 무슨 의미인지 모르겠음. 마치 건축가를 슬라이드 룰(계산자) 실력으로 뽑으려는 것과 같음. 이런 채용 방식은 결국 복잡한 코드베이스를 낳고, 진짜로 필요한 건 복잡성보다 비즈니스 목표 달성이 되어야 함. 나는 문제를 쪼개고 논리와 구조를 단순하게 유지하는 동료와 함께 일하고 싶음. leetcode로 똑똑한 사람을 고르는 것도 장점이 있긴 하지만, 현실 문제를 꾸준히 효과적으로 푸는 사람이 더 나음.

    • 나는 채용자 입장에서 이런 상황을 겪은 적 있음. 프로젝트에 오래 참여한 학생과 전화 인터뷰를 했는데, 여러가지 스트레스, 언어 장벽 때문에 제대로 실력 발휘를 못 하는 것 같았음. 형식을 바꿔볼 의향도 있었지만, 지원자가 스스로 더 이상 시도하지 않겠다고 함. 그런데 비동기 코딩 인터뷰로 전환하면 오히려 LLM 사용 여부만 테스트할 수도 있음. 결국 인터뷰에서 얼어붙는 사람을 거를지, 전혀 능력 없는 사기꾼을 거를지 둘 중 하나를 선택해야 한다면, 나는 전자를 필터링하는 게 더 나은 선택이라 봄.

    • 이런 성향의 불일치를 회사에서 많이 봄. 많은 프로그래머는 내성적인데, 채용하는 쪽은 외향적인 경우가 많음. 이런 차이를 제대로 관리하지 않으면 내향적인 인재가 배제되거나 이해받지 못하는 문제가 생김. 오픈 시트 환경(공유 앉는 공간)도 비슷한 문제임. 매니저들은 협업을 좋아해도, 내향적인 사람들에겐 매우 힘든 환경임.

    • indie 개발에서 성공하기 시작한 계기가 궁금함. 나도 거의 40살이고 프로그래밍을 오랫동안 취미로 해왔지만, 작년부터 본격적으로 직업 삼기로 결심했음. Github에 공개 프로젝트도 많고, 다른 분야에서 성공 경험도 많으며, 소통 능력도 나쁘지 않음. 하지만 라이브 코딩에서 어려움을 겪고 있음. 진짜 실력을 보여줄 수 있는 independent contribution 루트에 대해 어떤 생각이 있는지 궁금함. 진짜 실력이 있다면 그걸로 돈을 받고 싶다는 생각임.

  • 이번 주에 Data Engineering 후보자를 인터뷰했음. 아주 기본적인 4개의 SQL 문을 줬더니, 문제를 소리내서 읽고 바로 정답을 정확한 문법으로 냄. 마지막은 난도가 살짝 올라갔는데 막힘. "결과를 확인해봐라"고 했더니 못 알아듣고 방어적이었음. "테이블을 덤프해봐라"고 하니까도 아예 이해를 못하고 변명만 했음. 최종적으로 붙여넣은 SQL에는 [redacted].ai가 출력에 있었음. 아마 앞의 문제들은 AI로 해결했다가, 마지막 문제에서 티가 난 것임. 이런 기술 문제가 없었으면 부정행위를 못 걸러냈을 것임.

    • AI 인터뷰 부정행위 도구가 젊은 층에서 매우 퍼지고 있음. 어떤 경우는 바로 걸리지만, 경험이 많은 지원자들은 AI 활용과 중간중간 '소리가 안 들려요' 등으로 빈틈을 가리기도 함. 내가 속한 매니저 그룹에서도 이게 최근 가장 많이 논의되는 채용 주제임. 여력이 되는 회사는 마지막 면접을 오프라인에서 직접 봄. 원격 스크린에서는 괜찮은 것처럼 보이다가 실제 만나면 기본 질문도 못하는 경우가 있어서 결국 탈락시킴. 시간과 돈 낭비이긴 해도, 잘못된 채용의 비용보다 낫다고 판단함. AI 사용은 기술면접만이 아니라 이력서, 행동질문, 심지어 ChatGPT가 만들어준 S.T.A.R. 형식 답변까지 전체적으로 퍼져 있음. 신뢰할 수 있는 참고인 확인이 그 어느 때보다 중요해짐. 예전 상사가 말하는 업무 내용과 이력서에 적힌 내용이 완전히 다를 때도 여러 번 경험했음. 만약 처음부터 우리 도메인 직접 경험이 없다고 솔직했으면 채용했을 수도 있는데, 이렇게 거짓말이 강할 경우 신뢰가 전혀 안 생김.

    • 요즘 후보자 인터뷰하면서 약 50%가 live GenAI를 실시간으로 활용했음. 지금까지는 누가 AI 쓰는지 알아채기 매우 쉬웠음. 자연스러운 대화에서 쉽게 드러남. 아이러니하게도, 마지막 후보자 역시 문제를 항상 되풀이해 말한 뒤 10~15초씩 대기함. 이런 테스트 자체가 근본 문제의 해결책이 아님을 의미함. 오히려 새로운 문제를 만들고, 뛰어난 후보자를 떨어뜨리는 원인이 됨.

    • "AI를 쓰면 부정행위가 아니라, 실제 현업에서 하게 될 일을 미리 해보는 것이라면?" 이런 시각으로 보면 그 인터뷰는 실제로 매우 효과적인, 작은 규모의 <i>요구사항 해석</i> 예시임. 결국 현업에서 쓸 도구를 자유롭게 쓰도록 하면서 그 안에서 직무와 언어 본연의 이해를 테스트하는 방향이 더 긍정적이라고 생각함. 요구만 단순히 Leetcode에서 벗어나 더 나은 방법을 찾아야 함.

  • 모든 것은 결국 '상황에 따라 달라짐'. 라이브 코딩 인터뷰도 마찬가지임. 지원자 입장에서 최고의 경험은 아니지만, Meta, Google 같은 대규모에서는 다른 방식보다 false positive(실제 실력 없는 사람을 뽑는 오류) 비율을 더 잘 줄임. 다만, 인터뷰어가 충분히 훈련받지 못했고, 문제가 지나치게 수수께끼 같은 경우가 많아 LeetCode를 많이 연습하거나 학계/졸업 직후가 아닌 이상 힘듦. 나는 6년간 평가(assessment) 분야에서 일했고, Fortune 10부터 스타트업까지 다양한 채용 과정을 직접 접했음. 후보자에게 실제 업무와 유사한 평가를 권장하고, unpaid labor에 가까운 '실제 업무' 표현은 이제 좋아하지 않음. 평가는 회사가 고액 연봉을 안심하고 제안할 수 있게 만드는 수단이어야 함. AI의 등장으로 짧은 take-home 문제도 공정성을 유지하기 어려워 졌음. 그래서 다시 온사이트 면접, 실시간 감시 같은 극단적 방법에 의존하는 기업도 있음. 내가 생각하는 완벽한 솔루션은 모든 후보자가 같은 시간과 환경, 도구에서 자신의 최고 능력을 발휘할 수 있도록 하는 것임. 늘 이 문제를 고민 중이지만 아직 답을 찾지 못함.

    • "Meta, Google 수준에선 잘 동작한다"고 하는데, 사실 데이터가 없음. Facebook, Google 출신 F급 개발자들과 같이 일한 경험이 있음. 실제로는 이런 대기업도 3~5% 인력을 해고하고 있고, 인터뷰만으로 false positive를 제대로 잡아내지 못한다는 증거임. 인터뷰어들이 들인 시간에 비해 3%의 오류율은 너무 높다고 봄. 사실상 이전의 'Fizzbuzz' 수준과 다를 바 없음.

    • 벽돌공에게 벽을 만들어보라고 시키는 게 아니라, 자격증만 인증하면 바로 채용하는 것임. 많은 직업이 이런 방식임. 실력이 안 맞으면 채용 후 내보내면 됨. 굳이 모욕적인 기업 면접 절차를 거칠 필요 없음.

    • 내가 본 최고의 엔지니어들은 항상 false negative로 분류되는 경우가 많았음. 라이브 코딩 면접에서 긴장해서 제대로 못 보여줌. 이런 면접이 "잘 작동한다"는 식으로 단정 지을 수는 없다고 봄.

    • "상황에 따라 다르다" 이후에 "라이브 코딩 인터뷰는 잘 된다"는 식으로 단정 짓는 이야기는 앞뒤가 안 맞음. 반대로 나는 "상황에 따라 다른데, 라이브 코딩 인터뷰는 안 통한다"고도 주장할 수 있는 것임. 논리적 차이가 없음.

    • leet-code 통과가 진짜 문제 해결 능력이 없는 사람을 걸러내는 데 쓸 만함. 최고의 솔루션은 후보자가 자신이 가진 도구와 환경에서 최대치를 낼 수 있도록 하는 환경을 만드는 것임. 하지만, 실제로는 leetcode를 오프라인에서 화이트보드로 인터뷰어와 페어 프로그래밍하며 문제를 푸는 것이 가장 공정하지 않을까 생각함. 그게 정말 편안한 환경임.

  • 두 설명 모두 동시에 맞을 수 있다고 생각함. 실제로 일을 못 하는 "시니어" 개발자가 있기도 하고, 그런 사람을 걸러내는 데 라이브 코딩이 도움됨. 하지만 다른 이유로도 인터뷰에 실패할 수 있음.

    • 라이브 코딩은 잘해도, 대규모 시스템 설계 경험이 부족한 개발자도 많음. 이런 사람들이 기술 부채, anti-pattern, 불일치 등을 도입해서 코드베이스를 더욱 악화시키는 경우가 많음. 사실상 정말 피해야 할 타입임. 회사는 기존 시니어가 신입을 통제할 거라 믿지만, 어느 회사든 "우리 코드베이스는 쓰레기"라고 하니, 이 대책도 실효성이 없어 보임.

    • 혼자 방에서 앉아서 코딩하게 하면, 비정상적 환경에서만 능력을 발휘 못하는 우수 인재를 놓치지 않을 것임.

    • 최근 라이브 코딩은 단순한 코딩 테스트를 넘어, 많은 알고리즘을 암기해야 하고, 30분 안에 두세 가지 알고리즘을 결합해서 문제를 풀어야 하는 수준임. 문제 푸는 데만 시간을 다 쓰다 보니, 오히려 진짜 코딩 실력을 보여줄 시간도 없음.

    • 20년 동안 현업을 하면서 그런 "실력 없는 시니어"를 실제로 같이 일해본 적 없음. 이력서와 15분 대화만 해도 충분히 거를 수 있었음. 반대로 화이트보드 인터뷰에 합격하고도 팀 생산성에 악영향을 준 사람은 훨씬 더 많이 봄.

    • 왜 짧은 기한과, 화이트보드 앞에서 동시에 생각과 설명을 요구하는 환경이 필수적인지 이해가 안 됨. 실제 일을 못 하는 사람을 걸러내는 게 목적이라면, 굳이 이렇게까지 할 필요가 없음.

  • 내가 보기에 어떤 직무 수행력을 제대로 확인할 수 있는 유일한 방법은 실제로 그 직무를 시켜보는 것임. 만약 대체 평가법이 있더라도, 실제 작업을 시켜볼 수 있다면 다른 방식을 쓸 이유가 없음. 만약 회사 업무 자체가 너무 복잡해서 잘라서 면접에서 시킬 수 없다면, 아마 회사가 불필요하게 복잡한 일만 하고 있을 가능성도 큼. 예를 들어, 10킬로그램 무게를 들어보는 게 필요하다면, 실제로 10킬로그램 짐을 들어올리게 하면 됨. 그런데 '힘을 평가하겠다'며 '바지 벗고 1kg 양동이를 엉덩이로 집어 들어올리라' 같은 이상한 시험을 보는 것임. 결국, 실제 업무에 필요한 스킬만 제대로 보면 됨. 예를 들어, 셰프면 실제 주방에서 요리를 하게 하면 되고, 지원 상담원이라면 모의 상황에서 의사소통을 보면 됨. 전화 스크리닝 쪽도 실시간 스크린을 보게 하면 됨.

    • "면접에서 실제로 작업 시키면 부정행위나 임금 착취 이슈가 생기지 않냐"는 반론이 있음. 면접 과제를 회사에서 활용한다면 법적으로 문제가 생길 수 있음.

    • 하루, 일주일, 한 달 단위로 직접 고용해서 시켜보고 적합하면 채용하는 방식 제안도 있음. 단, 이런 방식은 미국식 employer healthcare 시스템과는 맞지 않음.

    • 회사 입장에서는 시간이 너무 많이 들기 때문임. 그래서 false positive보다는 false negative(잘못 탈락시키는 것) 쪽에 치우친 proxy를 씀.

    • 실제 작업을 면접에서 시키면 '공짜 노동' 요구라는 우려에 대해선 어떻게 생각하는지 궁금함.

    • 새로운 조직에 적응하는 데 시간이 오래 걸리므로, 실제 업무로 테스트하는 게 오히려 비효율적일 수 있음. 라이브 코딩 평가로 소통, 문제해결, 순수 코딩 실력 측정이 더 낫다고 봄.

  • 아이를 갖고 난 뒤로 면접 코딩 능력이 확 떨어짐. 예전엔 한 번도 이런 적이 없었는데, 요즘은 인터뷰에 너무 많은 것이 걸린 것 같음. 건강보험, 대출, 은퇴 등을 떠올리면 압박감이 심함. 인터뷰 중 완전 멈춰버리고, 끝나고 나서야 해결책이 떠오르는 게 괴로움. 연습에 시간을 더 쏟을수록 오히려 실력이 더 떨어짐. 부양가족 때문에 연습할수록 죄책감도 큼. 학습 효과도 약하고 오히려 더 위축됨. 빅테크에서 일하면서 느낀 것은, 이런 면접 방식은 지극히 "모두를 동등하게 테스트하겠다"며 도입됐지만, 실제로는 각자의 상황 변화나 불균형을 전혀 반영하지 못함. 스트레스에 강한 동료라도 몇 년 후엔 달라질 수 있음. 편견을 제거한다는 명목으로 시작하지만, 방식을 바꿔야 한다고 생각함.

    • 이런 감정은 혼자가 아님. 나이 들어가면서 학습 속도가 느려지고, 자유시간도 줄어들어서 leetcode 연습 효율이 떨어짐. 그저 시간 여유 있는 사람들이 더 보상을 받는 현실에 짜증이 남.

    • 스트레스 완화법으로 명상, 호흡, L-Theanine, 베타 블로커 등을 시도해보는 것을 추천함. 스마트워치로 심박수와 혈압을 모니터링해보라 권장함. 실제로 이런 방법이 스트레스 악순환을 줄여줌.

  • 현업 스트레스와는 질적으로 다른, 매우 높은 강도의 스트레스 환경임. 구글 면접에서 경험을 공유하자면, 나는 네덜란드 최초의 지역 검색엔진을 만든 사람인데, 구글에서는 카우보이 모자를 쓴 인터뷰어가 화이트보드에 마커로 바이너리 서치를 코드로 쓰라고 시켰음. 나는 평소 손으로 글을 안 쓰고, 키보드만 쓰는데, 또 내가 설계한 검색 인덱스 경험을 전혀 보려고 하지도 않음. 아마 구글은 '카우보이' 마인드를 원했던 게 아닌가 싶음.

    • 나도 예전에 구글 리크루터의 설득에 넘어가 면접을 봤으나, 인터뷰어가 너무 형편없어서 기술 면접을 건너뛰었음에도 불구하고, 이후 구글의 어떤 제안도 거절 중임. 문제 대부분이 '낚시' 스타일이거나, 현실과 무관한 아주 옛날 UNIX 구조(예: inode 구조)를 물었음. 해당 역할에 전혀 연관 없는 내용이었음. 기업들은 반드시 인터뷰 질문을 트래킹, 피드백하는 과정과 인터뷰어 교육이 필요함. 여전히 인터뷰어 개인의 취향에 따라 질문이 정해지는 회사가 매우 많음.

    • 이런 구조가 실제로 의도한 대로 동작한 것임. 이런 회사들은 그 회사에 어떠한 수모도 견딜 수 있는 사람을 원함. 서로 fit이 아니었으니 서로 성공한 것임.

    • 바이너리 서치를 시키는 것에 모욕감을 느꼈다면, 자존심이 너무 강한 것 아닐까 생각함.

    • 연 25만 달러와 추가 Google 스톡 옵션이 걸려 있다면 하루 정도 "모욕"쯤은 기꺼이 감수할 수 있음.

  • 나는 live coding screening을 '코드에 대한 대화'로 대함. 지원자에게 면접의 목적이 서로 소통이 잘 되는지 확인하는 것임을 분명히 함. 실력만 좋은 걸로는 부족하고, 함께 협업할 수 있어야 함. 예를 들어, 대화 과정에서 오해로 잘못 구현하거나, 아무리 코드 잘 짜도 기술 대화가 불가능한 지원자라면 문제임. 그래서 Fizzbuzz 유형의 질문이 중요한 이유는 단순하게 실력이 아니라 '기술적 논의' 능력을 테스트하는 역할임.

    • 맞음. live coding 인터뷰의 본질은 "문제 해결 가능 여부"가 아니라 "어떻게 해결할지 설명할 수 있는가"임. 약간의 기술적 기본기와 커뮤니케이션 능력이 핵심임. 실제 업무의 상당 부분이 비기술적 매니저에게 설명하는 일이므로, 이걸 시험한다 생각하면 됨.

    • 이런 방식이 좋음. 난 FizzBuzz를 최소 3개 언어로, 4가지 방식으로 풀 수 있고, 12가지 모두 설명할 자신 있음.

  • 나도 이 문제점을 인식하고 있고, 이렇다 할 대안이 없는 것도 동의함. 경력 속에서 정말 '엔지니어처럼 말하고 행동하는데 실제로 코딩을 못하는 사람'을 여러 번 목격함. 인터뷰에서 코딩 실력을 무시한 채 들어갔다가 후회한 적도 많았음. 어린 개발자들은 채용 과정의 여러 단계가 나이 든 지원자를 더 유리하게 만든다는 점도 이해했으면 함. 쓸데없는 '전문가' 포장에 속아 실제 코딩 능력이 없는 엔지니어가 업계에 많음을 알고 있음. 실제로 코딩 과정을 단 한 번도 안 보고 뽑는다는 건, 그냥 이력서와 대화, 참조만으로 밴드에 기타리스트를 채용하는 것과 같음. 실제로 기타를 연주해본 적이 없는 기타 전문가가 여전히 채용될 수 있음. 특별한 자격 없이도 이런 식으로 통과하는 사람들이 존재함. 면접에서 직접 증거 없이 추측만 하게 되면, 결국 편견과 선입견이 개입될 수밖에 없음.

    • "문제가 있지만 대안이 없다"는 얘기에 답하자면, 의사와 변호사처럼 자격증을 기준으로 하는 시스템도 있음. 수술 전에 시범까지 보라고 요구하지 않음. 위험도는 더 높음에도. 사실은 하위 직군에만 검증 절차가 강하고, 실제로 임팩트가 더 큰 매니저나 고위직은 더 쉽게 통과함.

    • 나는 화이트보드에 pseudocode를 작성시키는 게 더 낫다고 생각함. 문법 스트레스가 줄고, 문제 해결 논리를 더 잘 볼 수 있음. 동시에, 내 협업 방식(화이트보드에서 함께 아이디어 교환)과도 잘 맞음.

  • “스트레스는 실력과 별개”라는 현상이 반복됨. Microsoft 논문도 참혹했음. 대부분 "LeetCode만 열심히 풀라"는 식의 조언만 있는데, 스트레스(코르티솔)를 간과함. 나는 스트레스 환경 자체를 스스로 익숙하게 만드는 연습을 함. 친구들은 강도 높게 훈련시켜주지 못하고, 코치는 시급이 너무 비쌈. 그래서 요즘 Tough Tongue AI라는 사이드프로젝트를 개발 중임. 목소리로 답하는 라이브 코드 에디터에서 실시간 질문, 방해, 즉각적인 피드백을 제공함. 이 훈련으로 '누가 날 지켜본다'는 긴장감이 점점 익숙해짐. 라이브 코딩 면접이 지속된다면, 알고리즘이 아닌 생리반응(스트레스) 자체를 훈련하는 방법이 필요함.

    • 최고의 학습 도구 중 하나임.
답변달기