뭐 여러글을 통해 밝혔지만, 코딩 인터뷰 준비라는 것이 비단 회사 이직을 위해 필요한 것이 아니라 내가 가지고 있는 머릿속의 문제해결능력을 바꾸는 데에 큰 도움이 된다는 것을 누차 느끼고 있다.
사실 작년 10월경부터 코딩공부는 하긴 했다. 리트코드 약 100문제, CTCI는 5판기준 다 보고, MIT의 Introduction to Algorithms강의를 듣고 책을 정독했다. 그리고 몇몇 유튜브 영상을 봤다. 그런데 이게 전부이다. 사실 공부하면서 느꼈지만, 예전에는 막연히 퀵소트나 BST, 링크드리스트, 해쉬맵, 트리, Priority Queue, 스택 등을 실제로 “구현” 해야 한다고 생각했었다. 작년 말쯤 처음으로 봤던 아마존 면접에서 우선순위 큐를 사용하는 문제가 있었는데, 주어진 1시간 시간 중 50분을 우선순위 큐를 “직접” 작성하느라고 결국 삽질하다가 못내고 좌절했던 경험이 있다. 그런데 그 이후로, 생각보다 웹상의 컴파일러(coderpad같은)가 일단 Java 8까지는 지원하고 심지어 Stream API 도 쓸 수 있으니 굳이 iterator를 외워서 짤 필요 없이 forEach를 하던 map을 하던, 데이터 가공의 문제의 경우에는 그렇게 할 수도 있더라. 물론 Stream API를 쓰더라도 내부에서 돌아가는 것은 알아야 하지만.. 최소한 온사이트에서는 말이다.
거기다 더 나아가, 사실 코딩인터뷰에서 컴파일이 제대로 될 필요는 없다. 지금까지 폰스크린 약 20번 온사이트 10번을 봤지만 한번도 컴파일을 요구하는 경우는 없었다. 어차피 컴파일이 되고 안되고는 그냥 습관에서 갈리는 것 같다. 세미콜론이나 변수 초기화나 패키지 import 함수 리턴형 등 말이다. 그래서 지금까지 컴파일이 되고 안되고로 피드백을 받은적은 없다. 다만, 자주 나는 돌아가는 “완벽한” 프로그램을 짜려고 노력하다 보니 이상하게 도는 경우가 많았다. 아마 문제는 리트코드나 interviewBit, hackerrank등 실제로 “컴파일”이 되어서 입/출력 결과가 “제대로” 나오는 경우만 맞다고 간주를 하니 그런 강박관념에서 이런 경우가 발생한 것이 아닐까.
그런데 인터뷰에서는 컴파일이 필요없고, 이에 대해서 강박관념을 가질 필요도 없다. 대부분 아는 문제는 이미 출제자로부터 문제를 듣는 순간부터 최소한 돌아가는, brute-force 플랜은 나와야 한다. 그리고 아무리 안다고 해도 몇 분 간은 생각해보고 혹여나 출제자가 의도한 것이 무엇인지, 문제의 어떤 요건(예컨데 sorted/continuous number, BST등) 이 최적화를 만들 수 있는지를 생각해야 한다. 이게 또 근데 완벽하게 최적일 필요는 없다. 내가 아는 생각을 말하고, 빠르게 이를 대입해보고, 또 정 안되면 원점으로 가서 해보면 된다. 간혹 면접관들이 힌트도 주는데, 그정도면 정말 만사 OK.
이런 경험을 지난 6개월간 했었다. 작년 초에 면접본거까지 하면 약 7개월 정도. 물론 풀타임으로 준비하진 않았고, 그때는 정말 일주일에도 10건 이상 전화통화 하느라고 정신도 없었고, 하나 리젝 먹으면 멘붕에 술먹고 (…) 스트레스 해소방법도 몰랐고 등등.. 여튼 그랬다. 그래서 그나마 위에서처럼 저정도 푼게 다행이라는거다. 그리고 사실 문제라는 것이 어느정도 선에서 나온다. 한시간 남짓한 인터뷰 시간에 심도있는 어려운 문제를 낼 필요는 면접관으로써는 없으니깐. 무슨 코딩 컨테스트도 아니고..
그래도 Hard한 문제들이 좋은 것은, 생각의 깊이를 높여주는 것 같다. 얼마전에 Facebook HackerCup이란것을 참가했다. 총 세 문제가 있었는데 내 생각엔 Easy하나 , Medium 두개 정도였던 것 같다. 세개를 다 풀었지만 실수로 easy만 맞았다. 그런데 틀리고 자시고간에 나는 이 문제를 도합 한 6시간은 풀었던 것 같은데 그렇게 한껏 머리를 쓰고선 문제를 풀고 나면 너무나도 기분이 좋다. 물론 틀렸지만, 틀려도 답을 위한 approach는 얼추 비슷했다. 그런데 이런 경험을 easy같은 문제에서는 그 과정이 아니라 그저 정답을 맞췄다는 것에 “이야” 라고만 할 뿐이지, 실제로 도움은 거의 안되는 것 같다.
다만 경험상 인터뷰에서는 easy-medium급 문제가 나오기 때문에, 특히 이런 문제들은 정석을 요하기 보다는 몇 가지 솔루션을 생각해야 하더라. 올 초에 Yelp와 본 면접에서는 정확히 기억은 나지 않았지만, Priority Queue와 HashMap을 융합한 문제가 나왔었는데 N과 M이 주어지면 이 크기에 따라 PQ와 HM이 각각 어떤 장단점을 가지는지를 물어봤다. 사실 두 가지 이상 자료구조가 쓰이는 문제는 훌륭한 문제다. 그런데 또 알고리즘마다의 장단점을 알아야 한다. 너무 깊게 생각할 필요도 없고, 그저 내가 저 자료구조에 대해 아는대로 생각해보고 답을 도출하면 된다.
여튼 이상하게 글이 점점 코딩 인터뷰 팁으로 갔는데, 여하튼 오늘 쓰고싶었던 글은 지금 인터뷰 몇 개를 앞두고 공부할 것들을 좀 정리하고 싶어서였다. 내가 지금 가지고 있는 레퍼런스는
<코딩문제 – 사이트>
– Leetcode – Explore, Example, 인터뷰 후기 / 이미 100문제 품
– HackerRank – 왠지 시스템이 정이 안가는.. 하지만 5개 정도 회사에서 pre-screening으로 요구했었다.
– InterviewCake – 내가 가장 좋아하는, step-by-step으로 문제해결을 어떻게 해야하는지 알려줌.
– TopCoder – 오늘 알게됬는데 문제가 참 많다.
– InterviewBit – 작년 초에 많이 풀었는데, 뭐 submit한번으로 점수 깎이고.. 그런거 좀 별로임 ㅠ
– CodeSignal – 최근 생긴 “게임” 형식의 문제푸는 사이트. TopCoder랑 비슷하지만 인터페이스가 더 깔끔하고 문제가 세련됬다.
<코딩문제 – 책, pdf>
– CTCI 6th- 5판은 한글로 읽었는데 이건 처음. 기본적인 문제가 많다. 다만 원서니 읽는 시간이 걸릴듯.
– Leetcode에서 구입한 pdf – 말 그대로 기본 문제 50개 정리되 있는데 코딩인터뷰 전날에는 항상 읽고 간다.
– Elements of Programming Interviews in Java – 문제가 너무너무 많음.. 책 자체가 정리가 잘 안되있어서 아쉽다.
<알고리즘 – 사이트>
– Coursera – Algorithms Toolbox (SDSU) vs Algorithms Part 1, 2 (Princeton) : 나는 sdsu꺼 선택. Princeton은 교수님이 너무 유명하신 분이지만 너무 심도있게 강의하고 좀 매체도 old한 느낌.
– MIT Introduction to Algorithms (OSU, https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-006-introduction-to-algorithms-fall-2011/lecture-videos/) – 이게 젤 재밌었음. 기회가 되면 다시 듣고싶은데.. 다이나믹, 그래프, 해시, 캐시 및 몇몇 첨들어보는 알고리즘은 좋다.
<코딩문제해석 – 유튜브>
– Tushar Roy – 내가 젤 좋아하는 인도친구. 내가 SJSU를 다녀서 그런지 인도애들은 은근 이해하기 쉬운 꼼수를 많이 쓴다. 나같이 인도영어 익숙하면 들어도 좋은듯. 이친구 꽤나 문제를 많이 다룬다.
– CS Dojo – 전직 구글러인 일본 친구. 전부는 아니지만 몇몇 강의(다이나믹 등)은 들을만함.
<자바기본, 프로그래밍기본>
– JAVA 8 in Action, Java 8 Lambdas – 람다 관련 내용이 많지만 잘 이해안됨. 그냥 Stream API만 보면 좋을듯.. 람다는 하스켈이나 스칼라로.
– 클린코더, 클린코드, 클린아키텍처 – 꼭좀 봐야하는 책들.
– 대규모 서비스를 (인프라를) 지탱하는 기술
– 조대협의 대용량 아키텍처 성능과 튜닝 – 세상에서 가장 좋아하는책
– Design Pattern – 자바개발자라면 꼭 알아야 할듯.. (이건 언제보지..)
– 소프트웨어 컨플릭트, 소프트웨어 크리에이티비티…
<지난 인터뷰에서 내가 부족한 것들>
– 자바의 기본. String의 c++와 자바의 차이. 그냥 자바와 C++의 차이들. 다중상속이나 virtual friend같은.
– 시스템 디자인에 대한 숙련도 – 트위터나 tinyurl같은거 설계.
하도 책이 많아서 정리도 안되고, 문제푸는 사이트도 워낙 많아서 정리도 안된다. 이것뿐이랴, 코딩 인터뷰에 필수 등장하는 CS/DS/OS기본도 그렇고..
일단 나는 정리가 필요하므로 대충 정리하면, 일단 Algorithm Toolbox만 꾸준히 하는걸 기준으로 하고 나머지 유튜브 사이트는 시간나거나 머리식힐 때 보는거로 한다.
코딩 문제는 다른건 제쳐두고 우선 CTCI한번 다 보고, interviewCake 다보고
leetcode 를 200개까지 푸는거로. 하루 5개정도만.
여기서 시간 좀 나면 codesignal 을 하는거로 하자. 다른건 도무지 지금 못건들것다..
프로그래밍 기본서는, 일단 람다랑 Stream API만 얼추 정리해두고 Effective Java먼저보고, 다른 대용량 처리나 코딩 관련 책은 휴식취할때 보는거로. 특히 오늘같은 날엔 좀 지쳐서 보고싶다.
사실 더 중요한건 내생각엔 영어랑 시간관리 같다. 회사 코딩을 못해도 8시간은 해야하는데, 이거 제하고 운동 한시간 밥시간 취침 등 제하면 별로 남지도 않는다. 그래도 쓸때없는 시간을 생각보다 많이 줄여놨으니, 남는 시간에 영어공부랑 코딩공부를 할 수 밖에. 영어는 원래 하던 스터디에, 회화 따라하기, 주제 생각해서 말하고 녹음해서 들어보기, 단어랑 문장 암기 정도. (도 많다!)
개발자로서, 공부는 정말 평생하는건가 보다. 왜 내 주변 개발자 친구들이 그토록이나 잠수를(!) 타고 있는지 잠깐 유라임에서 한걸음 물러나서 인터뷰를 준비하는 시점으로 보니깐 알 것 같다. 다들 그렇게나 열심히 하나보다. 참 인생이란 쉴 틈이 없다. 이런 와중에도 우린 소셜 활동도 해야하고, 몸도 만들고 건강도 챙겨야하고 가정도 챙기고 등등등.. 그런데 확실한 것은, 긴장을 늦추는 순간 확 멀어진다는 것. 어차피 코딩 인터뷰 준비라는 것도 그렇다. 그저 적당한 긴장감을 유지하기 위해서가 아닐까.
그런 의미에서 나는 오늘도 문제를 풀러 간다.
