나의 작은 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 점이라도 더 받은 사람? 아니면 매니져에게 강한 인상을 남긴 사람? 누굴까요?

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