[코딩 인터뷰] 온라인 코딩 테스트의 사전 준비사항

16 Dec 2020

코딩 인터뷰 시리즈

이 글의 내용은 《파이썬 알고리즘 인터뷰》 책에 수록된 내용을 기반으로 작성하였습니다.

<목차>

온라인 코딩 테스트의 사전 준비사항

온라인 코딩 테스트의 사전 준비사항

이제 코딩 인터뷰의 첫 관문이 될 온라인 코딩 테스트를 잘 치르기 위해서, 어떤 준비가 필요한지 그리고 어떤 요령이 필요한지 하나씩 살펴보겠습니다.

연습장과 필기 도구

아무런 준비물 없이 노트북만 갖고 바로 진행해도 관계 없지만 연습장과 펜 정도는 있으면 큰 도움이 됩니다. 특히 재귀 구조를 구현할 때는 머릿속으로만 구조를 그려내는 게 쉽지 않은 편인데 연습장에 적어두면서 값의 변화를 추적해보면 많은 도움이 됩니다. 특히 처음에 자신만만하게 도전했다가 나중에 허겁지겁 챙기게 되면 흐름이 깨지므로, 되도록 시작 전부터 미리 챙겨두고 준비하는 편이 좋습니다.

저 또한 지금까지 수천 개가 넘는 문제를 풀이 해왔지만, 여전히 코딩 테스트 문제를 풀 때는 항상 연습장과 필기 도구를 곁에 두고서 값의 변화나 최종 결과를 기록하고 머릿속에 떠올린 구조와 비교하면서 풀이해 나갑니다.

좀 더 정확하게 풀 수 있는 매우 좋은 습관입니다.

어떤 프로그래밍 언어가 유리할까

온라인 코딩 테스트 준비 과정에서 가장 먼저 결정해야 하는 사항은 어떤 프로그래밍 언어를 선택하느냐는 점입니다. 간혹 지원하는 기업에서 언어를 강제하는 경우도 있지만(야놀자의 경우 사내 공식 언어로 자바를 지정하고 코딩 테스트를 자바로만 풀이하게 합니다), 대부분은 자유롭게 언어를 택할 수 있게 면접자의 선택지를 열어두는 편입니다. 어떤 언어로 풀이할지 택하는 것은 매우 중요한 문제입니다. 『파이썬 알고리즘 인터뷰』 책에서는 각 언어별 특징을 충분히 살펴본 후 코딩 테스트 풀이를 위한 언어로 파이썬을 선택하고, 왜 파이썬으로 풀이해야 하는지 특징에 대해서도 상세히 살펴봅니다. 관련해서는 책 내용을 참조하시기 바랍니다.

자신만의 코드 스니펫 준비

코딩 테스트 시 자주 쓰이는 동작들에 대해서는 코드 스니펫 ^Snippet을 미리 만들어 두면 도움이 됩니다. 예를 들어 연결 리스트를 뒤집거나 삭제하는 등의 작업들은 갑자기 구현하려고 하면 헷갈리기도 하고 시간도 제법 소요되는 편인데, 이런 작업에 대한 코드를 빠르게 가져올 수 있도록 코드 스니펫을 사전에 만들어 두면 좋습니다.

로컬 컴퓨터에서 별도 프로그램을 사용할 수도 있고, 깃허브 기스트 ^{GitHub Gist}처럼 코드 스니펫을 관리할 수 있는 좋은 무료 온라인 서비스도 있습니다. 코드 스니펫은 인터넷에도 모음집이 많이 공개되어 있으나, 그렇게 하기보다는 어떤 코드를 스니펫으로 만들면 좋을지 스스로 많이 연습하고 풀어보면서 자신에게 가장 어려운 알고리즘이나 코드 위주로 직접 정리하는 편이 가장 좋습니다. 직접 만든 코드여야 원리나 동작을 제대로 이해하고 바르게 적용할 수 있으므로, 각자 스스로 만들어두고 활용하는 방법이 가장 좋습니다.

모든 테스트 케이스를 통과하도록 풀어야

