안녕하세요 둥이아빠입니다.
보통 컬리지에서 오는 이메일들은 동문들에게 기금모금을 하는 연락이거나, 동문파티 등등 별로 관심이 없는 내용들이라 읽어보지도 않고 휴지통으로 직행하는 편입니다. 얼마 전에도 센테니얼 컬리지에서 이메일이 한 통 왔습니다.
'Invitation for PAC member'
메일 제목도 뭔지 알 수 없는 단어인 PAC이라는 말이 적혀있어서 바로 삭제를 했었죠.
그 사실을 잊고 며칠이 지난 후 얼마 전 주문한 TV가 아직 배송이 되고있지 않아서 혹시나 스팸함이나 휴지통에 메일이 들어있지 않을까 싶어 스팸함과 휴지통을 뒤져보는데, 의도치않게 그 메일의 본문이 열렸습니다. 떡 본 김에 제사지낸다고 열린김에 잠시 읽어보는데 메일의 시작이 제가 아는 교수의 이름으로 시작하더군요.
'XXX 가 추천을 해주어서 너를 Mobile Applications Development 학과의 PAC 멤버로 초대하고싶다.'
PAC이 뭔지도 모르겠지만, 일단 학교다닐 때 만났던 교수의 이름이 들어있기에 구글에서 PAC이 무엇인지 찾아봤습니다. 찾아보니 Program Advisory Committee의 약자로 학과 프로그램 구성 및 설계, 방향성에 대해 자문을 하는 외부 자문위원 활동이더군요.
발신인도 찾아보니 그 학과의 full-time faculty 중 한 명인데, 교수를 하고있는 사람이 메일을 보내면서 아무도 알지 못 할 PAC이라는 약어를 제목으로 쓰고, 메일 본문에 PAC이 무엇을 하는 것인지도 쓰지 않아서 이 교수가 이상한 것인지, 저를 초대 할 의욕이 전혀 없는건지, 제가 상식이 부족한 것인지 잠시 생각하게 되었네요
여하튼, 구글링을 통해 PAC이 무엇인지는 알게 되었고, 참석을 여부에 대해 고민을 시작했습니다. 모바일 어플리케이션 개발쪽을 하긴 했지만 이미 손을 놓은지 거진 3년이 다 되었고, 제가 했던 모바일은 일반적인 시장에서의 그것과는 사뭇 다르기에 잠시 고민을 하다가 모바일 분야를 떠난지 약 3년가까이 되었고, 지금은 DevOps관련 일을 주로 하는데 그래도 괜찮은 것인지와, 구체적으로 어떤 활동을 하게되는 것인지 소개를 해 달라고 답장을 보냈죠.
메일을 보내고 잠시 후 곧바로 답장이 왔는데, 한 번 시작하면 3년간 임기이며, 일년에 2회 정기회의 외에 필수적으로 참여해야하는 별도의 활동은 없는 일종의 봉사활동이라는 답이 왔습니다.
일단 안그래도 바쁜 상황인데 저를 더 힘들게 만들만큼 일이 큰 것은 아니라는 점에 마음이 놓였지만, 반대로 학과 프로그램 설계에 참여하는데 연간 2회 미팅만으로 무엇이 가능할까 싶어 형식상 존재하는 위원회일 수도 있다는 생각에 다시 한 번 망설였습니다.
그래도 언젠가 제가 충분한 실력과 자질을 쌓은 후에는 컬리지 강사를 한 번 쯤은 해보고 싶다는 생각이 항상 있었기에 일단 한 번 참석을 해 보기로 결정을 하였고, 이번 주 월요일에 첫 프로그램 자문위원회 회의에 참석을 했습니다. 졸업 후 4년간 단 한 번도 학교에 갈 일이 없었는데, 지난달 지식 더하기 정보 나누기 행사에 스피커 참석 건으로 가고 다시 한 달 만에 학교에 오니 왠지 학생때로 돌아간 것 같아 이상하더군요. 제 신분이나 일자리 등등 모든 것이 불명확하던 시절이라 그 시절이 그리운 것은 아니였고, 자주오니 많이 바뀐 캠퍼스가 다시 눈에 익기 시작하더라고요.
지난번 행사는 학교 행사라기보다는 아리랑 TV의 행사에 학교와 같이 주관을 한 것이고, 학교 전체라기 보다는 국제학생 학부에서 주관한 행사라 딱히 학교 관계자들을 만나보지 못했는데, 이번에는 컬리지 학부에서 하는 행사인지라 오래간만에 몇몇 반가운 교수들과 학과장을 만나볼 수 있었습니다.
저를 추천해 준 교수 사무실에서 10분 가량 이야기를 나눈 후, 회의실로 들어가니 저에게 메일을 보냈던 교수가 테이블 세팅을 하고 있더군요.
이번 회의 아젠다, 위원회 활동에 대한 가이드 문서 등을 읽어 볼 때만 하더라도 형식적으로 하는 활동이라는 생각이 들었는데, 지난 회의록을 읽어보니 그래도 무언가 의미있는 활동이 가능할 수도 있다는 생각이 들었습니다. 자세한 행간의 내용은 제가 알 수 없지만, 현재 학과의 커리큘럼을 읽어보면 지난 회의록에서 제안한 몇몇 사항들을과 연관된 키워드들이 보였습니다.
저를 포함한 신입 위원 3인과 기존 위원들간 자기소개를 시작으로 본격적으로 회의를 시작하였습니다.
처음에는 어떤 회의인지 몰라 적당히 눈치를 보고 있었는데, 위원들 각자 자신이 생각하는 의견들을 가감없이 내던지고 있고, 학교에서도 이를 진지하게 받아들이는 모습이 포착되어 저도 제 생각을 이야기 하기 시작했습니다. 새로운 화두를 던지거나 이야기 전환할 만큼의 영어실력은 안되기에 제 생각과 어느정도 일치하는 이야기가 나올 때, 기회를 봐서 하나씩 생각들을 던졌죠.
"1년 2학기라는 시간은 그리 긴 시간이 아니다. 학기마다 배우는 전공 5과목 중에 서로 연관성이 아주 낮은 코스가 3-4개 정도로 학생들은 매 학기마다 전혀 다른 것 3-4개 이상 배우는 것인데, 차라리 1학기에는 mobile관련 다양한 것들을 general하게 배우고, 2학기에는 몇가지 스트림을 선택할 수 있게 하여 선택적으로 특정 스킬셋에 대해 깊이있게 배우는 것이 더 좋을 것 같다."
"개인적 경험상 컬리지 졸업자들이 대졸자 대비하여 인터뷰 뿐 아니라 실무에 있어서도 상대적으로 크게 취약한 것 3가지가 있는데, 디자인패턴/설계, 테스팅, 안드로이드 activity/fragment/service 라이프사이클 관리 등과 같은 기본지식이다. 4년간 배운 학생들만큼 성취를 할 수는 없을지 몰라도 어찌보면 현업에서 가장 기본이되고 중요한 지식을 전혀 배우지 않는 것은 문제가 될 수 있다."
회의가 진행되면서 여러 이야기들이 오갔고, 현재 프로그램에서 백엔드, iOS, Android, Mobile Web 등 너무나 다양한 기술들을 배우는 것이 문제라는 것은 학교에서도 동의를 했고, 학생들 설문조사를 거쳐 두번째 학기에는 2개 혹은 3개의 스트림으로 나누는 방향에 대해 학교에서 좀 더 고민을 하기로 했습니다.
현재 파트타임 교수를 하는 일부 위원회 멤버들이 우려하는 것은 비용/난이도 등의 문제로 학생들이 스트림을 선택할 경우 90%이상 Android로 가서 스트림 운영이 불가능할 수 있다는 것인데 (과목 개설을 위한 최소 학생 수 확보가 안될 수 있기에) 그래서 학생들의 의견 수렴이 필요하다는 것이였죠.
또, 학생들에게 너무 과부하가 걸린다는 것에 학교도 동의를 하여 2020년 가을학기 부터는 프로젝트 과목에서 모든 과목에서 배운 내용을 모두 총망라한 integrated capstone project를 하고, 각 과목에서는 학기말에 별도의 프로젝트를 하지 않기로 했습니다. 여러 과목의 교수들이 같이 협동해서 코스 커리큘럼과 프로젝트를 진행해야 하기에 학교 입장에서는 좀 더 일이 많아졌겠지만, 이전에 비해서는 학생들의 로드가 줄어들 수 있기에 좋아진 것 같아요.
그리고, 원래는 2학기에만 capstone project를 했는데, 이것을 1학기부터 하는 대신에 1학기 중반정도 까지는 진짜 프로젝트를 하기 보다는 실제 현업에서 필요로 하는 지식인 테스팅, CI/CD, 디자인 패턴/설계 등등에 대한 내용들을 조금씩이라도 훑어보도록 과목 설계를 하기로 했습니다.
이와 관련해서는 회의 중 세부적으로 정하지는 않았고, 추후에 shared document를 통해 서로의 의견을 주고받은 후 결정하기로 했습니다.
다음 미팅은 거의 반년 뒤에 다시 있을텐데, 이번에 제안된 내용들 만이라도 다 반영이 된다면 확실히 이전보다는 나아질 수 있을 것 같다는 생각이 듭니다.
하지만 결국... 수업을 어떻게 설계하건, 그 누가 와서 강의를 하건, 교육에서 가장 중요한 마지막 단추는 학생인데, 과연 학생들이 얼마나 열정적으로 수업에 참여를 하고 스스로 노력을 할 것인지가 의문이긴 합니다. 공자/맹자가 와서 가르친다 한들, 학생이 아무런 의지가 없다면 무엇 하나 깨우칠 수 없으니까요.
위원회 회원들 중 컬리지를 다녀본 경험이 있는 사람은 저 뿐이라, 대학생들을 생각하고 의견들을 제시한 것일텐데, 컬리지를 다녀본 저로서는 궁극적으로 마지막에 허무해지는 것이...
'아무리 낮게 잡아도 절반 이상의 학생들은 공부 안하고 그냥 대충 학교만 다니고 졸업장만 받을텐데... 우리가 이렇게 목에 핏대 세워가며 토론하는 열정의 절반이라도 가진 학생은 아주 드물텐데...'
이 생각이 드는 것이죠.
그래도, 이 학과는 다른 IT분야 학과와는 달리 관련 전공 기 졸업자들이 mobile 특화된 개발을 배우기 위해 듣는 프로그램이라 하니, 제가 경험했던 컬리지 학생들과는 사뭇 다른 열정이 있으리라 믿어보고 위원회 활동에 열심히 참여 할 생각입니다.
최소한 학교측에서 위원회의 의견을 경청하고 제안을 받아들일만큼 충분히 개방적이고, 커미티 멤버들 역시 이 봉사활동을 한낱 지나가는 일 정도로 생각하지 않고 열정적으로 참여하는 만큼 열심히 활동하다보면 무언가 발전이 있을 수 있을테니까요.
안녕하세요 둥이네 아빠입니다.
이제 내일이면 입사 교육이 끝나고, 제 부서로 자리를 옮길 예정입니다. 일단 팀원이라고는 저 혼자 뿐이지만 새로운 팀 킥오프도 합니다. 제 팀에서 해야 할 일을 저 스스로 찾아가야 하기에 이전에 했던 일 보다 더 부담되기는 하지만, 그래도 그나마 제가 가진 능력 중에 조금은 나은 분야의 일로 돌아가기에 즐겁네요.
사실 이 글은 현재 직장으로 이직을 생각하면서 올리려고 작성 해 두었던 글인데, 생각보다 인터뷰 스케쥴 잡히는 것 부터 채용까지 진행이 일사천리로 되어버려 미처 글을 마무리 짓지 못하여 지금에서야 올리는 글입니다.
다름아닌 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 점이라도 더 받은 사람? 아니면 매니져에게 강한 인상을 남긴 사람? 누굴까요?
기술이 있어도 언어와 환경이 달라 처음에는 이런저런 어려움들을 많이 겪게되는 것이 보통인데, 그런 분들께 저의 필승 공략법은 아니지만, 만약 비집고 들어 갈 작은 틈이 있으면 기회를 잡을 수 있는 기회가 될 수 있는 작은 팁이 조금이라도 도움이 되었으면 좋겠습니다.
