코딩 인터뷰 꼭 해야 하나?

아재 연배가 되다 보니 의도하지 않게 최근 몇년 동안은 채용을 위해 개발자의 면접관으로 참석하는 일이 많아 지고 있습니다.  면접관마다 지원자를 보는 관점과 방식은 다르겠지만 이 글에서는 제가 개발자 인터뷰를 진행할 때 주로 묻는 질문과 어떤 관점을 중점적으로 보는지 정리해보려고 합니다. 최근 제 지인분들도 인터뷰를 많이 다니고 계신데 한군데 오래 계신 분이나, 아직 경력이 짧은 분들은 인터뷰 경험도 많지 않으시기 때문에 인터뷰에 힘들어 하시는 것 같아 이 글로 조금이나마 도움이 되었으면 합니다.

다시 한번 밝히지만 채용 인터뷰는 면접관의 개인적인 취향이 강하기 때문에(물론 기업에서 가이드는 주기는 하지만...) 이글은 참고만 하시기 바랍니다.

이력서 읽기

솔직히 저는 이력서를 깊게 보지 않습니다. 특히 개인의 성장 배경, 성격 등을 설명한 자기소개 부분은 거의 읽지 않습니다. 그 부분은 지극히 자기 중심의 글이라고 생각하기 때문이기도 하고 실제 이야기를 해보지 않는 이상 파악하기 어려운 부분입니다. 많은 지원자가 자기 소개서에 가장 많이 공을 들이고 있는 것 같은데  이 부분은 채용 공고를 내는 회사에서 개선할 수도 있는 부분이라고 생각합니다. 자기 소개서를 중요하게 생각하는 회사도 있을 것이고, 저와 같이 별로 중요하게 생각하지 않는 회사도 있을 것입니다. 이 경우에는 채용 공고에 서술식의 자기 소개는 쓰지 않아도 된다고 명시하는 것도 좋다고 생각합니다.

제가 이력서에서 보는 영역은 딱 두군데 입니다. 첫번째는 인적사항, 두번째는 경력사항입니다. 인적 사항 부분에서는 나이만 봅니다. 제 자신이 다른 개발자들에 비해 나이가 많은 편이라서 나이 자체에는 의미를 두지 않습니다. 나이를 보는 이유는 경력이 몇년 정도 되었는지를 판단하기 위해서 입니다. 물론 경력사항에 기술된 내용을 보면 몇년 정도의 경력인지 볼 수 있지만 계산을 해야 하는데 귀챠니즘 때문입니다.

이력서에서 가장 중요하게 생각하는 부분이 경력 사항입니다. 다시말하면 저는 이 부분만 봅니다. 이 부분으로 면접을 봐야 할 지원자인지 아닌지를 판단합니다. 이력서의 역할은 여기서 끝입니다.  면접이 결정되면 이력서는 더 이상 중요하지 않고 면접볼때 참고 자료 정도로 활용하게 됩니다. 자와 같지 않더라고 기술 면접관의 대부분은 경력 사항을 가장 중요하게 보고 있기 때문에 경력 지원자라면 이 경력 사항 부분 작성에 많은 공을 들여야 한다고 생각합니다. 경력 사항 작성 시에는 다음 정도를 고려하시면 될 것 같습니다.

• 경력의 순서는 최신 순으로 작성 이력서를 통해 자신의 경력을 어필해야 하는데 과거 경력부터 쓰게 되면 과거 기술이 가장 먼저 눈에 들어오게 됩니다. 그리고 경력이 많은 경우 보고 싶은 최근 몇년 경력이 한참 뒤에 나오기 때문에 좋지 않습니다. 따라서 경력은 "order by date DESC" 로 작성하는 것이 좋습니다.
• 참여했던 프로젝트에 대한 간단한 소개와 자신의 역할, 프로젝트의 성과 및 자신이 프로젝트 내에 이룬 성과 중심으로 작성
• 프로젝트에서 사용한 기술이 아닌 본인이 사용했던 기술 셋 작성
• 지원하는 Position과 관련된 경력 사항은 조금 길게 지원하는 포지션과 관련된 경력은 다른 경력 사항에 비해 몇줄 정도 더 나오게 작성하여 관심을 가지게 할 수도 있습니다. 실제로 이력서 읽을 때 분량이 많은 부분에 더 강점이 있을 것 같다는 생각이 들기 때문입니다. 반대로 경력이 많은 경우 지원하는 포지션과 관련이 없고 짧은 프로젝트 경력인 경우 기술하지 않는 것이 좋을 수도 있습니다.