테스트 케이스 ^{Test Case}란 특정한 테스트 목표를 달성하기 위해 실행되는 입력, 실행 조건, 테스트 절차, 기대 결과 등의 스펙을 말합니다. 코딩 테스트의 주요 특징 중 하나는 제출한 답안이 좋은 점수를 받기 위해서 모든 테스트 케이스를 반드시 통과해야 한다는 점입니다.

대개 코딩 테스트 플랫폼에는 문제당 수십 개의 테스트 케이스가 있으며, 어떤 테스트 케이스는 입력값의 크기만 해도 수천 개에 달해서 효율적인 알고리즘으로 구현하지 않으면 타임아웃이 발생해 실패로 처리되는 경우도 있습니다. 따라서 모든 테스트 케이스를 통과 할 수 있도록 풀이해야 함은 물론, 비효율적인 알고리즘으로 타임아웃이 발생하지 않도록 최적화에도 많은 신경을 써야 합니다.

게다가 일부 기업의 경우 문제 제출 횟수를 평가 기준으로 삼는 경우도 있으므로, 무턱대고 제출을 반복하다가는 오히려 손해일 수 있습니다(이는 매우 잘못된 평가 방식이라 생각합니다). 이는 가급적 테스트를 많이 진행하면서 일부러라도 버그를 유발해 문제를 수정해 나아가는 형태로 개발을 진행하는 테스트 주도 개발 ^{Test-Driven Development}(이하 TDD)과는 완전히 대척점에 있습니다. 또한 해커랭크 같은 플랫폼은 입출력을 보여주지 않도록 설정할 수 있는데 이 경우 사실상 테스트의 의미도 없습니다. 자칫 일부러 오류를 내다가 혼동이라도 하게 되면 스스로 코드를 리뷰하면서 문제를 유추하여 원인을 찾아내야 하기 때문에 훨씬 더 어려운 상황에 처할 수 있습니다.

따라서, 적어도 코딩 테스트 시에는 충분히 생각하고 문제가 없는지 코드를 다시 한번 더 꼼꼼히 확인 후에 제출하는 편이 유리합니다. 실무에서처럼 일단 돌아가는 코드를 제출하고 테스트를 지속적으로 돌려보면서 오류를 수정해나가는 방식은 대부분의 코딩 테스트에서는 적용하기가 어렵다는 점을 명심하시기 바랍니다.

타임아웃이 발생하는 경우

테스트 케이스 중에는 일부러 입력값에 수천, 수만 개를 입력해 두고 타임아웃을 유발하는 경우도 있습니다. 시간 복잡도가 \(O(n^2)\)인 알고리즘은 타임아웃이 발생하고 \(O(n)\) 또는 적어도 \(O(n\log{n})\)정도는 되어야 풀리는 상황을 만들어내기 위해서 입니다.

이 경우 언어별로 타임아웃을 다르게 설정하는데, 문제는 파이썬의 경우 너무 빡빡하게 설정하여 C++에서 풀리는 알고리즘이 파이썬에서는 동일한 알고리즘임에도 풀리지 않는 경우가 있다는 점입니다. 대부분의 경우에는 파이썬이 C++나 자바보다 실행 속도가 느리기 때문입니다. 이건 사실 코딩 테스트 플랫폼의 심각한 문제점 중 하나인데, 수십 개가 넘는 언어를 지원해야 하는 플랫폼 입장에서는 타임아웃을 언어별로 달리 설정하는 게 얼마나 어려운 일인지 이해는 됩니다. 하지만 아무리 그래도 같은 알고리즘일 때 C++나 자바는 통과하고 파이썬은 통과하지 못한다는 점은 파이썬 개발자 입장에서는 적잖이 억울한 일입다. 이런 경우가 심심찮게 발생하므로, 파이썬으로 풀이를 작성할 때는 다른 언어에 비해 알고리즘 최적화에 좀 더 많은 고민이 필요합니다.

예외 처리를 잊지 말자

