IT

Google SDE의 phone screening 까지 후기

kaffeit 2020. 6. 23. 22:18
반응형

 

 

 

그렇다.
나도 후기 한 번 써본다.

제목의 'phone screening까지' 에서 알 수 있듯이 결국 실력의 미숙함을 극복하지 못하고 온사이트 면접까진 가지 못했다. 그냥 후기도 쓰지 말까 하다 이것조차 안 쓰면 정말 아무것도 안 남을 것 같아서 그냥 써본다.

한 편에 쓰기에는 조금 길어서 두 편에 나눠 쓸까 하다 안 그래도 열 받는 거 길게 끌기 싫어서 한 방에 가기로 함.

 

 

 

지금 회사가 마음에 들고, 월급도 그럭저럭 잘 받는 편이라, 한 3,4년간은 이직할 계획이 없었다. 그런데...

 

 

난데없이 구글 리크루터가 보낸 메세지 덕분에 (옮긴 지 1년도 안 되었는데) 제대로 이직 뽐뿌가 왔다...

 

 

솔직히 Android에서 손 뗀지 좀 되었는데, 그 얘기를 했더니 그 외 부분에서도 인상적이어서 일단 간단한 인터뷰를 했으면 한다고 해서 덥석  진행하기로 했다. 이런 기회 언제 온다고...

 

 

나중에 듣기로는 LinkedIn에서 내 이력서를 보고 기술 블로그(이거 말고 영문 기술 블로그) -> GitHub를 보더니 나름 쓸 만했는지 연락을 했다고 한다. 이럴 때는 정말 기술 블로그나 GitHub에서 서브 프로젝트를 간간히 해 놓은 보람을 느낀다.

 

 

 

나와 GitHub의 5년

내가 GitHub를 '제대로' 알게 된 것은 대략 2015년 정도? 그 전에도 알고는 있었지만 회사 업무 차 필요해서 계정을 만들어 놓은 것뿐이었다. 그때가 이직을 위해 면접을 보러 다니던 시기였는데, 지

kaffeit.tistory.com

잔디밭 잘 관리하세요. 기술 블로그도 웬만하면 꼭 하세요. 언젠가 반드시 도움이 됩니다.

 

당연 면접 준비가 전혀 되어있지 않은 상태라 여유를 두고 면접을 진행하기로 하고, 주말이나 퇴근 직후 틈나는 대로 코딩 및 CS공부를 진행했다. 보통 시험을 치기 위한 가장 자신 있는 프로그래밍 언어를 미리 물어보는데, Java나 Go로 하는 게 평가가 좋다는 근거 없는 소문이 있어서 개중에 자신 있는 Java로 진행하기로 했다

 

(지금 보면 정말로 근거 없는 거 같다...).

 

 

 

코딩 공부에 도움을 받은 곳은:

 

- LeetCode: 코딩 테스트 사이트 중에서도 거의 반 표준 취급받는 곳이다. Easy 30, Medium 70 정도 풀었다. 다만 전부 내 능력으로 푼 건 아니고 해답을 보고 공부한 것까지 포함.
- HackerRank: 여기도 괜찮은데, 공부하기에는 LeetCode가 좀 더 좋았던 듯 하다. LeetCode에 나온 문제는 절대 구글 면접에 안 나온다는 소문이 있어서 몇 번 써봤음.
- CodeSignal: 잘 안 알려진 곳 같은데, 생각보다 괜찮은 코딩사이트. 게임하듯이 진행하는 느낌이라 덜 심심했다.
- YouTube 채널: Byte By Byte, interviewing.io, 승지니어님 채널
- GeeksForGeeks 등등

 

 

면접에 관해 구글링을 해보면 LeetCode에 의존하지 말고 이론에 충실하라는 말이 많은데,

이제 와서 공부 방법에 대해 복기해 보자면:

 

