코딩테스트를 준비하면서 느낀 것들..

leekeunhwan·2020년 3월 8일

들어가는 말

얼마전에 코딩테스트를 치뤘으며,
코딩테스트를 준비하는 분들에게 도움이 되었으면 하는 마음으로
제 느낀점을 전달해보고자 합니다.

저는 코딩테스트를 보기 전에 큰 착각을 하고 있었습니다.
프론트엔드라 문제가 비교적 쉬울테니 실무에서 쌓은 경험으로 봐야지라고 생각했기 때문입니다.
(무슨 자신감인지 하하...🤣🤣ㅜㅜ 불과 몇달전의 저는 너무 생각이 없어요...)

기술 면접을 대비하여 도메인 지식에 더 많은 시간을 투자하며 공부하고 있던 도중..
K기업에 냈던 지원서가 서류를 통과하였고,
해커랭크라는 서비스를 통해 올해들어 처음으로 코딩테스트를 보았습니다.
결과는 준비를 많이 안했으니 참담했죠..
3문제중 2문제는 풀었고, 한문제는 테스트케이스를 3개 통과하지 못한채 제출이 되었습니다.
지금와서 문제의 난이도를 다시 생각해보면 그리 크게 어렵지 않았던 문제였습니다..OTL

그렇게 탈락을 맛을 보고 난 후, 다행히도 저는 정신을 차리게 됩니다.
그리고 나서 하루에 5~7문제씩 문제의 의도를 파악하고 풀기위해 많은 노력을 하였습니다.
기본적인 정렬, 탐색, 자료구조들을 공부하면서, 다른 사람이 푼 문제도 보고,
해커랭크, 코딜리티, 리트코드, 프로그래머스등.. 다양한 플랫폼의 문제를
골고루 풀어보려고 노력했습니다. (정신차리고 나서 한 70~80문제정도 풀어본 것 같습니다.)
(지금도 계속 하루에 1~2문제는 감각을 잃지않게 풀어나가고 있고, 앞으로도 계속할 계획입니다.)
(문제를 많이 풀면 요런 뱃지를 주는데 묘한 성취감이 있습니다)

이런 노력하는 과정에서 깨닳았던 것들이 있었고, 이 부분을 공유하고자 합니다.

1. 문제의 의도를 파악하자 (무조건 코드작성 No..)

중/고등학교시절 수학문제를 풀 때,
출제자의 의도를 파악해라라는 말을 자주 들었던 것 같습니다.
출제자의 의도를 파악하고 출제자의 눈으로 문제를 보면 답이 보인다라는 뜻인데요.
이는 알고리즘에서도 마찬가지인 것 같습니다.

K회사의 코딩테스트를 보았을 때, 이런 부분에서 크게 실수한 것 같습니다.
특정 조건에 부합하는 무언가를 찾아야할 때, 문제의 의도를 파악하면서
보다 효율적인 탐색방법으로 접근해서 연산수를 줄이면서 결과를 얻을 수 있을 것입니다.

하지만 과거의 저는 그냥 생각없이 선형 탐색(Linear Search)를 했습니다.
알고 있던 것이 그 것밖에 없기도 했고,
어떻게 보다 문제를 이해하고 잘 풀수 있을까 고민하기보다는
당장 문제를 해결하기 위해 코드를 작성했습니다.

돌이켜보니 이 부분이 크게 아쉬웠습니다.

문제를 파악하고 접근하여 문제를 못풀면,
파악한 것과 접근한 방법을 대조하여 문제를 못푼 부분에 대해 복기(復棋)를 하며,
다음에는 문제를 틀리지 않는 경험이 될 수 있습니다.

하지만 당장 문제를 해결하기 위해 바로 코드를 작성하면서
테스트케이스 돌리며 해결되는지 안되는지 파악한다면,
왜 문제를 못풀었는지, 어떤 부분이 미숙했는지,
왜 이런 생각을 하면안되는지에 대해 생각할 포인트가 없기에
문제를 못풀면 못푼 상태로 끝나게 되는 것 같습니다.

