오늘은 면접에 대해서 제가 생각하는 것을 써보려고 합니다.
어차피 제가 경험한 면접이란 것이 개인적인 경험일 수 밖에 없겠지만, 혹시 도움이 될까.. 하는 생각에 씁니다.

좋든 싫든 면접이란 것을 종종 들어가게 됩니다. 작은 회사일수록 인력 채용이란 것이 중요하다보니, 제가 다니는 회사 역시 기술 면접 과정이 까다롭다고 알려져 있습니다. 일단 상당히 오랜시간 상당히 깊숙히 들어가는 면이 있어서 그렇기도 하고, 하드웨어 엔지니어를 뽑는 회사치고는 드물게 실기 면접을 병행하고 있기 때문이기도 할 것 같습니다.

첫 번째로 실기 면접의 경우 많은 경우에 아주 간단한 설계 + 이를 검증하기 위한 테스트 벤치로 구성되는데요.
실기 시험이란 것의 특성상 1) 문제를 읽고 설계 스펙을 구체화시켜 간단한 아키텍처를 만들어 내는 능력, 2) 이를 RTL(혹은 C)로 구현하는 능력, 3)구현된 부분을 검증하기 위한 테스트 벤치를 작성하는 능력, 4) 테스트 벤치에 맞는 테스트 시나리오를 만들고 이를 테스트 케이스로 만드는 능력, 5) 설계물과 설계 과정에 대해서 설명하는 능력을 보려고 하는 것이죠.
이 이야기는 정상적으로 동작하는 것을 만드는 것도 중요하지만, 이걸 어떤 방식으로 검증해야 하는지, 그리고 어떻게 분석해서 왜 이렇게 만들었는지를 논리적으로 설명하는 과정 역시 매우 중요하다는 것입니다.
즉, 실수한 부분이 있더라도 이걸 논리적으로 설명하려 노력하는 것이 중요합니다. 가끔은 실기 시험이란 것이 이야기를 풀어나가기 위한 시작점으로 사용되기 때문입니다.

두 번째로 경력 사항에 대한 설명이 있는데요.
경력자(혹은 석/박사)는 당연히 그 동안 했던 프로젝트 중 지원자가 생각하기에 가장 참여도가 높거나 가장 기억에 남는 주요 프로젝트 한 두가지를 가지고, 내용에 대해서 설명하고 질문에 답을 하는 것입니다.
(물론, 면접 위원들에게 특별히 눈이 가는 프로젝트가 있다면 (예를 들어, 저희 회사 같은 경우는 Video Codec) 이 부분에 대한 질문이 추가되기는 합니다. )
이때, 가장 fancy 해 보이는 프로젝트를 선택하지 마시고 가장 자신 있는 프로젝트를 선택하시는 것이 좋습니다.
보통 면접위원들은 프로젝트 자체에 대해서는 대부분 별로 관심이 없습니다. 다만, 어떤 식으로 일을 했는지 살펴보기 위한 “이야기꺼리”로 프로젝트를 사용하는 것뿐이죠.
따라서, 보통 상당히 긴 시간동안 프로젝트에 대해서 이야기하게 되는데, 이런 종류의 일을 할 때 반드시 알고 있어야 할 것이라 생각하는 다양한 사항들을 물어보며, 스펙부터 설계, 기법까지 다양한 부분에 대해서 질문과 답을 나누게 됩니다.

이 부분에서 중요한 건 틀려도 되니까, 당황하지 않고 논리적으로 이야기가 진행되는 것이 중요합니다.
예를 들어, bandwidth등을 물어봤을 때 실제 수치가 중요한 것이 아니라 논리적으로 어떤 방법으로 계산을 진행했으며, 이런 이런 파라미터가 왜/어떻게 사용된다가 중요한 것이지 정확한 숫자를 기억해 내기 위해서 노력할 필요까지는 없습니다. (보통은 말이죠. 다만 그 수치 자체가 중요한 경우도 있기는 합니다. – 이 일을 하는데 당연히 알아야만 하는 숫자라면 말이죠. )
또한, 앞에도 언급했지만 이런 종류의 일을 하기 위해서 반드시 알아야 하는 사항들이 이 이야기 프로젝트 이야기에 질문으로 나오게 됩니다. (보통 하드웨어 엔지니어, 검증 엔지니어, 소프트웨어 엔지니어의 기본적인 면접 질문을 포함해서..)

