코딩테스트 준비를 하는 사람이 많을 것이다.

요즘 구인 공고를 보고 가고 싶다고 생각이 드는 곳은 약속이라도 한 듯 서류 – 코딩테스트 – 1, 2차 면접 – 처우 협의로 가는 모양새다.

내가 마지막으로 회사에 들어갔을 2017년 까지만 해도 코딩 테스트를 보는 곳이 그리 흔하지는 않았던 것 같다. 그때 쯤 슬슬 시작되는 분위기 였던 것 같다. 이직을 적극적으로 생각해보지 않은 나로서는 코딩 테스트를 굳이 준비 할 필요가 없다고 생각했는데, 이게 막상 필요할 때가 되니 꾸준히 해둘걸 싶다.

약 2주 정도 코딩 테스트 공부를 하고 몇군데 테스트를 보고나서 처음에 알아두면 좋았을 걸 싶은 것들이 몇가지 있다.

코딩테스트 원래 어렵다

처음 접하고 푸는 똑똑한 사람도 있겠지만 나를 포함 주변 다수는 나와 같은 경험을 했고, 그걸 습득하는 과정에서 포기하냐 안돼도 꾸역꾸역 풀어보냐의 문제이지 천부적인 능력과는 거리가 있다는 것을 알았다.

처음에 코딩 테스트가 잡히고 연습 하겠다며 백준 아저씨네 놀러 갔다가 깜짝 놀랐다.
놀라울 만큼 손도 못대는 내 자신에게 당황해서 도대체 이 문제가 나에게 하고자 하는 말이 무엇인지 몇 번을 다시 봤다. 난독증인가?

문제를 읽어도 이해가 안되는 기적 같은 일이 벌어지고 나니 이거 만만하게 볼게 아니구나 싶었다.

우선 입 출력을 어떻게 하는지부터 좀 배우자 싶어 유튜브와 구글, GPT 형님을 열심히 조졌다.
그렇게 일주일 쯤 하다보니 느끼게 된 것은 코딩 테스트는 원래 누구에게나 공평하게 어렵다는 것이다.

물론 첫번째 코딩 테스트는 신나게 말아먹었다.

이거 실무에서 쓰임?

당연하겠지만 백준 같은 곳에 있는 다수의 문제(예를 들면 이런 것)는 실무에서 쓰이지 않는다고 봐야 할 것 같다.
실무에서 쓰였다면 내가 아무리 멍청해도 10년 가까이 개발을 했건만 손도 못 댔을까?

예전에 코딩 테스트가 도대체 뭔지 궁금해서 한번 쓱 보고는 ‘에이 이딴 것 실무에 아무 쓸모 짝에도 없는 거’ 정도로 취급하고 말았는데, 막상 준비하면서 배우는 점이 꽤 있다. 어떤 항목을 객체화 할 지, 동작을 어떻게 나눌지, 내가 생각한 것보다 더 효율적인 로직이 무엇인지 한번 더 고민하게 되고 주어진 문제를 해결하는 아주 작은 단위의 프로젝트와 같은 느낌이 있다.

그리고 코딩 테스트에 쓰이는 언어에서 제공하는 기본 메써드를 IDE에 전적으로 의존해왔던 나로써는 최소한의 도구마저 빼앗긴 느낌이랄까. 평민 1레벨에 목도를 빼앗긴 느낌이다.

개발 할 때 어떤 자료구조로 만들어서 어떻게 해결할지 고민하는 능력을 길러주는데 도움이 되는 것은 있다고 생각한다. 다만 실무 능력과 코딩 테스트 실력이 정비례 할지는 잘 모르겠다.

빨리 벼락치기로 어떻게 좀 안됨?

경우에 따라 될 것 같기도 하다.

최소 2주 정도는 열심히 봐야 어느정도 문제가 풀릴 것 같고, 똑똑하면 더 빨리 하겠고 나처럼 평범하거나 습득이 느리면 더 오래 걸릴 것이다. 너무 당연한 얘기라 쓰고 나니 미안할 정도.