이 부분은 고치려고 노력하고 있으며,
최근부터는 항상 문제를 보면 어떻게 접근하려고 하는지 먼저 정한뒤,
왜 그렇게 생각했는지 당위성에 대해 짧게 생각한다음,
그게 맞다고 판단되면 보다 좋은 방법은 없을지 고민한 후
코드에 옮깁니다.
(아이러니하게도 바로 코드를 작성하는 것보다,
문제도 더 잘풀리고, 시간도 단축되는 효과를 보았습니다.)

2. 코드를 보기좋게 나누자 (밀도 조절)

최선을 다해 작성한 코드를 어떻게 보여줄 것인가? 라는
질문에 대해 스스로 생각을 많이 하게 되었습니다.

동일한 두 개의 코드를 보면서 한번 무엇이 다른지 느껴보셨으면 좋겠습니다.

function solution(A) {
  let leftNum = 0;
  let rightNum = A.reduce((a, b) => a + b);
  let answer = null;
  for (let i = 0; i < A.length - 1; i++) {
    leftNum += A[i];
    rightNum -= A[i];
    const diff = Math.abs(leftNum - rightNum);
    if (answer === null || answer > diff) {
      answer = diff;
    }
  }
  return answer;
}

function solution(A) {
  let leftNum = 0;
  let rightNum = A.reduce((a, b) => a + b);
  let answer = null;
  
  for (let i = 0; i < A.length - 1; i++) {
    leftNum += A[i];
    rightNum -= A[i];
    const diff = Math.abs(leftNum - rightNum);
    
    if (answer === null || answer > diff) {
      answer = diff;
    }
  }
  
  return answer;
}

1번 코드보다 2번 코드가 보다 읽기가 편하시진 않으신가요?

저는 2번처럼 코드를 작성하고 정리하는 과정에서
변수 선언 및 할당, 연산, 호출을 나누어 가독성을 제공하고자 하였습니다.

이를 밀도 조절이라고 부르는 분들도 있는 것 같습니다.
코드를 제출하면 기계가 채점하지만, 결과적으로 채점 결과와 코드를 보는건
앞으로 입사하고자 하는 곳의 동료이자 선임일테니 보다 읽기 좋은 쪽으로
코드를 고친다면 좋을 것 같다는 생각에 이와 같은 행동을 하였고,
확실히 의도도 더 잘 보여지는 것 같아서 이전에 붙이는 것보다는
가급적 2번처럼 나눠서 보여주는 방식으로 코드를 작성하고 있습니다.

3. 다양한 플랫폼에서 문제를 많이 풀어보자.

`다양한 플랫폼에서 문제를 풀어보자`

저는 주로 한국어로 되어있는 프로그래머스에서 레벨 1~2정도로 문제를 풀며 준비를 했었습니다.
블라인드 코딩테스트도 프로그래머스로 봤으니 프로그래머스에서 보겠구나라는 생각이였는데,
해커랭크라는 곳으로부터 링크가 오게되면서 제 계획은 모두 수포로 돌아갔습니다.

뒤늦게 부랴부랴 해커랭크 문제를 몇개 풀어보고 테스트를 보았지만,
인터페이스도 조금 다르기도 했고, 테스트케이스 유형도 다르다보니 낯설음 + 문제의 어려움으로...
좋은 결과를 내지 못했던 것 같습니다. (물론 제가 못해서 그런거에요..ㅠㅠ)

그래서 이후에 결심한 것은 테스트 플랫폼을 조사한다음, 플랫폼마다 10문제이상 풀어보는 것이였습니다.
그렇게 다양한 사이트에서 문제를 풀어보았고, 그 다음부터는 링크를 봐도
아하 여기구나! 하고 보다 낯설음은 없이 문제에만 집중할 수 있었습니다.

`문제를 많이 풀어보자`

당연한 말이지만 다양한 문제를 많이 풀어봐야 경험이 뒷바침되기에 좋은 결과가 나오는 것 같습니다.
K회사에서 낙방후 40~50문제 정도를 더 풀어봤고, 그 다음에 본 N회사의 경우
코딩테스트를 합격하는 경험을 할 수 있었습니다.
의미없이 열문제 푸는 것보다 의미있게 한 문제를 푸는 것이 더 좋지만
의미있게 한 문제를 푸는 것과 열 문제를 푸는 것과는 또 큰 차이가 있습니다.