Virtual onsite interview (코딩 테스트/시스템 디자인)기록

11월에 B사와 전화 인터뷰를 보고 이틀쯤 뒤에 리쿠루터에게 연락을 받았다. 

예상했던대로 현재 하고 있는 업무랑 비슷한 팀에서 계속 진행하고 싶다는 얘기.

B사와의 첫 인터뷰 후기는 여기 : randomthoughts.tistory.com/entry/2020년-하반기-이직-준비?category=785306

 

 

다른 회사랑 면접 보느라 휴가를 이미 써버려서 ㅋㅋ 금방 또 쉬기엔 눈치가 좀 보여서 11월 말로 미뤘더니, 이쪽 회사에도 땡스기빙 주간 전후로 휴가 쓰는 면접관들이 많은 바람에 12월로 일정이 잡혔다. 

 

한시간짜리 테크니컬 인터뷰가 2개 잡혔고, 이후 HR 이랑 매니저랑 면접은 유동적으로 잡힐거라고 했다 (후기를 찾아보니 코딩 테스트를 통과하지 못하면 ㅋㅋ 이 단계에서 면접이 마무리가 된다고 하더라)

 

면접에 들어가서 조금 놀랐던게, 2명의 면접관과 1명이 shadowing (참관) 하러 들어왔다. 그래서 본의 아니게 이날 팀원? 부서원?을 6명이나 만나게 되었다. 

지금 회사에서 면접관으로 들어갈때도 있는데, 사람을 한명 뽑으려고 해도 최소 3-4명의 지원자와 만나다보니 생각보다 시간을 많이 잡아먹어서 ㅋㅋ 나중에는 면접 들어가기 참 싫어졌는데 (일이 밀려서 야근하는게 반복 됨), 이 회사는 새로 들어오는 사람들에게 많은 공을 들이는구나 싶었다. 

 

첫번째 면접은 코딩 테스트로 2개의 문제를 무난하게 풀었다 (Leetcode 난이도 하 ~ 중).

다른 회사들과 달리 여기는 Graph나 Dynamic programming 관련 문제는 없었다. 알고리즘보다는 class design / data structure 를 더 중요시 여기는 느낌을 받았고, 이어지는 질문들은 대부분 최적화에 관한 것이었다. 

 

두번째는 시스템 디자인 인터뷰였는데, 공유되는 화면에다가 그림을 그리면서 설명하느라 애를 먹었다 ㅜㅜ 그림은 진짜 기본만 그러놓고 거의 말로 설명을 했다. 직접 화이트보드에 그리면서 설명했더라면 좀 더 수월하지 않았을까 싶다. 

이것도 나름 기본적인 - TinyURL 을 생성하는 시스템을 디자인 하라는 - 질문이 나왔다. 전반전에는 서버, 데이터베이스, 캐시, 로드 밸런서 등의 컴퍼넌트를 대충 그려놓고는 system flow 를 설명했고, 후반전에는 deep-dive 를 하면서 시간 가는줄도 몰랐다. 요악을 조금 하자면

 

# Consistency

- TinyURL 을 생성해서 저장하는 서비스가 많아지면 consistency 관리가 어려워지는데...

  . 일단 이 서비스는 Consistency 보다는 Availability 가 중요하다고 가정한다 (CAP theory 언급). url이 생성은 됬지만 replication 이 미처 되지 않았을 경우엔  그냥 없는 url 에러를 내보낸다. 

- 여러개의 서버가 새로생성된 url 을 저장하는데 문제가 생긱 수도 있다. 예를 들자면 2개의 사이트가 같은 tiny url 을 생성해버리는.. hash code collision 의 경우 (Collision 이 기억 안나서 뭐라더라.. conflict 는 아니였는데 했더니 면접관이 알려줌); 두번째 경우는 하나 이상의 서버에서 동시에 데이터베이스를 업뎃하려다 conflict 가 나는 경우. 

  . Hashing function 자체를 새로 만들 수 있는데; 1번 케이스가 절대 안생긴다는 보장도 없고, 로직이 더 복잡해질 수록 새로운 url 을 생성하는 시간이 길어질 수 있다. 

  . 어차피 랜덤한 url 이니까 pre-generate 하는건 어떨까? 미리 생성한것을 읽는다면, hashing 하는 시간을 절약할 수 있음. 포인터나 카운터로 서버마다 할당을 해주면 같은 url 을 사용하려는 경우도 방지할 수 있음. 

 

# Performance

- 2가지 서비스를 제공하는데 하나는 Read, 다른 하나는 Read/Write 를 해야한다면, 8:2 의 법칙(?)을 적용해서 80%의 사용자가 Read 서비스를 이용할 것이라고 가정하고 Read 서비스를 최적화 하기.

  . 2개 서비스를 제공하는 서버를 분리하면 된다. 

  . Read 가 많다면 캐시를 사용하기. LRU 캐시가 적당. 캐시 용량은 전체 데이터 베이스 대비 10% 정도

 

# Scaling

- 500 Million request / month 로 시작했는데 사업이 대박나서 사용자가 더 많아진다면? 10% 만 캐시에 저장한다고 가정해도 용량이 늘어날텐데 그럼 O(n)도 당연히 늘어난다. 더 빠르게 읽을 수 있을까?

  . 이건 처음에 감을 조금 못잡았는데, 그래서 이건 인프라에 투자할 돈이 얼마나 있냐의 문제라고 ㅋㅋ in-memory hashmap 에다가 로딩을 하면 조금 빨라진다고 했더니, 면접관이 hashing 쪽으로 강한 힌트를 주었다. 

  . TinyURL 을 해싱한다면, O(log (n)) 근접해질 수 있고... 만약 consistent hashing 까지 사용한다면 더 빨라질거라고 했더니 만족해한듯. 

 

이 외에도 살짝씩 언급했던 부분들 :

- abuse 를 하는 악성 사용자를 방지하는 방법 -- 이 시스템을 쓸려면 user key 가 필요하게 만들면, 하루에 몇개까지 생성할 수 있을지 관리 가능

- load balancer -- request 를 어떤식으로 스케쥴링 할지 

- fail over -- 백업이 필요할지

- DB 용량 -- 한번 생성된 url를 5년동안 저장해야된다고 가정하고 purge 하기

 

 

디자인 인터뷰는 항상 시간이 좀 빠듯한 느낌. 시간이 너무 지나버려서 살짝 아쉬운 느낌으로 잘 마무 되었다. 

면접이 끝나고는 바로 리쿠루터에게 연락이 왔는데, 다음 단계로 넘어가자고 한다.

금융을 떠나고 싶었는데... 생각이 조금 많아진다.  

 

 

 

 

인터뷰가 끝나고 기록용으로 스샷을 찍어보았다