brunch

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 민창 Mar 25. 2017

이직 연습 #2

개발자, 어쩌다 해외 취업

이직 연습 #1에 이어서 계속 작성합니다.

4. 그들도 최선을 다한다.

온사이트 면접 단계에 들어가면 회사 입장에서는 면접관이나 면접자에게 많은 체제 비용을 지불하기 마련인데 투자 대비 좋은 결과를 위해 면접을 잘 보기 위한 대부분의 전략들을 잘 알려준다. 사실 책이나 인터넷에서 봤던 면접 팁 이상을 알려줘서 좀 놀라기도 했다. 좋은 사람들을 뽑을 수 있도록 회사에서도 최선을 다한다는 것이 느껴지는 순간이었다. 이는 면접 과정에서도 비슷한데 무엇보다 좋았던 것은 면접자의 방이 따로 있고 면접관이 돌아가면서 면접을 들어오는 것이었다. 면접자는 오랜 시간 동안 면접을 보면서도 한 공간에 익숙해질 수 있어서 좀 더 편안하게 생각을 정리할 수 있었다.

5. 코딩은 코딩대로 화이트보드는 화이트보드대로

이번 스텝을 위해 우선 구글에서 회사명 + interview questions를 검색하여 어떤 문제들이 나왔는지 살펴봤다. 자료가 너무 많아서 좋은 정보를 고를 수 없을 정도였다. 코딩 테스트를 준비하며 드나들던 사이트와 인터넷에서 찾은 기출문제, 얼마 전 구입한 면접 책의 문제들을 하나씩 골라서 하루에 두세 개씩 풀기 시작했다. 풀이는 예전처럼 종이에 먼저 낙서를 해가며 생각을 정리하고 바로 터미널에서 파이썬으로 문제를 풀었다. 똑같이 30분 정도만 시간을 썼다. 문제를 푸는 순서도 가장 먼저 떠오르는 나이브한 방법으로 우선 무조건 풀었다. 그 후 더 좋은 생각이 떠오르면 수정하는 방식을 택했다. 또 한 가지 추가적인 작업은 해당 문제에 대한 시간 복잡도를 함께 공부했다. 간단한 문제도 막상 시간 복잡도를 말하려니 잘 안되었다. 그동안 거의 해본 적 없는 일이었기에 당연했다.

시간 복잡도에 대해서 한 가지 더 언급하자면 보통 인풋 개수를 N이라고 했을 때 N, logN, N 제곱 등으로 표현하는 게 일반적인데 루프들이 여러 개 중첩되는 경우 좀 더 자세히 말해야 하는 경우가 발생한다. 나의 경우 한 번의 면접에서 N x M x K라는 답변이 면접관이 원하는 답변이었고 N과 M과 K를 정의하기 위해서 면접관과 3번 이상의 답변 수정 과정을 거친 적도 있었다.

컴퓨터에서의 코딩과 종이에서의 코딩과 화이트보드에서의 코딩은 상당히 그 감에서 차이가 많다. 나 역시 화이트보드 코딩이 제일 힘들었는데 우선 경험이 별로 없고 다른 사람에게 보여줘야 한다는 부담감에 생각이 잘 진행되지 않기 때문이다. 일단 문제는 계속 풀어야 하니깐 문제풀이는 컴퓨터로 하다가 종이에 풀어보는 방식으로 서서히 옮겨 왔다. 화이트보드 코딩은 연습을 하려면 회사를 가야 했다. 회사에서도 조용히 할 수 있는 기회가 잘 없으니 주말 아침 시간에 회사에 갔다. 회의실에 틀어박혀 코딩 테스트 책에 나와 있는 자바 답안들을 파이썬으로 포팅하며 필사를 시작했다. 목적은 하나였다. 파이썬 코딩을 화이트보드에 적는 것을 익숙하게 하자. 그래서 문제를 풀지 않고 그냥 베껴 적는 수준으로 연습량을 채웠다.

6. 말하고 질문하고, 질문하고 말하고

면접관은 으레 면접자에게 질문 있니?라고 말하기 마련이다. 나는 이 순간을 위해서 30여 개의 질문들을 면접 전날 미리 작성했었다. 영혼 없는 질문부터 정말 궁금한 질문들이 많이 있었다. 내가 일하게 될 회사면 좀 더 잘 알고 싶기도 했다.

"코드 리뷰 하루에 얼마나 하니? 릴리즈는 어떤 주기로 하니? 그룹 스터디 같은 문화도 있니? 언어 뭐쓰니? 인하우스 시스템이 많니 오픈소스도 많이 쓰니? 얼마나 일하니? 출장은 자주 다니니?" 등등 이 사람들이 회사 생활하는 느낌이 어떤지 궁금한 부분이 많았기에 그만하자고 할 때까지 계속 질문을 했다. "내 영어 알아듣겠니? 너 내가 이 문제 완전 망친 것 같은데 평가가 가능하겠니?" 이런 질문들도 했다. 질문을 많이 했더니 면접시간 동안 면접관이 더 많이 말하는 경우도 있었다. 우스갯소리로 하는 말이지만 나는 영어도 잘 못하는데 말할 시간은 좀 줄어드니 오히려 좋은 것 같기도 했다.

면접관 중 한 명이 문제를 내기 전에 자기가 만든 시스템을 설명하는 순간이 있었는데 나는 그가 문제를 내기 전에도 그 시스템에 관한 질문을 했다. (그가 그 시스템에 관한 문제를 낼 거라고 이야기를 안 한 상태였고 그냥 갑자기 막 자기가 만든 거 소개를 하길래...)

면접관 : "여기서 이렇게 되면 데이터가 이렇게 전달되는 건데.."

나 : "야 그러면 여기서 이런 경우에는 데이터가 막 폭탄으로 쏟아지지 않냐?"

면접관 : "어 맞어, 그래서 여기서는 앞에서 몇 개만 써"

나 : "어 계속해봐"

상황이 이렇게 되니 사실 누가 문제를 내고 누가 답변을 하는지는 별로 의미가 없었다. 그냥 서로 각자가 가지고 있는 의문을 푸는 시간이라는 느낌이었다. 기획자와 개발자가 처음 만나 함께 대화를 나누던 그 시간의 느낌이었다.

이직 연습 #3 에서 계속

keyword