- LeetCode는 분명 도움이 된다. 다만 인터넷에 나온 것처럼 수백개씩 풀 필요는 없다. 100개 정도면 충분하다고 본다.
- 대신 다양하게 풀자. Array 50개 String 50개 이렇게 말고, Tree, LinkedList, Graph, DFS, BFS, DP 등 골고루...
- Medium(LeetCode 기준) 위주로 푸는 게 좋을 것 같다. Medium 레벨을 잘 풀 정도면 어차피 Easy에서 막힐 일은 없을 것이고, 이 정도 수준의 응용은 할 수 있어야 한다
- 한 번 풀어본 문제라도 해답이나 Discussion 항목을 보자. 한 문제에 대해 다양한 풀이 방법을 아는 게 좋다.
- 어려운 알고리즘(다익스트라 등)까지는 안 나오는 것 같다. 대신 기초적인 알고리즘(배열, 트리, 링크드 리스트...)은 확실히 숙지해야 한다.
- 문제를 풀 때, 일단 러프하게 구현한 뒤 돌려보면서 디버깅하기보다, 좀 느리거나 쉬운 문제라도 좋으니 처음부터 끝까지 한 번에 optimal 한 솔루션을 만드는 습관을 들이자.
- 내 솔루션의 Time/Space complexity에 대해 정확히 얘기할 수 있어야 한다.

 

널리 알려진 것처럼 폰 스크리닝 과정은 google docs에서 진행된다.

 

 

당연히 자동완성 기능이나 컴파일이 될 리 없으니

메모장이나 구글 문서에 코딩하는 훈련이 필요하다.

 

위 내용은 물론 실제 내용과 무관합니다

 

 

일정이 확정되면 테스트 당일 사용할 구글 문서 링크를 공유해 준다. 본인이 코딩하기 좋은 폰트가 있다면 미리 세팅해 두는 게 좋다. 

그 이외 환경 설정에서 대문자 자동 변환 기능이나 자동교정 설정 등을 꺼 두면 코딩할 때 편하다.

 

 

내 면접관은 중국계 엔지니어 였는데 검색팀 소속이라고 한다.

간단하게 자기소개를 하고 난 뒤 바로 문제로 들어갔다.

 

 

참고로 자기 소개(a.k.a. 자랑) 길게 해 봤자. 평가에 영향도 전혀 없는 듯하고, 오히려 문제 풀 시간이 줄어드니 이런 건 지양을...

 

 

문제를 바로 주고 '해답 Go~'식이 아니라, 하나 하나 질의응답을 진행하면서 문제를 풀어나가게 된다. Google 면접 공식 가이드에 'think loud' 항목이 있을 정도로, 수시로 내 생각을 말로 표현하는 것이 중요하다.

 

 

여차저차 문제를 풀고, 풀이에 대해 설명하고 나니 2분 정도가 남았다. 질문이 있냐는 말에 회사 업무에 대해 짧게 묻고 그대로 종료. 진짜 무미건조하게 끝났는데(원래 그런 건지 내가 못해서 그런 건진 잘 모르겠지만), 이때부터 예감이 썩 좋지 않았고...

 

 

대략 1주일 뒤 탈락 결과를 받았다 ㅠㅠ 사실 그렇게 못 했다고 생각하진 않았는데, 만든 코드에 일부 오류가 있었고, 그 이외 마이너스가 된 부분들에 대해서도 설명을 해 주었다. 

 

 

고마운 건 리크루터가 직접 통화해서 면접관의 피드백을 직접 얘기해 주고, 아쉽지만 더 공부해서 내년에 보자고 한 부분. 아마도 내년에 재도전하게 될 것 같은데, 그 때는 하다 못해 온사이트라도 가보고 싶다. 구글 밥 좀 먹어보게...

 

 

 

당연한 얘기지만 실제 문제에 대한 언급은 할 수 없고, 공부한 내용과 시험 경험을 기반으로 생각해보면:

 

- 문제의 자세한 사항에 대해 확인하는 과정, 내가 생각하는 풀이방법 등을 꼭 대화로 표현할 것
- 코딩을 진행하면서 예외상황을 확인하지 말고 코딩 전 다양한 예외상황을 잘 확인할 것
- 시간이 생각보다 짧으니(나 같은 경우는 45분) 시간 배분을 잘 할 것
- 사양을 정확히 파악해서 한 번에 정확한 솔루션을 만들도록 할 것

 

 

주저리주저리 쓰고 보니까 내가 붙은 것 마냥 쓴 것 같아졌다 =_= 그냥 내가 기억하기 위한 글 쓴 셈 치자.

 

 

어쨌든 구글러를 향한 내 첫 도전은 이렇게 허무하게 끝났다.

다음을 기약하며...

 

반응형