Back to basics

지난 주말에 느낀 점이 있어서 Junior 기준 Technical 인터뷰에서 질문하는 질문 형식들에 대해 간략하게 포스팅을 남길까 합니다.

GTA지역 한인 개발자 모임에서 구직자 몇 분이 모여서 취업 스터디를 같이 해 오셨는데, 그 마지막 스터디로 모의 인터뷰를 하는데, 저를 비롯한 몇 분께 interviewer 롤을 맡을 수 있는지 부탁을 하더군요. 사실 저는 Interviewer로서의 경험은 한 손에 다 꼽힐만큼 적고, Interviewee로서의 경험 역시 열손가락에 한참 부족할 만큼 적은 상황인데다, Junior로서 제대로 인터뷰를 본 것은 달랑 한번인지라 거절을 했지만, 이런저런 사유로 모바일 쪽에 다른 경력자들 께서 사정이 여의치 않다보니 제가 모의 인터뷰의 Android쪽 기술 인터뷰 Interviewee로서 참석을 하게 되었고, 그래서 기존에 경험들을 기반으로 인터뷰 질문지를 준비 했었습니다.

캐나다에서 첫 인터뷰를 하고, 처음으로 취업에 되었을 때 올린 글에도 당시에 제가 받았던 질문들에도 나와있는데, 사실 캐나다에서 이후에도 시니어 포지션으로 면접을 볼 때에도 거의 항상 나오는 질문 유형들이 있습니다. 

첫 번째 유형의 질문셋은 이 포스팅 제목에서도 감 잡으셨겠지만, 아주 fundamental하고도 기본적인 그런 질문들입니다.
두 번째 유형은 지원자의 실제 경력이나 경험을 파악하고자 하는 의도가 있는 질문들로 회사 업무에서 바로 사용하게 될 특정 skill set에 관련된 in-depth 질문들입니다.
그리고 마지막 유형은 코딩 능력과 간단한 알고리즘 이해/구현 능력을 보는 질문들입니다.

사실 인터뷰에서 질문을 하는 내용이나 틀은 각 회사마다 다 다르겠지만, 인터뷰 틀이 어느정도 잡힌 회사들이라면 보통은 이와 같은 틀 내에서 움직입니다.

첫 번째 fundamental 질문의 예를 들자면,

- Class/Interface/Abstract Class는 어떻게 다르죠? 어떨 때 어떤 것을 사용하나요?

- 오버라이딩과 오버로딩에 대해 설명 해 보시겠어요?

- xxx 키워드에 대해 설명 해 보시겠어요? 어떨 때 그걸 사용할까요? (final, static, synchronized...)

- Activity와 Service는 무엇이 다르고 무엇이 같죠?

- Android에서 Context가 무엇일까요?

- Activity와 Fragment 라이프사이클과 각각의 콜백에서 놓치면 않되는 중요한 행위들이 무었이 있고 왜 그것이 중요한지 몇가지만 설명 해 보실래요?

회사 내부 인력 사정상 피치못하게 제가 기술면접에 Interviewer로서 나가게 되었을 때에도, 회사 팀 리드들이 미리 뽑아놓았던 문제은행(?)에도 이런류의 질문은 반드시 처음에 있었고, 시니어 포지션으로 다른 회사에 면접을 볼 때에도, Junior 때 보다는 비중은 줄었지만 적어도 한 두 문제 정도는 이런 류의 질문이 꼭 나왔었습니다.

그리고 제가 Interviewer로 나가기 전에 교육 받은 내용에도 그랬고, 제가 Interviewer로서 느낀 바로도 그랬는데, 질문은 interviewee의 백그라운드에 따라 꼬리에 꼬리를 무는 방식으로 진행이 됩니다.

즉 쉬운 질문부터 시작해서 점점 난이도가 있는 질문들을 던져보며 지원한 포지션에 맞는 스킬셋에 대해 어느정도의 seniority를 갖췄는지 판단하기 위함입니다. 그리고 간단한 알고리즘 구현에 대한 코딩 시험을 거치며 1) 단순히 달달 외워가며 인터뷰만 준비한 사람인지 아닌지도 확인 해 보고, 2) 코딩 습관이 어떤 사람인지도 파악 해 보고, 3) 문제에 따라 덤으로 얼마나 꼼꼼한 사람인지도 확인 해 봅니다.

한 손으로 꼽을만큼 적은 경험이지만, 제가 Interviewer일 때에 이런 fundamental 질문들은 사실 형식적으로 던졌습니다. 당연히 답변을 할 것이라고 기대는 깔고 있었고, 실제로 제가 interviewer로 나갔을 때에는 대부분의 interviewee들이 이런 질문들에 대해 적절히 대응 했었습니다.

그 다음 질문셋은 지원한 롤에서 요구하는 기술셋에 대해 어느정도 지식과 경험이 있는지 판단하는 그런 류의 질문들입니다. 사실 하나하나 놓고보면 어려운 질문은 아니긴 하지만, 회사에 오면 당장 자주 부딛칠 수 있는 일들에 대한 내용에 대해 얼마나 경험이 있는지, 혹은 경험은 없더라도 이론적으로라도 이해하고 있는지 보는 것입니다.

예를들면 제 직전 포스팅에서 처럼, 화려한 UI 구현이 필요한 회사라면 다양한 UI 구현 Skill에 대한 질문이나, 안드로이드에서 Service/Intent Service/Thread/AsyncTask에 대한 질문, 혹은 최근 안드로이드 OS에 추가된 Run time permission이 뭔지 또 어떻게 app에서 대응해야하는지, Doze Mode는 무었인지, 또 각 app은 이를 어떻게 처리해야 하는지 같은 질문을 할 것입니다. 

저희 회사의 경우는 업무 특성상 UI가 거의 없기에 보통 묻는 질문들이 Android Fundamental과 과련된 질문들이 좀 더 많습니다. 예를들어, Looper/Handler 설명, Android에서 각 app은 어떻게 isolated된 환경에서 구동되는 것인지, Shared UID, package signing은 무엇이고 대략적으로 어떻게 동작하는 것인지, Permission Level, Out Of Memory가 무엇이고, 어떻게 하면 이를 최대한 회피할 수 있는지 등등...

그리고 Junior인 경우 (혹은 기존 경력들이 있지만 우리가 지원자에 경력에 대해 잘 감이 안잡히는 경우. eg. 찾을 수 없는 회사 경력, 전혀 모르겠는 외국 회사 경력. 정말 상품화 과제를 한 적이 있는지 잘 모르겠는 경력 등등)에는 toy project에서는 구지 필요 없지만, 상용화 프로젝트에서는 필요 한 그런 기술들을 좀 더 자주 물어봅니다. 예를들어 Android에서 Unit Test, Instrumented Unit Test는 어떻게 하는지, Proguard는 뭐고 왜 쓰는지, 그리고 이런 것들을 한 번이라도 해 본 적 있는지 등등...

이런 류의 질문셋에서 간혹 안좋은 질문들을 보는 경우도 있는데, 특정 오픈소스 혹은 유료 라이브러리에 대해 별다른 배경설명 없이 직접적으로 질문이 들어가는 경우들입니다. 사실 이런 라이브러리들은 말 그대로 각 프로젝트 성격에 따라 다른 라이브러리로 변경이 될 수도 있고, 또 그럴 때 마다 필요에 따라 reference보고 몇몇 라이브러리 도입 acceptance test를 해보면 다 알 수 있는것이라 단순히 경험의 많고 적음만 볼 수 있지 경험의 깊이를 알기에는 일반적으로 어려운 질문들이기 때문이죠. 특정 라이브러리를 직접 언급하면서도 나름 괜찮았다고 생각했던 질문이 하나 있었는데, 특정 라이브러리의 어떤 API의 입력값/출력값, 그리고 내부 동작 원리를 간단히 설명하고, 제품 요구사항을 설명하더니, 이렇게 요구사항과 API behaviour가 상이한데 어떠한 방식으로 Wrapper Layer를 구현하면 좋을까 라는 질문이였죠.

그리고 회사에 따라 퀴즈, 혹은 해커톤에 가까운 번뜩이는 아이디어나, 복잡한 알고리즘 적용을 하는 류의 문제가 있기도 합니다. 저희 회사에서도 제가 입사하기 이전에는 이런 문제들을 종종 냈다고 하는데, 이런 류의 문제는 사람이 얼마나 학술적인 혹은 수학적인 사고능력을 갖췄는지 판단하는데 도움이 되지만, 실제 업무에서 이런 이슈를 만나는 경우가 거의 없기에, 업무능력 판단에는 무의미하다는 내부 결론으로 제가 아는한 요즘에는 이런 유형의 문제는 내지 않습니다.

그리고 코딩 문제는 사실 많이 어려운 문제는 아닙니다.

간단한 소팅이나, 루프, 재귀, 자료구조나 tree traversal같은 류를 구현하는 문제들이고, 만약 문제 내에 특정 알고리즘알아야만 하는 것이라면 해당 알고리즘의 설계 원리도 미리 알려주기에 interviewee 입장에서는 이를 적절히 구현만 하면 되는 식의 문제입니다.

코딩 문제에서는 당연히 이 사람이 알려준 알고리즘을 제대로 구현하는가를 먼저 봅니다. 그리고 구현해 냈다면, 이 사람의 코딩 습관이나 스타일도 간략하게 확인 합니다. 문제 성향에 따라 이 사람이 주어진 요구조건에 맞는 절절하고 효율적인 자료구조형태나 설계를 했는지도 보기도 하고요. Junior 면접 때에는 특히나 일부러 HashSet(or HashMap)을 쓰는 것이 딱 맞는 문제나, 중복 키/값이 반드시 있을 수 밖에 없기에, 혹은 잦은 sorting이 필요하기에 무조건 쓸 수 없지만 왠지 Hash를 써야만 할 것 처럼 첫 인상을 주는 문제 유형을 만들어서 내기도 합니다. Hash의 유혹에 전혀 흔들리지 않는 것 같으면, "여기 이거 HashSet 쓰면 안될까?" 라고 일부러 질문을 던지기도 하고요.

그리고 앞선 질문들과 코딩 문제를 잘 소화해 냈다면 기존 문제에서 확장을 해보거나, 우리 내부적으로 봤을 때 조금 더 어려운 난이도의 문제를 한두개 더 내기도 합니다.

예를들어 3/6/9 게임하고 비슷한 Fizz Buzz라는 게임이 있습니다.

차례대로 숫자를 말하되 3의 배수라면 숫자 대신 Fizz가, 5의 배수라면 Buzz를 말해야 하고, 3과 5의 공배수라면 FizzBuzz를 말해야 하는 게임입니다.

그러면 첫번째 난이도 문제로 1~n까지 FizzBuzz 게임 룰로 stdout 출력하는 프로그램을 짜보게 합니다.

두번째로는 배수 뿐 아니라 그 수의 첫번째 자리수 혹은 마지막 자리수의 숫자가 3이면 Fizz 5면 Buzz가 나오는 것으로 확장하여 수정을 요구합니다.

마지막으로는 자릿수에 상관없이 3이 들어가는 숫자는 다 Fizz, 5가 하나라도 들어가면 Buzz 나오는 것으로 수정을 요구하죠.

그래서 제가 이번 스터디 용으로 준비한 질문지 역시 위에 언급한 내용들로 준비를 해갔는데, 예상치 못한 변수로 인해 사실 첫번째 Fundamental 질문 이외의 질문은 거의 하지 못했습니다.