가끔 상당히 괜찮아 보이는데, 면접 과정에서 계속된 질문으로 심하게 당황하셔서 당연히 아실 것이라 생각되는 질문조차 답을 못하는 경우가 있습니다.
이런 경우에는 면접위원으로 들어갔음에도 제가 더 안타깝습니다.  조금만 보고 왔다면 당황하지 않을텐데.. 하는 생각이 들기도 하고요.
(사실 이 글을 쓰게 된 직접적인 원인이기도 합니다.)

마지막으로, 글의 성격에 맞게 기술 면접 전에 챙겨보면 도움이 될 만한 것을 이야기하자면..

1. 구글에서 일반적인 “하드웨어 설계 엔지니어/하드웨어 검증 엔지니어/ 소프트웨어 엔지니어 ” 인터뷰 질문을 대충 한번 훓어보고 오면 도움이 됩니다. 예를 들어 하드웨어 엔지니어라면 metastable/CDC 문제는 아주 기본입니다. (http://babyworm.net/archives/150 )
2. 경력 사항 중 중요한 프로젝트에 대해서 한번 보면서, 당시에 “어떻게” 스펙을 정했는지, “어떻게” 일을 진행해 나갔는지, “어떻게” 검증 시나리오를 작성했는지, “어떻게” 합성 조건을 잡았는지 등을 기억해 보는 것도 도움이 됩니다. “어떤”일을 했는지도 중요하긴 한데 “어떻게”가 더 중요합니다.
3. 목적으로 하는 회사에서 원하는 것이 어떤 것인지 확인해 보는 것도 중요합니다. 보통 필수 부분과 우대 부분이 있는데, 이 부분에서 대해서 강조하는 것이 좋습니다.
4. 면접이란 것이 ‘지원자’가 이 회사를 선택하지 않으면 이루어질 수 없습니다. 따라서, 면접 과정에서 이 회사에서 나에게 어떤 것을 원하는지를 탐색해 보는 것도 잊으면 안될 것 같습니다. (물론, 국내에서는 이게 허용되지 않는 곳도 있습니다만…)

진짜 마지막으로, 인터뷰는 누구를 배제하기 위한 과정이 아니라, 뽑기 위한 과정이기 때문에 질문이 반복되더라도 ‘공격받는다’라고 생각하셔서 당황하실 필요가 없다고 봅니다.

면접 보시는 분들께 좋은 결과가 있길 바랍니다.

오늘 결재 메시지가 온걸 보니 Netflix를 사용한지 꼬박 한달이 되었나봅니다.

그동안 Netflix에 대한 많은 이야기들이 있었는데, 개인적으로 몇가지 이야기하고 싶은 부분이 있습니다.

Netflix를 사용하면서 가장 크게 느낀 점은 상당히 사용자 친화적이란 겁니다.  추상적이죠?

구체적으로 이야기하자면, 광고가 없습니다.  그동안 많은 서비스들에서 유료 고객에게 버젓히 광고를 강요했고(시작할때, VOD 하나를 켤때, 채널 돌릴때 등등), 우리는 어느틈에 내 데이터를 희생하며 광고를 보는데 너무 익숙해져 있었다는 겁니다.

처음 Netflix를 이용하면서 이 작은 차이로 인해서 “너무나도 편안하게” 컨텐츠에 집중하게 되더군요.

두번째 차이는, 시리즈를 볼때 자막과 동시에 다음편으로 넘어갈 수 있도록 만들어줍니다. 별거 아닌것 같지만 이어볼때 아주 편리하더군요.

 

세번째는 영상의 화질(실제로는 영상의 크기를 포함해서.)이 자유롭게 변하면서 버퍼링을 최소화한다는 점입니다.

예전에 MPEG meeting에서 Netflix에서 나온 사람이 bitrate보다 해상도를 변경시키는 것이 사용자들에게 더 좋더라.. 그래서 자신들은 scaleable codec이 아주 중요하다는 이야기를 한 적이 있어서 유심히 봤는데, 정말 부드럽게 해상도와 bitrate가 변하더군요. (SVC는 아닐테니 simulcast겠죠.) 미국 인터넷 트래픽의 50%이상을 점유하고 있는 회사의 의견이니 아마 HEVC scaleable codec + DASH가  조금더 발전할 수도 있겠습니다.

여하튼, 중간에 잠시 딴 이야기를 했네요. 마지막으로 짚고 싶은건 이어 보기가 쉽다는 겁니다. 핸드폰에서 보다가, ipad에서 보다가 PC에서 보다가.. 이런 식으로 하는데 모든 기기에서 언제든지 “조금전에 보던 부분”에서부터 다시 볼 수 있습니다.  뭐 귀찮게 pop-up이 뜨거나 하지도 않고, 그 영상을 누르면 거기서부터 다시 볼 수 있습니다.

Netflix를 써보고 느낀 점은 간단합니다. 큰 차이는 아닌데, 상당히 편하다는 겁니다. 국내 VOD에서 기술적으로 못할거냐.. 하면 그건 아닌데, 국내 서비스는 어떤 서비스를 나타낼 때 “강요”하거나 수많은 기능을 “나열”하는데 반해서, Netflix는 그냥 어떻게 배치해야 쉽게 선택될 것인지를 고민하고 은근하게 알려주는 맛이 있습니다. 어떤 기능을 전면에 내세우지 않고도 ‘그냥되는’ 그런 맛이 있는 거죠.

엔지니어의 입장에서 사실 이해는 됩니다. 기능을 PR하지 않으면 어느 순간 짤릴수도 있고, 무능하다고 평가 받을 수도 있으니까 어떻게든 전면에 보여주고 싶고, pop-up으로 나타내고도 싶고.. 회사에 이익을 가져다 줘야 하니까 버퍼링하는 중간 중간에 광고도 끼워넣고 싶은 마음이겠죠.

제가 알기에 “성과 지상주의”는 Netflix에서 아주 심한데요.. (Netflix의 절대적인 평가 기준이 유명하죠.  “경쟁사로 이직해도 잡지 않을 것 같은 직원은 즉시 내보내라”는 평가기준..) 여기서는 왜 이렇지 않을까요. 바로 최상위 설계자(혹은 결정권자라 이야기해도 마찬가지입니다.)의 역량 차이가 아닐까요? 뒤에 있는 기능도 인정받을 수 있다면, 굳이 전면에 배치하지 않을 것이고, 여러 기능을 균형감있게 배치하는 것 말이죠.

작은 차이지만, 어찌보면 큰 차이일 것 같습니다.

2016년 병신년이 되었습니다. 어감은 이상하지만요.

연초에 안사람과 딸래미가 반친구들과 1박 2일로 놀러갔었는데요.. 이 황금같은 “진짜” 연휴를 어떻게 보내야 하나.. 생각하다가 문득 글이나 써볼까 싶었었습니다. (과거형이니 이미 안사람과 딸래미는 돌아왔습니다. 대신 제가 월요일부터 열심히 데리고 다니고 있죠.. 여하튼..)

그런데, “영양가 있는” 글이 참 안써지더군요.

이유가 뭘까 조금 생각해보게 되었습니다.  예전에는 참 별거 아닌거로도 글을 잘 끄적거렸는데 말이죠.

가장 큰 이유는 SNS때문인 것 같습니다. 짧게 개인적인 뭔가를 남기기에 SNS가 너무 편합니다. 에디터만 해도 그렇고요.

두번째는 예전보다 아는게 ‘조금은’ 더 많아졌기 때문인거 같습니다. 예전에는 무식하면 용감하다고 그냥 글을 적어보고, 궁금하면 그냥 코딩해보고 그랬는데.. 이제는 틀리면 어쩌지.. 라는 생각도 들고, 혹시 이게 업무 연관성이 있어서 대외비를 유출하는 건 아닐까 싶은 자기 검열도 심해졌고, reference도 찾을 생각 + 코드나 사진 같은 것을 같이 첨부할 생각에  ‘귀찮다…’라는 생각이 불쑥 불쑥 듭니다.

사실 제 블로그에 draft  상태로 publish 되지 않은 글이 상당수 있습니다. 아무생각없이 예제 코드를 적고나니 ‘이건 우리 회사에서 했던 건데..  ‘ 이렇고 빼고 나면 새로 코드 짜기도 귀찮고.. 열심히 적어놓고 ‘요거 찾아보고 나서..’ 라고 생각한 다음 결국 귀찮음에 지는 거죠.

세번째는 쉬고 싶다는 생각 때문인 것 같습니다. 예전에는 집에서도 논문보고 코딩하는 거 참 좋아했는데.. 요즘엔 많이 못하네요. 연휴에 기초적인 안드로이드 앱을 하나 만들 생각으로 Android Studio를 받았는데.. 음.. 버튼 몇개 붙인 hello world도 앱인가.. (사실 예전에 만들려던 위치받아서 주기적으로 서버의 RESTful address를 이용해서 위치를 보내는 앱을 만들 생각이었는데, 결국은 만들다 말고 hello world와 다를바 없는 앱이 되었네요.. 아마 안끝낼듯..) 만들다가 XCOM을 건드리는 것이 망하는 지름길이죠.

마지막으로는 비난받기 싫다는 감정도 있는 것 같습니다. 비난이라고 썼지만, 실제 비난보다는 ‘내 부탁을 왜 안들어주니..’라는 비난이죠. 예전에 블로그를 나름 열심히 운영할 때는 숙제/업무상 궁금증에 대한 질문이 참 많았습니다.

이해합니다.

안풀릴때의 답답함이나, 알 것 같은 누구에게든 답을 듣고 싶어하는 마음을 저도 잘 압니다. 저도 많이 그랬고, 정말 도움도 많이 받았습니다. 그래서 되도록이면 blog, 게시판, e-mail로 자주 알려드렸는데요. 어느 순간 같은 질문이 반복되고, 알려주지 않는다고 비난하시는 분들이 생기면서 그냥 모든 글에 반응하지 않게 되더군요.

사실 비슷한 이유로 블로그에 방문자가 늘어나면 블로그를 폐쇠하고 이동하는 일을 몇 번했죠..  찾기 힘든 섬같은 느낌의 블로깅을 하고 싶었거든요..

이제는 블로그에 사용하는 사람도, 찾는 사람도 별로 없으니  편하게 글을 쓸 수 있는 환경이 되었지만, 긴 글을 읽지 않는 환경이 되었죠.

즉, 글만 길게 쓰면 찾아오지 않겠죠. (아닌가..)

여하튼, 그래서 2016년에는 글을 좀 써볼 예정입니다. 예전부터 많은 분들이 써보라고 권유하는 내용도 있고, 업무 연관성 관련해서 ‘직접적으로’ 대외비를 유출하지만 않는다면 적극적으로 써보려고요. (사실 일이 거의 비슷한지라.. 완전히 새로운 걸 하기는 어렵고 여하튼.. 회사에서 직접적으로 회사일로 한 것만 아니면 되겠죠. )