Amazon 본사 면접후기: 리더십에 관한 질문들은 어떻게 대답을 해야하나?
아마존의 개발자 면접과정은 다른 대기업 테크회사들과 마찬가지로 리크루터와 간단하게 전화통화후 기술전화면접으로 시작하였다. 그동안 접했던 기술전화면접들에 비해 코딩문제가 조금 어려운 편이었으나 그래도 주어진 시간내에 면접관의 힌트와 함께 문제를 끝마칠수 있었다. 그후 몇주 뒤 (2017년 8월) 시애틀로 최종면접을 가게 되었다.
아마존 최종면접의 특징은 개발자면접이라고 해도 아마존이 직원들에게 늘 강조하는 Leadership Principles 에 대해 모든 면접관들이 질문을 하는 것으로 유명하다. Attitude, Behavior 등에 관한 질문들인데 예를들어 (다음의 질문들이 꼭 아마존에서 물어본 질문들은 아니고 일반적으로) -
“제품개발과정에서 주요기능에 관해 어려운 결정을 내려야 했을때 어떤식으로 결정을 내렸으며 결과는 어떠하였는가?”
“제품출시 직전 제품의 중대한 결함을 발견했을때 어떤식으로 해결했는가?”
“팀내에 성과가 부진한 동료가 있을경우 어떻게 대처하였는가?” 등등.
일단 나는 아마존 최종면접에서 개발자면접의 핵심인 코딩문제들을 제대로 풀지 못했다. 이런경우 대부분은 불합격이다. 하지만 결과는 합격. 나중에 리쿠르터, Hiring manager 와 얘기했는데 리더십과 소프트웨어 설계에 관한 질문들, 특히 리더십, 에 대한 평가가 매우 좋았다는 피드백을 받았다.
여하튼 다시 리더십에 관한 질문으로 돌아가서 이런 질문들이 나올 때에는 논란이 일어나거나 한쪽으로 치우치게 되는 대답을 하기 쉽다는 것. 가령 다음의 질문을 예로 들어보자.
(참고로 다음의 질문이 꼭 아마존에서 나온 질문은 아니다. 큰 틀에서 비슷한 유형의 문제임을 밝힌다.)
“3개월 뒤에 제품을 출시해야 하는데 워낙에 버그(문제)가 많아서 현재 스케쥴로는 품질의 희생이 불가피하다.어떻게 할것인가?”
위의 질문에 일반적인 선택은 -
- 버그가 좀 있어도 고객들과의 약속이 있으니 약속한 날에 출시를 한다.
- 제품의 품질은 절대 양보할수 없다. 출시가 늦어지더라도 제품을 완벽하게 만들겠다.
문제는 위의 답들중 어느쪽으로 대답하더라도 결국 다른쪽으로는 논란이 일어날수 있다는 것. 가령 1번으로 대답할 경우에 “품질이 떨어지는 제품을 출시해도 괜찮다는 거냐?” 라는 반문에 대답을 해야하고 2번으로 대답할 경우에 “고객들과의 약속을 져버려서 신뢰를 잃어도 괜찮다는 거냐?” 라는 반문이 올수 있다는 것. 아마존의 Leadership Principles 과 빚대어서는 1번으로 대답을 하면 “Insist on the Highest Standards” 를 어기는 것이고 2번으로 대답을 하면 “Earn Trust” 혹은 “Deliver Results” 를 어기게 되는 것.
이 질문에서 처음에 가장 안전하고 면접관의 입장에서 옳은 대답은 우수한 품질의 제품도 만들고 출시일도 맞추어 두마리의 토끼를 다 잡는것. 어떻게 하면 이렇게 하는 것이 가능한지를 얘기하고 비슷한 상황에 처해서 문제를 해결했던 자신의 경험을 얘기하는 것이 가장 좋은 시작이라고 볼수 있다. 나는 다음과 같이 말하면서 대답을 시작 -
“The goal should be to meet the deadline with the highest quality of a product. Delivering a product on time and with the highest quality are just two things that cannot be compromised in my book.”
일단 위와같이 대답해서 대충 ‘나는 둘중 어떤것도 포기할수 없는 사람이다’ 라는 전제를 깔아놓고,
“… At the same time, how you go about doing it sometimes can be tricky. But if you put in the right plans and resources, it can be done. For example, as soon as you or your team finds out that the current schedule doesn’t allow you to deliver the product on time, one thing you can do is to re-evaluate the product specs and reprioritize the features to see if some of those features can be pushed back or slimmed-down. Or sometimes, given a problem, there is more than one solution. So you have to take a step back to see if a different, but more efficient and quicker, solution can be implemented to achieve the same results for certain features.”
단순히 의욕만 있어서 될일도 아니니까 평소 자신이 쓰던 1–2개 방법론을 위와 같이 high level 에서 얘기하는 것으로 시작. 그리고 자신의 ‘실제' 경험을 아래와 같이 진솔하게 얘기한다.
“…When I was working on (a project), that was exactly what happened. We initially started with 6 engineers to build this client application in 6 months. It was already a very aggressive schedule. But two months into the project, two most senior engineers left the team and I took over the team as a tech-lead. At that time, it was clear to me that it would be impossible to meet the deadline if we continue our path. So I sat down one day and analyzed all remaining features to develop. I quantified all of them with metrics such as the amount of resource needed, the impact, and found out if there is an alternative, but quicker, solution to implement for some of those features. So I managed to come up with a reasonable, but still very aggressive, feature set that if we execute with near-perfection, it can be done. I pushed back some features which were simply bonus features that only few people cared about. For some features, I came up with an alternative solution for speedy implementation. In this case, it was to use 3rd party cloud and client database instead of using our own. Then, I met with everyone involved in the project, including my managers, sales, and marketing, to set the right expectation with them and have everyone on the same page...”
위의 대답후에 프로젝트 기간중 어떠한 decision-making framework 로 중대결정들을 내리고, 이런 비상상황시 어떠한 커뮤니케이션 프로토콜을 따르고, 어떻게 리소스의 재분배 최적화를 이루었는지에 대해서도 장시간 얘기를 하였지만 글이 너무 길어지므로 여기서는 생략한다. 간단한 예는 이런 상황에서 많은 부분 개발자들과 비개발자들의 기대치 간극을 줄이는 것에 커뮤니케이션의 집중이 필요하다. 그리고 개발과정에서의 모든 변수를 수치화하여 좋은 결정을 내리는 데에 필요한 90% information + 10% intuition 의 룰을 시스템화한다 등등.
위와 같이 대답함으로써 나는 은연중에 면접관에게 다음과 같은 메세지를 전달하게 된다.
- Ownership: 어려운 상황에 처했을때 평소에 제품기획자나 매니저가 하는 일을 내가 주도해서 한다.
- Insist on the Highest Standards: 어떠한 상황에도 품질은 포기 못한다.
- Are Right, A Lot: 단순한 열정만 가지고 하는 얘기가 아니다. 좋은 결정을 내리는 나만의 확실한 프레임워크가 있고 이를 실행한다.
- Bias for Action: 주어진 문제에 평소의 경험과 지혜를 이용해 탁월한 차선책을 택하여 실행하는 능력.
- Earn Trust: 이렇게 하는 과정에서 프로젝트에 연관된 모든 사람들과의 긴밀한 커뮤니케이션을 통해 그들의 신뢰를 얻는다.
어찌보면 여기까지는 꽤 일반적이고 상식적인 대답일수도 있다. 여기서 나만의 결정타 한방 -
“And you know what? Everyone worked so hard but it wasn’t still enough. The sheer amount of work that needed to be done just overwhelmed our resources. Then, sometimes, that’s when you have to reprioritize things in your life and make some sacrifices. That’s what I did. My kid was born on Wednesday. But it was very clear to me that my extended absence would just delay the launch. Again, my kid was born on Wednesday. And I showed up at work on Friday. Sometimes, you have to make a tough choice to make things happen.”
위는 실제 얘기다. 내 아이가 수요일에 태어났는데 이틀후인 금요일부터 다시 회사에 나가서 일을 하기 시작했다. 이모습을 보고 당시 상사가 나를 “A man with steely determination (강철같은 의지력의 소유자)” 이라고 표현하였는데 당시 면접관 앞에서 스마트폰을 꺼내 여기에 관한 아래의 스크린샷을 보여줌으로써 Ownership, Dedication, Commitment, 그리고 Deliver Results 에 관한 모든 의구심을 깔끔하게 종결.
위의 예는 약간 논란의 소지가 있을수도 있다. 내가 이렇게 하니 다른 사람들에게도 비슷한 희생을 요구하는 사람이 될수가 있다는 것. 여기에 관해서 이러한 희생은 ‘It may not be sustainable but may be necessary from time to time.’, ‘It’s not reasonable to ask for the same dedication from everyone.’ 이라고 말함으로써 부가설명을 하는것으로 마무리.
그리고 마지막으로 이런 과정이 어떠한 결과로 이어졌는지에 대한 설명을 하였다. 당연히 훌륭한 품질의 제품을 출시일에 맞춘것 포함, 어떻게 기대이상의 결과를 낳았는지에 대해서도 수치에 근거한 설명이 필요하다. 이부분은 기밀사항이 포함된 내용이라 이 글에서는 생략한다.
자, 그럼 이렇게까지 대답을 했는데 마지막 순간까지도 면접관이 “그래도 도저히 스케쥴을 맞출수가 없다고 하자. 모든 리소스를 다 써도 그냥 그 자체가 완전히 불가능하다. 그렇다면 어떻게 할것이냐?” 이렇게 질문이 나올수가 있다. 이런 상황에서는 결국 부족한 품질로 출시날짜를 맞추던지 품질을 개선하고 출시를 늦추던지 둘중 하나의 답은 꼭 들어야 하겠다는 것이다. 여기서 이렇게 대답 -
“It depends. It depends on the product. It depends on the customers. It depends on the goal. I don’t think there is one right answer to this. But if you really force me to answer it one way or another, then I will have to go with the principles. The idea is to ask the right question. In this case, it would be to know which one has a long term value. Then, my answer would be to delay the launch but have the right product. It may upset some customers initially. But ultimately, a great product can do some wonders and magic. On the other hand, if you launch a product on time with a lot of bugs, people will be upset no matter what and it will ruin the company reputation. We simply cannot afford that. So I will have to go with the delayed launch with the highest quality product.”
결국 위의 리더십에 관한 질문을 요약해보면 -
- 기본적으로 제품의 품질 그리고 고객만족에 관해서는 어떠한 부분도 양보하지 않는 자세 (Work ethics)
- 어려운 문제를 풀기위해 요구되는 탁월한 결정능력 (Intelligence & Decision making)
- 위의 것들을 증명할수 있는 본인의 구체적인 경험 (Experience & Wisdom)
- 자신의 행동과 결정이 훌륭한 결과들로 이어짐 (Result-oriented)
- 때로는 탁월한 성과를 내기 위해서는 높은 IQ 만이 아닌 높은 EQ 도 가지고 있어야 한다는 것 (Attitude/Behavior/EQ)
- 그리고 최후의 순간에 하나의 결정을 해야할때는 어떠한 원칙에 의해 결정을 내릴것인가 (Principles & Values)
이처럼 리더십에 관한 질문은 위의 예처럼 리더들에게 요구되는 중요사항들을 중심으로 스토리텔링을 잘 할수 있다면 좋은 결과가 있을것이라 생각한다.
개인적으로 이런 리더십에 관한 부분은 평소에 아마존과 관계없이 자주 생각하는 부분이라 아마존 면접관들이 한 질문들은 나름 촘촘한 논리로 잘 방어했다고 생각한다.다시 말하지만 코딩문제를 못해서 불합격이라 생각했는데 운좋게 합격통보를 받고 리쿠르터와 연봉협상을 시작한다.
처음에 내가 아마존에서 개발자 면접을 보기로 한것은 지역적인 이유가 가장 큰몫을 하였다. 최근 시애틀이 아마존, 마이크로소프트를 중심으로 테크산업이 세력을 확장하고 있고 또 시애틀에 거주하는 지인들이 이구동성으로 그곳의 삶에 큰 만족을 하고 있었다. 그래서 한번 면접을 보고 혹시 합격이 된다면 그 다음에 이주결정을 하면 어떨까라는 생각으로 면접을 하였다. 그래서 아마존은 오퍼를 받은후 장고의 고민을 하였는데 결국 시애틀로 가지 않을것이라는 결론을 내리고 자연스럽게 아마존의 오퍼는 거절하게 되었다. 마지막에 리쿠르터와 실리콘밸리에 있는 아마존 지사들에서의 채용에 관해 문의했으나 아마존은 채용구조상 그러기 위해서는 처음주터 새로운 면접을 다시 해야 한다고 하더라.
이번글이 면접자들이 leadership 과 soft skills 에 관한 답을 할때 도움이 될수 있기를 바란다.
PS) 오늘은 미국이 Martin Luther King Jr. Day 로 많은 회사들의 공휴일이다. 딱 1년전에 여기에 관한 글을 쓴적이 있는데 관심있으신 분들은 다음글 참조:
