나의 작은 Job Interview 팁

안녕하세요 둥이네 아빠입니다.

이제 내일이면 입사 교육이 끝나고, 제 부서로 자리를 옮길 예정입니다. 일단 팀원이라고는 저 혼자 뿐이지만 새로운 팀 킥오프도 합니다. 제 팀에서 해야 할 일을 저 스스로 찾아가야 하기에 이전에 했던 일 보다 더 부담되기는 하지만, 그래도 그나마 제가 가진 능력 중에 조금은 나은 분야의 일로 돌아가기에 즐겁네요. 

사실 이 글은 현재 직장으로 이직을 생각하면서 올리려고 작성 해 두었던 글인데, 생각보다 인터뷰 스케쥴 잡히는 것 부터 채용까지 진행이 일사천리로 되어버려 미처 글을 마무리 짓지 못하여 지금에서야 올리는 글입니다.

다름아닌 Job Interview에 대한 것인데, 제가 채용 인터뷰의 전문가도 아니고, 커뮤니케이션의 달인도 아니니, 거창하게 인터뷰 기술이나, 필승 공략법이라고 말 하기에는 힘들고, 예전부터 그냥 제 경험과 여기저기서 주어들은 지식들을 섞어서 만든 조악한 팁 정도로 생각하시면 됩니다.

Interview의 형태와 내용은 지원 Position과 Job에 따라 다르지만 거의 모든 경우에 들어가는 인터뷰 프로세스가 Behavioural Interview라고 할 수 있습니다. 한국에서 이른바 인성면접이라고 통칭하는 면접과 비슷한 면접으로, 직무 기술보다는 Soft Skills를 검증하는 자리라고 생각하시면 됩니다.

회사에 인터뷰에 대한 가이드가 체계적으로 잡힌 경우라면 Behavioural Interview에서 어떠한 항목에 비중을 더 두어야 하는지, 아니면 최소한 어떠한 것들은 필수로 검증해야 하는지 정해져 있기도 합니다. 예를 들어서, 
"Communication, Empathy, Self-Motivation, Teamwork는 필수로 보고, Personal Development, Creativity, Mentoring, Royalty, Pride등을 보는 것을 권장" 이런 식이죠.

별도의 인터뷰 가이드가 없다면 Interviewer의 재량에 따라 각자 알아서 판단하기도 합니다.

그리고 저와 같은 Software Engineer라거나 그와 유사한 기술직들은 직무 능력을 평가하는 Technical Interview 단계가 있습니다.

Technical Interview의 경우 그 형태나 단계가 회사마다 다양한데, SW 쪽에서는 일반적으로 큰 규모의 기업이고 IT 기업일 수록 좀 더 단계가 많고 좀 더 오랜 시간을 투자합니다.

가장 기본적인 Technical Interview의 형태로는 채용을 진행하는 hiring team의 엔지니어들과 1-2시간 가량 질의응답 및 토론을 하는 것입니다.

작은 회사에서는 아직 이런 경우를 보지 못했는데 IT 공룡 기업들에서는 보통 hiring team 뿐만 아니라 전혀 관계가 없는 다른 팀의 엔지니어와 따로 기술 면접을 추가로 보거나, 그 사람이 기술면접 장소에 동석하는 경우도 있습니다. Hiring team에서는 당장 사람이 부족해 힘들다보니 어지간하면 통과시키고 싶은 마음이 분명히 있습니다. 하지만 그 포지션에 걸맞는 실력을 가진 사람이 아니면 채용하지 아니하는 것 만 못하다는 속설이 있는데, 규모가 큰 IT 기업들은 이 말을 비교적 잘 따르는 편이죠. 그렇게 외부에서 온 엔지니어는 보통 지원자에 대한 평가권한은 없지만, 절대 거부권이 있습니다. 절대 거부권은 다른 모든 Interviewer들이 찬성을 해도 그 사람이 거부하면 절대 채용될 수 없는 권한입니다. 즉 합격에는 아무런 영향을 줄 수 없지만, 탈락에는 절대적인 영향력을 가지죠. 

아무리 손이 부족해도 아무나 뽑지 않게 하기위한 장치로 활용하는 회사들이 많이 있습니다.

사실 캐나다는 네트워크 사회라 네트워크 없으면 구직 못한다는 말도 많은데, 이런 채용 프로세스를 생각하면 아무리 내 친구가 자기 팀으로 끌어준다 해도 전혀 모르던 다른부서 직원이 인터뷰에 동참하여 거부권을 행사 할 수도 있는 것이기에 네크워크가 넓으면 기회는 좀 더 많이 부여받을 수 있지만, 채용까지는 결국 본인 실력이 있어야 합니다.

이런 큰 회사들은 기술면접도 다단계로 진행하는 경우가 많이 있습니다. 
질의응답 식의 일반적인 기술 면접, 문제 상황에 대한 해결방법 토론, 설계에 대한 토론, on site 코딩 혹은 디버깅 테스트 등등... 여러가지 다양한 방법으로 지원자의 기술을 확인 해 보죠.

이 처럼 여러 단계를 거치고 오랜 시간동안 지원자를 테스트 하다보면, 이른바 '입코딩'을 하는 말만 번지르르한 '저' 같은 지원자를 걸러내고 진짜 실력과 풍부한 경험이 있는 지원자를 찾아내기 수월한 점은 있지만, 사람 한 명 뽑을 때 마다 회사 입장에서도 지원자 한 명당 수십 시간을 투자해야 하고, 며칠간에 걸쳐 다단계로 진행되는 면접을 참고 기다릴 만큼 지원자에게 매력적인 경우가 아니라면 적용하기 힘든 단점이 있습니다.
저만 하여도 인터뷰가 하루종일 이뤄진다는 것 까지는 받아들일 수 있는데, 여러 날에 걸쳐서 이뤄지는 경우 제 개인휴가를 여러 번 쓰기 아까워 망설이게 되는 것이 보통이니까요.

그래서 정말 많은 메리트들이 있는 일부 기업을 제외하면 대부분의 회사들은 1-2 시간 이내에 기술면접을 마치게 되는데, Interviewer로서 경험이 있으신 분들이라면 1-2시간 이내에 지원자의 실력을 확실히 파악하는 것이 얼마나 쉽지 않은 일인지 잘 아실 것입니다.
차라리 신입 채용의 경우에는 워낙 확실하게 못하는 지원자들이 많아 처음 5분만 이야기해도 

'아... 남은 55분은 그냥 버려지는 시간이군' 

이런 생각이 드는 경우가 적지 않지만 3-6년 정도의 경력자를 인터뷰 할 때에는 한치건 오징어건 다 비슷하게 보이는 경우가 정말 많죠.

그래서 이전 직장에서 제가 채용 시 마다 불만을 제기했던 이슈 중 하나가, 기술 면접으로 2시간이 아닌 1시간으로 제한한다는 점과, 인터뷰 이전에는 지원자의 온라인 코딩시험 점수를 알려주지도 않고, 코딩시험의 점수에 무관하게 모두에게 인터뷰 기회가 제공된다는 것이였습니다. 
인터뷰 이전에 점수를 알면 일종의 선입견이 생길 수도 있다는 것에는 동의합니다. 하지만 1시간 내에 정확한 파악이 힘들다보니 사전에 어느정도 수준인지 온라인 시험 성적을 알고 그에 맞춰 질문을 준비하면 좋은데, 때로는 실력이 좋은 사람과 인터뷰를 하는데 초반 10-20분은 쓸데없는 기본 질문만으로 시간을 낭비하기도 하고, 때로는 면접기회가 아까울 만큼 전혀 실력이 되지않는 사람과 인터뷰를 하느라 1시간을 허비하기도 해서 이런 점에 불만이 있었습니다.

그런데 만약에 하나의 포지션에 여러 지원자들이 있었고, 압도적인 내공이 있음을 느낄만한 지원자도 없이 모두 다 고만고만 했다면 누구를 채용해야 할까요?

앞서 예를 들은 IT 공룡들은 이 경우 아무도 채용하지 않고 정말 느낌이 오는 사람이 나올 때 까지 기다리지만, 제 이전 직장에서는 그럴만큼 여유가 없었습니다. 2-3 달은 공석으로 놔두고 있지만, 그 이상 지연이 될 경우 팀원들 모두가 힘들어 이후에 지원자들 중에 그냥 가장 느낌이 오는 사람을 고릅니다. 

어떤 느낌이냐고요? 흠... 느낌적인 느낌입니다.

저의 팁은 이 느낌적인 느낌을 잘 주기위한 저만의 팁입니다. 체계적인 연구와 데이터를 통해 축적된 것은 아니고, 예전에 기술 영업 비슷한 일을 하면서 몸으로 배우고, 일부 여기저기 자료들을 보고 배운 것들이죠.

이 팁들을 잘 활용하여 캐나다에서 첫 직장을 구할 때에도 첫 면접에서 합격을 하여 취직을 했었고, 그 후에도 이번 이직을 포함하여 총 11번의 면접을 보았는데, 그 중 4번은 면접을 통과했죠. (4번 중 이번 이직을 제외한 3번은 이직 생각이 없는 상황에서 학습차원에서 본 면접이였거나, 이직 시 메리트가 전혀 없는 케이스라 제가 오퍼 거절을 했습니다)

자, 우선 저처럼 기존에 경력이 있는 상황에서 남들보다 조금은 늦은 나이에 이민을 오신 분들의 경우, 취업 준비를 하면서 가장 많은 시간을 투자하시는 것이 기술면접입니다. 자신의 기술에는 어느정도 자신이 있지만, 이를 영어로 말하고/설명하고/설득하는 것에 대한 부담도 있고, 이민을 위해 현업에서 손을 놓은 지난 2-3년 동안 변화된 기술들을 따라잡기 위해, 혹은 자신이 했던 일과 같은 분야가 없어 현재 캐나다 시장에서 인기있는 기술들을 따라잡기 위해 새로운 기술을 공부하고, 포트폴리오 만들고 좀 더 멋진 어휘로 자신의 이야기를 하고자 영어 공부도 많이 하십니다.

그런데 말입니다, 아까 말씀드렸던 것 처럼 1-2시간의 기술면접으로는 사실상 이 사람이 어느정도의 실력이 있는지 확실한 느낌이 오는 경우가 거의 없습니다.

그런데 이런 경력직 이민자분들은 '무엇을' 말 할지에 너무 집중하게 된 나머지 '어떻게' 말 할지에 대해서 너무나 많은 것을 놓치는 경우가 많습니다. 그리고, 앞서 말씀드린 '느낌적인 느낌'은 무엇을 보다는 어떻게에 더 큰 영향을 받습니다.

사실 인터뷰 시에 질문하는 내용이라는 것이 보기에 따라 뻔하기도 하기 때문에, 어떤 질문을 하건 4-5년 이상 경력을 가진 지원자들의 답변에서 '무엇을'은 크게 차이가 나지 않지만, '어떻게'는 각자 다릅니다.

그래서 STAR method라는 것을 잠깐 소개드리려 합니다. STAR에 대한 자세한 내용은 구글링을 하시면 수 없이 많이 보실 수 있으니, 자세한 것은 직접 찾아보시기를 권해드립니다.

STAR는 Situation/Task/Action/Result의 약자로, 인터뷰 질문에 대해 위 내용을 모두 넣어 체계적인 답변을 하라는 것입니다. 회사에서 Interviewer 교육을 하는 경우에 interviewee들이 STAR에 맞춰서 답변하는지 확인하라는 내용이 포함된 경우도 많이 있습니다.

예를들어, “네가 기억하는 가장 성공적인 너의 업적이 무엇인지 말해줄래?” 라는 질문에 답변한다고 해보죠.

그러면 먼저 S, 상황을 말합니다.
얼마 전 일이였는데, 우리의 major 고객 중 하나가 일부 타블렛이 갑자기 동작을 멈추고 부팅이 안된다는 티켓을 접수했어. 그런데 시간이 갈 수록 그 수가 늘어나서 24시간 이내에 총 8천대의 단말에서 문제가 발생했지. 그리고 똑같은 이슈가 다른 고객들에게서도 발견되었어.

그 다음 T, 무엇을 해야했는지 그 목적을 말합니다.
그래서 나는 더 이상 문제가 확산되기 전에 문제의 근본 원인을 찾고, 근본 원인을 빨리 수정하거나 최소한 문제가 더 퍼지지 않도록 막아야했지

그 다음은 A, 내가 어떻게 했는지를 설명합니다.
우선 부팅도 되지 않는 단말에서는 아무런 정보도 추출할 수 없었기에, 어떤 단말들에서 문제가 발생한 것인지 데이터를 뽑아 정리했어. 정리한 후 보니 발생 지역은 유럽뿐이고, 특정 제조사의 여러 모델, 하지만 특정 Android OS에서만 나왔지. 우리 서비스가 지역이나 모델별 차이는 없기에 제조사의 문제라고 생각되어 그 제조사의 유럽향 모델들을 모두 수집했어. 그 다음…

마지막으로 R, 어떤 결과를 냈는지를 설명합니다.
한국에서는 겸손한 것이 미덕이지만, 이 나라에서는 너무 심하게 떠벌리거나 부풀리지만 않으면 자기 자랑을 하는 것이 바람직합니다. 무엇을 배웠고, 어떤 결과를 냈고, 또, 일련의 사건을 통해 앞으로 유사문제가 발생하지 않도록 어떤 조치를 취했는지 등을 이야기 하면 됩니다.

Behavioural Interview에서 자주 묻는 질문들이 있습니다. 
예를 들자면
  너에 대해 말 해 볼래?
  지금 (혹은 이전) 직장에서 네 롤이 뭔지 설명해줄래?
  너는 왜 우리 회사를 선택했지? 수 없이 많은 회사들 중에서 말이야
  왜, 어떻게 이 직업을 선택했니?
  이전에 네가 한 일 중에 가장 자랑스러운 일을 이야기 해 줄래?
  이전에 네가 실패한 일 중에 가장 치욕스러운 실패담을 들려줄래?
  팀 내에 너랑 의견이 다른 사람이 있으면 어떻게 하니?
  너는 어떤 팀이 가장 이상적인 팀이라고 생각하니?
  네 매니져 중에 가장 좋았던 매니져가 누구야? 어떤사람이야? 왜 좋았는지 설명 해 줄래?
  네 동료들 중에 <이하동문>
  너는 요즘 어떤 기술이 끌리니? 너에게 2주 정도 시간이 주어진다면 뭐를 연구 해 보고 싶어? 왜?

구글링을 조금만 하셔도 찾으실 수 있는데, 대표적인 질문들은 인터뷰 전에 미리 STAR에 맞추어 생각을 해 두고 하시는 것이 좋습니다.

이렇게 체계적인 답변을 하는 연습을 해 두어 습관이 되면, 기술면접에서도 유리합니다.

단답형으로 대답이 가능한 문제가 아니라, 어떠한 상황을 주고 어떻게 설계할까? 혹은 어떻게 개선할래?와 같은 토론을 위한 문제가 주어졌을 때, 보다 체계적인 대답을 하는데 도움을 줍니다.

이런 질문에 대해 저는 보통 아래와 같은 방식으로 대답을 합니다.

우선 주어진 문제 상황을 제가 잘 이해하고 있는지 확인하는 차원에서 Interviewer가 말 한 문제상황을 한 번 rephrase해서 말합니다. 그러는 사이 제가 생각 할 시간을 벌기도 하지만, 제가 영어가 약하다보니 간혹 잘못 알아듣거나 놓치는 부분이 발생하기도 하는데, 이렇게 하면 동문서답 하는 경우를 방지할 수 있습니다.

그 다음으로 제가 주로 말하는 것은, 주어진 문제상황에서 어떤 것이 중요한 문제이고 어떤 것이 중요도가 낮은 문제인지 순서를 말하고, 그래서 나는 이 우선순위에 기반하여 문제를 해결 할 것임을 천명합니다. 한 눈에 봐도 바로 알 수 있는 경우도 있긴 하지만, 구지 말하는 이유는 '나에게는 수 백 가지의 수가 있지만, 이런 이유리 나는 지금 이 수를 쓰는 것이다' 라는 느낌을 풍기는 것이지요. 또 답변을 말할 때 까지 시간을 조금 더 끌면서 잠시라도 생각 할 시간을 다시한번 더 벌고요.

마지막으로 제가 생각하는 해결방안을 말합니다.

제가 말한 해결방안과 똑같은 말을 한 다른 지원자가 있더라도, 사실 면접이 끝난 후에 복기를 하면 제가 한 답변이 뭔가 더 있어보이는 그런 느낌을 줄 수 있습니다. 저 역시도 Interviewer로서 경험해본 적이 있는데, 결국 같은 답이지만 보다 체계적으로 말 한 지원자가 좀 더 느낌이 좋습니다.

미리 달달 외워둬서 즉문즉답을 하는 것 같은 느낌 보다는 생각을 하면서 말한다는 느낌을 줄 수도 있고, 결국 나와 Interviewer간 서로 대화가 오고가면서 일방향의 소통이 아닌 쌍방향 커뮤니케이션이 이뤄진다는 느낌을 줄 수 있습니다.
기술영업 할 때 어디서 읽었던 내용인데, 사람간의 대화에서 티키타카가 활발하게 오간 경우 대화 후 호감도가 더 올라간다고 합니다. 그래서 긴 질문과 긴 답변보다는 짧게짧게 끊어서 중간중간 상대의 피드백을 묻고 그 피드백에 대한 리액션을 해주며 대화를 끌고나가는 것이 좋다고 하더군요.

자, 그러면 저처럼 영어에 자신감이 없는 한국분들이 자주하는 실수에 대해 말씀드립니다. 저도 기술영업으로 첫 PT를 하러 외국에 나갈 때 똑같은 실수를 했었죠.

영어에 대한 부담 때문인지 몰라도 각 예상 질문들에 대한 답변들을 풀 스크립트로 짜는 경우가 많은데, 저는 개인적으로 이 방법을 매우 지양합니다.
이전에도 영어 연설이나 PT경험이 풍부하신 분이면 사실 문제가 아닌데 (그런데 그런 분들은 풀 스크립트 자체를 만들지 않습니다), 발표나 말하기 경험이 부족하신 분들이라면 더더욱 풀 스크립트를 만들지 않기를 권해드립니다.

그 이유는 자신이 만든 스크립트를 외워서 말하는 것을 동영상 촬영을 하여 한 번만 돌려보면 스스로 느끼실 수 있습니다.

첫 번째로 자주하는 실수는 어휘입니다. 한국에서 오래 영어교육을 받으신 분들의 강점은 문법과 어휘입니다. 워낙 쓰잘떼기 없는 단어들까지 줄줄 외웠고, 현대인들의 대화에서는 크게 신경쓰지 않고 말하는 문법들까지 다 외웠죠.
그래서인지, 글로 무언가를 쓰려고 하면 참 어려운 단어들을 많이 씁니다. 그 어려운 단어들이 본인의 입에 착착 감기면 모를까, 그렇지도 않습니다. 더군다나 너무나 열심히 하시는 분들은 좀 더 고급어휘를 쓰겠다는 욕심에 원래 알지 못했던 단어들까지 사전을 찾아서 스크립트에 포함시키기도 하죠.
기술 관련 용어들은 영어로 미리 숙지하고 가야 하지만, 그 외에 어휘들은 이미 익숙하여 자기 입에 착착 붙는 단어들로 준비해야 합니다.
잊지 마세요 지금 참석 할 자리는 웅변대회나 UN연설이 아닌 Job Interview라는 것을요.

두 번째 자주하는 실수는 스크립트를 통채로 외우려고 한다는 것입니다. 워낙 암기력이 좋아 스크립트 전체를 외우고 말하는데 아무런 문제가 없다면 모를까, 보통의 경우에는 잘 기억이 나지 않습니다. 이 경우 크게 당황하여 그 날 인터뷰 전체를 다 망칠 수도 있죠.
그래서 전체 스크립트를 외우기 보다는 자기가 말 할 이야기의 흐름을 외우는 것이 좋습니다. 각 문장 혹은 문단별로 키워드만 잘 알아두고 그 때 그 때 필요한 만큼 가능한 쉬운 문장으로 만들어서 말을 하는 것이지요.

그 다음은 연기력에 관련된 문제가 아닐까 싶은데, 미리 외워둔 내용을 말 할 때에는 상당히 부자연스럽지만, 흐름 정도만 외워둔 내용을 그때 그때 생각나는대로 문장을 조합하여 말 할 경우에는 보다 자연스럽습니다.

마지막 실수로는 면접을 준비하면서 놓치는 경우가 자주 나오는 것으로 나의 질문을 준비하지 않는 경우입니다.

인터뷰는 회사가 나를 평가하는 자리이기도 하지만, 내가 이 회사를 평가하는 자리이기도 합니다.
미처 생각하지 못했는데 갑자기 Interviewer가 

"너 궁금한거 있으면 물어봐.”

라고 말하면 머릿 속이 하얗게 됩니다. 보통 진짜로 지원자들이 궁금해 하는 내용들 (회사 복지, 분위기, 베네핏, 사장 착하냐?, 돈은 잘 주고? 등등…)은 이럴 때 질문하면 일반적으로 마이너스라고 생각하시면 됩니다. 이런 내용은 일단 합격을 하고 오퍼를 받았을 때 인사과 직원과 조율하면 되는 내용들이고, 보통은 인사과에서 전화로 컨택을 해 왔을 때, 연봉 외에는 인사과에서 미리 이야기 다 해 놓았을 내용이죠.

자신의 직무와 회사의 특성에 맞게 이 회사에 정말 관심이 있었고, 그래서 궁금하다는 것을 보여주는 것이 좋습니다.

이런 질문은 behavioural interview시에 할 질문 2-3개, technical interview시에 할 질문 1-2개 정도는 미리 준비를 해 두시는 것이 좋습니다.

때로는 자신이 인터뷰를 리드하는 경우도 있습니다. 이는 보통 그 사람이 더 대단하게 보이는 착각을 불러 일으키기도 합니다.

예를 들어서 기술면접 때, “이런 이런 상황이야. 넌 문제를 해결해야 하는데, 이거 어떻게 할래?” 라는 질문을 받았을때 이렇게 이야기 하는 것입니다.

오, 이런. 나 이거랑 거의 비슷한 문제가 있었어.
그 때, 나는 이렇게 저렇게 해서 요렇게 조렇게 해결했지. 그런데 그 때 보니까 우리가 이런저런 정책이나 방어장치가 부족하다는 것을 느껴서 그런 것을 셋업 했었지. 
그런데 너희는 어때? 이런 경우를 사전에 차단을 어떻게 하니? 나처럼 이런저런 툴을 셋업했니? 너희 시스템 중에 A가 그거랑 비슷한 일이 있을 수도 있는데 아니야?

그리고, 제 질문에 대한 Interviewer의 답변 내용에 맞추어 추가적인 질문들을 더 하면서 자신이 리드하는 시간을 좀 더 끄는 것이지요. 아무래도 자기가 답변을 생각하고 말하는 시간이 줄어들고 주도적으로 이끌어가는 시간이 길어지기에, 특히나 저처럼 언어가 짧은 이민자들에겐 유리한 방법 중 하나라 할 수 있습니다. 대신, 이런 질문을 던지려면 이 회사에 대해 미리 공부를 좀 해 두어야 하죠.

경우에 따라 이런 경우에 인터뷰가 끝나고 자신이 확인하고자 했던 질문들을 미처 다 하지 못해서 지원자의 실력을 알 수 없었다고 불만을 토로하는 사람도 있긴 하지만, 보통은 ‘뭔지 모르겠지만 이 친구 경험도 다양하고 뭔가 내공이 있는 것 같아...’ 라는 생각을 하며 좋은 평가를 내리게 되는 편입니다.
특히나 언변이 좋은 인도 친구들이 이런 것들을 참 잘 써먹는데, 덕분에 채용 이후에 눈탱이 맞았다며 후회하는 경우도 있습니다. ㅎㅎ

그리고 마지막으로 회사에 따라서 인사팀에서 인터뷰 스케쥴링을 하면서 누구와 인터뷰를 보게 되는지 알려주는 경우가 있습니다. 간혹 Interviewer가 나름 지명도가 있는 사람인 경우 신문 기사나 잡지 인터뷰, 그 사람이 작성한 테크 블로그 글 등을 찾아낼 수도 있습니다.
저는 Interviewer 명단을 받은 경우엔 보통 그들에 대해 한번 씩은 구글링을 해 봅니다. 그리고 간혹 신문이나 잡지 인터뷰/기사를 보게되면 그들이 평소에 중요시하는 가치관이나 기술, 생각하는 방향에 대해 미리 파악하고 제 인터뷰 답변 내용도 최대한 그에 맞게 맞춰주기도 합니다.

마지막으로, 경력이 있는 이민자 분들께 말씀드리자면 Technical Interview를 챙기느라 Behavioural Interview를 놓치는 우를 범하지 마세요. 잘 생각 해 보시면 보통 Technical Interview의 Interviewer들은 합격 할 경우 자신의 peer인 다른 개발자들입니다. 그리고 Behavioural Interview의 Interviewer들은 시니어 개발자들도 있지만, 보통 자신의 hiring manager입니다. 기술 면접의 평가결과에서 지원자 모두 비슷한 점수를 받았고, 그 중에 한 명을 꼭 뽑아야 한다면 누가 뽑힐까요? 기술 면접에서 0.1 점이라도 더 받은 사람? 아니면 매니져에게 강한 인상을 남긴 사람? 누굴까요?

기술이 있어도 언어와 환경이 달라 처음에는 이런저런 어려움들을 많이 겪게되는 것이 보통인데, 그런 분들께 저의 필승 공략법은 아니지만, 만약 비집고 들어 갈 작은 틈이 있으면 기회를 잡을 수 있는 기회가 될 수 있는 작은 팁이 조금이라도 도움이 되었으면 좋겠습니다.

좋은 소식과 안좋은 소식

컨퍼런스 출장, 그리고 짧은 업무 복귀 후 다시 약 10여 일간 휴가를 보내는 사이에 제 주변에서 Good News와 Bad News가 함께 들려왔습니다.

Bad News는 두가지인데, 하나는 좀 많이 안좋은 뉴스고 다른 하나는 조금 안좋은 뉴스입니다.

약 3달쯤 전에 제가 일하는 회사로 이직을 하게 된 한인 개발자가 계십니다. 사실 직장 자체만 놓고보면 이전에 일하시던 직장은 대기업 중 하나로 좋은 복지제도와 괜찮은 연봉을 주는 곳이며, 오피스 위치도 토론토였기에 미시사가에 위치한 중소기업으로 올 이유가 별로 없었습니다. 이직을 결심한 이유는 이민 때문이였는데, 이전 직장에서는 주정부 이민 지원이 없는 반면, 저희 회사에서는 주정부 이민을 서포트 하기에 이직을 한 것이죠. 하지만 컨퍼런스 출장 후 복귀를 하고나서 보니 안타깝게도 3개월 Probationary 기간을 통과하지 못하고 회사를 떠나고 말았다는 소식을 듣게 되었습니다. 

뒤돌아보면 그간 몇 번의 신호가 있었던 것 같기는 합니다. 그 분과 식사나 산책을 같이 하면서 그 분의 매니져와 1:1 면담 내용에 대해 전해들은 적이 몇 번 있었습니다. 그 일이 있기 약 1~2달 전쯤에는 매니져가 그 분께 바라는 롤이 어떠한 것인지를 설명하면서 현재 진척에 대해 약간의 아쉬움을 표시한 적이 있었습니다. 그리고 이 일이 있기 약 2주 전, 마지막 면담 때에는 일을 익히고 따라오고, 또 팀에 새로운 value를 불어넣는 역할이 기대에 미치지 못한다며 직접적으로 이야기를 꺼내기도 했었고요.
그 분에게 면담 스토리를 들을 때, 그 분께서는 당시 면담 내용이 우려되어 힘들게 말을 꺼낸 것이였지만, 저는 그 때만 해도 이 일을 그다지 심각하게 받아들이지는 않았었습니다.
제가 처음 이 회사에 왔을 때, 저의 매니져 역시 probation기간이 끝날 때 까지 1:1 면담시에 칭찬을 했던 기억은 별로 없었고, 항상 내가 어떠한 것을 더 해주기를 바라는지, 그리고 나의 부족한 점이 무었인지를 계속 이야기 했던 기억이 있습니다. 덕분에 캐나다 회사에서의 기대치에 대해 전혀 감을 잡지 못했던 저는 항상 긴장상태를 유지했었죠. 하지만 막상 probation이 끝나고 나니 이런저런 칭찬도 해 주었고, 또 저의 연봉 또한 조정을 해 주었기에 probation기간 중 다소 딱딱한 이야기들이 그다지 심각하지 않다고 생각했었기 때문이죠.

제가 아는 그 분은 이렇게 허무하게 가실만한 분이 아니셨는데, 아무래도 경력과 연봉수준 등에 따른 회사의 기대치도 다를 것이고, 당시에 개인적으로 영주권 관련하여 몇번의 폭풍이 몰아쳤던 상황이라 그런 것 같기도 합니다.

또 다른 안좋은 소식은 사실 생각하기에 따라 안좋은 소식이 아닐 수도 있습니다.
저희 부서에서도 사람을 구인 중이였고, 반드시 DevOps 경력이 아닐지라도 좋은 개발자이고, DevOps에 관심이 있는 사람이라면 얼마든지 추천을 해 달라는 말에, 그렇지 않아도 커리어에 고민이 있던 친구 한 명을 추천을 한 일이 있습니다. 하지만 면접결과 안타깝게도 채용하지 않기로 했다고 하네요. 그래도 이미 재직중인 회사가 있는 상태에서 다른 기회를 찾아보기 위해 면접을 봤던 것이기에 크게 나쁜일은 아닐 수 있습니다. 오히려 좋은 일이라고 할 수도 있는데, 면접 과정에서 저희 매니져가 마음에 들었던지, 따로 장문의 메일을 써서 어떠한 점들이 부족했고 무엇이 더 필요한지 자세히 피드백도 주었고, DevOps와 관련된 책을 한 권 사서 우편으로 보내주어 혹시 관심이 있다면 이 책을 자세히 읽어보고 더 공부한 후에 다시 한번 만나고 싶다고 했다네요.

다른 한가지 안좋은 소식은 제가 리퍼럴로 추천을 해 준 친구가 회사 면접에 붙지 못한 일입니다. 그래도 그 친구는 다른 회사에 지금 재직중인 상태에서 다른 기회를 찾아 본 것이기에 크게 나쁜 일이라고 까지는 하기 어렵겠죠. 그리고 면접 과정에서 매니져가 마음에 들었던지, 그 친구에게 따로 어떤어떤 점들이 부족했는지 메일도 보냈고, 이쪽 커리어를 생각한다면 도움이 될 만한 책이라며 책도 따로 구매해서 보내주었습니다.

좋은 소식도 두가지이며 둘 다 취업 소식입니다.

먼저 같은 학교를 다녔던 한국인 동생 중 한 명의 취업 소식입니다. 한국에서의 별도의 학력이나 경력은 없는 친구였지만, 항상 성실하고 열심히 하는 멋진 친구였는데, 얼마 전 Web 개발자로 취업을 했다고 하네요. 이 친구도 졸업 후 2년 가까이 다른 분야에서 계속 일을 하고있었고, 시간이 다소 오래 걸리기는 했지만 드디어 개발자로서 커리어를 시작하게 되었습니다.
얼마 남지않은 PGWP 비자 기간때문에, 주중에는 개발자 job을, 주말에는 현재 영주권 진행중인 현재 job을 뛰면서 당분간 투쟙을 유지해야 한다는데 힘들지 않을까 걱정이네요. 부디 영주권을 받아 정착하고 개발자로 완전 전업을 하는 그 날까지 젊음과 체력이 버텨 주길...

다른 취업 소식은 저와 같이 학교를 다녔던 인도 친구 소식입니다.
빈약한 실력 때문에 같이 학교를 다니면서 가능하면 프로젝트는 같이하지 않으려고 했던 친구이긴 하지만, 캐나다에서 가장 큰 은행에서 코업도 했었고, 언변에 능해 취업이 비교적 쉽게 될 것이라 생각했지만, 취업까지 약 2년의 시간이 걸렸네요. 이 친구도 역시 생계를 위해 그동안 보석상에서 일을 하고 있었습니다.

그리고 이 글을 쓰는 사이에 방금 전 페이스북 챗을 통해 안좋은 소식이 하나 더 들어왔네요.

학교에 있을 때 저보다 나이가 조금 더 많은 40대 일본인 아저씨 한 명이 있었는데, 다음 주 월요일에 토론토를 떠나 다른 주로 옮겨간다고 합니다. 이 아저씨도 아직 개발자 쟙을 얻지 못하고 있는 상황이긴 한데, 이제는 1년이 채 안되게 남은 비자기간 때문에, 당장 내일 개발자로 취업을 해서 경력을 쌓는다 해도 1년 미만의 경력인지라 CEC이민을 할  수 없으며, 어찌어찌하여 1년, 혹은 2년의 경력을 쌓는다 해도 Express Entry 점수 충족이 어려워 토론토에서 이민은 포기하고, 마지막 방법으로 반년의 경력으로도 주정부 이민이 가능한 주를 찾아 떠나간다고 합니다.
참 착했고, 학교를 같이 다녔던 친구들 중 저와 문화적으로 가장 잘 맞았던 친구인지라 안타깝네요. 단순한 저의 추측이긴 하지만 아마도 언어실력과 커뮤니케이션 스킬 때문이 아닐까 추측을 해 봅니다.

이 친구의 개발실력은 뛰어난 편은 아니였습니다. 하지만 또 다른 학생들에 비해 뒤쳐지는 수준도 아니였죠. 그럼에도 코업 학기 때 부터 코업 쟙을 구하지 못했었고, 결국 졸업을 할 때 까지 코업을 하지 못하고 졸업을 했습니다. 그 당시만 하여도 대부분 큰 어려움 없이 코업을 구하던 시절인지라 그 친구가 코업을 구하지 못해 1학기 강제 휴학을 할 때만 해도 정말 운이 없는 케이스라고 했었죠.

언어에 대해서는 제가 누구에게 무어라 할 만한 처지는 아닙니다. 저도 매우 영어를 못하고 또, 모르니까요. 이 친구도 저 못지않게 참 영어를 잘 못하는 편이지만, 영어 자체에 대한 능력보다 대화의 스킬에 대해 이야기를 하고 싶습니다.
고급진 영어, 화려한 언변과는 거리가 먼 것이지만, 더듬더듬 서바이벌 잉글리시를 말하는 이민자 영어의 입장에서는 조금 더 적극성을 가지고 대화를 하는 것이 좋은 스킬 중 하나라고 생각합니다.

저는 대화를 하다 어휘가 생각나지 않거나, 적당하게 표현할 방법이 떠오르지 않으면 제가 생각해 낼 수 있는 가장 쉽고 기본적인 단어들로 저의 느낌/생각/경험을 여러번 반복해서 표현을 합니다. 가능한 상대방이 이해할 수 있을 때 까지요. 이 친구가 저와 다른 점이 한가지 있다면 원래 화법 자체가 느린 편인데다, 매우 신중하고 조심스러운 성격을 가지고 있다보니, 이러한 상황이 발생했을 때, 일단 최소 수초간 입을 닫고 생각합니다. 그리고 어느정도 시간이 지나면 그 후에 만들어진 문장을 말을 하죠. 그렇다보니 다자간 대화 뿐 아니라 1:1 대화인 경우 종종 이미 지나간 주제를 뒤늦게 다시 꺼내오기도 합니다.

무엇이 옳고 그르다고 판단할 수는 없지만, 제가 마치 가족오락관 게임을 하듯 비슷한 말로 제가 표현하고자 하는 바를 몇 번 설명하다보면 대부분 native들은 결국에는 그 뜻을 이해하고 저의 말을 rephrase해서 '이 말인거지?' 라고 되묻습니다. 어찌되었건 저는 이렇게 대화가 계속 이어지고 서로 집중을 하면서 대화를 하는 것이 더 편합니다.
신중하게 생각하여 올바른 말과 표현을 하는 것의 장점도 있겠지만, 그 친구와 대화를 하다보면 시간도 오래 걸리고, 때로는 심지어 다음 날 만났을 때에야 서로의 뜻을 이해하게 되기도 합니다. 이러한 대화가 면접장에서도 지속이 된다면, 면접관의 입장에서는 언어를 몰라 말을 못하는 것인지 내용을 몰라 설명을 못하는 것인지 알 수가 없겠죠.

참 재미있는게, 서로간의 코딩스타일은 각자의 화법과 비슷했습니다.
저는 외부 서비스나 플랫폼과 연동되는 새로운 프로젝트를 만들 때, TDD와 비슷하게 합니다.
먼저 간단한 파일럿 클라스와 그의 유닛 테스트를 먼저 만들고 하나씩 돌려보며 외부 서비스의 behaviour를 파일럿 클라스에서 확인을 해 보면서 시작하는 경우가 많습니다. 어느정도 확인이 된 후에 제대로 다시 설계해서 만들어 나간다면 참... 좋은 일이지만 개발자에게 세상에서 가장 힘든 일이 이미 만든 코드를 삭제하는 것이라고 했던가요? 귀차니즘과 파일럿 클라스에 대한 근자감으로 대부분은 그 파일럿 클라스를 수정/확장 해 나아가며 프로젝트 코드가 되버립니다.
하지만 이 친구는 외부 서비스나 API, 플랫폼의 문서부터 파고, 문서를 다 파고나면 그 때서야 설계를 시작하고, 설계가 다 되어야 코딩을 시작했었습니다.
제가 보기에 이 친구는 다소 답답했었고, 이 친구는 저를 다소 무모하다고 생각 했을 것 같네요.

아마 각자의 성격에 따라 화법도 다르고 목소리의 톤도 다르고, 또 개발 스타일도 다른 것 같습니다. 그래서일까요, 예전에 그 친구에게 설명이 안되면 다른 표현으로 설명을 해 보는 것이 어떻겠냐고 권해 본 적은 있지만, 사람 성격이 그리 쉽게 바뀌는 것은 아니다보니...

제 멘탈이 약해서인지 몰라도, 주변에서 좋은 소식들이 들려오면 저 역시도 좀 더 기운이 나고 기쁘지만, 반대의 경우에는 같이 힘들어지는 편인데, 올 해 남은 기간동안이라도 제 주변에서 좋은 소식들이 많이 들려오면 좋겠네요.

College와 취업률 데이터, 그리고 제 체감 취업률

요즘 연이어서 저에게 문의를 주신 많은 분들께서 '취업이 잘 되는 컬리지를 가는 것이...' 라는 말씀을 하셔서 글을 올립니다.

이전에도 제 다른 포스트에 댓글이나 메일로 따로 문의주신 분들께 답장으로도 이미 나간 적이 있는 내용이긴 한데, College의 SW 학과 졸업생의 취업률에 대한 이야기입니다.

캐나다에 첫 발을 내딛기 위한 준비 하면서 컬리지를 알아보았을 때에 제가 가장 중요하게 생각하고 찾아본 데이터는 각 프로그램의 커리큘럼과 취업률 데이타입니다. 아무래도 이미 전공을 했던 분야인지라 너무나 기초적인 과목으로 커리큘럼이 되어 있으면 피하고 싶어 커리큘럼을 찾아 봤었고, 당연히 이민을 간 이후에 일을하며 돈을 벌고 살아야 하기에 가장 중요한 '취업'을 확인하지 않을 수 없었죠.

정확한 수치로는 기억이 나지 않지만, 대부분의 토론토 인근 컬리지 SW 관련 학과의 취업률 데이터는 졸업 후 6개월 이내 70%를 웃돌았던 것으로 기억합니다. 그 외에 조금 더 범위를 넓혀서 오타와나 나이아가라 등 다른 온타리오 주의 컬리지들을 찾아 보아도 낮아봐야 60-70% 정도는 되었던 것으로 기억하고요.

당시에 이 데이터는 저에게 상당히 긍정적인 요소로 작용을 했던 것이 사실입니다. 아무리 언에에서는 disadvantage가 있다고 해도 60-80%의 확률이면 충분히 스스로의 힘 만으로도 돌파해 낼 자신이 있었거든요.

이 자료는 누구나 쉽게 인터넷으로 찾을 수 있는 자료이긴 한데, 저도 처음 준비를 했을 때에는 직접 자료를 찾아 볼 생각은 하지 않았고, 유학원에 문의를 하여 자료를 받아 보았었습니다. 대부분 유학원들이 캐나다 컬리지 요강 같은 두꺼운 책이 있고, 그 책에는 각 학교/학과 별 입학시기, 입학정원, 취업률 같은 데이터들이 있었죠.

예를들어 제가 다녔던 학교의 취업률 통계 자료는 이 링크에서 찾아볼 수 있죠.

위 스크린샷은 2015년 자료 첫 장을 캡쳐한 것입니다. 저도 사실 본 포스팅을 준비하면서 처음 본 자료인데, 위 자료에서 가장 중요한 부분은 % Working Related 부분과 Available for Employment가 아닐까 생각합니다.

한국에서도 정부에서 발표하는 실업률과 취업률 수치와 실제 체감하는 정도에 차이가 많아 허수가 많다고들 이야기가 많이 나오는데, 그 원인 중 하나가 이를 계산할 때 모수가 전체를 대상으로 하지 않고 Available for Employment만을 대상으로 하기 때문이죠.

위 표에서도 볼 수 있듯, 총 6,449명의 졸업자 중 Available for employment는 2,730 명입니다. 그리고 2,730명이 취업률을 계산할 때 분모로 들어가는 숫자인데, 실제 전체 졸업자의 약 40% 수준밖에 되지 않습니다. 즉 졸업자 100명 중 10명만 취업이 되었어도 취업률 계산은 10/100으로 하지 않고 10/40으로 계산하여 25%라고 말하는 것과 같습니다.

위 테이블에서 녹색 부분에 표시된 72%라는 취업률은 캐나다에 오기 전에 보았던 수치와 상당히 유사한 수치인지라 익숙한 데이터이지만 그 옆에 Working Related의 48%는 저에게는 매우 생소한 수치입니다. 제가 컬리지를 생각하면서 받아보았던 자료에서는 절대 나온적이 없었던 과반 미만의 취업률 수치입니다.

자 그러면 실제로 제가 체감하는 컬리지 SW 학과 취업률에 대해 말씀드리고자 합니다.

다른 글과 마찬가지로 제가 경험하고 아는 캐나다 사회는 제 경험만을 기반으로 하기에 전체를 대변하기는 어려울 수 있지만, 실제 이 곳에서 생활하는 사람 중 한 명으로서 어떻게 느끼고 생각하는지를 참고하실 수는 있을 것입니다.

제가 입학을 한 시기는 2014년 1월 학기이며, 프로그램은 3년제 프로그램의 Fast-Track 과정인 Software Engineering Technology Fast-Track 과정입니다. 그리고 같은 시기에 같은 프로그램에 입학했던 친구들의 절대다수는 외국인 학생이였으며, 또 대부분이 Co-op 프로그램으로 등록을 하여 저처럼 non co-op으로 등록한 학생들은 많지 않았고, 또 non co-op으로 처음에 입학을 했어도 상당수의 학생들이 첫 학기중에 학교에 이야기 하여 Co-op으로 프로그램 변경을 했었습니다.
1월학기에 시작했던 당시 프로그램의 일정상 코업 유무와 상관없이 방학이 없이 학사계획이 잡혀있어 졸업까지 non co-op의 경우 16개월, Co-op의 경우 24개월이 걸리는 과정으로 저처럼 중간에 자퇴?를 한 경우를 제외하면 대부분 2015년 4월에서 2015년 12월 사이에 졸업을 했기에 졸업 후 지금까지는 약 1.5~2년 정도의 시간이 흘렀습니다. 같이 입학했던 친구들 중 한 명은 Software Engineering Technician Fast-Track 과정으로 8개월(2학기)만에 졸업을 했지만 총 50여명의 모수 중 1명이니 일단 예외로 하겠습니다. (참고로 그 친구는 졸업과 동시에 BlackBerry QA로 취업이 되서 월털루로 갔으며 이후로는 연락이 안되서 잘 모릅니다)

졸업 후 1.5-2년이 지난 지금 시점에서 살펴보면 졸업자의 대부분은 취업을 했습니다.

하지만 단순 취업률이 아닌 전공 관련분야 취업률을 보자면 이야기가 조금 달라지는데요, 카페나 식당, 마트 등에서 전공과 무관한 일을 하고있는 경우를 제외하고 전공 관련분야인 Software Developer, QA, Tech Support, IT 테크니션, Tech sales 등으로 취업을 한 경우는 다 합치면 21명으로 절반에 미치지 못합니다. 그리고 그 중 가장 근무여건이나 연봉 면에서 가장 나은 대우를 받는 직업군인 SW Developer (DBA 포함)로만 보자면 총 11명이 SW Developer로 현재 일을 하고 있어 25% 미만이고요.

시계를 돌려서 졸업 후 반년 정도의 시점인 2016년 여름으로 돌아 가보겠습니다.

당시에는 SW Developer로 취업을 한 사람은 총 8명이고, QA 등 다른 포지션 취업자는 정확히 기억나지는 않지만 매우 소수였습니다. 제 생각에는 당시만 해도 친구들이 근무 조건이나 연봉에서 상대적으로 나쁜 대우를 받는 다른 포지션에는 지원을 잘 안했기 때문이라고도 생각합니다.

그러면 SW Developer로 취업을 한 8명의 면면을 살펴보겠습니다.

컬리지 입학 전에 모국에서 Software Developer (or DBA) 근무 경력이 있던 사람은 저를 포함하여 총 8명이지만, 저는 제대로 된 경력자는 7명이라고 생각을 합니다. '본인 주장'에 의거하여 PHP 경력이 3년 남짓 된다는 한 친구는 같이 과제나 프로젝트를 하면서 코드를 보면 3년의 경력이 거짓 주장이거나, 제대로 된 회사에서 일을 했던 경력이 아닐꺼라고 생각되기 때문입니다. PHP의 syntax는 이것저것 많이 아는 것이 확실하지만, 프로젝트 설계나, 로직 구현 수준에서는 도무지 경력자라고 믿어지지 않는 수준이였거든요. 아마 개인 웹 서비스 개발/운영 정도를 경력으로 말한 것이 아닐까 생각됩니다.

이 7명 중 6명은 졸업 후 반년 정도가 지났던 당시 시점에 Software Developer로 취업을 했습니다. 나머지 경력자 1명은 상해에서 C++ 쪽에서 경력도 10년이 넘었고, 실력도 좋은 친구였는데, 이력서를 아무리 넣어도 좀처럼 인터뷰 기회조차 잡지 못하고 있다며 힘들어하곤 했었죠.
그 외에 기존 학력은 있으나 (Fast-track 이였기에 기존 학력이 다들 있었습니다) 경력이 없었던
친구들 중에 Software Developer로 취업이 된 케이스는 단 2명입니다. 지금은 취업이 안되 고생하던 그 상해 친구도 구직에 성공을 해서 경력자들은 100% 취업을 했고, 경력이 없지만 SW Developer가 된 사람은 현재 기준 총 4명입니다.

물론 제 체감 통계에는 여러가지 구멍이 있습니다.
제가 아는 케이스들로만 예를 들자면, 당초부터 명확히 SW 개발자가 되겠다는 의지는 없었던 홍콩인 캐나다 영주권자 아저씨는 졸업 후 모국으로 돌아갔습니다. 처음 입학 후 학기초에 영주권 갱신을 위해 머무르기 위해 왔는데, 그냥 놀 수는 없어서 컬리지에 왔고, 20대 시절에 코볼 개발을 한 적이 있기에 요즘 기술이 궁금해서 왔다고 했었죠. 캐나다에서 모델로 활동하던 여자친구와 함께 살기 위해 캐나다 컬리지에 왔던 베네주엘라 친구는 졸업 후 1년정도 지났을 때, 여자친구가 주 신청자가 되어 영주권을 받은 뒤 다시 모국으로 돌아갔고요. 또, 정확한 나이는 잘 모르지만 최소 40세 이상이였던 파키스탄인 아저씨는 나이 감점때문에 자력 이민이 어렵다는 판단으로 캐나다에 이민와 개인 비지니스를 하는 친척이 사는 도시로 이동하여 그 업체의 스폰서를 받아 영주권을 받기 위해 자발적으로 전공분야 취업을 하지 않았다고 다른 친구를 통해 전해들었습니다.

이런저런 케이스들을 모두 고려한다면 제 체감 통계도 좀 더 정확해 질 수 있지만, 제가 그들 모두와 친밀하게 지내고 있는 것도 아니고, 또 지금은 건너 건너서도 연락이 닿지 않는 사람들도 있다보니 실제 취업이 되었어도 알지 못하는 케이스도 있을겁니다만, 저와 같은 학교 같은 프로그램에 같이 입학했던 친구들도 그렇고, 주변에 다른 사람들의 경험을 통해 보더라도 대략적인 느낌은 비슷합니다.

졸업 후 1년이 넘으면 전공관련 분야는 전체 졸업자 중에 절반가량이 취업을 하고, SW Developer로는 25% 가량이 취업을 합니다. 그리고 SW Developer로 취업을 한 친구들의 면면을 살펴보면 학교 재학시 "저 친구랑 팀프로젝트 같이 해야겠다" 라는 생각이 들었던, 나름 잘한다는 느낌을 받았던 친구들이기도 하고요.

그리고 "학사/석사를 받았으나 취업이 안되어 컬리지에 다시 갈 정도로 컬리지에 가면 취업이 잘된다더라" 라는 말이 있어 이에 대해서도 잠깐 말씀드립니다.

컬리지는 직업 시장을 위한 직업 학교라는 그 특성상 학교 전체를 놓고 보자면 학문 연마를 목적으로 하는 대학/대학원 대비 전반적으로 취업률이 높을 수 있습니다. 아무래도 실질적인 특정 직업을 겨냥한 학과의 졸업생이 순수학문 학과를 졸업한 졸업생 보다는 특정 직업군에 특화되어 있기에 구직 시장에서 더 유리할 수 있죠.
하지만 이는 전반적인 컬리지 vs 유니의 이야기라면 맞을 수 있지만, 대학/대학원/컬리지 졸업자, 심지어 그냥 고졸자라도 모두 같은 포지션을 두고 다투는 SW Developer라는 직업군에서는 맞는 이야기가 아닙니다.
만약 컬리지가 아닌 대학/대학원이라면 "꼭 관련분야 취업을 해야하나?", "취업률이 전부는 아니자나!" 라는 말이 맞겠지만, 직업을 위한 교육기관에서 가장 중요한 지표는 결국 졸업생들이 졸업 후 관련분야에 얼마나 정착하는가라고 생각합니다.

대학/대학원에 대한 저의 직접적인 경험은 없지만, 저희 팀에 들어오는 갓 대학/대학원을 졸업한 쥬니어 개발자들을 통해 듣는 바에 의하면 그들 역시 그 누구도 손쉽게 취직이 되지는 않지만, 제가 느끼는 컬리지 졸업생들의 취업률 수준에 비하면 훨씬 수월하다는 느낌이였습니다.

제가 생각하는 Software, Computer Science 관련 컬리지의 취업을 정리하자면 이렇습니다.

- 학교 다닐 때 잘 했던 사람들은 시간이 좀 걸리지만 결국엔 SW Developer로 취업을 한다.

- 컬리지 졸업해서 SW Developer가 되는 것은, 낙타가 바늘구멍 들어갈 만큼의 어려운 경쟁은 아니지만 졸업하면 대부분 취업되는 수준도 아니다.

- Developer가 아니라 해도 전공 관련분야/유사분야로의 취업 역시 절반 미만으로 쉽지는 않지만 많이 어렵다고 하기는 힘들다.

- SW/CS 관련 학과로 한정지어 보자면 컬리지 졸업자의 취업률은 대학/대학원 취업률보다 낮으면 낮았지 높지는 않다.

제 블로그의 다른 글에서 오직 컬리지만이 유일한 선택지는 아니라는 말씀을 드린 적이 있는데요, 간혹 "컴싸/컴공 석사를 하는 것 보다 컬리지를 가는 것이 취업에 유리할 것 같아 컬리지로 간다" 라고 생각하시는 분들이 계시다는 것은 참 안타까운 일입니다.
컬리지와 석사는 분명 그 목적성도 다르고, 입학 요건도 다르며, 졸업의 난이도 또한 차이가 나고, 학비 역시 대학원이 더 비쌉니다. 입학 요건의 문제, 시기상의 문제, 다른 환경적인 문제, 자금의 문제, 혹은 졸업시 까지 공부를 할 자신감의 문제라면 모를까 만약 취업률을 걱정하여 컬리지에 오신다면 컬리지에 실망을 하실 수도 있을 것입니다. 만에하나 컬리지에 오시면서 70%의 취업률이라는 통계만 믿고 하위 30%에만 벗어날 정도의 노력을 하며 졸업한다면 최악의 경우가 될 것이고요.

오늘 포스팅을 준비하면서 갑자기 짧게나마 같이 생활했던 컬리지 친구들이 생각나서 오래간만에 페북/페북 메신져/링크드인/문자 등으로 연락을 했네요.

Probationary period는 안전할까?

벌써 2년이 넘었네요. 아직 스스로 준비가 되었다고 생각하지 않은 상태에서 정말 운이 좋게도 회사에 들어가게 되었고, 스스로 자신이 없는 상황이라 언제든지 당장이라도 해고가 가능한 probationary period를 어떻게 버텨야 할지 항상 고민을 하며 발버둥 쳤던 것이 바로 딱 2년전 저의 모습인 것 같습니다.

갑자기 이 이야기를 꺼낸 이유는 최근 팀 이동 후 겪은 몇 가지 일들 때문입니다.

팀 이동을 한 지 벌써 벌써 한 달이 넘었는데, 처음 2주 정도 제가 맡았던 일은 빌드 파이프라인 서비스용 플로그인을 제작하는 일이였습니다. 아니, 정확히 말하면 현재 사용중인 플러그인의 개발 프로세스를 완료하는 일이였습니다. 그 전에 DevOps팀에 몸 담았던 어떤 직원이 개발한 플러그인으로 현재 사용중인 플러그인이지만 정상적인 개발 프로세스를 거치지 않아 코드리뷰 상태에서 거의 한달 째 팬딩이였죠.

처음 이들 정도는 전체 빌드 파이프라인 서비스 서버의 구조와 플러그인 설계관련된 문서등을 참고하고 그 플러그인이 어떤 동작을 해야하는 것인지 requirement 파악에 주력했고, 이후 현재 소스코드와 그간 코드 작성이 된 히스토리를 살펴보기 시작했습니다. 오픈소스 프로젝트인지라 문서화에 중간중간 공백이 있었지만 전체 그림을 읽는데는 큰 문제가 없었는데, 문제는 코드 리딩과 히스토리 확인이였죠.

 일단 코드 리딩을 시작하니 온갖 곳에 다양한 예외처리 로직들이 있었습니다. 메인 비지니스 로직보다 더 길고 복잡하게 구현되어있는 예외처리 로직들이 제가 흐름을 쫒아가는데 방해가 되기 시작했죠. 그래서 최종 마스터 브랜치를 읽는 것이 아니라, 그간 커밋 히스토리를 읽으며 왜 그러한 예외코드들이 작성되어있는지 알아보기로 했습니다. 하지만 더욱 더 가관은 커밋 히스토리였죠. 분명 git을 도입하면서 저희가 만든 가이드라인에 의하면 한 커밋에 2개의 티켓이 포함되어도 안되고, 하나의 티켓이라고 해도 각각의 구현 내용, 목적 등에 따라 커밋을 나눠어야 하는데, 이 프로젝트의 각 개별 커밋에는 3~4개의 티켓 번호가 들어간 것은 기본이거니와 각 티켓번호마다 4~5개 이상의 수정 내역을 적어 두었더군요. 그나마 커밋 메시지에 들어온 내용이면 다행인데, 전혀 언급이 되지 않은 수정내역도 많이 있었고요.

플러그인이라 그다지 큰 프로젝트는 아니기에 하루면 충분히 프로젝트 파악이 될 수 있을 것이라는 저의 생각은 완전히 물 건너갔고, 현재 코드 구조를 읽고 이해하는데만 첫 주의 남은 근무일을 모두 소진하고 말았습니다.

코드 리딩에 결정적인 장애물은 위 두 가지였지만, 사실 자잘하게도 여러가지가 있었습니다. Java 프로젝트임에도 Java에서 사용하는 네이밍 노테이션을 따르지도 않았고, 코드 인덴테이션도 맞지도 않고, 함수명이나 변수명이 그 목적이나 의미와 잘 맞지 않은 경우도 많았으며, 프로젝트 생성 시에는 퍼블릭 함수에 Java Docs를 만들어 두고서는 관리를 전혀 하지않아 설명과 실제 코드가 맞지 않기도 했고, 유닛 테스트는 유의미한 유닛테스트를 한 것이 아니라 단순 테스트 커버리지를 어느정도 확보하기 위한 테스트들만 있었기에 유닛 테스트를 통해 각 매서드의 expected behaviour를 알아내기도 힘들었습니다.
 예를들어 플러그인에서 외부 웹 서비스를 통해 어떠한 값을 받아오면, 그 값에 따라 3가지 다른 핸들링 케이스가 나오며, 그 외의 경우에는 BAD_REQUEST exception을 던져야 한다고 가정해보죠. 그런 경우 보통 외부 서비스를 mocking 처리를 하고, 유효한 리턴값 3가지와, 유효하지 않은 임의의 리턴값을 포함한 최소 4가지 시나리오가 나오는 테스트 매서드를 만드는 것이 보통의 접근 방법이겠죠? 그런데 이 유닛테스트는 어찌 된 것인지, 외부 서비스를 mocking하지 않고, JUnit테스트 프로젝트 내에서 더미 서비스를 직접 구현했고, 리턴 값에대한 setter/getter 함수를 만들어 놓고, "외부 서비스가 1을 리턴하게 설정했을 경우 서비스는 1을 리턴해야 한다." 를 테스트 하는 말도안되는 유닛 테스트를 하고 있었습니다. 즉 실제 제품의 비지니스 로직은 전혀 테스트 하지 않고, 테스트 프로젝트 내에서 작성한 더미 클라스의 세터와 게터 함수를 확인하는 것이였죠.

사실 Java 개발자가 한명도 없는 DevOps팀에서 신입 개발자가 이 플러그인을 개발했다면 어느정도 이해를 할 수도 있는 부분이 있긴 했습니다. 그래서 어마어마한 인내심을 가지고 1달동안 이 프로젝트 리뷰를 어떻게든 해보려고 노력했던 Java Architect에게 그간의 이런저런 히스토리를 듣고 거의 처음부터 다시 작성한다는 기분으로 하나씩 하나씩 리팩토링에 들어갔습니다.

그렇게 2주 정도 지났을 무렵, 이전 팀 매니져와 만나서 이런저런 이야기를 하다가, 지금 제가 하고있는 프로젝트 상황을 잠깐 이야기 했죠. 그러자 바로 매니져가 대뜸 하는 말이 

"아. 그 코드 original author가 누군지 말 안해도 알겠다. 분명 xxx일꺼야."

"응? 맞아. 너 xxx알아?"

"알아. 너 우리회사 오기 전에 안드로이드 팀이였거든"

"근데 난 그 친구 얼굴도 본 적이 없는데? 언제부터 DevOps로 옮긴거야?"

"말하자면 긴데, xxx가 첨에 면접 통과해서 Intermediate 급으로 안드로이드 왔었지. 근데 너 그 프로젝트 보면 이해 되겠지만, 도저히 같이 일할 수 없어서 probationary 기간 중에 그만 뒀어"

"뭐야? 그럼 회사 나갔다가 다시 DevOps로 재입사 한거야?

"응. DevOps에서 면접본거 우연히 알게되서 안드리(DevOps 매니져)에게 절대 뽑지 말라고 얘기했는데, 2년이면 사람이 바뀔만한 충분한 시간이고 면접할 때 인상 좋고 잘했다면서 구지 뽑더니만... 결국 DevOps에서도 2달정도 있었나? 그러다 짤랐지."

"그래, 솔직히 프로젝트 코드 보면서 어쩜 이럴까 싶긴 했는데... Build Tool 전문가가 그냥 코드 짰거나 쥬니어나 인턴이 작성한건줄 알았어"

"걔 DevOps엔 시니어로 들어왔어! 그것도 Java Specialist로!"

"DevOps에 Java Developer가 없어서 면접볼때 제대로 확인 못했나보네"

"아냐, 우리팀에서 면접권으로 같이 나가서 봐줬었어"

"그럼 우리팀 면접 질문에 문제가 있네. 바꿔야지"

"근데, 참 신기한게 내가 xxx 채용 할 때에도 면접할 때엔 정말 인상 좋았어. 기술면접 진행한 시니어들도 평가가 좋았고. 그래서 채용한거고"

"안드리도 마찬가지였나보네."

"응, 내가 그래서 속지 말라고, 진짜 후회한다고 그렇게 말렸던거지."

잠시잠깐 제가 개고생 하고있는 프로젝트의 원작자의 뒷담화?를 하면서 속으로 뜨끔 했습니다.

'헉! 그래... 면접을 잘 봐서 실제 실력보다 과대평가 되서 다른 회사에 간다면 이런 일이 생길 수도 있겠구나. 내가 만약에 그 전에 면접에서 어찌어찌하다 잘 되서 다른회사로 이직 했으면 바로 이 꼴 났겠다.'

불행인지 다행인지 사실 저는 직접적으로 팀 내에서 이런 팀 동료를 아직까지는 만난 적이 없기는 합니다. 게으른 동료들은 있어도 못해도 잘하는척, 몰라도 아는척 하면서 자기 실력을 뻥튀기 하지는 않았거든요. 대학생 코업 학생 중에 그런 친구가 한 명 있긴 했는데, 팀원 다수가 매니져에게 차라리 인력 1명이 줄더라도 그 친구는 있는 것 보다 없는 것이 오히려 도움이 된다고 이야기 해서 그 친구는 다른 팀으로 보낸 이력이 있죠. 그래도 그나마 그 친구는 코업 학생이라 해고되지는 않았는데 이 친구는 intermediate와 senior로 들어와 그 미만의 실력을 보였던지라 회사에서 probationary 기간 중에 바로 쫒아 낸 것이였죠.

그리고 플러그인 개발을 마친 후 빌드용 VM관리 서버의 동작 확인을 위해 VM관리용 서비스 C# 프로젝트를 오픈하고나니, 또 비슷한 상황을 볼 수 있었습니다. 당연히 같은 친구가 한 일이라 생각했는데, 또 다시 제가 모르는 다른 이름이 나오더군요. 그래서 처음 DevOps팀 설립 멤버인 동료에게 물어보니 이런 말을 해주더군요.