이력서를 쓰시는 분들은 면접관이 이력서를 깊게 보신다고 생각하는데 제 경우 아닙니다. 위에서 밝힌 경력 중심으로 쭉 읽어 본 다음에 현재 우리가 원하는 포지션에 부합되는 사람인지만 판단하고 부합되면 인터뷰 요청, 그렇지 않으면 Drop 입니다.

인터뷰 방식

인터뷰 진행 방식은 회사별, 면접관에 따라 많이 차이가 납니다. 저는 주로 다음과 같은 방식으로 인터뷰를 진행합니다.

1. 간단하게 상호 인사

면접관 소개(화사내 역할 등) 정도, 지원자 본인 소개는 그냥 인사만

2. 지원자의 긴장감을 풀어 주기 위한 멘트

저는 이 부분이 인터뷰 진행에 있어 아주 중요한 부분이라고 생각합니다. 뛰어난 실력을 가지신 분들도 인터뷰에 긴장을 해서 횡설수설 하는 경우도 많기 때문에 초반에 긴장을 풀어주는 활동을 해야 합니다. "격식을 갖추지 않는다.", "중간에 잘못 이야기 한 부분이 있으면 언제든지 정정을 할 수 있다." , "단순히 토론이라고 생각해라." 이런 식의 멘트와 긴장을 풀어 줄 수 있는 분위기를 조성합니다.

실제로 인터뷰를 보면 지나치게 긴장하시는 분들을 가끔 보게 됩니다. 긴장 때문에 땀도 많이 흘리기도 하고요. 이런 분들이 질문을 받으시면 횡설 수설하는 경향이 많습니다.  이 경우 질문을 받으면 바로 대답하지 마시고 너무 긴장해서 그렇다고 하면서 생각할 시간을 달라고 양해를 구하고 본인의 생각을 정리해서 이야기 할 수도 있습니다. 인터뷰 분위기에 따라 그렇게 할 수 없을 수도 있겠지만 최근 소프트웨어 개발직군에 대한 인터뷰는 가능한 자연스러운 분위기에서 하기 때문에 많은 회사에서는 가능하다고 생각합니다.

3. 본인 소개

어느 정도 분위기 편해지면 경력 중심의 본인 소개를 요구합니다. 이때에도 어디서 태어났으며 아버지가 뭐하시는지에 대해서는 별로 관심이 없습니다. 그리고 대학에 무슨 봉사활동을 했는지, 무슨 동아리 활동을 했는지에 대해서도 관심이 별로 없습니다. 주로 경력에 대해서만 관심을 가집니다.

이런 주변 멘트들을 말씀하시는 여러 분들이 본인 소개 시 긴장해서 떠시는 분들이 많은데 이런류의 멘트들은 정리해서 어느 정도 암기해서 하기 때문이지 않을까 생각했습니다. 이렇게 부자연스러운 본인 소개보다는 자연스럽게 이야기 할 수 있는 본인의 경력 사항 중심으로 이야기 하는 것을 권장합니다.

저는 본인 소개를 들으면서 본인 소개 이후에 어떤 질문을 하는 것이 좋을지를 생각합니다.

4. 경력에 대한 질의/응답

경력 사항에 나와 있는 내용 중 현재 포지션과 관련된 부분에 대한 질문을 합니다. 기술적인 부분이나 어떤 과제였으며 어떤 역할을 수행했는지 등에 대한 질문입니다. 이 질문을 통해 어느 정도 기술 수준이 있는 과제에 참여하였는지를 파악하고, 기술적인 부분보다는 어느 정도의 팀 규모에서 어떤 역할을 수행했으며, 어떤 방식으로 일을 했는 지 등과 같은 개발 이외의 중요한 요소에 대해 파악을 합니다.

5. 기술적인 질의/응답

해당 포지션 수행에 필요한 기술적인 질문을 하고 답변을 듣습니다. 지원자는 필요하면 화이트보드 등을 사용해서 기술을 설명할 수도 있습니다. 지원 분야에 대한 개요에 대한 지식이 있는지에 대한 질문과 일부 아주 깊게 내려간 질문 몇가지도 합니다.

질문하고 답변하고 바로 다음 질문하는 방식이 아니라 지원자의 답변에 대해 다시 질문하는 방식으로 하는 경우도 많습니다. 따라서 여기 가면 이 질문을 하더라고 해서 해당 질문에 대한 답변을 외워오시면 그 다음 질문에 당황하실 수도 있습니다.

