코딩테스트에 대하여
지금 까지 해온 방식
우선 입사용 코딩테스트에 필요한 알고리즘 적인 지식 기반은 충분히 알고 있는 듯하다.
하지만 지금까지 코딩테스트를 보면서 했던 실수들을 적어보자면,
- 사소한 실수들이 많음 → 변수명을 잘못적어서 반영되는 변수가 달라짐, 너무 당연히 똑바로 적었을것이라 생각하고, 디버깅 시 그런 부분은 상세히 체크를 안함 → 시간지연
- 문제에 대한 충분한 고민을 하지않음 → 일단 코드가 작성되는 시점쯤 가면 코드부터 작성 → 작성하다가 로직에 맹점을 발견 → 다시 고민 → 점점 머릿속이 복잡해짐 → 시간지연
- 변수명을 너무 대충 지음 → 나중에 코드가 복잡해지면 논리 흐름을 쫓아가기 힘들어짐 → 시간지연
이렇게 결국 코딩테스트는 시간과의 싸움인데, 시간을 줄이고자 다급하게 푸는 것이 오히려 시간지연을 발생시킴
정답률을 높히려면, 아무리 쉬운 문제여도 해결 방법을 구하고 문제를 푸는것이 유리하다
딜레마
분명 실력 좋은 사람들은 쉬운문제를 보고 바로 풀이를 코드로 적어가면서 시간을 아낄 것.
그렇지만 나는? 그정도의 실력이 없기도 하고, 문제간 기복이 심한편이므로, 안정성을 키우는게 급선무 → 남들보다 쉬운문제에서 20분 더 쓴다해도 명확히 풀방향을 잡고 코드를 작성하는 방식으로 연습
삼성 코테의 경우 4시간~5시간 동안 2문제를 푸는 것이므로 충분히 고민하고, 생각정리를 마치고 코드를 작성해도 시간이 충분 하지만 카카오나 다른 기업 코테의 경우 시간이 촉박하여 못 푸는 문제들이 발생 이 때는 고점을 보기위해 고민보다 코드 작성을 해야할까? 아니면 안정성을 위해 똑같이 적용을 할까 정답은 안정성, 대신에 지금부터 열심히 문제를 풀면서 생각정리하는 시간을 최소화하는 방향으로 노력
현재 코테 추세
특정 알고리즘을 묻는 코딩테스트는 이제는 없음. 대부분 시뮬레이션, 에드혹 문제들로 구성 그 중에서도 문자열, 최적해, 완전탐색 문제들이 대부분
문자열 문제는 주로 서비스 기업들의 1번 문제로 자주 나오는 듯 하는데, 나는 C++를 사용하므로 문자열 처리에 대해 준비를 해야함 최적해 문제는 그리디, dp, 백트래킹 등 위주로 나오고, 나는 그리디 그리고 특히 DP 문제에 충분히 익히지 못했음 완전탐색 문제는 bfs, dfs 위주로 나오지만, 요새는 너무 익숙해져서 코테에 잘 나오지 않는 편인 듯함
최근들어 우선순위 큐를 사용하는 문제도 많아진 듯 하다. 그렇지만 시뮬레이션과 연계되어 나오는 것 중 dp, 그리디가 가장 많은 것 같으니 dp에 대해 좀 알아가야함 그리디 문제도 생각보다 까다로움, 어떤 것을 기준으로 그리디하게 선택할지 선택하는게 핵심인데 생각보다 잘 안보임 그리디, dp 문제를 완전탐색으로 풀면 무조건 시간초과 발생 따라서 문제가 완전탐색, 브루트포스 라고 판단하는건 가장 마지막에 고려해야한다. 그리고 보통 완전한 브루트포스는 없고, 조건문을 추가하여 중간중간 prunning 을 하여 연산량을 줄여야함