-
미국 소프트웨어 엔지니어 포지션 인터뷰카테고리 없음 2013. 5. 27. 20:40
미국에서 소프트웨어 엔지니어링 포지션을 지원하면서 얻은 경험을 바탕으로 인터뷰 절차 및 내용에 대해 좀 적어보고자 한다. 이 내용은 경험에 의한 내용이므로, 회사에 따라 또한 포지션에 따라 들어맞지 않는 경우가 있다는 것도 미리 알려두고 싶다. 미국에서 소프트웨어 엔지니어로 일하고자 한다면, 코딩 인터뷰라는 절차를 거치게 되기 마련이다. 한국에서 12년전 인터넷 뉴스회사에 소프트웨어 엔지니어로 입사하기 위해서 거쳤던 내 면접이나, 9년전 세계최대 소프트웨어 회사에 컨설턴트로 일하기 위해 면접을 봤을 때, 이런 기술적인 내용에 대한 검증은 전혀 없었던 것과 비교해 보면 사뭇 다르다. 회사에 따라서 문제의 유형이나, 내용은 많이 달라질 수 있을 것 같다. 특히, 구글, 마이크로소프트, 아마존과 같은 큰 회사들은 명확한 자신들의 채용 절차가 정해져 있고, 코딩 인터뷰라는 것이 너무나도 자연스럽고 당연한 것으로 여겨지고 있는 것을 볼 수 있다. 횟수와 시간도 상당히 길고 전 미국의 컴퓨터 과학 졸업생과 경쟁해야 한다는 부담감도 있다. 최근에는 한국에서도 이런 인터뷰가 점점 일반화되어 가는 분위기가 보이는 것 같다.
반면, 상대적으로 인지도가 낮은, 즉, 회사의 규모가 작은 스타트업의 경우는 인터뷰 과정을 예측할 수 없는 경우도 있다. 횟수와 시간 등도 다르고 면접 방식도 다르다.
소프트웨어 엔지니어 인터뷰는 대부분의 엔지니어들에게 쉽지 않은 것 같다. 특히 미국에서 인정받을 만한 경력이 없는 경우는 더욱 그러하다. 개인별로 차이가 있다고 하지만, 실리콘밸리에서 일을 하고 있는 엔지니어의 경우에도, 이직을 생각한다면 약 석달 정도의 준비 기간은 필요해 보인다고 얘기하고 있다. 잊어버린 내용을 되살려 기억해 내고 정리하고 연습하는 기간이 필요하기 때문이다. 물론 경력이 많을 수록 질문하는 내용이 알고리즘에서 벗어나 지난 회사에서 했던 내용에 초첨이 맞춰질 것 같다.
0. 지원할 곳 찾기
미국에서 소프트웨어 엔지니어로 일하는 사람들을 보니 여러가지 경로로 일자리를 찾는 것을 보았다. 미국에서 학교를 다니는 경우 학교의 리크루팅 행사를 적극적으로 이용하는 방법이 있고, 한국에서 글로벌 소프트웨어 회사의 지사에서 일하다가 미국 본사로 옮기는 방법도 있다. 또는 한국에서 미국의 일자리를 직접 찾아볼 수도 있다. 이 경우도 미국의 회사에 아는 사람이 있다거나 하면 훨씬 유리할 것이다. 관광비자로 미국에 머무르면서 인터뷰를 보고 채용이 되는 경우도 보았다. 인터뷰 볼 회사가 현재 충분히 많다면 모를까 그렇지 않다면, 온라인 채용 사이트(dice.com과 같은 사이트, SF bay area의 craigslist.org도 채용 공고가 많이 올라옴)를 열심히 뒤져가며 이력서를 보내고, 잡 매칭 서비스를 해주는 사이트(monster.com과 같은 사이트)에 이력서를 올리는 작업 등도 고려해 봐야 할 구직 활동이다. 미국 현지에 있다면, meetup.com에 있는 많은 스타트업 관련 모임에 나가 사람들을 알아가고 일자리를 구할 수 있다. 어떤 모임 같은 경우 자신이 하고 싶은 말이 있으면 누구나 할 수 있는 피치 시간이 있는데, 예를 들면, 나는 스타트업 시작했는데, 어떤 어떤 사람 찾는다던가, 나는 개발자인데 오늘 처음왔고 일자리를 구하고 있다라던가 하는 이야기를 모든 사람이 듣는 가운데 할 수 있다. 이런 모임 가운데는 잡 페어를 주최하는 모임도 있고, 어떤 모임은 특정 언어 개발자들과 채용하려는 기업의 리크루터를 한자리에 모아놓고 짧은 시간동안 이력서를 나누고 인터뷰를 할 수 있는 기회를 만들어 주는 경우도 있어서 취업 기회를 보다 많이 엿볼 수 있다. 이런 모임의 경우 대부분 스타트업 엔지니어를 찾고 있고, 가장 많이 필요로 하는 엔지니어는 풀 스택을 구현할 수 있는 웹 엔지니어나, 모바일 앱 엔지니어 들이다.
주변 사람들의 이야기와 실제로 겪어본 사례에 의하면 인터뷰를 하면 할 수록 자신의 부족한 부분을 알 수 있고 인터뷰를 통해서 배우는 점들도 있으므로, 인터뷰를 많이 하면 인터뷰 스킬이 느는 것도 사실이다. 따라서, 많은 인터뷰 기회를 가질 수 있다면 가지는 것이 좋고, 그런 기회를 얻기 위해 다니고 싶지 않다고 하더라도 인터뷰 스킬 배양을 위해 여러 회사에 인터뷰를 해보는 것이 좋다. 어쩌면, 기대하지 못한 회사에서 좋은 기회를 찾을 수도 있으니 말이다.
1. 이력서 준비
일단 지원을 하는 데 있어서 가장 중요한 것이 이력서일 것이다. 이력서도 여러 형태가 있겠지만, Google Resume와 Cracking the Coding Interview를 출간한 Gayle McDowell님의 이력서 템플릿을 알고 나서는 이것을 이용했고, 실제로 지원자 중에 이것을 사용하는 경우를 많이 봤다. 일부 한국 이력서처럼 사진을 넣거나하지는 않는다. Careercup.com 사이트의 Resume 섹션을 보면 다운로드 할 수도 있다. 전에 학교에서 한 멘토님이 하신 말씀이 생각나는데, resume의 목적은 인터뷰 기회를 얻기 위하는 것이라고 한다. 실제로 다른 사람의 resume sample을 보면 굉장히 자신감에 차있고, 굉장한 일을 한 것처럼 보이는 것들이 많은데, 스스로 그렇지 않은 사람이라고 생각하더라도, 자신의 한 일을 잘 돌이켜보고 그러한 항목들을 창의적으로 끌어내는 기술이 필요해 보인다. 어떻게 보면 거짓말을 해야 하는 것이냐고 생각할 수는 있는데, 어디서나 거짓은 좋은 것이 아니므로 사소한 일이라도 자신의 장점을 나타내 보일 수 있는 항목을 잘 생각해서 끄집어 내는 것이 중요해 보인다. 실제로 일부 지원 사이트에서는 거짓일 경우 나중에 해고를 포함한 책임을 져야 한다고 적혀 있는 경우도 있으니 거짓이 없도록 조심해야 할 것이다. 결국 이력서는 자신의 마케팅 자료를 만들듯이 만들어야 하지만, 자신을 거짓에 기반해서 광고해서는 안된다. 사람에 따라 이력서에 대한 의견이 분분하겠지만, 사실 대체로 채용담당자가 이력서를 훑어보는 시간은 1분도 안될 것이다. 따라서, 길게 작성하기 보다는 공간 활용을 잘 해서 1페이지에 압축시킬 것을 권유하곤 한다. 아무리 불가능해 보여도 공간활용을 잘하고, 지금 지원하는 자리와 정말 관련 있는 내용만 신중에 신중을 기해 적으면 1페이지로 줄일 수 있다. Gayle님의 세미나를 두번 들어본 적이 있는데, 경력이 10년이 넘는다면 두쪽으로 쓰는 것도 괜찮다고 했다.
이와 더불어 Cover letter도 요구하는 경우도 있다. 이 경우 보통 3~4개 정도의 단락으로 1쪽내지 2쪽으로 하는 것이 일반적이다. 첫 단락에서는 간략히 지원자의 중요한 이력과 어떤 자리에 관심있는지를 나타내고, 두번째 단락과 세번째 단락에서는 내가 왜 이 자리에 적합한지를 적는다. 그리고 마지막 단락에는 어떻게 연락하면 되는지와 지원하는 자리에 대한 관심을 다시한번 표명하는 것으로 마무리하는 형식이다. 실제로 구직활동을 하면서 어떤 리크루팅 업체의 글을 읽었는데, Cover Letter가 없는 지원서는 채용담당자가 보지 않을 가능성이 높다는 말도 했다. 물론 100% 다 그런 것은 아니겠지만, 그만큼 어떤 회사를 지원하는 데 정성을 들인다는 의미이므로, 특히 이직이 잦고 합격한 이후에도 오지 않는 다는 사람이 많은 실리콘 밸리와 같은 분위기에서는 자신이 꼭 가고 싶은 회사라는 의지를 피력하는데 Cover Letter가 도움이 될 것 같다.
이렇게 준비를 마친 다음, 원하는 회사의 웹사이트의 채용 페이지를 통해 이력서를 제출하거나 양식을 작성하여 지원하면 된다. 요즘에는 버튼 한번으로 LinkedIn을 프로파일을 그대로 전달할 수 있게한 시스템도 널리 사용되고 있으므로, 링트인을 잘 관리하는 것도 지원시 편리하다. 또한, 워드나 PDF 파일로 작성된 이력서를 업로드 하면 양식을 채워주는 시스템도 많다.
지원시 한가지 명심해야 할 점은 그 회사에 다니고 있는 직원을 통해 지원하는 것이 훨씬 더 유리하다는 점이다. 실제로 지원자가 많은 인기있는 회사의 경우 직원을 통해 추천된 사람을 우선적으로 인터뷰하는 경우가 많으며, 그렇지 않은 경우 연락이 아예 오지 않고, 기회조차 주어지지 않는 경우도 많다. 또한 연락이 오더라도 직원 추천으로 지원한 경우가 훨씬 더 빨리 채용담당자로부터 연락을 받을 수 있으며, 채용절차가 더 빠르게 진행된다. 예로, 구글의 경우 직원 추천으로 지원하면 다음날 채용담당자로부터 이메일이 오고 일주일 이내에 첫 전화 인터뷰를 진행할 수 있는 반면, 웹으로 지원할 경우 첫 연락을 받기까지 한 달 정도 걸리는 것을 보았다. 또한 직원 추천의 경우 보통 이력서를 직원을 통해서 전달하는 방식으로 진행되므로, 이력서가 준비되어 있으면 온라인의 긴 양식을 채워넣을 필요가 없이 간편하게 끝난다는 점도 또 하나의 장점이라고 할 수 있겠다.
이후에는 리크루터로부터의 연락을 기다리거나 전화인터뷰를 기다리면 된다. 반면, 어떤 회사는 이력서 접수 후 인터뷰를 진행하기 전에, 몇가지 질문을 이메일로 보내고 응답을 받기도 한다. 회사에 따라 기본적인 지원자에 대한 정보 외에, 제품이나 서비스에 대한 피드백이나 개선 방향등에 대해 적어달라고 하기도 한다.
2. 전화 인터뷰
회사마다 천차 만별이지만, 일단 전화로 먼저 인터뷰를 하지 않는 경우는 없는 것 같다. (가까운 거리에 지원자가 있고, 직원 추천 등으로 신분이 명확하다고 판단되는 경우 바로 직접 면접을 보는 경우도 있긴 하다.) 전화 인터뷰의 용도는 여러가지인 것 같다. 실제로 이 사람이 존재하는 사람인지, 이력서 내용을 묻고 답하면서 정말 제대로 작성한 것인지 등을 확인하기도 하고, 시간과 돈을 들여 직접 만나볼 필요가 있는 사람인지 검증하는 과정이라고 본다. 미국에서는 지원자가 멀리 있는 경우 교통비와 숙박비용도 회사가 내주는 것이 보통이므로...
그래서 첫번째 전화 인터뷰를 Phone Screening이라고도 하는데, 주로 물어보는 질문은 엔지니어 자리를 지원한다고 하더라도 실제 기술적인 질문이 아닌 경우도 많다. 또한 전화를 걸어오는 사람도 인사부 소속 리크루터일 수도 있고 아니면 정말 채용을 담당하는 매니저이거나 동료 엔지니어일 수도 있다. 회사의 규모가 클 수록 이런 스크리닝을 간소화하거나 아니면 생략하고 엔지니어링 스킬만 보겠다는 회사도 많이 존재한다.
회사에 따라 다르겠지만, 첫 폰 인터뷰에서 리크루터로부터 연락을 받았다면, 2가지 타입의 인터뷰로 구분할 수 있을 것 같다. 첫번째는, 자기 소개를 요구하고, 현재 어디 있는지, 이력서를 낸 사람이 맞는지, 구체적으로 어떤 포지션을 원하는지, 회사 선택시에 어떤 점을 중시하는지, 희망연봉 수준은 어느 정도인지, 회사 근처로 이사올 수 있는지 등을 간단히 확인하고 마치는 인터뷰라고 할 수 있다. 이 경우 자신의 이력서를 잘 숙지하고, 희망 포지션과 왜 잘 맞는지 이력과 가지고 있는 스킬로 잘 대답할 수 있도록 준비하면 될 것이다. 모든 인터뷰에서 예상할 수 있겠지만, 인터뷰 마지막에 지원자에게 회사에 대한 질문이 없는지를 물어보는 경우가 있는데, 이 시간에 질문이 없다고 그냥 넘어간다거나 업무와 상관없는 질문으로 넘어가기보다는 자신이 드러내지 못했던 부분을 알려주는 기회로 삼는 것도 좋은 방법일 듯 하다. 따라서, 첫번째 인터뷰라고 하더라도 또한 상대방이 엔지니어가 아닌 인사부직원이라고 하더라도 회사에 대한 열망이 있다는 점을 부각시키는 것이 필요해 보인다. 왜 내가 이 회사에서 일하고 싶은지 또는 내가 어떤 도움을 줄 수 있는지에 대해 이야기하면 좋은데, 이를 위해서는 포지션과 회사에 대한 어느정도의 리서치가 필요하다고 할 수 있다. 미국에서는 인터뷰 준비로 지원하는 곳에 대해 미리 알아보는 것을 일종의 숙제라고 생각하고 이에 대한 이해가 부족하면 숙제를 안했다고 생각할 수 있다.(웹사이트나 지인을 통해서 반드시 확인하는 것이 필요하다.) 상대방이 리크루터인 경우에는 회사의 분위기나 일하는 방식, 조직 구조 등에 대한 적절한 질문도 채용에 대한 열의나 똑똑한 사람이라는 인식을 심어줄 수 있을 것이다. 마지막으로, 리크루터지만 아주 간단한 기술적인 문제를 던져서 전혀 가치 없는 사람이 다음 단계로 넘어가지 못하도록 하는 경우도 있고, 코딩을 얼마나 했는지, 예전 직장에서 한 일이나 과거의 프로젝트를 통해서 지원하는 자리와 얼마나 관련이 있고 도움이 되는지를 확인하고 필터링하려는 리크루터도 있다.
두번째는 리크루터가 연락을 했으나 지원자에 대한 간단한 정보를 넘어서 소위 behavioral question이라고 하는 인성이나 일하는 방식에 대해 알아보려고 물어보는 질문도 있다. 특히 규모가 크지 않고 단순 엔지니어가 아닌 보다 책임지는 영역이 넓은 포지션인 경우 이런 인터뷰를 예상할 수 있다. 자신의 장단점에 대해 이야기 해 보라는 경우도 있고, 가장 큰 challenge가 무엇이었냐는 등의 질문을 할 수 있다. 그리고 팀으로 일하는 것에 대해 문제가 없는지 등을 알아보려고 하는 경우도 있다. 이런 경우 전화 인터뷰라도 상당히 시간이 길어질 수 있다.
실제 채용하는 매니저 (자기 밑에 둘 엔지니어를 찾는 매니저)나 아니면 동료가 될 사람과 인터뷰를 하는 경우도 있는데, 이 경우는 바로 기술적인 질문으로 넘어가거나 아니면 리크루터와 하는 이야기를 하고 기술적인 질문으로 넘어가는 경우도 있다. 기술적인 인터뷰에 대한 이야기는 다음 섹션에서 따로 하도록 하겠다.
요즘에는 proxy를 이용한 인터뷰(누군가 대신 인터뷰를 하는 것)을 막기 위해서 인지 아니면 보다 자연스러운 의사소통을 위해서인지, 아니면 인터넷이나 책 등을 보는 것을 막기위해서인지... Skype를 통해 얼굴을 보면서 인터뷰를 보자는 경우도 있다. 간단한 팁을 언급하자면, 전화 인터뷰시에는 반드시 이어폰 등을 준비해서 두 손이 자유스러울 수 있도록 하는 것이 좋다. 또한 종이와 펜을 준비해서 전화로 설명해 주는 문제를 적어 본다거나 시각적으로 그려 보는 것도 문제 풀이에 도움이 될 수 있을 것이다.
3. 현장 인터뷰
기술 인터뷰는 그야 말로 인터뷰 내내 기술적인 내용에 대해 묻고 답하는 인터뷰라고 생각할 수 있다. 물론 전혀 모르는 사람끼리 만나서 인터뷰를 시작하게 되고, 전화 인터뷰든 현장 인터뷰 든, interviewer는 지원자의 이력서를 보통 가지고 들어오므로 바로 문제를 풀기 보다는 서로에 대해 알아가고 지원자의 소개 등을 통해 가지고 있는 스킬이나 경험을 파악하는 시간이 주어지는 것이 보통일 것이다. 기술 면접이라고 하더라도 마지막에 질문 시간이 주어지는 것이 보통이므로 이에 대한 준비를 하는 것도 필요하다.
기술 인터뷰는 세가지 형태로 구분할 수 있을 것이다. 전화 인터뷰와, 현장 인터뷰, 그리고 일부 회사에서 요즘 도입되고 있는 코딩 테스트가 있을 수 있겠다. 코딩 테스트라는 것은 온라인 툴을 이용해서 문제를 내고 제한된 시간내에 답안을 제출하는 것이다. codility.com와 같은 사이트를 통해서 문제를 풀게되며, 시간에 대한 부담과 interviewer와 상호작용이 없다는 점에서 힌트를 받거나 잘못된 접근에 대한 피드백을 받을 수 없다는 점은 인터뷰를 더 어렵게 만든다. 물론, 능력이 뛰어나 문제를 쉽게 풀수 있다면 더 편할 수도 있겠지만... 이와는 별도로 폰 스크린 이후 혹은 그것도 생략한채 이메일을 통해 문제를 보내거나 며칠의 시간을 주고 작은 프로젝트를 해서 결과물을 보내라는 회사들도 존재한다.
전화 인터뷰나 현장 인터뷰 모두 내용 면에서는 동일할 것으로 보이나 수준면에서는 차이가 있을 수 있겠다. 먼저 전화 인터뷰에 대해 이야기해 보자면, 아무래도 의사소통이 직접 대면한 상태보다 어려울 수 있으므로 문제의 난이도는 낮아지는 것이 보통이다. 문제의 형태는 brain teaser라고 불리는 지적 능력 검사에 등장할 법한 간단한 수학 문제부터 굉장히 복잡해 보이고 어려워보이는 문제를 내는 경우도 있고, 포지션에 따른 기술적 문제를 질문을 하기도 한다. 예를 들어 테스트 엔지니어 포지션이라면, 회사의 웹사이트의 특정 페이지에 가보라고 한 다음, 이 페이지를 테스트하려고 한다면 어떻게 해야겠는가를 물어보기도 한다. 혹은 객체지향에 기본적인 질문을 물어보고 답하라는 경우도 있고, 특정 언어에 대한 지식이 얼마나 있는지에 대한 질문을 하는 경우도 있다.
위에서 언급한 내용이 아니라면 대개의 경우 문제를 내고 직접 코딩을 해보라고 한다. 물론 이때, 전화로 문제를 내고 전화로 코드를 불러주는 식으로 진행하는 것은 아니다. 보통은 구글 닥스를 통해 온라인으로 서로 작성하는 코드를 보면서 의사소통을 한다. collabedit.com이라는 도구도 전화로 코딩인터뷰를 보는데 자주 쓰인다. 이런 인터뷰 방식은 eclipse같은 IDE (Integerated Development Environment)의 도움을 받지 말고 스스로 정확한 코드를 작성하라는 의미를 지니기도 한다. 하지만 최근에는 온라인 문서 공유 도구들이 프로그래밍 언어를 인식하고 키워드를 색깔로 하이라이트시켜주기도 하므로 그런 의미는 약화되어 가는 것도 같다. 또한 어떤 회사의 경우는 Skype 음성 통화로 인터뷰를 시작하고 화면 공유를 통해 지원자 컴퓨터의 데스크 탑을 공유하여 IDE에 작성된 코드를 보자는 경우도 있다. (Skype가 화면 공유기능을 유료화해서 이제는 쉽지 않은 방법일 것 같기도 하다.)
전화 인터뷰에서 주의할 점은 모르는 문제가 나왔다고 해서 아무말도 하지 않고 한참동안 혼자 생각하는 것이라고 할 수 있겠다. 혼자서 문제를 꼭 풀어내는 것이 중요하다고 생각할 수도 있겠으나, 그것 보다는 인터뷰어에게 힌트를 구하고 인터뷰어가 원하는 방향으로 답에 이르는 것이 더 긍정적인 결과를 나을 수 있다. 그런 상호작용 능력도 인터뷰를 통해서 확인하고 싶은 항목이기 때문이다. 실제로 인터뷰어였던 분이 말씀하시길 문제를 냈는데 한참동안 아무런 말도 없다가 20분정도 지나서 답을 말하면, 도대체 그 시간동안 어떤 사고를 거쳐 결론에 이르렀는지, 누가 도와줬는지, 인터넷을 뒤졌는지 알 수 없어서 난처하다고 했다. 그리고 실제로 인터뷰어들이 막혔을 때, 힌트를 던져 주는 경우를 자주 볼 수 있으므로 힌트 받기를 주저할 필요는 없어 보인다.
방문 인터뷰를 하게 되면 좀 더 어려운 문제나 복잡한 유형의 문제를 물어 볼 수 있다. 폰 인터뷰에서 물어 봄직한 문제도 충분히 나올 수 있지만, 폰 인터뷰에서 물어보기 어려운 문제 즉, 어떤 문제를 풀기위한 클래스를 디자인해보라고 하는 문제도 등장할 수 있다. 예를 들어, 카드 게임을 하기 위한 클래스를 디자인하고 관계를 그려보라던가, 비디오 렌탈 샾을 위한 클래스 디자인을 해보라든가 등이 될 수 있다.
이 경우 주로 화이트 보드에 코드를 작성해 가며 인터뷰를 진행하게 된다. 따라서, 문법이나 철자등에 주의해 가며 코드를 써 내려가야 한다. 이 인터뷰를 위해 알려져 있는 여러가지 팁이 있는데, 몇 가지 소개하자면, 공간을 위해 제일 왼쪽 위부터 쓰기 시작할 것, 글자를 작게 쓸 수 있도록 가는 펜을 준비할 것(이렇게 까지는 필요없을 지도 모르겠다), 문제를 그림으로 그려 이해해 볼 것, 인터뷰 도중 막히면 힌트를 요구할 것, 입력값 밸리데이션을 할 것(시간 절약을 위해 해야 한다는 것을 알지만 시간이 남으면 하겠다라고 이야기하고 넘어가는 것도 좋은 방법), 코드 작성 후에 테스트를 해볼 것 등이 있다.
4. 돌아와 감사 메일 보내기
미국 사람들은 잡 인터뷰 과정 전체를 마치 결혼식을 하는 것처럼 일종의 의식으로 여긴다는 말을 들었다. 우리나라 채용에서는 거의 이런 메일을 보내지 않는 것 같지만, 미국에서는 현장 인터뷰를 마친 후, 감사 메일을 보내는 것이 관례인 듯 하다. 감사 메일의 내용은 인터뷰를 볼 수 있도록 해줘서 감사하다는 말과 함께, 인터뷰를 통해서 해당 포지션과 회사에 대해 더 잘 알게 되었고 나의 스킬과 경험과 잘 맞는 것 같아 꼭 일하고 싶다는 내용 정도가 될 것 같다. 들은 바에 의하면, 감사 메일을 보내지 않으면 지원한 자리에 관심이 없다는 것을 표시하는 것이라는 말도 있고, 감사 메일을 통해 혹시 인터뷰 동안 미처 전달하지 못한 내용이나 다시 한번 강조하고 싶은 말을 전달하는 기회로 이용하라는 이야기도 있다. 어찌됐든 현장 인터뷰 후 24시간 이내에 감사 메일을 보내는 것이 좋다. 웹 검색을 통하면 이런 메일의 샘플을 쉽게 구할 수 있을 것이다.
부디 미국에서 소프트웨어 엔지니어로 일하고자 하는 분들에게 조금이나마 도움이 되었으면 한다.
5. 참고 자료
미국 사람이라고 해서 물론 이런 인터뷰가 쉬운 것은 아닐 것이고, 우리나라 사람들이 취업을 위한 수험서를 읽고 준비하듯이 이런 시험에 대비하기 위한 정보가 여러가지 형태로 존재한다. Cracking the Coding Interview와 같은 책을 사서 보기도 하고, glassdoor.com과 같은 웹사이트를 통해 준비하는 사람도 있다. 하지만, 인터넷에 떠돌아 다니는 문제와 그에 대한 답안이 100% 맞다고 볼 수는 없다. 실제로 블로그를 통해 이런 문제들을 소개하고 있는 페이지의 아래에 보면 버그가 있다거나 오답이라는 댓글이 달린 경우를 많이 볼 수 있고, 더 좋은 풀이 (어쩌면, 인터뷰어가 원하는 대답)가 있는데, 적혀 있지 않은 경우도 있으므로, 신뢰할 수 있는 자료를 확보해서 공부하는 것이 필요해 보인다.