Learnings from conducting ~1,000 interviews at Amazon
Learnings from conducting ~1,000 interviews at Amazon shares key learnings about behavioral interviews, emphasizing that how candidates present themselves and their fit with the role and company are crucial for securing an offer, often outweighing technical skills alone.
- 아마존에서 17년간 근무하며 약 1,000번의 면접(그 중 약 600회는 Bar Raiser 면접)을 진행한 경험을 바탕으로, 기술 면접보다 행동 면접이 채용 결정에 미치는 영향을 분석한 내용
- 기술적으로 뛰어난 후보자가 탈락하는 주된 이유는 기술 부족이 아니라 자기 표현 방식의 문제
- 면접 준비 시간의 95%를 기술 준비에 투자하는 반면, 행동 면접 준비에는 거의 시간을 쓰지 않는 것이 가장 큰 맹점
- 면접은 시험이 아니라 "이 사람과 함께 일하고 싶은가"를 판단하는 오디션에 가까움
- 기업이 행동 면접에서 평가하는 핵심은 역할 적합성, 조직 적합성, 그리고 레벨 판단이며, 이를 이해하면 더 나은 스토리를 선택할 수 있음
Bar Raiser 면접에서 발견한 핵심 패턴
- Bar Raiser는 채용 팀 외부에서 참여하는 특별 훈련된 면접관으로, 신규 채용자가 Amazon의 인재 수준을 높이는지 확인하는 역할
- 모든 후보자에 대한 거부권을 가지며, 인턴부터 Principal Engineer까지 모든 레벨의 면접 루프에 참여
- 약 50회의 Bar Raiser 면접 이후 명확해진 패턴: 오퍼를 받지 못한 후보자 대부분은 기술 역량 부족이 아니라 자기 표현 실패가 원인
- 최종 라운드에 도달한 시점에서 기술 스크린이나 과제는 이미 통과한 상태이므로, 최종 라운드의 핵심 질문은 "이 팀이 이 사람과 함께 일하고 싶은가"
-
교훈 1: 한쪽 면접에는 과도하게, 다른 쪽에는 준비 부족
- 평균적인 후보자는 기술 준비에 95%, 나머지에 5% 의 시간을 투자하며, 일부는 비기술 준비에 아예 시간을 쓰지 않음
- 기술 준비는 구체적이고 진행 상황을 측정할 수 있어 매력적이지만, 코딩 문제는 처음 보는 문제도 힌트를 받아 추론할 수 있음
- 반면 행동 면접에서 "프로젝트가 잘못됐을 때 어떻게 대처했는지" 같은 질문에 준비된 스토리가 없으면 즉흥으로 대응 불가
- 힌트도 없고, 실시간 추론도 불가능하며, 준비 없이는 두서없는 답변으로 이어짐
- 코딩 라운드를 잘 통과한 후보자가 경험 관련 질문에서 무너지는 패턴을 수백 번 목격
- 디브리프에서의 피드백: "구체적인 답변을 얻을 수 없었고, 모든 스토리가 모호하고 설득력이 없었다"
- 비기술 준비는 기술 준비보다 훨씬 적은 시간이 소요: 80~100시간의 면접 준비 중 주말 하나(약 10시간)만 스토리 준비에 투자해도 행동 면접 결과가 완전히 달라질 수 있음
- 기술 준비의 수익은 급격히 체감 감소하지만, 스토리 준비의 수익은 거의 아무도 하지 않기 때문에 기하급수적
-
교훈 2: 스토리의 전달 방식이 스토리 자체만큼 중요
- 가장 인상적인 업적도 나쁜 전달로 완전히 낭비 가능하며, 가장 흔한 실패 패턴은 "ramble and stumble"(두서없이 더듬기)
- 후보자가 이야기하면서 스토리를 그 자리에서 구성하는 것처럼 보이거나, 5분간 맥락을 설명한 뒤 다시 빠뜨린 세부사항을 추가하는 경우
- 중요한 업무 프레젠테이션은 구조, 흐름, 핵심 포인트를 준비하고 리허설하지만, 면접에서는 즉흥으로 임하는 사람이 많음
- 면접 스토리 준비가 "부자연스럽다"거나 "속임수"라고 느끼는 경향이 있지만, 음악가가 콘서트 전 리허설하듯 연습은 진정성과 무관
- 실천 방법: "자기소개"와 "왜 이 회사에서 일하고 싶은가" 두 질문부터 시작
- 답변을 작성하고, 녹화하고, 녹화를 보며 어디서 장황해지는지, 불필요한 말버릇이 있는지 확인
- "이 사람과 함께 일하고 싶다"고 느끼게 될 때까지 반복
- 30분의 이런 연습이 20시간의 코딩 연습보다 면접 성과를 더 크게 향상시킬 수 있음
- 가장 인상적인 업적도 나쁜 전달로 완전히 낭비 가능하며, 가장 흔한 실패 패턴은 "ramble and stumble"(두서없이 더듬기)
-
교훈 3: 면접은 함께 일하는 것이 어떨지를 보여주는 오디션
- 대부분의 후보자는 면접을 시험으로 생각하지만, 정답지가 있는 것이 아니라 면접관이 인상을 형성하는 과정
- Bar Raiser의 구체적 역할은 후보자가 해당 직무에서 이미 있는 직원의 상위 50%보다 나은지 판단하는 것
- 면접에서 묻는 코딩 문제는 실제 업무와 다르지만, 행동 질문은 매일 겪는 상황(의견 충돌 해결, 프로젝트 위기 대응, 불완전한 정보로 결정하기)을 직접 테스트
- "이해관계자에게 반대 의견을 제시한 경험"을 물을 때, 면접관은 다음 기획 회의에서 그 사람을 상상
- 팀 내 갈등 대처를 설명할 때, "이 사람과 같은 방에 있고 싶은가"를 자문
- 시험처럼 접근하는 후보자는 면접관이 듣고 싶어하는 답을 추측해 매끄럽고 거친 부분 없는 답변을 제공
- 결과: "이 사람과 실제로 일하면 어떨지 전혀 파악이 안 된다"는 불확실성 → 대부분 "No"
- 실천 방법: 면접관이 듣고 싶어하는 것이 아니라, 자신의 팀에 합류하려는 사람에게서 듣고 싶은 것을 기준으로 스토리 준비
- 어려웠던 부분과 아슬아슬했던 판단을 포함한 실제 버전을 솔직하게 전달
약 1,000회 면접의 핵심 결론
- 채용되는 사람은 방에 들어와서 자신의 업무와 역량에 대해 명확한 스토리를 전달하고, 면접관이 "이 사람과 함께 일하고 싶다"고 느끼게 하는 사람
- 스토리 전달 능력은 연습을 통해 향상되는 기술이며, 대부분의 사람은 이것이 준비 가능한 영역이라고 생각하지 않기 때문에 연습하지 않음
- 약간의 준비만으로 경력에서 할 수 있는 거의 모든 다른 것보다 더 큰 효과
기업이 행동 면접에서 찾는 것
- 기술 역량만으로는 오퍼가 결정되지 않으며, 기업은 행동 면접을 통해 두 가지 핵심 질문에 답변: "역할과 회사에 적합한가?" 와 "어떤 레벨에서 가장 효과적인가?"
- 적합성(fit)이 맞지 않으면 기술이 뛰어나도 탈락하고, 레벨 판단이 틀리면 다운레벨 또는 자격 미달로 거절
-
적합성 이해: 역할 적합성과 조직 적합성
- 역할 적합성(Role Fit): 해당 포지션의 특정 도전과 업무 조건을 감당할 수 있는지 여부
- 빠르게 성장하는 스타트업의 백엔드 역할과 대기업의 백엔드 역할은 기술은 비슷해도 요구사항이 다름
- 조직 적합성(Company Fit): 해당 조직의 환경에서 성공할 수 있는지 여부
- 업무 스타일, 의사결정 방식, 가치관이 회사의 업무 방식과 일치하는지 평가
- 역할 적합성(Role Fit): 해당 포지션의 특정 도전과 업무 조건을 감당할 수 있는지 여부
-
기업이 적합성 신호를 감지하는 방법
- "우리 회사에 맞나요?"라는 직접 질문은 불가능하므로, 후보자 스토리에서 정렬 또는 불일치 신호를 탐색
- 역할 적합성 신호: 모호한 요구사항을 다루는 편안함, 팀 간 조율 능력, 빠른 반복과 피드백 반영 등
- 조직 적합성 신호: 후보자의 선택과 그 설명 방식에서 드러남
- "bias for action"을 중시하는 회사는 불완전한 정보에도 빠르게 움직인 스토리를 선호
- "customer obsession"을 중시하는 회사는 사용자 니즈를 깊이 파고든 사례를 원함
- "radical transparency"를 강조하는 회사는 불편하더라도 정보를 공개적으로 공유한 스토리를 탐색
- 동일한 스토리가 회사에 따라 다른 신호를 보냄: 3주간 솔루션을 완벽히 다듬은 사례가 한 회사에서는 품질 중시, 다른 회사에서는 분석 마비로 해석 가능
-
흔한 부적합(Mis-Fit) 유형
- 독립성 vs. 협업: 혼자 문제를 해결하고 돌아오는 스타일 vs. 매 단계에서 팀을 참여시키는 스타일
- 모든 스토리가 단독 작업이면 합의 중심 기업에서 우려, 반대로 모든 스토리가 그룹 확인이면 개인 소유권 중시 기업에서 우려
- 속도 vs. 철저함: 스타트업의 빠른 실험과 MVP vs. 의료·금융 분야의 신중한 검증
- 코드 품질에 대한 관점 차이도 포함: 깔끔한 아키텍처에 추가 시간 투자 vs. 기한 내 작동하는 솔루션 우선
- 탁월함 vs. 실용주의: 기술적 완벽함과 깔끔한 아키텍처 최우선 vs. 불완전해도 기한 내 출시하는 실용적 솔루션
- 혁신 vs. 안정성: 새로운 솔루션 창출과 기존 방식 도전 vs. 검증된 시스템 유지·최적화
- 직설적 vs. 외교적: 생각을 그대로 말하는 radical candor 문화 vs. 조화와 체면 유지를 중시하는 문화
- 데이터 vs. 직관: 모든 결정에 데이터 근거를 요구하는 문화 vs. 경험 기반 판단을 신뢰하는 문화
- 전문가 vs. 제너럴리스트: 대기업의 한 도메인 깊은 전문성 vs. 소규모 회사의 다양한 역할 수행 능력
- 독립성 vs. 협업: 혼자 문제를 해결하고 돌아오는 스타일 vs. 매 단계에서 팀을 참여시키는 스타일
레벨을 결정하는 4가지 차원
- 모든 스토리에서 나타나는 네 가지 차원을 통해 후보자의 레벨을 평가하며, 이 차원들이 함께 가장 효과적으로 운영되는 위치를 보여줌
-
Scope (범위)
- 작업이 영향을 미치는 사람의 수와 범위를 측정
- Entry Level: 개인 생산성 향상, 소수 팀원에게 도움
- Mid Level: 팀 운영 방식의 일부에 영향
- Senior Level: 전체 팀에 직접 영향, 최소 한 개의 다른 팀에 영향력 확장 시작, 프로덕트·디자인 파트너와 긴밀 협업
- Staff Level: 최소 두 개 팀에 직접 영향, 더 넓은 조직으로 확장, 엔지니어링 너머 프로덕트·디자인·프로그램 관리 영역까지 영향
- Principal Level: 다수 팀 또는 조직의 대규모 부문 운영 방식 변경, 비즈니스 전략까지 영향력 확장
-
Contribution (기여)
- "나"와 "우리"의 경계를 명확히 구분하여 본인이 실제로 한 일을 측정
- Entry Level: 할당된 작업 수행, 잘 정의된 기능에 대한 완전한 책임
- Mid Level: 문제 식별부터 구현까지 완전한 솔루션 소유, 동시에 다른 사람 안내
- Senior Level: 조율이 필요한 이니셔티브 주도, 요구사항이 불명확하거나 방향이 불확실한 상황에서도 진전
- Staff Level: 팀 간 이니셔티브 주도, 기술 방향 수립, 이해관계자 우선순위가 상충하는 상황 대응
- Principal Level: 조직 역량 창출, 새로운 업무 방식 수립, 문제 자체를 정의해야 하는 고도로 모호한 환경에서 활동
-
Impact (영향력)
- 작업 결과로 무엇이 더 나아졌는지 보여주며, 기술적 성과를 비즈니스·사용자 결과에 연결하는 숫자 포함이 중요
- Entry Level: 개인 생산성 향상, 반복 작업 시간 단축, 버그 방지 등
- Mid Level: 특정 영역에서 팀 효과성 향상, 배포 시간 단축, 도구 생성 등의 정량화 가능한 개선
- Senior Level: 전체 팀 업무 방식 변화, 인접 팀으로 확산, 제품 결과·사용자 경험·운영 비용까지 영향 확장
- Staff Level: 여러 팀 운영 개선, 매출·고객 유지·출시 속도 등 비즈니스 지표와 연결 가능한 영향
- Principal Level: 조직 역량 창출, 전략적 변화 주도, 비즈니스 결과와 전략적 역량으로 측정
-
Difficulty (난이도)
- 해결한 문제의 복잡성, 제약 조건, 트레이드오프를 반영하며, 큰 영향의 쉬운 문제보다 잘 해결한 어려운 문제가 더 인상적
- Entry Level: 확립된 패턴 내 직관적인 문제, 새로운 기술 학습이나 익숙하지 않은 코드 디버깅 수준
- Mid Level: 움직이는 부분이 더 많고 해결책이 덜 명확한 문제, 상충하는 요구사항이나 이전에 보지 못한 기술적 복잡성 처리
- Senior Level: 여러 시스템이 상호작용하는 제약 관리, 팀 수준 아키텍처 결정, 기술적·비즈니스 요소 모두 고려 필요
- Staff Level: 여러 팀에 걸쳐 상충하는 트레이드오프 관리, 팀들이 진정으로 충돌하는 니즈를 가질 때 다양한 기술적 접근법 균형 조정
- Principal Level: 조직적 니즈 간 근본적 트레이드오프 처리, 확립된 패턴이나 선례가 없는 새로운 문제 해결, 경영진 승인이 필요한 회사 전략 수준의 결정
기업이 진정으로 중시하는 것 리서치하기
- 완벽한 정보는 불가능하지만, 약간의 집중적 리서치로 대부분의 다른 후보자가 놓치는 인사이트 확보 가능
-
리크루터 활용
- 대부분의 후보자가 리크루터를 단순 관문으로 취급하지만, 실제로는 최고의 내부 정보원
- 리크루터의 성과는 후보자의 수락된 오퍼 수에 기반하므로 후보자의 성공을 원함
- 직접 질문할 것: "이 회사의 현재 도전은 무엇인가?", "이 역할에서 가장 중요한 역량은?", "면접 준비 자료를 공유해줄 수 있는가?"
- 준비 자료의 예시 질문은 실제 면접에서 물어볼 가능성이 높음
-
공개 정보 활용
- 채용 공고에서 반복되는 단어가 기업의 중시 사항을 드러냄: "fast-paced"와 "compliance"는 매우 다른 신호
- 확인할 곳: 엔지니어링 블로그(어떤 성과를 축하하는지), 테크 토크·컨퍼런스(발표 주제), 오픈소스 기여(무엇을 공개하는지), 기술 문서(공개 API 문서의 품질), 상태 페이지·포스트모템(실패에서 학습하는 문화 여부)
- 엔지니어링 블로그가 없어도 제품 출시 패턴(개발 속도)과 기술 선택(혁신 vs. 안정성)에서 우선순위 파악 가능
-
토론 패턴 분석
- Glassdoor, Blind, Reddit에서 개별 불만은 무시하고, 여러 게시물에 걸친 패턴 탐색
- "회의가 너무 많다"는 불만은 협업·합의 중심 문화 또는 과도한 회의로 인한 생산성 저해를 시사
- "자율성" 칭찬은 의사결정 시 확인 없이 신뢰받는 환경 시사
-
현직자 대화
- 표면적 문화 질문 대신 구체적 질문 필요
- "승진하는 사람들은 무엇을 해서 승진했는가?"
- "어떤 행동이 부정적 피드백을 받는가?"
- "의견 충돌 시 팀은 어떻게 결정하는가?"
- "여기서 일하며 가장 놀란 점은?"
- 현직자는 회사 웹사이트에서 절대 알 수 없는 진실을 전달: "customer obsession"이 실제로는 코드 작성 전 사용 데이터 확인을 의미하거나, "ownership"이 새벽 2시에 프로덕션 이슈 해결 대기를 의미할 수 있음
- 표면적 문화 질문 대신 구체적 질문 필요
-
리서치의 궁극적 목적
- 모든 리서치는 하나의 목적: 면접에서 공감을 얻을 스토리가 무엇인지 파악
- 속도를 중시하면 빠르게 출시하고 반복한 스토리 강조, 기술 깊이를 중시하면 근본 원인을 파고든 사례 강조, 협업을 중시하면 팀 간 작업에 초점
- 리서치는 자신에게 맞는 회사인지 판단하는 데도 도움: 자연스럽게 보여주지 않거나 개발하고 싶지 않은 행동을 가치 있게 여기는 회사라면 해당 역할 추구가 불필요할 수 있음
종합
- 기업은 업무 수행 가능 여부뿐 아니라, 특정 환경에서의 성공 가능성과 가장 효과적인 레벨을 평가
- 적합성 이해는 회사의 가치관과 가장 잘 연결되는 경험을 선택하는 데 도움
- 레벨 이해는 스토리를 적절히 포지셔닝하는 데 도움: 동일 프로젝트도 실제 기여와 프레이밍에 따라 entry-level 실행, mid-level 소유권, senior-level 리더십으로 다르게 보임
- 목표는 아무 오퍼가 아니라, 성공을 보장하는 적합한 회사에서 적합한 레벨의 적합한 오퍼를 받는 것