6. 기술에 대한 생각에 대한 질의/응답

기술 자체가 아닌 기술의 학습, 사용해보지 않은 기술 사용에 대한 생각(예를 들면 Python 개발자에게 Java로 개발이 필요하면 어떻게 할 것인지 등) 등에 대해 질문을 합니다. 소프트웨어는 빠르게 변화하고 있기 때문에 계속해서 학습하거나 트렌드를 따라가야 하는데 이런 활동을 어떻게 하고 있으며, 얼마나 오픈된 생각을 가지고 있는지 확인하기 위한 질문입니다. 

7. 지원자가 궁금해 하는 사항 요청

인터뷰는 소개팅과 같아야 된다고 생각합니다. 채용을 하는 조직과 지원자가 서로 잘 맞는지를 확인하는 과정입니다. 위에서의 모든 행동들은 조직 -> 지원자로의 방향이었다면 지원자 -> 조직이 맞는지에 대해서도 판단을 할 수 있어야 합니다. 지원자가 입사전에 생각했던 조직과 입사후에 생각했던 조직이 다르다면 그 지원자는 입사후에 제대로된 업무 퍼포먼스를 낼 수 없고 오래 그 조직에 남아 있기 어렵기 때문입니다.

따라서 지원자에게 조직의 많은 정보를 제공해줘야 한다고 생각합니다. 그리고 지원자도 면접 시에 반드시 알고 싶어하는 항목을 정리해서 질문하는 것이 좋습니다. 이것은 메모해서 메모지를 보고 해도 무방하다고 생각합니다. 스타트업에 지원할 경우 "현재 비즈니스 모델이 불명확한 것 같은데 어떤 비즈니스 모델로 매출을 내려고 하느냐?"와 같은 질믄이라든지 아니면 "야근은 많이 하는가", "기획 팀과의 관계는 어떤가?", "배포 주기는 어떻게 되는가?", "조직의 구성원은 어떻게 되는가? 주니어 시니어 비율은?" 이런 식으로 궁금한 것이 있으면 모두 물어 보는 것이 좋습니다.

저 같은 경우 질문을 하지 않아도 이런 내용에 대해서는 많이 알려 주려고 합니다.

8. Closing 및 감사의 말씀

방문 및 인터뷰 답변에 대해 감사의 말씀을 드리고 인터뷰를 종료합니다.

많이 하는 질문

인터뷰 진행 중 다른 부분은 거의 정형화되어 있지만 기술적인 질문에 대한 부분은 포지션, 주니어/시니어 등에 따라 많이 달라집니다. 저는 대략 다음과 같은 질문을 이용하여 지원자의 기술적 역량을 파악합니다.

개발 사이클에 대한 설명

본인이 생각하는 전체 개발 프로세스에 대해 가능한 길게 설명해보세요.

이 질문을 통해서는 기능 기획 -> 디자인 -> 개발 -> 코드 리뷰 -> 수정/보완 -> 테스트 -> 배포 등에 이르는 전반적인 지원자의 생각과 실제 어떤 도구를 사용했는지 등을 파악할 수 있습니다.

위 질문과 비슷하게 이 글의 뒤에 나오는 여러 질문도 "가능한 길게 설명해 보세요"입니다. 이런 질문을 통해 단순히 단편적인 지식이 아닌 해당 분야의 전반적인 기술에 대해 어느 정도 수준으로 알고 있는지 파악할 수 있으며, 답변이 부족하다고 해도 추가 질문을 통해 지원자가 긴장해서나 잊어 버리고 이야기 하지 못한 부분도 쉽게 끄집어 내어 다시 답변을 받을 수 있기 때문입니다. 지원자가 자신은 이미 알고 있는데 답변에 그 내용을 넣지 않았을 수도 있기 때문에 지원자의 답변을 듣고 다음 질문을 통해 유사한 내용을 질문하게 됩니다.

이런 질문 방식의 질문 -> 답변 -> 답변 내용에 대한 질문 등의 형태는 단순히 암기를 해서는 대응하기 어려운 방식입니다. 어느 정도 경력이 있는 개발자라면 면접 인터뷰를 암기를 하거나 공부하기 보다는 자신의 경력 중심으로 준비하고 답변하는 것을 권장합니다. 인터뷰 준비도 자신의 경력 내에서 사용한 기술을 이론적으로 잘 정리하고 부족한 부분을 보완하는 형태로 준비하는 것이 바람직할 것입니다. 질문을 하는 면접관도 지원자의 경력과 동떨어진 질문보다는 연관성이 있는 질문을 하는 것이 지원자의 기술 수준을 파악하는데 더 도움이 되지 않을까 생각합니다.