"아, 전에 팀에 있던 사람이야. 지금은 회사 떠났어. 처음에 우리도 Continuous Delivery 공부하면서 팀을 만들 때, 인력 확장도 필요하고, 기존에 관련 경험과 경력이 있는 사람이 필요해서 채용한건데, 사실 우리가 이에대해 아는 것이 없다보니 그 사람이 얼마나 아는건지, 제대로 아는건지 확인을 하지도 못하고 채용했던 사람이야."

역시나 약간의 허세와 말빨, 그리고 인터뷰를 위한 공부를 통해 들어왔던 사람 이였던 것 같았습니다.

예전에 차승원씨가 삼시세끼에서 손호준씨를 칭찬하면서 이 모든 것을 갖추었다며 이런 말을 한 적이 있었죠.

“능력이 없으면 열정이 있어야 하고, 열정이 없으면 겸손해야 하며, 겸손하지도 못하면 눈치가 있어야 한다”

그런데 Probationary 기간 중에 해고되었던 그 친구들의 사례를 보면, 차승원씨가 한 이야기 중에 눈치는 확실히 있었던 것 같네요. 능력과 열정은 없거나 부족하지만, 겸손하기는 커녕 자기 자신을 과대포장해서 인터뷰 시에 눈치껏 잘 홍보 한 것이죠.

그리고 코드 자체를 보면 능력이 부족하다는 것이 (적어도 Senior로 들어온 사람으로서는) 명약관화하게 보이며,  코드리뷰 히스토리를 보면 정말 겸손함과 열정이 없습니다. 회사 가이드라인에 맞지 않은 커밋에 대해 Architect가 초반부터 지적했음에도 조금도 개선되지 않았죠. 사실 git이기에 본인 브랜치 삭제하고 커밋을 다시 잘라 push해도 되는 일인데, 그 리뷰에 대해 "나 그 가이드라인 따르려고 많이 노력중임. 그런데 그거 다 따라하기는 어려움. 일단 그냥 마지막 커밋 기준으로 코드 리뷰 해주길 바람. 돌려보면 동작함" 이런 답변을 달고 끝낼 정도로 열정도 없고, 리뷰어에 대한 존중도 없었죠.

최근에 갑자기 Probationary기간에 해고된 2명의 직원 이야기를 몰아서 들은 후에, 제대로 다른 회사에서 Senior로 일 할 만한 실력도 준비도 안된 상태에서 면접을 보러 다녔던 제가 부끄럽기도 했거니와 오히려 이직을 하지 않은 것에 대한 감사함이 떠오름과 동시에, 2년여 전 처음 어쩌다 입사를 해서 항상 게눈을 하고 이곳저곳 동태를 살피며 눈치보고, 캐나다 직장에서는 나에게 바라는 기대치가 얼마일지 전혀 감을 잡지 못해 행여나 운 좋게 잡은 직장에서 해고당할까봐 밤 늦게까지 공부하고 일하면서 보냈던 그 때의 시간이 다시 생각나기도 했네요.

그 때엔 능력은 정말 없었지만, 열정도 있었고, 또 스스로를 바닥이라고 생각했던 만큼 당연히 겸손했으며, 모든 것이 불안했기에 당연히 또 눈치가 있었는데, 요즘 겨우 경력 다시 시작한지 2년 조금 넘었다고 열정은 있으나 거만하고, 눈치없이 자기 목소리만 너무 내세우지만, 그렇다고 또 어디 가서도 지지않을만큼 당당한 실력도 갖추지 못한... 그런 애매한 실력에 성격도 좋지 못한 개발자가 된 것 같네요.

팀 이동도 했고, 새로운 분야에서 일을 시작했으니 초심으로 돌아가 하나씩 다시 배워봐야 할 것 같습니다.

난 어떻게 취업이 된걸까???

처음 회사에 입사를 하고나서 3개월의 probationary 기간의 쫄깃한 긴장감을 겪고있었던 시절, 저는 한 가지 의문이 있었습니다. 

"근데 왜 내가 취업이 된거지?"

영주권을 받고 이력서를 돌리기 시작했을 때 저는 일단 회사에 들어가면 일을 잘 할 자신이 있었습니다. 당장 실력이 좋아 가자마자 잘 할 자신이 있던것은 전혀 아니지만, 수 년 전에 제가 해왔던 개발자 세포 하나하나가 빠른 시일 내에 깨어나며 언젠가는 잘 할 수 있다는 자신이였죠.

하지만 동시에 취업을 할 수 있다는 자신은 없었습니다. 제 스스로 저를 돌아봐도 경력은 있으나 이미 5년 전 경력이고, 그렇다고 해도 그리 긴 경력도 아니고 4년 남짓의 경력일 뿐이고, 무엇보다 제가 해왔던 업무나 분야와 비슷한 직종은 찾기 힘들기에, 새로운 언어와 개발환경에서 일을 해야하는 것이 뻔했죠.

그러면 결국 엔트리레벨로 입사를 해야하는 상황일텐데, 엔트리레벨로 다른 경쟁자와 비교하자면 당장 컬리지 졸업도 안한 재학생인지라 처음 이력서를 작성하고 여기 저기 돌릴 때 부터 속으로 "안되겠지? 그래도 한 두번이라도 면접 걸리면 나중에 경험이 될테니 좀 해보자. 누가 알아? 이러다 덜컥 되버리면 좋은거지" 라고 생각했습니다.

어쩌면 첫 구직에는 오랜시간이 걸린다는 많은 분들의 이야기 때문에 제 스스로 방어기재가 작동해서 자기 방어와 최면을 거는 것일수도 있죠.

그러다 처음으로 면접 기회를 잡은 곳이 지금 회사였습니다.

지금도 저는 면접 당일의 기억이 생생합니다.

면접 전부터 지원 포지션 상세설명을 잘 읽지않고 잘못 지원했던 포지션이였고, 전화 통화로 진행했던 스크리닝 인터뷰 때 전혀 경력도 없는 Java쪽인 안드로이드 개발 포지션도 제안 받았으며, 막상 면접에 도착해서는 제가 안드로이드와 Java쪽으로는 정말 쑥맥이였다는 것을 확실히 증명만 하고 나오는 면접이였습니다.

진짜 마지막 VP 면접에서 VP가 같이 일하자고 말하기 전까지는 속으로 계속 눈물만 흘리며 이렇게 생각하고 있었죠.

"이미 답은 다 정해진 것 같은데, 여기 더 이상 남아서 인터뷰 볼 필요가 있나? 
그래 맘을 비우자. 처음부터 경험삼아 해보는거였자나. 괜히 욕심 부려서 맘만 상하지 말자. 
경험삼아 보는거니까 일단 계속 남아있자... 
면접 할 때 물어보나 하나하나 다 기억해두고 적어두고 나중엔 이런거 다 공부 한 다음에 면접보자.
그런데 집에는 뭐라고 말해야하지???"

그렇게 너무나도 운이좋게 직장을 구해서 일을 시작했고, 처음 일을 시작하며 Java라는 언어와 요즘의 개발환경, 그리고 프로세스에 어색해 하며 모르는 것 하나하나 구글링 해가며 감을 잡아가던 시기에도 '그런데... 내가 왜 뽑힌거지?' 라는 생각은 계속 가지고 있었습니다.
그리고 언젠가 내가 회사를 떠나게 될 때, 혹은 내 매니져가 나보다 먼저 회사를 떠나게 될 때, 한 번 물어보자고 생각하고 있었습니다.

지난 금요일에 팀런치를 하러 밖에 나가게 되었고 어쩌다 이야기가 각자의 이민 이야기와 처음 직장을 구할 때 에피소드 등으로 연결이 되었습니다. 저나 제 매니져가 회사를 떠나는 상황은 아니였지만, 이야기가 이렇게 흘러가다보니 저는 오래된 궁금증 하나가 다시 떠올라 질문을 던지게 되었습니다.

"갑자기 내 오래된 궁금증 하나가 떠오르네?
알렉스, 기억 날 진 모르겠지만 내가 여기 처음 죠인할 때 기억나?
너 왜 날 뽑았었니???
난 경력이 있긴 했지만, 이미 5년도 지난 오래전 경력이고, 그나마도 4년 남짓으로 짧았고, 안드로이드는 커녕, 자바도 제대로 된 경험이 없고, 시니어도 아닌데 원래 시니어 포지션 포스팅에 지원한 거자나. 
더구나 솔직히 인터뷰 과정도 난 완전 엉망이였다고 생각했거든. 
너 왜 날 뽑았었니?"

이미 2년 가까운 시간이 지난지라 사실 매니져도 당시의 상황을 전부 기억하지는 못했습니다.

다만 제 인터뷰 과정에서 안드로이드 팀과 Windows팀 양쪽에서 동시 인터뷰를 진행하는 등, 몇 가지 특이한 상황이 있었던지라 그와 관련해서 하나 둘 씩 어렴풋한 기억을 꺼내 놓았습니다.
그리고 특유의 솔직함으로 기억하는 바를 털어 내더군요.

"먼저 이유가 어찌되었던, 당시 면접 전에 괜찮아 보이는 사람이라면 Junior 포지션으로 뽑기로 이야기 되었었어. 분명 선입견이긴 하지만, 한국사람이라 잘 따를꺼라 생각했고, 그래서 junior로는 적절할 것 같다는 느낌이 있었어."

"회사가 커지며 업무가 많아지니까 중급 아니면 고급 개발자가 필요한건 맞긴 했지만, 당시에 사람 찾기는 어려웠고, 있던 사람들이 오히려 나가고 있었지. 스티븐이랑 (윈도즈팀 매니져), HR이랑 이야기 하다가 그랙 괜찮다면 쥬니어로 받아보자 지금 당장 사람 필요한데 그렇게라도 사람 받아서 일해야지 라고 정했었어"

"네가 진행했던 기술 인터뷰 내용들은 내가 지금 기억이 안나. 얼마나 잘했었는지 못했었는지. 그런데 확실한건 기술 인터뷰들을 진행했던 interviewer들의 평가가 괜찮았다는거야.
처음부터 시니어 받는거라면 인터뷰 질문 과정들에 답변을 얼마나 잘하냐. 시니어로서 알아야만 할 만한 질문들에 다 대답을 하는지가 중요해. 그런데 넌 쥬니어 수준으로 면접 시작 한 거자나. 그러면 네가 얼마나 많이 정답을 맞췄느냐는 중요하지 않아."

"아, 그러고보니 몇가지 생각나는 피드백이 있었고 다들 그걸 좋게 생각했어. 어떤 질문들이 주어졌을때, 너는 '몰라' 라고 이야기 하면서, '예전에 이런거 했는데 그거 비슷한 것 같다. 이것도 이런 식으로 풀어나가면 되지 않을까'. '똑같은 개념은 아닌것 같은데 C에 있는 이런거랑 같은 방식으로 쓰이는거 아니야?' 등등, 몰라도 그냥 모르고 끝나거나, 모르는 것에 대한 변명을 하기보다는 다른 방식으로 접근을 해보는게 좋았다. 시니어 면접이였으면, 이것도 모르면서 시니어야? 했겠지만, 쥬니어이기에 이런 접근 방식들이 좋았다"

"그리고 오스카 (당시 CTO)가 면접 전에 네 이력서 보고 맘에 들어하더라. 개발과 PO경력 둘 다 있다고. 개발자로서 PO를 이해할 수 있는 사람이고 우선순위에 대해 명확할 거라고. 그리고 개발자로서 우리가 생각하는 만큼 진척을 보이지 못한다면, 시간이 지나 우리 회사 제품에 익숙해지고, 만약 말도 좀 된다면, PO 포지션으로도 쓸 수 있을 가능성도 있다면서."

사실 위 이이야기는 면접 과정에서 오스카가 제게 '난 니가 개발과 PO경력 둘 다 있는 것이 맘에 들었다' 정도로 간략하게 말 한 적도 있었습니다. 당시엔 그냥 립서비스 정도로 생각했는데, 그냥 솔직히 이야기 했던 거였네요.

어찌되었건 지금은 매니져가 모든 과정을 세세하게 기억을 못하지만, 정리해보니 역시나 저는 정말 운이 좋았습니다.

실수로 시니어 포지션에 지원한 것이지만, 회사에서 마침 사람 부족한데 구하기는 힘들다보니 쥬니어라도 사람 괜찮아 보이면 채용 해보겠다고 매니져들이 결정한 것은 누가 뭐래도 100% 운이죠.

누가봐도 개발자로서 경력단절인 지원자였지만, 회사가 커지며 PO역량 또한 중요시 되고 있던 시점이였고, 당시 CTO가 PO와 개발을 모두 담당했었기에, VP가 보기엔 제가 오히려 괜찮을 수도 있는 멀티 플레이어 카드였습니다.

