면접관이 세부까지 파고들 때, 내가 만든 프로젝트를 설명하는 법

당신의 프로젝트입니다. 코드 대부분을 직접 썼고, 가장 골치 아픈 버그를 새벽 2시에 고쳤고, 그 자리의 누구보다 잘 압니다. 그래서 면접관이 캐시를 왜 그런 방식으로 무효화하느냐고 물었을 때, 당연하게 느껴졌던 답이 문장 중간에서 무너지면 크게 당황하게 됩니다.

심리학자들은 이 틈을 측정했고, 그 원리를 알면 대비하기가 훨씬 쉬워집니다.

내 일을 설명하기 어려운 이유

잘 알려진 연구에서 Leonid Rozenblit과 Frank Keil은 예일 대학교 대학원생들에게 지퍼, 수세식 변기, 실린더 자물쇠, 헬리콥터 같은 일상적인 장치를 얼마나 잘 이해하는지 7점 척도로 평가하게 했습니다. 이어서 학생들은 각각이 어떻게 작동하는지 단계별로 설명을 쓰고, 이해도를 다시 평가했습니다. 점수는 떨어졌습니다. 실린더 자물쇠를 어떻게 따는지처럼 작동 원리를 진짜로 알아야 답할 수 있는 진단 질문 뒤에는 더 떨어졌습니다. 마지막으로 학생들이 전문가의 설명을 읽고 원래 얼마나 알았는지 돌아보며 평가했을 때도, 점수는 낮은 채로 남았습니다. 처음의 이해한다는 느낌이 그저 너무 높았던 것입니다(Rozenblit과 Keil, 2002).

저자들은 이를 설명 깊이의 착각이라고 부릅니다. 이 착각은 사실, 절차, 이야기보다 설명에서 훨씬 강하게 나타났고, 저자들이 든 이유는 소프트웨어 프로젝트에 놀랄 만큼 잘 들어맞습니다. 작업하는 동안에는 시스템이 눈앞에 있어서, 찾아볼 수 있는 것을 안다고 느낍니다. 위층을 이해하면 아래층도 안다고 여깁니다. 전체를 처음부터 끝까지 설명할 일이 거의 없어서, 자기 설명이 어디서 끊기는지 알게 될 기회가 없습니다.

면접이 묻는 것이 바로 그 진단 질문입니다.

면접관이 파고드는 것

Amazon의 채용 담당자들은 가장 흔한 실수를 직설적으로 말합니다. 지원자가 충분히 깊이 들어가지 않는다는 것입니다. 질문마다 하나의 상황을 숫자, 그 프로젝트에 참여한 사람들, 낸 성과와 함께 자세히 이야기해 달라고 합니다. 또 면접은 당신이 무엇을 했는지 알기 위한 자리이므로, 행동은 1인칭으로 설명해 달라고 합니다(Amazon 채용 담당자). 이 회사의 리더십 원칙 중 하나인 Dive Deep은 세부 사항을 계속 파악하고 있을 것을 요구합니다(Amazon).

어디서 면접을 보든 같은 형태를 예상하세요. 당신이 짧게 전체를 설명하면, 면접관이 한 단계씩 더 깊어지는 질문을 이어 갑니다. 전체 설명은 쉬운 부분이고, 평가는 꼬리 질문에서 이뤄집니다.

2분짜리 프로젝트 설명

문제와 그 문제로 불편을 겪은 사람들로 시작하세요. 어렵게 만든 제약을 포함해 한두 문장이면 됩니다.

환자 포털의 검색에 1초 가까이 걸렸고, 봄 배포 이후 관련 문의가 두 배가 됐습니다.

내가 맡은 것과 다른 사람이 한 것을 각각 한 문장으로 말합니다. 2분의 대부분은 두세 가지 결정에 쓰고, 결정마다 택하지 않은 방안을 함께 말합니다. 택하지 않은 방안이 있는 결정은 판단력을 보여 주고, 도구 목록은 아무것도 보여 주지 못합니다.

복제본을 늘릴 수도 있었습니다. 느린 부분은 랭킹이었고 복제본은 읽기에만 도움이 되기 때문에, 미리 계산한 인덱스를 택했습니다.

결과와 숫자, 그리고 바꾸고 싶은 점으로 마무리합니다.

p95가 약 800밀리초에서 200밀리초 미만으로 줄었습니다. 다시 한다면 인덱스를 다시 만드는 작업에 처음부터 백프레셔를 넣겠습니다.

거기서 멈추고, 어느 실마리를 따라갈지는 면접관이 고르게 하세요.

꼬리 질문에 대비하기

프로젝트를 깊이 파고드는 자리에서 거의 매번 나오는 꼬리 질문이 몇 가지 있고, 하나하나 면접 전에 한두 문장으로 답을 적어 둘 만합니다. 면접관은 왜 이 설계를 골랐고 뻔한 다른 방안은 왜 택하지 않았는지, 가장 어려웠던 버그는 무엇이었고 어떻게 찾았는지, 잘 작동한다는 것을 어떻게 알았고 무엇을 측정했는지 묻습니다. 의존하는 서비스가 멈추거나 작업이 중간에 다시 시작되거나 입력이 10배로 커지면 어떻게 되는지, 어떤 부분을 직접 쓰고 결정하고 검토했는지, 다시 한다면 무엇을 바꾸겠는지도 묻습니다.

Rozenblit과 Keil의 테스트는 자신에게도 똑같이 쓸 수 있습니다. 프로젝트의 핵심 흐름, 예를 들어 요청 하나나 작업 하나의 처음부터 끝까지를 골라, 코드를 열지 않고 단계별로 적습니다. 서비스가 중간에 다시 시작되면 어떻게 되는가 같은 진단 질문을 하나 덧붙여 답합니다. 망설인 곳은 모두 곧 받게 될 꼬리 질문입니다. 코드를 열어 빈 곳을 메우고, 소리 내어 말할 수 있는 한 문장으로 답을 적어 두세요.

좋은 프로젝트를 망치는 실수

가장 흔한 실수는 기술 이름을 나열하는 것입니다. React, Node, Postgres, Redis라는 이름은 당신이 어떻게 생각하는지 알려 주지 못합니다. 두 번째로 흔한 실수는 처음부터 끝까지 팀 전체를 대신해 말하는 것인데, 당신은 자기 부분을 이야기하러 온 것입니다. 숫자가 한 번도 나오지 않는 설명도 많습니다. 지연 시간, 사용자 수, 금액, 줄인 시간, 오류율 중 하나면 충분합니다. 실제보다 많은 일을 자기 것이라고 하는 사람도 있지만, 다음 질문은 한 단계 더 깊어집니다. 모든 구성 요소를 설명하는 사람도 있습니다. 가장 흥미로운 결정을 담은 두 가지를 고르고, 나머지는 질문에 맡기세요.

파일에 일의 일부를 맡기기

저희가 Prepped를 만든 이유 중 하나가 이것입니다. Prepped의 면접에 프로젝트 폴더나 GitHub 저장소를 추가하면, 준비 단계에서 파일을 읽고 코드에 대해 받을 만한 질문의 답을 각각 어느 파일에서 나왔는지 밝히며 초안으로 씁니다. 파일이 뒷받침하지 않는 내용에는 표시가 붙어서, 무엇을 확인해야 할지 알 수 있습니다. 면접 질문집에는 문제, 내 역할, 주요 결정, 결과로 이뤄진 프로젝트 설명 구성도 있어서, 설명이 2분 안에 들어올 때까지 연습할 수 있습니다.