우선 참석자들의 데모그래픽을 보자면 대부분 캐나다로 오시기 이전에는 SW Developer 경력과 학력이 보통 없으셨고, 있더라도 10~20여년 전 경력인 분들이셨기에, 사실상 캐나다 컬리지를 통해 SW 관련 공부를 처음 하시거나 새로 하신 분들이셨습니다. 그래도 학교 재학도중 매 코옵 학기마다 코옵 쟙을 잘 구해 경력을 이미 어느정도 만드셨거나, 포트폴리오로 쓸 만한 수준의 App을 이미 개발하여 올리신 분들도 있었죠.

하지만, 저로서는 처음 접한 경험이긴 한데, 면접 시작부분에 묻게되는 Fundamental 질문에서 열에 아홉은 대부분 답변을 하지 못하였습니다. 단순한 언어의 장벽으로 제대로 설명이 못된 것이 아니라 OOP의 기본 철학에 대한 이해가 없다는 것을 느꼈죠. 제가 다른 포스팅들에서도 틈이 날 때 마다 캐나다 컬리지의 실망스러운 학업 수준에 대해 언급을 했었는데, 이번에 구직 스터디에 참석을 하면서 이러한 문제가 단순히 제가 다녔던 컬리지만의 문제는 아닐것 같다고 다시한번 느끼게 되었습니다.

워낙 컬리지에서 배우는 SW는 기본적인 이론에 대해 충분한 생각과 학습을 하기 보다는 일단 IDE 띄워서 메인 메소드 만들고 커맨드 창이건 UI로건 뭔가 빨리 보여주는 것만 배우다보니 아주 기본적인 개념에 대한 학습과 이해가 부족할 수 밖에 없는 것이이라 생각합니다.

아무래도 인터뷰의 서두에 Fundamental 질문에서부터 꽉 막히다보니, 이후 참석자의 seniority level이나 경험을 확인하기 위해 파고들어가는 인터뷰가 진행될 수 없었던 것입니다. 그리고 당시 제가 느꼈던 솔직한 심정은 이후 코딩 테스트에서 잘 동작하는 코드를 만드신 분들 역시 썩 좋은 느낌이 아니였고, 만약 이것이 진짜 인터뷰라 인터뷰 결과를 보고해야만 한다면 저는 부정적인 피드백을 남겼을 것 같았습니다.

Back to basics. 언제나/누구에게나 중요한 일이긴 한데, 혹시나 컬리지를 통해 개발자가 되신 분이라면, 워낙 이 basic fundamental을 건너띄는 컬리지들이많다보니, 더욱 더 중요할 수 있다고 느꼈습니다.

아, 마지막으로 첨언을 하자면, Junior 포지션의 인터뷰에서는 사실 모든 질문에 답변을 받을 수 있을 것이라는 기대를 사실 않습니다. 하지만 Fundamental 관련된 질문들에 대해서는 지원자가 명확하게 컨셉을 잡고 있거나, 아니면 그렇다고 느껴지는 수준을 (말로 풀어서 각각의 개념 설명은 잘 못하지만, 어떤 경우에 어떻게 사용해야 하는지 잘 알고있는 경우) 기대합니다. 어차피 개인 프로젝트에서는 고려 할 일이 적거나 없는 실무 경험기반 지식들은 와서 하나씩 스스로 배울 수 있다고 생각하니까요. 

당연히 모든 질문에 정확한 대답을 한다면 좋겠지만, 그렇지 않더라도, 강한 fundamental 지식을 보였고, 코딩 능력도 부족함이 없었다면 인터뷰 후 좋은 피드백을 줍니다. 적어도 Junior로서 기대 할 만한 능력을 보인 지원자이기 때문이죠. 반대로 다른 질문들은 다 대답을 했지만, fundamental 질문에 대해 적절히 대응을 하지 못한 지원자인 경우에는, 저희 회사는 일단 그런 지원자는 선발하지 않는 것으로 공감대가 있습니다. 손기술만 있는 Coding Monkey를 채용하면 근본에서부터 잘못된 설계로 인해 잠재적으로 더 큰 문제를 만들어 나아 갈 위험이 크기 때문입니다.