싱가폴의 코딩 테스트
그들은 코딩 테스트로 당신의 무엇이 알고 싶은가?
왜 코딩 테스트를 할까?
이 질문에 대해서 구직자든 개발자 채용을 고려하는 사람이든 충분히 고민을 해보면 좋겠다.
코딩 테스트를 통해서 개발자의 코딩 능력을 보겠다는 것은 너무 당연한 말이다. 싱가폴에서 코딩 테스트/면접을 진행하면서, 물론 모든 회사는 아니었지만 한국에서는 느끼지 못했던 부분에서의 세심한 고려가 느껴지는 몇몇 회사의 면접들이 있었다. 나는 그런 세심한 몇몇 회사들이 진짜 궁금해하는 것이 '이 개발자가 과연 우리 회사의 다른 개발자들과 함께 일할 수 있는 사람인가?'라고 느꼈다. 이게 무슨 말인지는 아래에서 코딩 테스트 종류에 대한 설명을 보면서 알아보도록 하자.
코딩 테스트 종류
내가 싱가폴에서 면접을 보면서 경험했던 코딩 테스트는 크게 3가지로 구분해볼 수 있다. '코딩 인터뷰 사이트', '온라인 실시간 면접', '과제 제출 후 오프라인 추가 면접' 이렇게인데, 아래에서 각각에 대해서 조금 더 자세하게 알아보자.
1) 코딩 인터뷰 사이트: Hackerrank, Codility
코딩 인터뷰로 유명한 위의 두 사이트에 대해 다른 글에서 소개한 적이 있으니 아래 링크를 참고하면 된다.
간단하게 말하면 화이트보드 코딩 테스트를 온라인으로 옮겨놨다고 생각하면 된다. 보통은 1~3시간 정도의 주어진 시간 동안 3개 정도의 문제를 푼다. 지원자는 충분히 해당 플랫폼에서 연습하고, 자기가 테스트를 진행하고 싶은 시간에 편하게 보면 된다. 질문도 할 수 없다. 그냥 못 풀면 끝이다. 이런 사이트 링크를 받았다면, 그냥 개발자로서 기본적인 컴퓨터 프로그래밍에 대한 지식이 있는지 알고 싶다는 거니 충분히 연습하고 풀면 된다. 장점은 회사나 구직자 모두 시간 낭비하지 않아도 된다는 점이고, 단점은 처음에 2~3번은 괜찮은데 링크를 5번쯤 받기 시작하면 짜증이 좀 난다. 그리고 플랫폼마다 원하는 답안 제출 방식이 조금 다르기 때문에, 처음에 1~2번은 연습이 충분하지 않다면 좋은 결과를 받기가 힘들다.
2) 온라인 실시간 면접
이 면접 방식은 처음 스카이프 같은 화상통화 프로그램으로 인사를 하는 걸로 시작한다. 각자 소개를 약 5~10분가량 하고 바로 실시간으로 지원자의 코드를 확인할 수 있는 링크를 보내고, 그 링크를 열면 간단한 문제가 적혀있다. 대략 코딩을 위한 시간은 20분 정도 주어졌고, 그 이후는 코드에 대한 설명을 요구하거나 피드백을 받아서 추가적으로 코드를 개선하거나 기능을 추가하는 요구가 있었다.
만약에 위에서 소개한 코딩 인터뷰 사이트에 대한 경험만 있고, 이런 방식의 인터뷰가 처음이라면 급한 마음에 코드를 써내려가기 쉽다. 물론 코딩을 깔끔하게 잘하는 것도 매우 중요하다. 하지만 이 방식의 면접에서 중요한 또 한 가지는 20분 동안 아무 생각 없이 코드만 써내려가는 게 아니라 면접관과 문제에 대해 확실하지 않은 부분을 사전에 명확하게 해야한다는 점이다. 아무 말 없이 한참 코드를 써내려 가다가 질문을 하는 것보다, 궁금한 부분들에 대해서 초반에 확실히 질문하는 게 좋다. 이 방식의 목표는 '당신이 정답을 쓰는가?'가 아니라 '당신이 왜 그렇게 코드를 짰는가?'를 확인하는 것이다. 그러니 조금 더 여유가 있다면 중간중간 왜 내가 이렇게 코드를 짜고 있는지, 가장 좋은 방식은 내가 앞으로 어떻게 코드를 미리 짤 건지 이야기를 하고 코드를 짜면 좋다.
아래는 실제로 온라인 실시간 면접으로 제공됐던 문제이다. 15~20분 정도 안에 풀어야 했다. 직접 한 번 풀어보는 것도 좋겠다.
You are building a chapter suggestion algorithm for a reader. You know each chapter length in pages and are given a duration in days for the user to complete this book.
Come up with an algorithm/function which can suggest a book reader, the chapters to be read by day to day basis.
Please note :
1) The chapters suggested should be consecutive and in order.
2) The reader cannot read partial chapters, once started he will complete the chapter on same day.
Input can be assumed in the form of zero indexed integer array - index represents chapter number, value is the number of pages in the chapter.
Second parameter is the number of days in which the user wants to read the book.
Eg :
Arr = [ 10, 3, 8, 4, 12, 5, 9, 2, 4, 11, 7 ]
Days = 5
Output :
Day : Chapter numbers
1 0, 1 i.e 13 pages
2 2, 3 i.e. 12 pages
3 4, 5 i.e. 17 pages
4 6, 7, 8 i.e. 15 pages
5 9, 10 i.e. 18 pages
이 문제를 다 읽고 코드를 짜기 전에 면접관에게 어떤 질문을 하는 게 좋을까? 문제에서는 각 챕터별 페이지 숫자와 전체 책을 다 읽어야 하는 기간과 예상 결과가 나와 있었는데, 문제 어디에도 각 날짜별로 어떻게 챕터를 배분했는지에 대한 내용은 나오지 않았다. 따라서 가장 먼저 "저 챕터 배분은 어떤 로직으로 이뤄진 거냐?"라는 질문을 해야 한다. 그러니 면접관이 "전체 페이지 숫자가 75페이지이기 때문에, 이걸 5일 동안 읽으려면 15페이지를 평균적으로 추천해주면 된다."라고 대답했고, 거기에 나는 "그렇다면 15페이지가 정확히 맞아떨어질 때는 상관없지만, 그렇지 않은 경우에는 어떻게 처리하면 되겠냐?"라고 질문을 이어나갔다. 물론 그 질문은 다시 나에게 돌아왔지만. 그리고 후속 요청이 들어와서 코드 수정도 조금 해야했다.
정리하면, 굳이 개발자 면접관이 시간을 내서 당신의 코드를 쳐다보고 있다는 건 입 다물고 코드나 치라는 이야기가 아니라, '문제가 주워졌을 때 제대로 된 질문을 할 수 있는지', 그리고 '동료 개발자와 충분히 대화를 통해 더 나은 해결책을 이끌어 낼 수 있는지' 등을 보고 싶어 한다는 것이다.
3) 과제 제출 후 오프라인 추가 면접
개인적으로 가장 좋았던 방식은 과제가 있는 면접 방식이었다. 과제가 있으면 "괜히 일하기도 전에 시간 쏟아야 하는 게 아니냐?"라고 불쾌해 할 수도 있지만, 회사 입장에서는 과제를 제출하지 않는 사람은 회사에 크게 관심이 없는 사람이라고 판단할 수 있을 테니 그렇게 나쁘지 않은 장치라는 생각이 든다. 대체로 이 과제는 회사에서 당면한 문제, 혹은 회사에서 개발하고 있는 서비스의 핵심과 관련된 내용인 경우가 많았다. (나는 경험해보지 못했지만, 정말 서로의 시간을 낭비하지 않기 위해 실제 회사에서 처리해야 하는 문제를 구직자에게 주고 해당 프로젝트를 진행하는데 돈을 주는 회사도 있다고 한다.) 그리고 관련해서 회사 내에 서비스를 소개해주는 경우도 있는데, 이런 경우에는 지원자가 회사 서비스에 대한 이해를 충분히 할 수 있어서 입사 후 초기 적응 시간을 단축시켜주는 역할을 하기도 한다. 회사 입장에서는 설명 들은 비즈니스 로직을 얼마나 정확한 질문을 통해서 이해하고 코드로 구현할 수 있는 사람인지 확인할 수 있는 기회라서 더욱 좋을 테고.
지금 다니고 있는 회사가 이런 방식으로 면접을 진행했다. 첫 면접부터 CTO가 면접에 들어왔는데, 서비스를 잠깐 설명해주더니 데이터베이스를 UML을 이용해서 설계해보라고 했다. (물론 데이터베이스 관련 질문을 한다는 걸 HR 담당자를 통해 사전에 들었기 때문에 간단한 UML 등은 복습을 하고 갔었다.) 그리고 두 번째 면접은 회사 서비스 기능 중 일부를 듣고, 미리 작성된 코드 템플릿에 빈 곳을 채워 넣는 면접이었다. 이 두 면접을 통해서 회사의 사업 내용 전반을 파악할 수 있었고, 회사에 적응하는데 크게 도움이 되었던 것은 물론이다. 개인적으로는 '회사가 사람을 뽑는데 정말 신경을 많이 쓰는구나'라는 생각과, 이곳에서 일하면 '똑똑한 사람들과 일할 수 있겠다'는 생각이 들었다.
코딩 테스트는 코딩 테스트가 아니다
많은 구직자들이 면접을 '회사가 후보자를 평가하는 시간'이라고 생각하지만, 나는 그와 동시에 후보자도 회사에 대한 많은 것을 파악하는 시간이라고 생각한다. 개발자가 너무 중요하다고 말하면서, 아무 말도 없이 해커랭크 링크만 한 줄 달랑 보내는 회사를 보면 머리 속에서 물음표가 마구 떠오른다. 그리고 면접에서 그 회사의 개발자를 만나면서도 '이 회사의 분위기는 어떤지?', '개발 팀의 업무 스타일은 어떨지?' 등 다양한 걸 유추할 수 있다.
그래서 개발자를 찾는 회사들이 면접을 설계하는데 좀 더 시간을 들였으면 좋겠다. 최대한 예의 바르되, 면접이 그냥 어쩔 수 없이 진행하는 시간 낭비가 아니라 (면접에 들어와서 회사에서 보내서 어쩔 수 없이 들어왔다는 지루한 표정을 짓는 사람들도 있다.) 회사에 들어와서 조금이라도 도움이 될만한 걸 물어볼 수 있도록 노력하는 그 과정에서 회사가 일하는 방식과 회사의 미래를 본다.
아무쪼록 해외 취업을 준비하시는 분들이 해커랭크 링크를 받은 게 아니라면, 좋은 질문을 통해 의사소통 능력이 있는 개발자라는 것을 잘 보여주고, 다니게 될 회사가 어떤 곳인지 생각해보는 기회를 얻었으면 좋겠다.
그리고 마지막으로 아래의 National Geography 동영상을 보고 면접 때마다 써먹고 있는 질문이 있는데 개인적으로 아주 만족하고 있다. 동영상을 직접 보면 좋겠지만, 지금 동영상을 볼 형편이 안 되는 분들을 위해서 간단히 소개하면, 면접 마지막에 "질문 있으세요?"라는 면접자의 질문에 어떻게 질문하면 좋을지에 대한 동영상이다. (물론 동영상에는 그 외에도 다양한 팁을 알려주고 있다.) 동영상에서는 "Is there any reason you wouldn't hire me for this position?"(이 면접에 제가 떨어질 이유가 있을까요?)라고 질문하라고 시킨다. 이 질문에는 두 가지 장점이 있는데, 하나는 면접관의 솔직한 피드백을 들을 수 있다는 것과 다른 하나는 면접관이 후보자에게 걱정하는 부분을 그 자리에서 바로 답변할 수 있다는 점이다. 아마 많은 분들이 '저런 질문을 어떻게 해?'라고 생각하실 수 있지만, 계속해서 저걸 물어보고 있는 사람 입장에서 말해보자면 매우 훌륭한 질문이니 꼭 하라고 권하고 싶다. 면접관에게 직접적인 피드백도 두려워하지 않는 열려있는 사람이라는 인상을 줄 수 있어서 일석이조다.
