서류를 통과하면 그 다음에 주어지는 전형은 보통 코딩테스트나 사전과제, 서면 질문지 등이 있었다. 때로은 이러한 절차 전에 스크리닝 인터뷰를 하는 경우도 있었다. 인터뷰는 다음 포스팅에서 다룰 예정이고 이번 포스팅에서는 코딩 테스트와 사전 과제에 대해서 이야기를 해 보려고 한다.
코딩 테스트
코딩 테스트는 일반적으로 가장 자신 있는 언어를 사용하여 알고리즘 문제를 푸는 경우가 제일 많다. 때로는 언어를 지정해 주는 경우도 있다. 웹 프론트엔드의 경우 자바스크립트로 지정해주는 식으로 말이다. 그리고 간혹 알고리즘이 아닌, Vanilla JS나 React를 사용하여 특정 기능을 구현하는 코딩테스트를 본 적도 있었다. 이 경우는 코딩 테스트와 과제 전형을 섞어놓은 느낌을 받았다. ㅋㅋ
나의 경우 어디 가서 알고리즘 잘 푼다 라고 명함 내밀 정도의 수준은 아니다. 다만 코딩테스트를 보면 웬만해서는 다 붙었다. 알고리즘 문제는 보통 백준 온라인 저지(BOJ)를 통해서 푸는데 지금까지 200문제 조금 넘게 풀었다. 예전부터 알고리즘 문제 푸는 걸 좋아해서 틈나는 대로 풀었던 것 같다. 이번에 취준을 하면서도 알고리즘 스터디를 두 달 정도 하면서 매주 문제를 풀었다.
https://www.acmicpc.net/user/jgyuity1289
지금까지 내가 풀었던 알고리즘 문제들 중에서 자주 나온 유형들을 몇 개만 적어보면 아래와 같다. 여기 있는 유형들 정도만 충분하게 연습해도 왠만한 입사 코딩테스트는 무난한게 풀 수 있을 것으로 보인다.
- 완전 탐색(BFS, DFS, 이분 탐색 등)
- 동적 계획법(DP)
- 문자열 처리
- 트리, 그래프
- 그리디 알고리즘
- 브루트 포스
이정도가 내 경험상 자주 나았던 것으로 기억한다. 백준에서 유형별로 문제를 풀어볼 수 있으니 참고해서 풀면 좋다.
때로는 외국 코딩테스트 플랫폼을 통해서 문제를 주는 경우도 많다. Hackerrank, Codility, Testdome 등등 되게 다양하다. 이 경우 문제가 영어로 나오는데 너무 겁 먹을 필요는 없다. 그렇게 어려운 영어는 아닌 경우가 많기 때문이며, 몇 단어 해석 못 한다고 문제를 못 푸는 것도 아니다. 한국 플랫폼은 프로그래머스로 많이 풀었던 것 같다.
플랫폼에 따라, 회사에 따라 문제를 풀고 제출했을 때 정답을 알려주는 곳도 알려주지 않는 곳도 있다. 그리고 부분적으로 맞아도 점수를 주는 곳이 있으며, 부분 점수를 인정하지 않는 곳도 있다. 부분 점수를 주는 문제의 경우, 일단 가장 먼저 생각나는 방법으로 빠르게 풀고, 점수를 긁어 나가면서 점점 더 최적화를 시키고 시간을 단축시키는 방법을 추천하며, 부분 점수가 없는 경우는 처음에 주어지는 값의 범위(ex. 입력값 N의 크기)와 생각나는 알고리즘의 시간복잡도를 계산해서 어느정도 AC 가능성이 보이는 방법으로 시도하는 편이 좋다. N = 1,000,000 인데 O(N^2) 방법으로 풀고 그러면 어짜피 잘 풀어도 틀릴 수 밖에 없기 때문이다.
경험상 시간 복잡도를 줄이는 방법 몇 가지를 소개해 보면,
- 탐색을 할 때 그냥 O(N)의 방법으로 탐색하지 말고, 트리 구조로 풀거나 이분 탐색을 통해 O(logN)으로 시간을 줄이는 방법이 꽤 유용했다.
- 문자열 탐색의 경우 일반 탐색으로 시간이 오래 걸리는 경우 KMP 알고리즘이나 트라이(Trie) 구조를 가지고 풀면 시간이 많이 세이브 되었다.
- 그래프에서 탐색을 할 때 불필요한 탐색 구간은 애초에 가지 않도록 설계를 해서 탐색 시간을 아끼는 방법도 있다.(ex. DFS의 백트래킹)
- 왜 시간초과가 나는지 모르겠는 경우 항상 최악의 상황이나, edge case를 확인해 보는 습관이 도움이 된다. 트리가 한쪽으로만 아예 치우쳐져 있다든지, 배열에서 맨 처음 값이나 맨 끝 값이라든지 말이다.
- 기본적인 자료구조의 접근, 탐색, 삽입, 삭제 시간복잡도는 기억하고 사용하는 편이 좋다. https://www.bigocheatsheet.com/
알고리즘 테스트가 끝나고 가능하다면 해당 문제를 잘 푼 사람들의 코드를 보는 것도 큰 도움이 된다. hackerrank 같은 경우 구글링 해보면 생각보다 해당 문제에 대한 소스 코드가 나와있는 경우가 꽤 많다.
종이나 아이패드 앱을 사용해서 문제를 그리며 푸는게 많은 도움이 된다. 머리속으로만 생각하면 복잡한 문제들이 실제로 그려보면 생각보다 쉽게 풀리는 경우가 많다.
일단은 자신있는 언어 하나에 대해서 사용할 수 있는 라이브러리(JAVA의 경우 util 클래스)에는 익숙해 지는 편이 좋으며, 웹 프론트엔드 개발자의 경우 자바스크립트로 알고리즘을 풀어야 할 수도 있으므로, 자바스크립트 메서드나 기본적인 문법들은 한 번 정리해 놓으면 좋다. 나 같은 경우 자바스크립트 배열에 관련된 메서드가 자주 나오는데 항상 헷갈렸어서... 따로 블로그 포스팅에 정리하면서 연습했다.
간혹 Testdome 같은 코딩테스트를 보면 알고리즘 문제 말고 웹 전반 + HTML, CSS, JS 지식에 대한 질문을 하는 경우도 있다. 그래서 웹 프론트엔드 개발자로 구직을 하고 있다면, 웹 생태계와 브라우저, HTML, CSS, JS에 대해서도 기본적인 개념 및 동작 원리 등은 알고 있으면 좋다. 이에 관해서는 나도 차차 포스팅을 해 보려고 한다.
사전 과제
나같은 경우 알고리즘 문제를 요구하는 곳이 더 많았지만, 사전 과제를 요구하는 곳도 있었다. 사전 과제는 보통 React로 지정해 주거나, 자신이 자신있는 SPA 라이브러리를 가지고 간단한 웹 어플리케이션을 구현하는 과제였다. 보통 데이터를 불러올 수 있는 API를 같이 제공해 주며, 피그마나 제플린 같은 툴로 디자인 가이드를 주는 경우도 있다.
처음에 과제 전형을 딱 받았을 때 생각보다 되게 오래 걸렸던 기억이 있다. 익숙하지 않아서 그랬던 것 같다 ㅠㅠㅠ 그런데 몇 번 해보니 금방 익숙해 졌고, 물어보는 내용들이 비슷비슷하다. 그래서 잘 만든 과제 하나 github에 만들어 놓으면 나중에 여러 차례 일부분만 바꿔 가면서 쓸 수가 있다. (이 방법이 잘못 되었다고 생각하진 않는다. 내가 직접 짠 코드고, 그 개념을 내가 알고 있는 상황이라면 굳이 그걸 매번 처음부터 코딩할 바에 겹치는 부분 개발할 시간을 아껴서 좀 더 최적화를 하거나 디자인에 신경쓰는 편이 더 효율적인 방법이라고 생각한다.)
많은 과제에서 공통적으로 물어본 부분을 정리해 보면
- 반응형 웹 구현(Responsive)
- state와 props를 통한 컴포넌트간 데이터 바인딩
- CSS 스타일링(CSS Modules, Sass/Scss, Styled-components 등)
- REST API를 통해 비동기로 데이터 불러오기
- Component Life Cycle
- 최적화 방법(Lazy Loading 등)
- 상태관리 라이브러리(React : Redux, MobX / Vue : Vuex)
이정도만 잘 쓸 줄 알아도 웬만한 과제 전형은 무난하게 패스 할 수 있을 것으로 보입니다.
이번에 React로 과제 전형을 할 일이 생겨서 Velopert 님의 <리액트를 다루는 기술> 책으로 실습 해 보게 되었는데, 1년 이내에 출판된 책 한 권으로 실습하면서 outdated된 부분만 공식 문서 참고해 나가면서 배우면 2주~한 달 정도 안에 충분히 SPA 라이브러리 하나 배울 수 있는 것 같다. 참고로 이 책은 매우 추천! 두껍지만 필요한 내용이 다 있고 친절하다. ㅎㅎㅎㅎ (Velopert 같은 개발자가 되고 싶다)
나중에 실무에 어느 정도 적응이 되면 React 기반 최신 or 대중적인 라이브러리 사용해서 만들 수 있는 어플리케이션 실습 포스팅도 만들어 보려고 한다. 아직은 리액트가 익숙하지 않아서 ㅠㅠㅠ 많이 공부해야 겠다...
오늘 포스팅은 여기까지 하고, 다음 포스팅에서는 기술 인터뷰(+화상 스크리닝 인터뷰)에 대해서 공략법을 적어보도록 한다.
'Dev. Life > 2020 구직 이야기' 카테고리의 다른 글
DevOwen의 구직 이야기 Ch5. 연봉 협상 및 최종 결정 (0) | 2020.08.01 |
---|---|
DevOwen의 구직 이야기 Ch4. 기술 인터뷰 (1) | 2020.06.29 |
DevOwen의 구직 이야기 Ch2. 이력서 작성 (0) | 2020.06.18 |
DevOwen의 구직 이야기 Ch1. 마음가짐 (3) | 2020.06.12 |