주먹구구식으로 풀어보니 이 정도는 알아두면 좋겠다.

언어를 정하고 입출력부터 익히자

내가 주로 사용할 언어를 선택해서 기본 입출력을 먼저 익혀야한다.

예를들어 자바는 BufferedReader, Scanner 와 같은 입력 도구를 통해 자료를 입력 받고, BufferedWriter, System.out 으로 요구사항에 나온대로 출력하는 것부터 돼야 뭘 푸는 척이라도 할 수 있다.
단순 암기를 무척 싫어하지만 이건 왕도가 없어서 외울 때까지 복붙하지 않고 일부러 타이핑했다. 이젠 프로젝트 생성하면 파블로프의 개 마냥 입출력이 줄줄 나오게 됐다. 역시 머리가 나쁘면 몸이 고생한다고.

파이썬으로 하면 쉽다는 얘기가 많길래 새로운 언어도 익힐겸 파이썬으로 해볼까? 싶었지만 솔직히 언어를 뭘 선택하는지는 크게 중요하지 않다고 생각한다. 물론 더 쉽게 풀 수 있고 효율적이고 할 수 있지만 내가 실무로 사용할 언어로 제한하는 경우가 많고, 의외로 준비하면서 이 언어에 대해 공부하는 것이 분명히 있기 때문에 굳이 사용해보지 않은 언어로 준비 할 필요가 없어보인다.

아무거나 붙잡고 풀어보자

일단 아무 놈이나 붙잡고 패보는거다.

똑똑한 사람은 처음부터 몇 문제 풀 수도 있겠지만 결국 막히는 문제가 필히 나올 것. 이걸 해결하기 위해 머리를 써보고 도저히 모르겠다면 다른 사람이 이 문제를 어떻게 푸는지 본다. 나는 그래야 기억에 남았다. 처음부터 설명하는 것을 들어보고, 알려주는대로 문제 풀어보고하면 어찌 어찌 풀리겠지만 돌아서면 너무 잘 까먹는다. 내가 한번 쯤은 고민해보고 어느 지점에서 막혔는지, 그 지점을 어떻게 풀었는지 보면 아 나는 볍신인가? 하면서 뇌리에 박힌다.

알고리즘을 편식하지 말자

백준 아저씨네 문제엔 알고리즘 분류로 문제를 구분했는데, 이게 특정 알고리즘을 집어서 하면 비슷한 자료구조와 비슷한 로직을 쓰게 돼서 학습 효율이 떨어진다. 어떤 문제가 나올지 모르는데 한놈만 패는 것은 그 한놈이 안나왔을 때는 어찌 할 방법이 없다.

어떤 알고리즘으로 푸는지에 따라 자료구조를 제한적으로 사용하게되니 특정 자료구조를 사용하면 아주 쉽게 풀릴 수 있는 문제도 아주 어렵게 돌아가게 되는 상황이 연출될 수 있다. 다양한 자료구조를 어떤 상황에서 어떻게 사용하면 되는지 여러가지 문제를 시간을 들여 풀어보고 푸는 것을 보는게 불특정 유형의 문제를 푸는데 더 효율적이라고 생각된다.

어디서 이런 뻔한 얘기를

쓰고보니 뻔한 얘기를 길게해서 안타깝지만

뻔한 얘기라는 것은 많은 사람이 같은 생각을 가지고 있다는 것이기도 하니 돌탑에 작은 돌맹이 하나 얹었다 생각하고 포스팅한다.

결론은 님이 천재가 아니라면 어려운거 당연하고 벼락치기, 꼼수, 미원 같은 마법의 레시피 같은 것은 없다. (있다면 비법 공유 좀.. 굽신) 운이 좋았으니 이게 비법이다 알려주는 사람은 운도 따른 사람일 것이고, 그게 꼭 나에게 적용되리란 법이 없으니깐.