빅데이터 플랫폼 관련 질문

빅데이터 플랫폼 포지션인 경우 이런 질문을 많이 합니다.

HDFS에 파일을 저장, 읽는 전체 과정을 설명하세요. MapReduce 또는 Spark에서 Job이 실행되는 전체 과정을 설명하세요.

어떤 지원자는 hdfs shell 명령을 이용하는 수준으로 답변할 수 도 있고, 어떤 지원자는 Java API에 대해 설명할 수도 있습니다. 정답은 없으며 어떤 포지션에 지원했는지에 따라 답변의 만족 수준이 다릅니다.

웹/앱 시스템 전반에 대한 설명

웹/앱 개발자 개발 포지션인 경우 다음 질문을 많이 합니다.

사용자가 브라우저(또는 앱으로) URL 또는 앱의 버튼을 클릭 했을때 화면에 결과가 나오기까지 전체 과정을 가장 길게 설명해보세요. 답변에 시간 제한은 없으며 가능한 길게 설명할 수록 좋습니다.

이 질문에서도 어떤 지원자는 아주 간단하게 답변하는 경우가 많은데 이때에는 다시 "사용자가 많아 지면 어떻게 시스템을 개선할 수 있는가.", "말씀하신 시스템에서 데이터베이스에 요청이 많은 경우 어떤 조치를 할 수 있는가?" 등 부가 질문을 통해 지원자의 경험과 기술적 수준을 파악합니다.

Spring 또는 Java 경력 위주 개발자들에 대한 질문

제가 Spring에 대한 경험이 많지 않기 때문에 세부적인 질문은 다른 분들이 하시고 저는 대략 다음과 같은 질문을 통해 지원자가 Spring에 대해 어느 정도 알고 있는지만 파악합니다.

• Spring이 무엇인가?
• Dependency Injection이란?
• 왜 Spring을 선택했는가?

일반적인 프로그램 언어에 대한 내용

• 동적 Type 언어와 정적 Type 언어의 장단점?
• ORM은 어떤 역할을 수행하는가?
• 상속과 위임의 차이

간단한 실제 프로그래밍에 대한 질문

• 파일에서 데이터를 읽어 특정 키의 갯수를 Count  또는 Sum을 해서 출력하는 프로그램
• 숫자 표기가 다른 국가를 위해 숫자 포맷을 어떻게 저장, 출력할 것인지?
• 리팩토링이란?

Why?에 대한 질문

주로 시니어 포지션인 경우 많이 하는 질문입니다.

과거 경력 중 본인이 선정한 플랫폼, 솔루션, 아키텍처가 있으면 설명하고 그렇게 선택한 이유에 대해 설명해보세요.

이 질문을 통해 기술선정 등에 있어 어떤 요소를 고려하고, 어떻게 요구사항을 만족 시켰는지에 대해 듣습니다.

코딩 인터뷰 꼭 해야 하나?

앞에서 보시는 것 처럼 제가 주로 인터뷰를 진행할 경우 코딩 중심의 인터뷰는 하지 않습니다. 물론 인터뷰 중에 실제로 pseudo code 수준으로 만들어 보는 문제는 한두개 하는 경우가 있습니다. 이런 질문도 최근 많이 하고 있는 문제와는 많이 다릅니다. 제가 코딩 인터뷰를 반대하는 이유는 다음과 같습니다.

일단 저도 잘 모릅니다.

여러 회사에서 수행하고 있다는 코딩 인터뷰에 나오는 문제들에 대해서는 저도 잘 모릅니다. 아무런 사전 지식이나 준비가 없는 상태에서 그런 문제가 나오면 제대로된 답을 만들지 못합니다. 물론 정답을 요구하지 않고 정답 풀어 나가는 과정을 본다고 하지만, 정답을 알고 있는 사람과 모르는 사람의 과정은 차이가 있습니다.

면접자도 잘 모르는데 문제를 풀어가는 과정을 평가는 것도 애매할 것 같아서 알고리즘에 대한 문제는 거의 묻지 않습니다. 정말로 알고리즘이 필요한 업무인 경우 그 기술을 아시는 분과 같이 인터뷰를 진행합니다. 그런 경우에도 알고리즘 자체에 대한 질문보다는 업무 중에 어떤 문제를 어떻게 해결했는지에 촛점을 맞추어 질문을 합니다.

