brunch

매거진 개발자 스웨덴 이직기

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 개발자 꿀 Jan 05. 2019

해외취업: 알고리즘 준비 2편

개발자가 스웨덴으로 이직한 썰 13

* 1편 https://brunch.co.kr/@ggool/28

하루에 한 문제씩 leetcode 풀기

알고리즘을 공부할 수 있는 플랫폼이 여러 개 있는데 그중에 leetcode(https://leetcode.com/)가 문제도 깔끔하고 사용성도 좋은 것 같아서 계속 leetcode만 사용했다.

카테고리와 레벨을 골고루 나누어서 하루에 한 문제 이상 푸는 것이 하루 할당량이었다. 인터뷰 후기 중에 하루에 문제를 열몇 개씩 풀었다는 글을 종종 보았는데 그들이 이미 알고리즘 존잘러이거나 퇴사 상태라고 생각한다. 내가 그 정도 수준이면 '바로 최적화하지 않았다'는 피드백은 받을 일이 없었을 것이다...

처음에는 손으로 풀고 (화이트보드 예행연습) 타이핑해서 결과를 확인했다. 문제를 잘 푸는 방법은 나도 명쾌한 답이 없다. 다만 코드가 길어지면 잘못 풀고 있다고 생각하고 일단 멈추자. 딱 봐도 더러운 문제가 아닌 이상 해답 코드는 보통 간결하다. one-liner라는 단어가 괜히 생긴 것이 아니다.

leetcode는 돈을 내면 각 회사에서 많이 출제된 문제들, 즉 족보를 볼 수 있기 때문에 앞서 말했던 페이스북 인터뷰를 준비할 때 한 달 동안 유료로 사용했다. 족보의 신빙성을 100% 신뢰하는 것은 아니나 수많은 문제들 중에서 검증된 목록을 볼 수 있는 것만으로도 단기간 인터뷰 준비에 도움이 된다.

요즘에는 유튜브 영상도 온라인 자료도 너무 많아서 어떤 것을 배울 때 유료 결제에 쉽게 머뭇거리는 것 같다. 인터뷰 준비도 많은 무료와 많은 유료 서비스들이 있다. 나도 굳이 '유료까지 써야 하나'라는 고민을 하다가, 인터뷰는 취미도 아니고 간절함을 해소하기에 35달러는 엄청 작은 돈이라는 생각을 하면서 결제했었다. 결과적으로 돈은 어떻게든 역할을 한다. 도움이 필요하면 구할 방법은 많다.

어려운 문제란 무엇인가

어려운 문제는 두 가지 경우가 많은 것 같다. 다시 말하지만 나는 알고리즘 천재가 아니라 대부분의 문제가 어려웠다.

1) 1%의 실패와 99%의 성공, 1%의 현실과 99%의 이상

테스트 100개 중 한두 개가 실패하는 경우. Edge case를 생각해내기 어렵거나 아주 큰 입력을 처리할 수 있는 최적화를 요구하는 문제들이다.

현업에서도 이 두 가지가 항상 고민인 것이 흥미롭다. 현실 세계는 0과 1의 세계보다 다이나믹한 법. 우리의 고객들은 개발할 당시에 생각해내지 못한 신박한 방법으로 시스템의 사각지대를 찾아내고, 예상을 뛰어넘은 큰 요청들은 제한이 제대로 걸려있지 않은 시스템을 한 방에 무너뜨린다.

시스템의 경계선을 한정하는 문제는 개발팀 안에서 자주 벌어지는 논쟁인데, 사실 여기서 방어적인 시스템이 좋다/나쁘다 같은 의견이 중요한 것이 아니라 사각지대가 있음을 '미리' 인지하는 것이 더 의미 있다는 것을 연차가 쌓이면서 점점 느낀다. 그래야 현실 세계와 비슷한 테스트도 해보고 overenginnering이다 아니다 같은 논의도 시작되는 것이 아닐까.

인터뷰와 연결 지어서 생각하면, 회사에서는 이런 사고를 가진 개발자를 원하고 알고리즘 인터뷰에서 이런 사고방식을 보여주는 개발자를 찾을 것이다. 함수 파라미터 List<String> list 가 아주 아주 클 경우를 미리 고민할 수 있는 사람은 1%의 까다로운 현실까지 내다볼 준비가 되어있다는 인상을 줄 수 있다.

2) 어떤 알고리즘/데이터 구조를 써야 하는지 말해주지 않음

Linked list를 써야 풀리는 문제를 linked list를 쓰라고 말하지 않는 문제들이다. 이런 문제는 패턴을 어느정도 알아야 쉽게 풀린다. 알고리즘 문제들에도 외워야 하는 것이 있는데 이 내용들은 외워주자.

스택이 이런 문제에 자주 등장한다. 나는 아이디어가 생각이 안 나면 막연히 스택으로 한 번 도전해보는 정도로만 알고 있다가, 메일로 받아보던 알고리즘 문제 해설에서 깔끔한 정리를 처음으로 보았다.

The trick was to use a stack.
It might have been difficult to have that insight, because you might not use stacks that much.
Two common uses for stacks are:
- parsing (like in this problem)
- tree or graph traversal (like depth-first traversal)
So remember, if you're doing either of those things, try using a stack!

출처 interviewcake

알고리즘 문제 응용하기

번외. 확장되는 알고리즘 문제들이 있다. 나는 data engineer로 지원했기 때문에 빅데이터 시스템 설계를 준비하지 않을 수 없었다. 처음에는 알고리즘과 빅데이터 처리를 별개의 준비로만 생각하다가 stream 처리를 검색하던 중 우연히 알게된 부분이다.

어려운 문제 2)와 비슷한 패턴이지만 leetcode 서버에서 실행시킬 수 없는 환경으로 범위가 더 넓어진다고 생각하면 쉽다. List<String> list가 stream으로 들어온다면? 분산 메모리 처리를 해야 한다면? 서버를 한 대만 써야 해서 파일 I/O가 필요하다면? list가 파일로 쪼개져있다면? 등등.

당연히-또는 다행히- 모든 문제가 이런 식으로 확장되는 것은 아니지만, 나와 비슷한 직무라면 자료를 찾아보고 한 번쯤 생각해보는 것이 좋다.

쉽게 찾을 수 있는 예제 중 Top K Frequent Items 문제가 있는데 잘 정리해둔 글로 내용을 대신한다. https://zpjiang.me/2017/11/13/top-k-elementes-system-design/

그리고 실제로 비슷한 질문을 온사이트 인터뷰에서 받았다. 쉬운 정렬 문제에서 시작해서 똑같은 로직을 이런 저런 상황을 바꿔가면서 재구현하는 방식이었다. 주어진 컴퓨터는 클라우드 서버가 되기도 하고 맥북 한 대가 되기도 했다.

물론 혼자 모든 해답을 생각낸 것은 아니다. 데이터를 수정해도 된다는 생각을 못해서 턱 막혔다가 힌트를 듣고 앞으로 나가기도 했다. 이런 내가 인터뷰를 통과한 것을 보면, 힌트를 들었을 때 빨리 문제에 적용하는 태도가 중요한 것 같다.

Good luck!

#개발자 #스웨덴 #해외취업

keyword