테스트의 어려움과 함께 코딩 테스트에서 가장 실수하기 쉬운 부분이 바로 예외에 대한 처리입니다. 입력값이 0이거나 널 ^null이 들어오는 경우가 있는데, 입력값에 대한 검증 과정을 깜빡 잊고 누락했거나 별다른 고민을 하지 않았다면 분명히 에러가 발생할 것입니다. 그나마 입력값을 보여준다면 쉽게 수정이 가능할 텐데, 해커랭크처럼 입력값을 보여주지 않거나 심지어 리모트인터뷰처럼 테스트조차 돌려주지 않고 그냥 제출을 받아버리는 경우에는 내 코드가 정상적으로 동작하는지 확인하기가 어렵습니다. 실무에서는 여러 가지 예외 케이스에 대한 테스트를 만들어 일일이 검증해볼 수 있으나, 코딩 테스트는 처음부터 예외 처리를 잘 하고 제출해야 나중에 번거로운 문제가 발생하지 않습니다. 이 부분은 개인적으로 코딩 테스트 플랫폼에 대한 불만사항이기도 하지만, 어쨌든 예외 처리를 하지 않아서 일부 테스트 케이스가 실패하면 감점으로 처리되므로 유의해야 합니다.

『파이썬 알고리즘 인터뷰』 책에서 제시하는 대부분의 코드들은 가급적 예외 처리가 필요 없을 정도로 알고리즘을 짜임새 있게 작성했습니다. 예를 들어 입력값이 널 ^null이라도 디폴트 값을 강제로 할당한다든지 등의 처리를 통해 되도록 예외 처리가 필요 없게 했습니다. 그러나 예외 처리가 반드시 필요한 경우에는 부득이하게 별도의 예외 처리 코드를 작성했습니다. 예를 들어 입력값이 없을 때나 입력값이 0일 때 핵심 알고리즘에서 걸러내지 못하는 경우, 상단에 별도의 비교를 통해 예외를 처리하도록 코드를 추가했습니다. 이처럼 코딩 테스트 시 실수를 줄이려면 아예 처음부터 상단에 예외 처리부터 해놓고 진행하는 것도 나쁘지 않은 방법입니다.

잘못 접근한 풀이, 어떻게 대처할까

문제를 풀다 보면 여러 가지 난처한 경우를 맞닥뜨리게 됩니다. 예를 들어 BFS(너비 우선 탐색) 방식으로 풀 수 있을 줄 알고 계속 시도해봤는데 끝내 풀리지 않고 DFS(깊이 우선 탐색) 방식을 써야 풀 수 있다는 걸 나중에야 발견한 경우입니다. 더군다나 초반에 문제를 발견했다면 모를까, 한참이 지나서야 겨우 문제점을 찾아낸다면 이를 어찌 해야 할까요. 또 다른 예를 들자면, 최댓값이 아닌 최솟값을 찾는 문제였다든가, 문제를 잘못 이해해서 중복 문자열을 무시하도록 겨우 구현해뒀는데 중복 문자열이 반드시 필요한 경우 등 … 이런 경우는 여기에 열거하기 힘들 만큼 엄청나게 많이 일어나고 의외로 자주 범하는 실수 이기도 합니다. 더 난감한 점은 이미 시간이 한참 지난 후고 다른 문제를 풀기에도 시간이 부족하다는 사실입니다. 지나간 시간은 되돌릴 수 없습니다. 정말 후회되는 순간입니다.

이런 일이 생기지 않도록 스스로 문제당 제한 시간을 정해두고 그 시간을 초과할 경우 바로바로 다음 문제로 넘어갑시다. 적어도 풀 수 있는 문제들은 모두 풀이할 수 있도록 빠르게 다음 문제로 넘어가야, 나중에 시간이 모자라 쉽게 풀 수 있는 문제도 놓치는 경우가 없습니다.

풀이 시간을 초과했을 때, 포기해야 할까

포기할 문제는 넘기고 시간 배정을 해서 최선을 다해 문제를 풀었지만 시간이 모자라거나 아쉽게도 문제를 다 풀지 못했다면 어떻게 해야할까요?