정답을 요구하기 보다는 해결을 어떻게 하는지 태도나 과정을 본다고는 하지만

문제 은행 식의 코딩 인터뷰인 경우 인터뷰를 준비하면서 공부 했던 문제가 나오면 풀수 있고 아니면 풀기 어렵습니다. 풀기 어려운 문제는 그 문제를 풀어 나가는 과정도 어렵습니다. 면접관에게는 그 모습이 그대로 비쳐지게 됩니다. 그러면 정답을 알고 있는 지원자와 모르고 있는 지원자가 당연히 차이가 나게 되어 있습니다.

실제 그 정도 기술 수준이 요구되는 포지션인가?

포지션이 코딩 테스트의 문제와 유사한 기술, 알고리즘 등을 많이 사용해야 포지션이면 코딩 테스트를 통해 확인할 수 도 있겠지만 대부분의 경우에는 많이 사용되지 않고, 설령 사용된다 하더라도 외부 라이브러리 등을 활용하는 경우가 많습니다. 물론 트래픽도 많고 처리해야 할 문제가 복잡하고 어려워질 수록 단순 라이브러리의 활용이나 API의 사용이 아닌 직접 구현해야 하는 경우도 간혹 발생하게 됩니다. 이런 경우 어느 정도 높은 기술 수준을 요구하는 것이 사실입니다. 구글, 아마존 등과 같은 글로벌하게 트래픽, 사용자가 많고, 시스템이 복잡하기 때문에 코딩 테스트를 기본적으로 실시하고 있습니다.

저는 이상하게 화이트보드나 노트에 코드를 쓰는 경우 생각이 잘 나지 않습니다. 이유는 모르겠지만 키보드에 타이핑을 하는 순간부터 아이디어나 생각이 떠오릅니다. 글쓰기도 마찬가지인 경우가 많습니다. 이런 개인적인 성향이 실제 인터뷰에서도 지원자에게 이런 방식의 코딩을 강요하는 것을 싫어할 수도 있습니다.

압박면접

가끔 어떤 회사에 인터뷰를 보신 분들이 불쾌한 경험을 하신 이야기를 듣는 경우가 있습니다. 이 경우 압박면접을 받은 경우도 많습니다. 채용을 하는 회사에서는 지원자가 압박 상황(업무적인 스트레스 또는 긴박한 상황 등)에서 어떤 반응을 하는지를 보기 위해 가끔 감정을 상하게 하는 발언이나, 기술적으로 아주 어려운 문제를 내거나 하는 등으로 지원자를 심리적으로 압박하는 경우가 있습니다.

저는 이것은 득보다 실이 많다고 생각합니다. 최근의 개발 조직의 문화를 보면 경쟁 보다는 협업을, 빡빡한 일정 보다는 품질 좋은 시스템을 만드는 방향으로 가고 있습니다. 이런 경우 실제 조직내에서 압박 상황은 많지 않으며, 이런 압박 상황을 만들어 내는 조직 자체가 문제가 있기 때문에 조직의 문화나 프로세스를 바꿔야 한다고 생각합니다. 따라서 팀원을 구성할 때 압박 상황에서 어떻게 대처 하는지에 대한 반응을 보기 보다는,  지원자를 편한 상황으로 만들어지 주고 최대한 지원자의 역량을 잘 설명할 수 있는 분위기를 만들어 주는 것이 좋다고 생각합니다.

이런 이유 때문에 인터뷰 시간에는 가능한 불편한 상황을 만들지는 않습니다.

글을 마치며

지금까지 기술 면접에서 어떻게 하는지에 대해 제 경험을 공유해 드렸습니다. 이 경험은 지극히 개인적인 경험이기 때문에 회사, 팀, Interviewee가 누구냐에 따라 채용 인터뷰는 완전히 다른 방향으로 전개될 수도 있습니다. 경험을 공유한 이유는 이런 토론을 통해 어떻게 하면 팀에 맞는 구성원을 찾을 수 있을지를 같이 생각해 볼 기회가 되었으면 합니다. 그리고 지원자들도 면접관이 "왜 이런 질문을 하는지?", "면접 준비는 어떻게 해야 하는지?"에 대해 조금이나마 도움이 되었으면 합니다. 마지막으로 이 글은 개인적인 의견이기 때문에 참고만 하실 것을 당부드립니다.