하지만 Software engineer라면 당연히 기술력에 대한 검증을 하는 technical interview가 없을 수 없고, 한국 기업들과 조금은 상이하기에 제 경험을 바탕으로 기술면접에 대해 정리해 볼까 합니다.
제 경험상 한국에서 기술 면접은 크게 어렵다고 느낀 적도 없었고, 따로 면접을 본다고 무언가 준비한 적도 없는것 같습니다. 대졸 신입으로 입사를 할 때는 대기업이나 외국계 대기업에만 지원을 해 보았는데, 일부 회사는 필기시험을 보는 것으로 기술면접이 사실상 끝이기도 했고, 보통 기술면접이 있다고 해도 면접 시작 10여분 전에 이론이나 개념적인 것에 대한 질문이 주어지고, 면접장에 들어가 10분 정도 자신이 정리하고 생각한 내용을 구술하는 것이 전부였습니다. 경력직 역시도 이전 혹은 현재 직장에서 어떤 일을 하고 있는지, 직책이 무었인지 경력은 몇 년인지, 어떤 툴이나 언어 기술에 대해 알고 있거나 상용화 프로젝트에서 활용해 본 경험이 있는지 정도가 인터뷰의 주된 내용이지, 직접적인 기술 질문들이 별로 없었죠.
제 기억에 삼성에 신입 공채로 들어갔을 때 기술면접은 총 3가지 주제였는데, "암호화/복호화에 대해 설명하라.", "운영체제에서 스케쥴링 방식에 대해 설명하라.", 그리고 "CDMA의 Collision Detecting에 대해 설명하라.", 이 세 가지 중에 하나를 골라 5분 이내로 설명하고 나머지 5분 저도 질의응답을 받는 것으로 기억합니다. 사실 컴공/컴싸/소프트웨어 전공으로 정상적으로 학교를 다녔다면 3가지 중 하나는 충분히 설명 가능한 내용이고, '책으로만 공부해서 코딩은 못해요' 라고 말하는 코딩 젬뱅이들 이라도 기술면접에는 딱히 문제가 없었죠.
한국 대기업의 대졸 공채 문화에서는 작게는 백 여 명에서 많게는 수 천명의 직원을 뽑으면서 각 interviewee 개개인에게 많은 시간을 투자하기란 쉽지 않기에 당연한 것일 수 밖에 없겠지요. 하지만 여기는 공채 개념도 없고, 수시로 사람이 빌 때 마다 1-2명 수준의 구인 공고를 내거나, 회사가 어느 정도 규모가 있을 경우 상시 지원을 받고, 역시 인력이 필요 할 때 마다 회사 내부 인력 DB를 돌려 가장 적합한 지원자들에게 연락하는 식으로 구인 프로세스가 진행되다보니, 한국보다는 기술면접이 까다롭습니다. 지금서야 다시 기억이 나는데, 대학생 시절에 읽었던 책 중 하나인 '생각하는 프로그래밍'에서 저자가 씨에틀의 Microsoft 본사 입사 면접 경험에 대해 기술한 내용을 보고, 이게 뭐 학교 동아리 세미나도 아니고 어떻게 저렇게 하루종일 면접을 볼까를 의구심을 가짐과 동시에 역시나 가장 큰 Software회사라 그런지 다르긴 다르구나... 라고 생각했는데, 막상 제가 여기서 구직자가 되어 인터뷰들을 보다보니 북미쪽의 채용 문화 자체가 그렇다는 것을 알게 되었습니다.
그런데 도대체 어떻게 하기에 면접이 짧게는 1시간 보통은 2-3시간, 길면 하루종일 진행되나요? 라고 생각하실 수도 있는데, 제 이전 포스팅 중 하나인 소프트웨어 개발자 기술면접 및 취업 후기을 보시면 대충 감을 잡으실 수 있습니다.
이미 취업 확정이 된 상태에서, 그리고 회사를 다니고 있는 상황에서도 제가 지원한 지 몇 달이 지난 후에 연락이 와서 경험삼에 몇몇 곳에서 더 면접을 봤는데, 결국은 다 비슷 했습니다.
온라인 혹은 기술면접을 보러 회사에 온 상황에서 프로그래밍/디버깅 관련 시험을 봅니다. Java에서 abstract, interface의 차이점을 묻거나 오버로딩 오버라이딩의 차이점을 묻는 식의 이론 문제가 나오는 곳도 있었고요.
보통 이런 온라인이나 필기 시험이 기술 면접의 1단계라고 보시면 됩니다.
그러면 1차 면접이 끝나고 괜찮은 결과가 나왔다면, 1주일 정도 후에 화상 혹은 오프라인으로 그 회사의 senior engineer들과 면접이 진행됩니다. 이 때 물어보는 것 들이 한국 채용 문화에서 보면 상당히 골때리는데, 제가 정리해 보자면 보통 6가지 정도의 유형이 있는 것 같고, 대부분 기술 면접시 이 중에 3-4가지 유형 이상의 질문들이 나온다고 보시면 됩니다.
1. 기술에 대한 이론적 이해도 평가
결국 필기시험에서 abstract, interface등을 묻는 것과 비슷하게, 기술적 용어나 해당 기술의 사용법에 대해 질문을 합니다. 이런 질문들의 종류가 무었이 있을까에 대해서는 구글에서 Java Developer interview questions로 찾아보시면 대략 100여가지 종류의 질문들이 있는데, 대부분 이론 관련 질문들은 구글에서 찾으시는 그 내용들에서 나온다고 보시면 됩니다. 지원하는 포지션에서 요구하는 언어나 기술로 검색 키워드만 변경하면 어지간해서는 다 나온다고 보시면 됩니다.
가장 간단한 예를 들면, "abstract class, concrete class, and interface에 대한 설명과 비교, 어떤 경우 사용하는지 등에 대한 설명", "overriding and overloading", "Constructor and Destructor", "Garbage collector 는 어떻게 동작하는가", "Event handling", "Multi thread와 thread 동기화" 이런 내용들에 대해 처음에는 "그 용어가 뭐냐?", "써본적 있냐?", "언제 써봤냐?", "그걸 쓸 때 주의점은 뭐가 있을까?", "이런 경우 이걸 쓰는게 맞을까?"를 물어보는 거죠.
2. 알고리즘 / 자료구조에 대한 이해
한국에서도 가끔 중소규모 IT회사들에서 채용시 이런 방식으로 기술면접을 진행해서 개발자들 사이에서는 나름 깨어있는 회사로 좋은 평가를 받기도 합니다.
알고리즘이나 자료구조에 대해서는 해당 알고리즘을 설명하라는 식으로 진행되기 보다는 화이트 보드나 종이에 pseudo code로 직접 짜보라고 합니다.
그다지 복잡한 알고리즘을을 요구하지는 않습니다. 보통 링크드 리스트나 배열, 혹은 그에 대한 소팅과 머지 정도를 요구합니다. 제 경험상 가장 복잡한 알고리즘을 요구한 것은 트리 traversal이나 트리 변환 정도였고, AVL Tree를 묻는 곳도 있었는데, 좌우 밸런싱을 유지하는 트리라는 것 외에 정확히 기억이 안난다고 하니 알고리즘 내용을 알려주더군요. 저도 소제목은 알고리즘 / 자료구조로 적었지만, 사실상 간단한 알고리즘/자료구조 구현을 통한 실질적인 코딩 능력을 보는 것이죠. 알고리즘이 아니라 아주 간단한 함수 구현을 요구하기도 하는데, 예를 들면 ATOI, ITOA 메소드나 함수를 구현해 보라고 하기도 합니다.
아, 딱 한 번이지만 진짜 알고리즘을 물어보는 경우도 있었습니다. 문제 상황을 이야기 해주고, "이런 상황을 가장 빠르고 효율적으로 연산하기 위한 알고리즘을 설명해 보아라. Pseudo 코드도 좋고, flow chart도 좋고, 말로 설명해도 된다." 라고 하더군요. 정확히 기억은 안나지만 정렬되지 않은 포커카드 1세트가 있는데, 거기서 특정 카드가 없어졌던가, 중복으로 두 장이 들어갔던가 해서 그 카드를 찾는 알고리즘으로 기억하는데, 제 솔루션을 말하니 왜 그렇게 했는지, 거기서 이런 방식으로 정렬하는게 더 효과적이지 않은지, 등등의 내용을 토론하는 방식으로 진행 되었습니다. 이 카드 문제에 대한 토론만 30분 넘게 했었죠.
3. 디버깅 / 문제 분석 능력
디버깅 / 문제분석 능력도 대부분 회사의 기술면접 단계에서 이루어집니다. 1차 온라인 시험때 버그가 있거나 잠재적인 defect이 있거나, 혹은 exception handling이 제대로 되지 않은 코드들을 보여주고 수정하라고 하는 것이 보통이고, 실제 면대면 면접에서도 이런 문제들이 주어집니다. senior engineer가 화이트 보드에 pseudo code를 적어 두고, "어떤 기능을 구현하려 한건데 여기서 문제점이 뭔지 찾아봐라." 정도로 물어보죠. pseudo code이기에 보통 자잘한 syntax 오류에 대해서는 찾을 필요는 없지만 로직 흐름상 주요기능이 잘못 구현되었거나, 특정 boundary case에 대해 ≤, <, = 등 비교 연산자가 잘못되었거나 비교하는 index넘버가 잘못된 경우도 있고, ++ / -- 같은 증감연산자가 앞이나 뒤에 붙은게 잘못 붙어서 시작하는 index나 마지막 index값이 범위를 벗어나는 경우가 있기도 합니다.
4. 논리 퀴즈???
저도 지금 직장 면접 시 처음 접하게 된 유형인데, 논리퀴즈에 가까운 질문입니다. 나중에 찾아보니 이런 식으로 질문이 던져지는 경우들이 종종 있더군요. 결국 주어진 문제의 핵심은 프로그래밍과 관련된 로직 흐름, 비트 연산, 알고리즘에 대한 내용들이지만 질문 자체를 프로그래밍과는 동떨어진 일상생활이나 넌센스 퀴즈와 같은 방식으로 포장해서 던지는 질문들입니다. 예를들면 제 이전 포스팅에도 올라온 10명의 죄수와 1,000병의 와인 문제 같은 것들이죠.
5. 경력사항 확인/검증
인사 담당자와 보통 전화면접을 하면서 경력사항을 1차로 확인하게 되고, reference가 있다면 reference를 해주는 사람을 통해서도 경력 확인을 하지만, 지원자가 맘먹고 경력을 속이면 사실 회사에서 알 방법이 없죠. 그래서 보통 기술면접을 하면서 경력사항 확인을 합니다.
간단하게는 레주메에 기록된 경력 내용들에 대해, "이 프로젝트에서 너의 포지션이 뭐였냐?", "네 롤이 뭐였냐?", "이 프로젝트는 어떤 프로젝트였냐?", "이 프로젝트 구조에 대해 대략적으로 설명해봐라"와 같은 다소 일상적인 질문들만 던지기도 하지만, 보통은 그 보다 조금 더 자세하게 들어갑니다.
예를 들면 제가 A라는 프로젝트에서 단말과 서버간 push messaging을 담당했다고 가정한다면, "Push messaging을 하기 위해 어떤 기술을 사용했나? C2DM?, Google Could Message?, 자체 솔루션?", "Push messaging에서 단말과 서버간 연결 유지는 어떻게 하나?", "소켓 연결 라이프 사이클은 누가 어떻게 관리하나?", "단말이 deep sleep상태에 빠지면 어떻게 되나?", "Battery life에 미치는 영향은 없었나? 어떻게 해결했나?", "단말 네트워크가 끊긴 상태에서 재 연결이 되었을 때 그 동안 업데이트 내용들은 어떻게 서버에서 단말로 보내지는가", "heart beat signal이나 Push noti에서 헤더와 페이로드는 어떻게 구성되어 있었나", "왜 그런 식으로 설계한건가?" 이런 식으로 자세하게 파고들어 오기에 어지간해서는 대충 주어들은 지식들로 대응하기 힘들 수 있습니다.
특히 지금 회사에서는 주로 VP면접 때 제 경력에 대한 검증이 진행되었는데, 우리 VP가 좀 영악해서 이것 역시 좀 다른 방식으로 포장해서 질문을 했었습니다. 다시한번 Push Messaging예를 들자면 client, router, firewall, internet, server와 같은 일반적인 네트워크 다이어그램을 화이트 보드에 그려 놓은 후에, "client에서 server로 연결을 하려면 어떻게 찾아가지?" 라는 질문을 일차로 던지고, "server에서 client로는 그럼 어떻게 갈까?" 라고 두 번째 질문을 합니다. 그러고는, firewall과 internet 사이에 무선 기지국을 추가하고는 "client 가 모바일 기기거나 dynamic IP 기기인데 이럴 땐 서버에서 client를 항상 찾아갈 수 있다고 보장할 수 있는가?", "연결을 보장하려면 어떻게 해야할까?" 이런 식으로 면접이 진행되면서 결국엔 제 경력을 검증해보더군요.
6. 자세, 인성, 가능성?
마지막은 한국 입사면접에서 인성면접에서 볼 만한 내용들입니다.
왜 캐나다 까지 온거니? 한국에서 직장은 왜 관둔거니? 개발자로서 어려운 점은 무었이였니? 왜 개발자가 된거니? 앞으로도 계속 개발할꺼니? 왜 우리회사 지원한거니? 어떤 career plan을 가지고 있니? 개발자로서 언제가 가장 자랑스러운 순간이였니? 이런 류의 질문들이죠.
보통 메니져 면접이나, VP면접에서 반드시 나오기 마련이죠.
정말 운이 좋게도 첫 면접에서 바로 면접 마지막에 job offer를 받아서 이후 더 이상 직장을 찾아다니지 않다 보니 면접 경험이 그리 다양하지는 않지만, skype화상 통화를 포함해 총 5번의 기술면접 경험을 정리하자면 전부 위에 6가지 유형 내에서 질문들이 주어졌습니다.
한국의 고용 프로세스와는 조금 다른 문화인데다 외국인 입장에서 익숙하지 않은 영어로 표현해야 하기에 쉽지는 않지만, 미리 준비한다면 충분히 패스할 수 있습니다.
기본적인 로직 구현 능력이나 pseudo코드 구현이야 언어 능력과 별개의 것이니 차치하고, 구글에서 인터뷰 질문들 미리 뽑아서 답변들 한번씩 읽어보고, 영어로 어떻게 기술 용어들을 설명할 지 준비 해보고, 자신의 경력사항들을 영어로 러프하게 혹은 디테일하게 설명하는 연습을 미리 해 본다면 면접에서 좋은 결과가 있을 것이라고 생각하네요.
아, 중요한 것 한가지가 있네요.
이전 포스팅 영어로 면접보기, 자기소개에서 서류 통과를 하여 면접 기회를 따기 위해서는 지원하는 회사, 포지션과 경력사항이 일치하는 것이 중요하기에 거짓말이 아닌 수준에서 resume와 cover letter를 이에 맞춰 어느 정도는 포장, 왜곡 시키는 것도 필요하다고 말씀드렸는데, 매니져나 VP면접에서 경력사항 검증 질문들에 대한 답변 역시 이와 일치해야 합니다. 어느 회사건 이력서의 내용이 전부 100% fact라고 믿지는 않지만, 눈에 띄는 거짓이 보인다면 interviewer입장에서 interviewee에 대한 신뢰가 떨어질 수 밖에 없으니까요.
이제 다시 주말이네요. 한 주의 피로를 다시한번 말끔하게 잊고 재충전해서 다음 한 주도 열심히 달려보렵니다. 여러분도 화이팅 하세요.
댓글 없음:
댓글 쓰기