대부분의 경우, 채용을 위한 코딩 테스트는 경진대회와는 달리 시간이 모자랄 정도로 시험 시간을 빡빡하게 책정하지는 않습니다. 하지만 어쨌든 면접자가 제한 시간 내에 풀이하지 못하는 경우는 얼마든지 발생할 수 있습니다. 만약 시간이 초과됐고 다음 2가지에 해당하는 경우를 생각해 봅시다.

시간이 좀 더 주어지면 다 풀 수 있을경우
면접관의 이메일 주소를 알고 있을 경우

이 경우 시간 초과 이후에도 계속 풀이를 시도해봅니다. 아마 플랫폼은 닫히겠지만 별도의 IDE를 사용한다면 계속 이어서 문제 풀이가 가능할 것입니다. 그리고 풀이가 끝나면 결과를 면접관에게 메일로 보내봅시다. 제 경우에도, 수학에 가까운 간단한 코딩 문제가 테스트 케이스(보여주지 않는)가 자꾸 틀리다고 나오는 바람에 제한 시간을 초과해 문제를 미처 다 풀지 못한 경우가 있었습니다. 그러나 조금만 더 시간이 주어진다면 풀 수 있을 거라 확신 했고 결국 새벽이 다 되어서 결과를 따로 메일로 제출한 적이 있습니다.

제한 시간 내에 답안을 제출해야 하는 코딩 테스트 플랫폼의 기준에서는 오답으로 처리 되긴 했지만, 끝까지 답변을 제출한 것에 대해 면접관에게도 좋은 피드백을 받았고 이후에 인터뷰를 진행할 수 있었던 기억이 납니다. 시간 초과를 너무 두려워하지 마세요. 끝까지 시도해보는 것이 오히려 좋은 피드백을 받을 수 있는 계기가 될 수도 있습니다. 마지막까지 포기하지 않기를 바랍니다.

코딩 도구가 필요할까

전 직장에서는 웹 브라우저만 있으면 어떠한 코딩 테스트도 문제 없다는 사람을 여럿 보았습니다. 물론 그 정도쯤 되니 국내 최고의 IT 기업 중 하나에서 개발자로 일하고 있는 거겠지만 적어도 제 경우엔 그렇지 않았습니다. 무엇보다 도구가 중요합니다. 좋은 도구가 어려운 문제 풀이를 견인하는 경우를 수도 없이 많이 경험해왔습니다. 경진대회보다야 덜 하겠지만 코딩 테스트 또한 좋은 도구로 생산성을 극대화하는 게 무엇보다 중요합니다.

자전거를 잘 타는 사람은 생활 자전거로도 충분히 결승점에 도착하지만 대부분의 평범한 사람들은 로드 바이크로 최고 속도를 내야 간신히 결승점에 도달할 수 있습니다. 우리에게는 결승점에 도달할 수 있게 해줄 로드 바이크 수준의 도구가 필요합니다. 2가지 추천 도구는 비주얼 스튜디오 코드와 파이참 ^PyCharm 커뮤니티 에디션입니다. 좋은 점은 둘 다 무료로 제공된다는 점입니다. 최고의 도구들이고 무료로 제공되는데 사용하지 않을 이유가 없습니다. 코딩 테스트 시에는 반드시 둘 중 하나를 활용해 문제 풀이에 임하기를 추천합니다. 『파이썬 알고리즘 인터뷰』 책에서는 주로 파이참을 이용할 것입니다.

IDE에 부정적인 면접관이 있다면

온라인 코딩 테스트에서 통합 개발 환경(이하 IDE)을 사용했다는 이야기를 하거나 면접 을 볼 때 IDE를 사용한다고 이야기하는 경우, 간혹 IDE에 매우 부정적인 의견을 내보이는 면접관도 있을 것입니다. 주로 vim을 선호할 것이고 emacs를 쓰는 경우도 있을 것입니다. 그러나 언제까지 콘솔 기반의 도구만을 고집할 순 없습니다. 면접관에 따라 끝까지 vim과 emacs를 고집하는 경우도 있겠지만, IDE는 반드시 필요하며 또한 반드시 사용해야 합니다. 앞서 언급한 파이참은 최고의 파이썬 IDE입니다. 프로페셔널 버전은 유료이지만 무료 버전인 커뮤니티 버전으로도 코딩 테스트 정도는 충분합니다. 여전히 면접관이 IDE에 대해 부정적인 생각을 갖고 있다면 다음과 같은 비유는 어떨지 모르겠습니다.

