기술 면접에서 주눅 들지 않으려면
가능한 질문을 예상하고 잘 대답해야 한다!
개발자로 취직을 하기 위해서 기술면접은 필수다. 국내 일반적인 기업일 경우 1차 면접이 기술 면접이며, 해외의 기업(구글, 아마존, 페이스북,...) 일 경우 1차부터 n(n>=3) 차까지 기술 면접을 진행한다.
면접에서 머리가 백지가 되는 현상은 나와 대부분의 사람들이 겪는 문제일 것이다. 아는 것도 생각나지 않고, 생각이 나더라도 제대로 설명하고 말할 수 없다면.. 불합격은 나의 것!
차라리 아예 몰라서 대답을 못했더라면 억울하지라도 않겠다. 이런 상황이 반복되다 보면 갈수록 주눅이 들게 된다.
이번 글은 면접장에서 백지가 되는 우리들을 위해 쓰게 되었다.
면접장의 상황과 면접 질문을 예상하고 자꾸 이미지 트레이닝을 하다 보니 전보다 부담감이 덜어지는 것을 경험했다. 무엇을 물어볼지 잘 예상하고, 대답을 잘 정리해나가다 보면 분명 여유도 생기고 발전할 것이다!
기술 면접에서는 뭘 물어볼까?
이력서/포트폴리오 관련 질문
- 서류에 간략하게 적었던 경험/프로젝트에 대한 구체적인 설명
- 프로젝트 진행 시 겪었던 어려움과 이를 해결하기 위해 시도했던 것들
K사 면접 때였다. 특정 프로젝트에 대한 모델링을 화이트보드에 그려볼 것을 요구했고, 왜 그렇게 설계했는지 물어봤다.
그 후, 지금의 '나'라면 과거의 프로젝트를 다시 설계한다고 했을 때, 어떻게 모델링할 건지 질문을 받았었다.
내가 해봤다고 기입해둔 것에 대해서는 명확하게 알고 있어야 하겠다.
기본적인 CS 지식
기본적인 CS(Computer Science) 지식을 테스트하는 것은 매우 일반적이다. 특히 신입이라면 여기에 더 비중 높게 질문할 것이다.
그중에서도 자료구조, 알고리즘 질문이 일반적인데, 어떻게 대답해야 잘 대답할 수 있을까?
노트에 미리 정리해두고 필요할 때마다 언제든지 쉽게 파악하도록 기록해두는 것이 좋다.
어떻게 기록하면 좋을지 예시와 함께 살펴보자.
정의
특징/특이사항
접근 시간
사용 상황 구분
G사 background check interview때 받았던 질문 중 자료구조에 대한 질문이 하나 있어 공유한다.
'What is a hash table?'
어떻게 답할 것인지 생각해보자!
Hash Table
정의: key-value의 map 자료구조다. Hash Table은 hash function을 사용하여 index를 버킷(bucket)의 배열로 계산
특징: index를 가져오기 위한 hash function은 해시 충돌(hash collision)이 발생할 수도 있는데, 두 개 이상의 다른 key에 대해 hash function이 같은 index를 리턴하는 것을 의미한다. 이 충돌을 해결하기 위해, linked list를 이용해 구현하곤 한다. 같은 index를 가지는 key-value 쌍을 linked list에 넣고, 충돌이 발생할 경우, 각 노드를 일일이 비교함으로써 해결할 수 있다. 따라서 최적화된 hash function을 선택하는 것이 중요하다.
접근 시간: 해시 충돌이 발생하지 않는다면 O(1)의 접근 시간을 가진다. 최악의 경우, 모든 노드를 일일이 비교하며 찾아야 한다면 O(n)의 시간 복잡도를 가질 수도 있다.
기본적으로 알아두어야 할 자료구조와 알고리즘은 다음과 같다.
자료구조
Array
Stack
Queue
Hash Table
Linked List
Tree
Heap
Trie
알고리즘
소팅 알고리즘의 비교
Quick Sort
Merge Sort
Bubble Sort
Heap Sort
검색 알고리즘의 비교
Linear Search
Binary Search
Depth First Search
Breadth First Search
도메인 지식
해당 팀에서 사용하고 있는 기술에 대한 지식이나 JD(Job Description)의 요구사항에 있는 기술 셋에 대해 질문할 수도 있다.
경력에 따라 질문 내용이 달라질 텐데, 지원하는 팀의 기술 셋을 사용해본 경험이 있다면, 깊게 질문할 것이고, 그들이 겪고 있는 문제나 내가 겪었던 문제에 대해 물어볼 가능성이 높다.
경험이 없다면, 해당 분야에 대한 기본적인 지식이 있는지 테스트하려 할 것이다.
N사에서 진행하는 front-end engineer 채용 면접에 갔었는데, 해당 팀에서 사용하고 있는 react.js, es6에 대한 질문이 많았고, 프린트된 js코드를 주더니, 어떤 값을 리턴하게 될지 물어보기도 했다.
배울 것도, try 해봐야 할 것도 너무 많은 기술의 홍수 속에서, 모든 것을 다해본 사람은 없다. (특히 신입이라면 모든 것을 알 거라는 기대는 하지 않고 있다고 봐도 무방하다.) 고로 모르는 건 모른다고 얘기하자. 어설프게 살짝 아는 것을, '안다'라고 대답했다가는 갈수록 깊게 들어오는 질문에 당황하고 나의 페이스만 잃어버릴 터, 도움이 되지 않는다.
확실하게 아는 것만 안다고 대답하자!
코딩
개발자를 뽑는 회사라면 코딩 시험은 필수라고 해도 과언이 아니다. 구글 독스 혹은 화이트보드를 이용해 지원자의 코딩 실력을 보는데, 논리의 흐름과 문제 해결 능력, 코딩 스타일을 보려고 하는 목적이 크다.
코딩 면접을 잘 보기 위해서는 손 코딩을 많이 준비해야 한다. 실리콘밸리는 물론 국내에서도 손 코딩을 시켜보는 회사들이 늘어나고 있다.
구글은 온라인 인터뷰 시, 문제를 주고 구글독스에 코드를 실시간으로 기입하게 한다. 카카오는 팀마다 다른데, 사전 인터뷰 때 과제를 주고 이메일로 제출하게 하여 코드를 미리 보기도 하며, 오프라인 인터뷰 때에는 화이트보드 코딩을 시키기도 한다.
기본적인 자료구조, 알고리즘, problem solving 문제들은 연습해가자.
IDE나 컴파일러에 의존하지 않고 짜는 코드는 problem solving skill 및 논리적 사고력을 향상하기에 아주 좋다. 고로, 단 기간에 되지 않는다는 이야기. 손 코딩은 평소에 해두어야 하며, 말로 설명하면서 연습하면 더욱 좋다.
내가 작성한 로직을 어떻게 설명할 수 있을까?
- 생각의 흐름을 계속 이야기하자!
- 특정 자료구조를 선택한 이유
- 내가 작성한 로직의 공간 복잡도와 시간 복잡도
- 여러 가지 테스트 케이스
K사 입사 전 G사의 면접을 준비하면서, 개발자들을 모아 스터디를 꾸려서 연습했다. 매주 문제를 선정 및 솔루션에 대해 논의하고 서로의 로직을 구성 및 화이트보드에 작성, 피드백을 주는 프로세스로 운영했다.
스터디까지 만들기 귀찮다면, 개인적으로 연습하기 좋은 사이트는 해커 랭크를 추천한다. 다양한 난이도와 도메인 문제, 풍부한 테스트 케이스, 문제별 open discussion 공간을 가지고 있어서 트레이닝하기 좋은 환경이다. UI가 깔끔한 것은 덤 :).
책은 코딩 인터뷰의 바이블 격인 코딩 인터뷰 완전분석(Cracking the coding interview)을 추천한다.
나를 어필
질문에 답을 하면서, 나의 태도는 매우 중요하다.
모르는 것도 '몰라요'라고만 하는 것보다, 어떤 느낌으로 말하냐에 따라 면접관들에게 나의 이미지는 천지 차이다.
- 내가 가지고 있는 개발에 대한 철학, 가치관을 공유하자.
- 내가 잘할 수 있는 것에 대해 어필하자.
- 나는 협업을 잘할 수 있는 사람임을 어필하자.
- 나는 열정적인 사람임을 어필하자.
기술 면접은 호락호락하지 않다.
기본기가 잘 다져져 있어야 하며, 그간 내가 해왔던 것들을 깊이 있게 잘 알고 있어야 한다.
'~을 했다.'에서 끝나지 않고, 어떤 실패를 했고, 어떻게 극복했고, 어떤 것을 얻었는지 말할 수 있어야 한다. 문제가 생겼을 때, stackoverflow나 구글 신의 힘을 빌려 코드를 후다닥 copy & paste만 했다면 깊이가 없을 터, 면접에서 잘 대답하기는 힘들 것이다.
내가 무슨 코드를 작성하고 있는지 충분히 생각하고 고민하자. 내가 작성한 코드가 어떤 side effect를 발생시킬 수 있을지, 또 다른 방법은 없을지 고민하며 모든 코딩에 임하고, 지속적으로 나의 try/fail/finally를 기록하는 습관을 가져보자.
준비를 철저히해도 별거 아닌거에서 멘탈이 털릴 수도 있고 한순간 꼬이면 원래 멘탈로 돌아오기 힘들더라. 아는것도 모르는 것이 되어버리고, 힌트를 힌트답게 사용하지 못한 적도 있다. 면접은 항상 긴장되고 어렵다.