또한, 정말 고마운 분들은 저보다 먼저 제 회사를 거쳐갔던 많은 한국인, 혹은 한국 출신 선배들입니다. 그 분들 모두 남들과 다투기 보다는 따르는 편이였고, 일을 하면서 입으로 싸우기 보다는 코드로 싸웠고, 좋은 성과와 평가를 남기고 떠나셨기에 제 매니져에게 좋은 선입견을 심어준 것이죠. 만약 그 분들이 게으르고, 말만많고 결과는 없고, 분란을 조장하고 떠났다면 제 면접에 악재가 되었을 수도 있으니까요. 이 역시도 제 스스로 어찌할 수 없는 부분이기에 그저 운이라 할 수 밖에 없을것 같습니다.

예전에 유럽쪽의 소도시로 유학을 가셨던 어떤 분이, 외국에 나가서 한 사회에 정착하여 장기간 소수민족/소수인종으로 지내면서 겪게되는 어려움 중 하나는 나 하나라는 개인이 우리나라/우리민족/우리사회라는 대표성을 가지게 된다는 부담감이라고 한 적이 있었습니다. 어떤 식이건 선입견이란 좋은 것은 아니지만, 그래도 가능한 저를 경험했던 다른 사람들이 한국인, 한국출신 사람들에 대해 좋은 선입견을 가질 수 있도록 해야 한다는 것을 다시한번 느끼기도 했습니다.

아 그리고, 제가 학교 다닐 때 같이 입학했던 친구들이 이제 졸업한지 9-10달 정도 지났는데, 이제 제대로 된 개발자 포지션으로 구직 소식이 하나 둘 씩 페이스북을 통해 들려오기 시작합니다. 아직 소수의 학생들만 개발자 포지션을 구직 했지만, 첫 커리어를 구하는 것은 적어도 반년에서 일년은 보통 걸린다는 말이 진짜인 것 같긴 하네요.

소프트웨어 개발자 / 프로그래머 캐나다 기술면접 및 취업 후기

북미 지역에서 엔지니어 취업에 관련하여 예상 질문 내용은 구글에서 영문으로 검색하면 수도 없이 많이 나오지만, 행여나 아직 영어가 익숙하지 못하신 개발자 분들을 위해 저의 수기를 남깁니다.

결론적으로 완전 엉망진창인 Resume와 Cover letter였지만, 제 기존 경력과 현 직장간에 어느정도 연결고리가 있었기에 회사에서 제 지원서에 관심을 가져주었고, 한국 경력에 대해 어느 정도는 인정도 받았고 몇 번의 기술면접을 통해 취업이 되었습니다.

캐나다에 온 이후 이곳 저곳에서 들리는 이야기에 의하면 이곳에서 취업을 하기 위해 가장 필요한 것 중에 하나는 스펙도 아니고, 실력도 아니고 훌륭한 resume와 cover letter라고 합니다.

하지만 북미 문화권에서 살아온 것도 아니고, 네이티브 수준의 언어를 구사하거나 작문 할 실력도 아니고(이 글에서 느껴지듯, 한국어 작문 실력도 우수하지 못합니다) Software developer에 대한 열망과 열의는 있지만 그간의 경력은 이미 한물 간 기술에 불과하며, 그간 쌓아온 지식 역시 최근 5년간 단절된 경력으로 인해 많이 잊혀진 상태인 저 였습니다.

한국인 개발자 모임에서 조만간 Cover letter와 Resumer관련 워크샵을 개최 할 예정이였고, 졸업을 위해 들어야 하는 마지막 한 과목에서 역시 이에 관련된 내용을 배우겠지만, 기왕 취업하기로 마음을 먹은 상태에서 저는 단 한 번이라도 인터뷰 기회를 잡아 실제 직업 인터뷰가 어떻게 진행되고 무엇을 물어보는지 경험을 하고 싶었습니다.

정확한 근거 데이터는 없지만 영어권 국가에서 경력이 없다면, 인터뷰 기회를 잡으려면 수십 곳에 job apply를 해야 할 것이라고 알고있었고, 그렇게 인터뷰를 십여 곳 이상 보아야 취업이 될것이라고 들은 바가 있었습니다. 그래서 Cover Letter와 Resume는 나중에 하나 씩 교정을 한다고 생각하고, 미리 이 나라에서 Job 인터뷰가 어떻게 진행되는지 경험을 해보고 싶은 마음에, 영주권을 받은 그 날부터 바로 monster, indeed 등 취업 포탈과 LinkedIn을 통해 관심업종/분야 의 구인광고를 필터링 걸어두고 매일매일 지원서를 넣기 시작했습니다.

처음에는 말 그대로 한번 정도는 인터뷰를 해보고 정말 마음에 드는 포지션만 지원을 해 보았는데, 벽에대고 말을 하듯 아무런 응답이 없었습니다. 
수십 곳에 지원을 하면 한 번 인터뷰를 본다고 했는데... 좀 과장이라고 생각했는데... 총 지원한 회사가 30 곳이 넘어가도 아무런 연락이 오지 않더군요.
그러자 오기도 생기고 욕심도 생겨나  하루에 3-4곳 씩 비슷한 분야가 나오면 지원을 하기 시작했죠.

제 Cover Letter가 워낙 부실했기 때문이기도 하겠고, 에이전시를 통해 지원된 것도 아니고 임직원 추천에 의해 전달된 것도 아니니 회사 HR에 제 지원서가 전달될 때 그다지 큰 영향력을 가지지 못했기 때문일 수도 있고, 제 경력에 최근 5년 정도는 Development 실무와 거리가 있었기 때문이기도 하겠지만, 누적 지원 포지션이 70-80 곳이 넘어도 아무런 연락이 없으니 점점 초조해지기 시작했습니다.

분명 처음에는 큰 기대를 하지도 않고, 어짜피 지금 학교 과정이 한 학기 남았지만 그냥 경험삼아 해보기로 한 일이였는데, 이제는 졸업을 해도 같은 상황이 반복될 것만 같고, 앞으로 이렇게 방 구석에  앉아서 "구인/구직 포털 자동 필터링 확인 - 포지션 확인 - 요구사항 키워드 체킹 - 커버레터 수정 - 발송" 이 생활만 반복할 것만 같아 불안하고 초조한 마음까지 들기도 했습니다.

크리스마스 때 지원 포지션들을 정리해 두었던 엑셀 파일에 100번째 줄이 채워지자, 쓸데없는 불안감이 스스로를 괴롭히는 것 같아 결국 학교에서 취업 관련 과목 수업과 개발자 모임에서 Resume 세미나를 통해 가다듬은 이후에 지원을 하기로 마음을 정리하게 되었습니다.

그리고 박싱데이 다음 날, 가족들과 차를 타고 근처 몰에 가던 중, 모르는 번호에서 전화가 왔습니다. 광고 전화 외에는 딱히 전화 오는 곳도 없어 보통 모르는 번호는 보이스 메일로 넘어갈 때 까지 안받는 편이지만, 요즘 이력서를 넣고있는 중이라 이건 꼭 받아야한다는 생각에 급히 골목길로 들어와 차를 정차시키고 전화를 받았습니다.

"안녕 나는 XX회사 인사팀의 OO이라고 해. 너 ㅁㅁㅁ 맞지?"

이 말을 듣는 순간 모든 안면근육들은 제 마음 속의 환희와 기쁨을 표현하기위해 노력했고, 제 아내는 그런 제 표정을 보자마자 눈치를 채서 아이들을 조용히 시켰습니다.

그런데 그 직후 전화에서 들려오는 소리는 곧바로 저를 경직되게 만들었습니다.

"네가 지원한 Senior C++ engineer 포지션에 대해 이야기 해보려고"

잉? 시니어? 이건 아닐텐데... 분명 아닐텐데...
포탈에 자동 잡 서치 필터링에 초급/중급으로 필터링을 걸어두기도 했고, 사실 제 경력상 최근 5년간은 실무 Development를 한 적이 없었고, 모든 경력을 합쳐도 실무 개발자로는 4년이 조금 안되게 근무한 것이 전부였기 때문이죠.

"자...잠깐. 포지션이 뭐라고?"
"Senior C++ engineer 포지션. 네가 지원한거. 나 XX 회사라고."

헉... 시니어? 뭔소리?
어느 정도 시니어로 덤벼 볼 만한 깜냠이 있다면 그냥 그러려니 했겠지만, 지금 제 상황이 전혀 그렇지 못하기에 그냥 넘어갈 수 없었습니다. 아... 처음으로 받는 회사 연락이 하필이면 기계적으로 이력서 넣다가 잘못 넣은 곳에서 온 연락이라니... 제 얼굴은 점점 흙빛으로 변해가면서 이렇게 이야기 할 수 밖에 없었죠.

"어... 난 Senior는 아닌것 같은데, 계속 C++를 해왔다면 시니어가 되었겠지만, 09년을 마지막으로 커리어 변경도 있었고, 내가 C++를 하긴 했었지만, WinCE나 Windows가 아니라 임베디드 폰에서 자체 OS였어. Windows/WinCE 플랫폼이나 프로그래밍은 아카데믹 수준 이상이 아니라 시니어는 아니야" 

주변에 자동차 경적 소리 등 여러 소음 때문인지, 제가 밖에 있다는 것을 알아 채고는 "혹시 밖에 있으면 다음에 통화하자"고 하면서 며칠 이내에 전화를 주겠다며, 서둘러 전화를 끊더군요.

내가 왜 지금 밖에 나와 운전을 하고 있었는지도 속상하고, 처음으로 연락이 온 것이 무언가 지원 포지션에 착오가 있는 것도 화가나고, 요즘 기계적으로 지원서를 작성했던 제 자신에게도 화가나서 제 낯빛은 점점 더 흙빛으로 변해가고 있었습니다.

곧바로 무언가 눈치를 챈 아내는 저 혼자만의 시간을 주기 위해 "전화해" 라는 한 마디를 남기며 서둘러 아이들을 챙겨 몰 어디론가 사라졌고, 저는 분통함에 스마트 폰을 꺼내어 그간 지원한 회사들을 정리한 엑셀 파일을 열어서 그 회사 포지션 링크를 열어보았습니다.

포지션 타이틀. 'C++ Software Developer'
다행히 시니어가 아니더군요. 그냥 인사과에서 제 경력이 05년 시작되었기에 그렇게 붙여준건가 싶어서 조금 안심을 하기 시작했는데, 세부사항을 읽다보니 "Senior or Lead role"이라는 말을 찾게 되었습니다.

헉... 입사 지원을 시작하고 두어 주 정도 지나자 점점 저도 모르게 기계적으로 움직이기 시작했고, 그 덕분에 회사 쟙 타이틀만 확인했지 세부 description에 언급 되었던 senior라는 말을 미처 인지하지 못하고 상향지원??? 을 하게 된 것입니다.

제가 지원을 잘못했다는 것을 확실히 확인하자 마음이 편해졌고, 고맙게도 저를 배려해 준 아내와 아이들을 찾아갔습니다.

그래도 혹시 몰라 그날 밤 잠들기 직전 연락이 왔던 번호를 폰북에 저장을 해 두었죠.

그리고 며칠 후 저장이 되었던 번호에서 연락이 왔습니다.

그 때에도 동네 YMCA에 갔다가 걸어도 돌아오는 길이였는데, 지난 번 처럼 주변 소음이 들려 전화가 중단되는 것이 싫어 바로 옆 콘도 현관으로 뛰어들어가 전화를 받았습니다. 
정말 다행히도 제 경력사항과 제가 가진 기술에 대해 이것 저것 상세하기 질문을 하기 시작했고, 결국 일단 기술시험을 한번 보자는 것으로 결론이 났습니다.

저의 경우 다음과 같은 순서로 채용 프로세스가 진행 되었습니다.

1. 인사과 직원과 전화 인터뷰
• 백그라운드 확인
• 경력 확인
• 개략적인 조건 확인(희망 포지션, 연봉, 복지 등등)
2. 온라인 기술 시험
• 1시간 내 2개의 C function 디버깅
3. 인사과 전화 인터뷰
• 경력사항 세부 확인
• 근무 조건 추가 확인
• 기술면접 일정 arrange
4. 기술 면접
• Senior Engineer 인터뷰 (Java, Android, C++ 3번)
• Group Head 인터뷰 (WinCE / Android 2번)
• Software VP(CTO) 인터뷰

1차 전화 인터뷰 이후 온라인 기술 시험을 치뤘습니다.