“IDE를 굳이 자동차에 비유한다면 자동 ^Automatic에 비유할 수 있습니다. 이제는 운전을 잘 하는 사람도 모두 자동변속기 차량을 몰지 더 이상 수동변속기 차는 선호하지 않습니다. 운전하기가 더 편리하기 때문입니다. 게다가 예전에 수동변속 차량들은 언덕에서 뒤로 밀려 사고도 심심찮게 발생했는데 요즘 자동차들은 언덕에서도 뒤로 밀리지 않습니다. IDE가 버그 가능성이 있는 코드를 경고해 버그를 줄여주는 것과 비슷합니다.”

물론 vim과 emacs를 최고라고 생각할 만큼 자존심 강한 면접관에게 무리할 정도로 계속해서 어필할 필요는 없습니다. 어차피 통하지도 않을 것입니다. 애초에 기술적인 이유가 아닌 감정적인 이유로(유닉스와 콘솔이 최고라는) 도구의 편의성과 관계 없이 배척하고 있을 가능성도 있습니다. 중요한 점은 당신이 IDE가 없어도 개발이 가능하다는 점을 분명하게 강조해야 한다는 점입니다. 자칫 IDE가 없으면 아무것도 할 수 없다는 인상을 주게 된다면 더욱 좋지 않은 평가를 받을 수 있습니다. 개발을 못해서 IDE를 택한 게 아니라 개발의 편의를 위해 IDE를 택했을 뿐이라는 사실을 강조해야 합니다. 운전을 잘 못 해서가 아니라 편리한 운전을 위해 자동변속기를 택한 것처럼 말입니다.

REPL 도구로 코드를 검증하자

REPL은 사용자가 입력한 프로그램을 읽고 ^read 값을 계산 ^evaluate한 다음 출력 ^print하는 일을 반복 ^loop하는 구조를 뜻하는 read-eval-print loop의 약어로서 사용자 입력에 대한 실행 결과를 바로 되돌려 주는 상호작용 환경을 말합니다. 보통 셸 형태로 제공되며, 파이썬은 이미 오래 전부터 python을 파라미터 없이 실행하면 즉시 REPL 환경을 제공해왔습니다. TDD로 접근이 어려운 코딩 테스트에서 REPL 환경은 print()와 함께 가장 자주 쓰이는 디버깅 기능이기도 하며, 즉시 실행할 수 있다는 점에서 모호한 알고리즘을 바로 검증할 수 있어 버그를 줄이는데 많은 도움이 됩니다.

루비 같은 언어도 초기 버전부터 REPL 환경을 제공해오고 있으며, 심지어 자바 같은 대표적인 컴파일 언어조차 버전 9부터 jshell을 통해 REPL 환경을 제공합니다. 과거 빌 게이츠가 개발하던 시절에는 완벽한 코드를 작성하고 단 한 번의 실행으로 돌아갈 수 있도록 만들었다는 얘기가 전설처럼 전해져 내려오고 있으나, 평범한 우리들은 그렇게 할 수 없습니다. 가능한한 REPL 환경을 적극 활용하여 여러 차례 검증하면서 코드를 작성해 나가는 방법을 추천합니다.

『파이썬 알고리즘 인터뷰』 책에서도 REPL을 자주 활용할 것이며 그 결과를 코드 스니펫으로 제공합니다. 가능하면 여러분도 직접 따라 해보면서 검증해보길 추천합니다. 참고로, REPL 환경을 극대화한 주피터 노트북 ^{Jupyter Notebook}은 데이터 과학 분야에서는 사실상 표준 분석 도구로 자리매김 했을 정도로 REPL은 매우 유용하며 강력합니다.