아직 누군가를 평가하기엔 부족한 부분이 많다고 생각하지만, 채용 인터뷰를 하면서 느꼈던 것들을 짧게나마 적어보았습니다.
1. 면접관이 생각하는 나는 이력서에 쓰여진 나다.
면접관은 면접자가 어떤 사람인지 모르기 때문에 인터뷰에서 면접관이 질문하는 내용은 이력서에 쓰여진 것을 기초로 할 수 밖에 없습니다. 면접자가 알고리즘 대회 경력을 이력서에 기재했다면 알고리즘을 물어보는게 당연하고, 인공지능에 관한 프로젝트를 진행했다면 인공지능에 관련한 질문을 할 것입니다.
이력서를 작성할 때 자신이 그동안 진행해왔던 프로젝트를 모두 기재하는건 당연한 일이지만, 애초에 그 프로젝트를 내 것으로 소화를 시키지 못했다면 질문에 대한 대답이 부족할 수밖에 없습니다. 결국엔 내가 했지만, 내가 하지 않은 것 같은 프로젝트가 되는 이상한 현상이 생길 수 있습니다. 따라서 그동안 해왔던 모든 프로젝트를 명시하는 것보다 자신의 역량을 보여줄 수 있는 프로젝트를 간추려 기재하는 것이 좋습니다. 그리고 프로젝트를 설명할 공간이 있다면, 자신이 기여한 부분을 조금이라도 명시해 주세요.
경력 5년 이내 개발자의 경우, 이력서는 최대한 압축해서 1장으로 요약하는 것이 좋습니다. 이력서 작성은 아웃사이더님의 이력서에 관한 포스팅 을 참고하세요!
2. 기술에 관련해서는 “왜”를 생각해보자.
면접관: “이력서를 보니 RxJava, Realm, React 등 신기술에 관심이 많으신거 같은데, RxJava로 개발하신 이유가 있을까요?”
면접자: “요즘 유행하고 좋아 보여서 사용했습니다.”
저도 한때 알려주는 사람 한 명 없었기 때문에 이것이 옳은 방향인 줄 알았습니다. “나 그거 해봤다, 이거 써봤다”. 겉으로 보면 무언가 많이 해 본 대단한 사람처럼 보이지만, “그거 왜 썼어? 그게 저거랑 다른 점이 뭐야?” 라는 질문에 명확한 대답을 하지 못했습니다. 이 상황이 이어지면 1번 항목에서 말했던 내가 했지만 내가 하지 않은 것 같은 프로젝트가 될 수 있습니다.
이와 같은 상황을 피하는 동시에 우리는 더 나은 엔지니어가 되기 위해 기술에 관련해서 “왜” 를 질문해야 합니다. “요즘 함수형이 좋다니까 Scala로 해봐야지, 리액티브가 대세니까 RxJava 해봐야지”라고 하기 전에 “함수형 패러다임이 좋다는데 왜 좋을까?, 리액티브 프로그래밍이 좋다는데 왜 좋을까?”라고 생각해 보아야 합니다. 행동에 앞서 “왜”라는 습관을 지니게 된다면 단순히 “Scala, RxJava 해봤다.”가 아닌, “함수나 모듈에 사이드 이펙트를 최소화하고 동시성을 고려하기 위해 함수형 프로그래밍을 도입하게 되었습니다, 비동기 코드가 많아지면 제어의 흐름이 복잡하게 얽혀 코드를 예측하기 어려우므로 Reactive programming을 통해 이를 해결해 보고자 적용하게 되었습니다.”와 같은 대답을 할 수 있는 능력이 자연스럽게 생길 것입니다.
기술에 대한 책임은 엔지니어에 있습니다. 내가 프로젝트에 왜 이 기술을 선택했는지, 더 나은 선택지는 없었는지 고민해봐야 합니다. 신입/주니어 개발자에게 기술에 대한 책임을 묻는다는게 이상하게 들릴 수 있지만, 훌륭한 시니어 엔지니어로 성장하기 위해서는 미리 준비해야 할 부분이라고 생각합니다.
3. 모든 질문에 정해진 정답이 있는건 아니다.
면접관: “이 프로젝트에서 고생했던 이슈가 있었나요?”
면접자: “리스트뷰를 렌더링하는 부분에서 가끔씩 로딩이 생기는 현상이 발생했었습니다.”
면접관: “그 문제와 관련해서 클라이언트의 리스트뷰에 문제가 있을 수도 있고, 클라이언트가 서버에 데이터 요청를 보낼 때, 서버가 클라이언트에 응답을 보낼 때, 서버가 데이터베이스에서 데이터를 가져올 때 등을 생각해볼 수 있을텐데 어떤 부분이 문제였다고 생각하시나요?”
면접관이 하는 모든 질문이 정답을 확인하기 위함은 아닙니다. 예를 들어, “Quick sort의 시간복잡도는 무엇입니까?” 등의 질문은 정답이 명확한 것이지만, 그동안 진행했던 프로젝트에 대한 질문이나 손코딩 등은 면접자가 어떠한 방식으로 문제를 해결해 나가는지 보기 위함입니다. 그렇기 때문에 질문에 대답할 때에는 자신감을 가지고 소신껏 대답하는게 중요합니다(모르는걸 아는척 하라는 말이 아닙니다).
손코딩의 경우, 처음부터 완벽한 코드를 작성할 필요가 없습니다. 예를 들어, “주어진 배열에서 2번째 큰 수를 찾는 함수를 작성하라.”라는 문제가 주어졌을 경우, 변경될 요구 사항을 고려하여 n번째 큰 수를 인자로 받아서 n번째 큰 수를 리턴하는 함수를 처음부터 작성하면 좋겠지만 그럴 필요가 없다는 것입니다. 문제가 주어졌을 때 처음부터 최적의 코드를 짜야겠다고 조용히 생각하고 있기 보다는 차근차근 해결해 나가는 모습을 보여준다면 더 좋은 인상을 줄 수 있습니다. 그리고 데이터 타입이 Signed인지 Unsigned인지, Null이나 예외 사항이 있을 수 있는지, sort()와 같은 라이브러리를 사용해도 되는지 등 면접관에게 질문해보면 좋습니다.