매우 어려운 문제는 아니였지만, Entry Level의 개발자의 기본적인 소양을 판단하기에는 적합한 문제로 생각되는데, C언어의 Syntax기반으로 짜여진 2개의 코드가 주어졌고, 각 코드의 작성 의도가 제시 되었습니다. 그리고 1 시간 내에 각 코드를 디버깅 하여 수정하고, 필요시 퍼포먼스를 향상시키는 것이였습니다. 최근 5년간 상용화 제품 레벨에서 직접 코딩을 한 경험이 없기에 바짝 긴장했지만, 막상 코드를 받아보니 Array length와 memory allocation관련 오류나, array의 값 read/write시 잘못된 루프 카운팅 혹은 O(n)으로 가능한 알고리즘이 불필요하게 O(n2)로 되어있는 등 예상보다는 쉬운 문제들 이였습니다.

시험을 치루고 약 1주 정도가 지난 뒤 다시한번 인사과 직원으로부터 연락이 왔고 엔지니어 팀에서 이력사항과 인터뷰 내용 그래고 온라인 시험 결과를 확인 해 본 결과 C++와 Android Engineer 양쪽 포지션을 제안해 보고 싶다고 했습니다.

여기서도 다시한번 문제가 있었죠. 이력서 상에 Technical Manager로 되어있는 4년 반 정도 경력에 Android 플랫폼으로 진행한 여러 프로젝트들이 있었지만, 실제 코딩은 전혀 하지 않았기에 혼자 이것저것 재미삼아 개발해본 Android 실력으로는 문제가 있을 것 같았습니다. 그래서 결국 다시한번 고해성사를 하게 되죠.

"Android 플랫폼의 몇몇 프로젝트에 Tech manager로 참여했지 실제 코딩 경험은 academic purpose 수준을 넘지 않는다. Android 개발은 해보고 싶은 분야이긴 하지만 너희 기대치와 다를 수 있는데 괜찮은가?"

결국 회사에서 검토해 보겠다고 하고 다시 몇일이 지난 뒤, 기왕 C++ 엔지니어로 면접을 보는거 Android 팀도 같이 한번에 면접을 보자고 하더군요. 이런 고마운 일이 ㅠㅠ

그렇게 면접 날짜와 시간을 정하고, 아래와 같은 순서로 약 2시간 반 정도에 걸쳐 face 2 face 기술면접을 치루게 되었습니다. 

1. Core JAVA 기술 면접 (Android팀 Senior Engineer)
2. C++ and WinCE UI 기술 면접( WinCE/Win Mobile Senior Engineer)
3. Android Architecture (Android팀 Senior Engineer)
4. Android  헤드 면접
5. WinCE 헤드 면접
6. CTO 면접

회사마다, 그리고 지원 포지션에 따라 기술면접 내용은 상이하겠지만, 그래도 혹시나 캐나다에서 기술면접 경험이 없으신 분들께서 참고하실 수 있도록 기억나는 질문 내용들을 적어봅니다.

• 화이트 보드에 Pseudo code로  Merge Sort의 코어로직 메소트를 작성하라
• Quick sort의 pseudo code를 작성해 보아라
• Java에서 Interface/Abstract class를 비교 설명하고 언제 어떠한 class를 쓰는지 예를 들어라
• 상속받은 2개의 Interface에 동일한 이름과 signature인 Method가 있고 상속한 class에서 동일한 이름을 가진 method를 구현하였을 때 어떠한 인터페이스의 method가 구현된 것일까?
• 오버라이딩과 오버로딩에 대해 설명하라
• 왜/언제 오버라이딩과 오버로딩을 사용하는가?
• 각각 오버라이딩과 오버로딩된 두 메소드는 언제 어떤 메소드로 링크될까?(컴파일/런타임)
• 사용해 본 디자인 패턴은 무었인가? 그 디자인 패턴에 대해 설명해 보아라
• 유닛 테스트란 무엇인가? 유닛 테스트의 장점과 제약사항은?
• Integration teset란 무엇인가? 언제 어떻게 해봤냐?
• 네가 작성하지 않은 코드나 라이브러리를 테스트하거나 거기에서 무언가 문제가 있다고 보일때 넌 어떻게 디버깅 할꺼냐?
• Android의 recovery mode란 무었인가? 언제 어떻게 사용하는가?
• ANR은 무엇인가? ANR 회피를 위해 어떻게 하는 것이 좋은가? ANR 발생 시 디버깅 방법은 무엇인가?
• Android에서 핸들러와 루퍼는 무엇인가?
• 핸들러와 루퍼는 각각 어떻게 사용하는가?
• Android에서 injection framework란 무엇인가? 언제 사용하는가?
• Android에서 signing이란 무었인가? 왜 중요한가? 시스템 내부에서 어떻게 동작하는가?
• Content Provider란?
• Content Provider는 어떻게 사용하는가?
• Broadcast Receiver란?
• Broadcast Receiver 사용해보았나? 어느 경우였나?
• Broadcast Receiver사용 방법에 대해 순차적으로 말하라
• Android의 Inter Process communication 방법은 무엇인가? 어떻게 사용하는가?
• Android Activity와 Fragment에 대해 설명해 보아라
• Fragment를 사용해 보았다면 언제 사용해 보았는가? 왜 Fragment 가 필요할까?
• Activity와 Fragment의 life cycle을 설명해 보아라
• Thread간 동기화 방법들에 대해 설명해 보아라
• 왜 캐나다로 오게 되었는가?
• 향후 장기적 커리어 플랜은?
• 개발자로서 가장 보람된 순간/가장 어려웠던 순간은?
• 멀티 쓰레딩에서 가장 중요하고 많이 사용되는 메소드 3개는?
• 프로젝트에서 사용했던 개발 방법론과 디자인 패턴은 무었이였는가?
• 왜 다시 Developer가 되려고 하는가?
• 새로운 기술이나 언어를 배워야 할 필요가 있을때 너는 어떤 방법으로 접근 하는가?
• 왜 University재학 기간이 6년이나 되는가? (병역의무를 모르기에 2년간 낙제한 걸로 생각 했던듯)
• 주어진 form에서 가능한 test case들을 뽑아 보아라
  
• 다음과 같은 n x n의 비트 2차 배열이 4개가 있다. 1사분면에 데이터가 있는데, 오직 copy(sourceRectangular, destinationRectangular) 함수만 사용해서 1사분면에 있는 데이터를 좌우로 flip 시켜라
  
• 192.168.xx.xx의 IP Address를 가지는 서버가 10.xx.xx.xx 주소를 가지는 firewall을 통해 인터넷에 연결되어있고 핸드폰 단말이 하나 모바일 데이터로 연결되어 있다. 핸드폰에서 서버로 접속할때 어떤 주소로 접근하나?
• 접속한 firewall주소에는 여러 서버가 있을 수 있는데, 어떻게 각 서버로 포워딩하나?
• 반대로 서버에서 핸드폰으로 연결을 하려고 할 때에는 어떻게 해야 하는가?
• Java와 C++에서 Constructor와 Destructor를 설명하라
• 왕실 와인셀러에 1,000병의 와인이 있다. 그 중 한 병에 단 한 방울이라도 마시면 24시간 이내에 사람이 죽을 수 있는 치명적인 독이 들어있는 것이 확실하다. 그리고 내일 처형될 예정인 10명의 사형수가 있다. 10명의 사형수를 통해 24시간 이내에 1,000병의 와인 중 정확히 어떤 병에 독이 들어있는지 확인할 방법을 제시해라.
• 기타 제 경력사항에 있는 프로젝트들에 대한 문의와 당시 Software 디자인을 어떻게 했는지에 대한 질문들, 그리고 포트폴리오로 올린 웹에 있는 여러 App에 대한 질문과 각 App에서 특정 기능 프로시져와 구현방법 등에 대한 질문들이 있었습니다.

사실 위 질문들에 모두 답변을 하지 못했습니다. C/C++ 개발시 제 개발환경이 제한적인 Embedded환경이였기에 Multi-Threading이 안되었고 멀티 타스크들이 라운드로빈 방식으로 운영되었기에 thread관련 코딩은 가능해도 무언가 질문이 날아오면 바로 답변을하고 입으로나 손으로 코딩을 줄줄 할 상태도 아니였죠. 또한 Android역시 개인적으로 몇몇 어플 만들어 보고, 학교 과제나 프로젝트 정도만 했기에 필요에 의해 API doc을 찾아 개발하지 머리속에 그림이 술술술 그려지지는 않아 어떠한 개념에 대해 설명하라 까지는 답변을 해도, 그걸 어떻게 사용하는지 단계별로 설명하라는 질문들에는 청문회 공식 답변인 모른다, 기억이 안난다 라는 말만 해야 했습니다. 결국 로직 관련 질문이나 설계관련 내용들은 다 답변을 했지만 일부 API나 라이브러리 실제 사용 프로시져에 대해서는 반절 정도만 답변을 할 수 밖에 없었죠. 

그래서 Senior Engineer들과 면접이 끝났을 즈음에는 아... 첫 경험은 이렇게 처참하게 끝나는구나 라고 생각을 했습니다. 이후 Head들과 면접 시 경력사항에 언급된 각각의 프로젝트들에 대한 세부 질문과 각 프로젝트와 관련이 있을법한 기술 사항에 대한 질문들이 이어졌고 제가 느끼기에 head들이 제 경력을 인정해주고 그간의 경력에 상당한 관심을 보이며 그나마 약간의 희망이 생겼습니다. 그리고 마지막 CTO와 면접 시 대충 알긴 아는데 실제 코딩 경력이 의심스러웠는지 여러가지 로직과 알고리즘 구현 관련 질문이 이어졌습니다. 제가 생각해도 실제 API사용에 대한 구술에서는 꿀먹은 벙어리가 되었기에 글로 코딩을 공부한 사람으로 보이기 다분했죠. 다행히 특정 라이브러리 사용이나 API관련 문제들이 아니였기에 생각만으로 답변 가능한 문제라 멍때리지 않고 인터뷰가 진행될 수 있었습니다. 마지막 2차 비트배열의 flip에 대한 질문을 마친 후에 CTO가 해 준 말로 모든 걱정이 사라지게 되었죠.
"네 경력과 경험을 높이산다. 인터뷰 하기 전 너에게 기대했던 것들이 있는대 그 기대를 만족시켜서 나도 좋다. 넌 C++쪽을 하고 싶다고 했고 Android나 Java쪽 경력이 없는 것도 알지만, 네가 곧 캐치업 할 수 있을 것이라 생각하고 우리는 너에게 Android expert 포지션을 제안하고 싶다. WinCE도 주요한 우리 사업 영역이지만 Android BYOD 쪽에서 우리는 세계 최고이고 너 역시 Android팀에 합류해서 네 커리어를 더 키우는 것이 너에게도 우리에게도 도움이 될 것 같다. 오늘 오후나 내일 중으로 HR을 통해 세부 내용을 조율하고 싶다."

우왕~!!! 진짜 10년만에 듣는 취업 합격 통지. 립서비스가 강한 문화권임을 알면서도 정말 기분 좋게 해주는 말들이였습니다. C로 시작한 커리어 인지라 로우레벨 랭귀지에 대한 향수와 동경이 있어 그 쪽 커리어를 더 쌓고는 싶었지만, 첫 직장을 구하는 이민자로서 이것 저것 따질 때가 아니였습니다.

그렇게 기대와 실망 자책이 연속되었던 제 첫 캐나다 취업 수기는 해피엔딩이 되었습니다.

최근 5년간 개발 경력이 없다는 것과, 기존 개발하던 개발환경이 현재는 존재하지도 않는다는 것, 엉망진창 레주메/커버레터와, 부족한 영어실력 등 여러가지 단점이 많은 개발자였지만 70-80여 곳을 지원하다보니 이렇게 얻어걸리기도 하는군요.
한국에서 경력을 캐나다에서 이어보기 위해 노력하시는 많은 개발자 분들께서도 쉼없이 찾다보면 분명 기회가 생길 것입니다.

많은 분들께 전해들었던 이야기와 같은데, 온라인 시험과 기술면접을 경험해보니 한국보다 확실시 그 depth가 깊습니다. 면접 시간 역시 한국보다 길고, 면접에서 질문 내용 역시 한국에서의 그것 보다는 더 상세하고 깊게 들어가더군요.
마지막으로 기술 면접 시 모르는 내용이 나와도 당황하지 마시고 모르면 모른다고 답변하는 것도 방법인 것 같습니다. 응시자가 답변을 잘 하면 면접관도 어디까지 아는지 궁금해서 양파처럼 하나씩 계속 까보면서 그 depth를 더 파고들어 보는 경향이 있습니다. 꼭 그 질문에 답을 해야만 하는 것이 아니고 그 사람의 실력과 지식을 좀 더 알고 싶어서 하는 질문들도 많으니 모르는 내용은 담담하게 지나쳐 버리세요.

이제 2월 부터는 직장인으로서 캐나다 삶의 제 3막을 열게 되겠군요.

캐나다의 한인 IT 구직자 여러분 모두 화이팅 하시길...