[IT개발] 인턴 서류, 면접 도움말

*당부의 글 - 그동안 제가 몸담았던 회사의 스펙트럼이 넓지 않아서(삼성전자, SK플래닛, 11번가 - 주로 대기업 위주) 다른 업종 혹은 규모의 회사에 직접 적용하기 어려움을 먼저 밝힙니다.

우리팀에 인턴을 한명 모시기로 했습니다.

요즘 많은 회사들이 인턴 모집을 한다. 한달 동안 명확한 업무를 주고, 또한 그에 따른 보수를 지급하는 것이라면 지원자나 회사 입장에서 win-win 할 수 있는 좋은 제도라고 생각한다(단연코 열정페이는 반대한다). 지원자는 보통 2~3개월 근무를 하면서 회사의 분위기나 업무 내용을 곁에서 지켜 볼 수 있고, 회사 입장에서도 지원자에 대하여 서류나 면접을 통해 알 수 없었던 실제 업무 능력을 살펴 볼 수 있기 때문이다. 채용 시장이 녹록치 않은 탓에 인턴 기회 조차 높은 경쟁을 뚫어야만 가질 수 있는 요즘, 최근 진행했던 인턴 채용 과정을 통해 느꼈던 몇가지를 정리해 볼까 한다. 정말 특출나게 우수한 분들도 계셨지만, 개인적으로 살짝만 코칭해 주면 훨씬 좋은 점수를 받을 수 있을 것 같은 분들도 있었으며, 뭔가 전혀 감을 잡지 못했다는 느낌이 드는 분까지 다양한 케이스를 보면서, 개인적으로 이런 경험을 기록해 둔다면 누군가에게 조금이나마 도움이 되지 않을까 하는 생각을 해 보았다. 또한, 웹상에 보이는 입사 지원과 관련된 글들이 너무 컨설팅 식의, 또는 지원자 위주의 To-do, Not-to-do 로만 정리되어 있기에, 심사자 입장에서의 좋았던 점과 아쉬웠던 점을 써 본다면 또다른 정보를 줄 수 있을 것이라고 기대한다.

이번 글은 아무래도 최근인 2019년 11번가 상반기 인턴채용 때 내게 할당되었던 113명에 대한 경험 위주이지만, 삼성전자, SK 플래닛 시절을 지내면서 심사했던 신입사원 공채, 학군단등 특별 전형, 경력 사원 채용등의 여러 케이스 또한 일부분 녹아 있음을 부정할 수는 없다.

인턴 선발 목적과 심사 위원 선정 - 왜 뽑고, 심사는 누가 하는가?

주로 탑다운(HR에서 실무팀으로)으로 인턴 선발 시기에 대한 공지가 각 팀에게 전달 된다. 외주 채용이나 경력직 채용 TO가 아닌 이상, 실무팀에서 HR에게 인턴을 선발해 달라고 하는 경우는 거의 없다고 보면 되고, 주로 전사 상반기 혹은 하반기 채용 형식으로 진행된다. 그러나, 특이하게 시장 조사 혹은 베타 테스팅 등을 위해 대학생 인턴을 채용하는 경우가 간혹 있으나 개발팀에서는 거의 찾아보기 어렵고, 이런 유형은 인턴 채용 보다는 아르바이트 모집과 더 가깝다. 또한 신입 사원 공채에 가산점 등이 적용되지 않기 때문에, 정식 인턴 과정과 성격상 차이가 있다고 봐야 한다.

인턴 선발 공지가 오면, 각 팀에서는 필요 유무와 심사를 볼 심사위원 1~2인을 추천하게 된다. 이 공지는 각 팀장에게 도착하게 되는데, 우리 팀의 경우 몇가지를 고려했다.

• 2개월 좀 모자라는 기간 (7~8월 기간이지만, 첫주 오리엔테이션, 마지막 주 발표 등을 제외하면 2개월이 꽉 차진 않는다) 에 부여할 만한 적당한 일이 있는가
• 그 일이 우리 팀 뿐만 아니라 인턴을 하는 친구에게도 의미있는 일인가 (우리 회사 업무 도메인과 맞는 일인가)
• 우리팀 인턴이 그 일을 실패 해도 빨리 복구 할 수 있는가
• 인턴 기간 동안 전담으로 도움을 줄 멘토 리소스가 있는가
• 인턴 기간이 성공적이라면 추후에 이 분을 채용할 TO를 받아올 수 있는가

다양한 회사의 각 팀마다 사정이 다르겠지만, 채용하는 팀에서 하는 고민은 위와 기본적으로 비슷할 것이다. 인턴 기간이 충분히 길지는 않기 때문에, 그 기간동안 맡길 만한 실무 업무를 찾아 보면 어쩔 수 없이 상당히 작은 부분이다. 또한, 바로 뭔가를 할 수 있을 것을 인턴에게 기대하지는 않는다. 물론 특출난 분들이 있겠지만, 그런 분들이 인턴을 우리회사에서 할 거라고는 생각하지 않는게 사실이다. 위 고민 사항들을 대략 정리해 보면, 일은 그래도 인턴분이 현업을 체험해 볼 만한 것을 찾고, 멘토 한명을 전담으로 붙혀서 리스크를 최소화 하겠다는 것인데, 그렇다면 과연 인턴을 왜 채용하려고 하는 것일까.

우리는 팀 내에서 자체 구현했던 air flow와 유사한 배치 프레임웍에 대해 web front를 인턴 분에게 맡겨볼 생각이었다. 이 과정에서 기능 명세를 잘 파악하고 화면 구현까지 빠르게 완료해 낸다면(기존 구성원이 구현한다면 2주 정도 소요될 정도의 업무였다), 나머지 기간 동안은 검색 키워드 광고와 관련된 좀더 업무 도메인과 가까운 업무를 같이 해 보겠다는 전략이었다(사실 검색 키워드 광고 관련 업무는 실패시 타격이 큰 업무다). 사실 우리 팀컬러는 각자 의견을 활발히 개진하며 끝장 토론을 하는 것이라서, 인턴분께서 우리와 논리적인 토론이 자연스러운, 다소 적극적인 성격이기를 원했다.

결국, 인턴 모집이 필요한 다양한 팀에서는 그 팀이 원하는 기술 스펙과 성향이 거의 명확히 정해져 있다고 보면 된다. 그래서 인턴 서류 및 면접에서 내가 탈락했다는 것은 실력이 낮아서라기 보다는 그 팀의(혹은 인턴 채용에 참여한 다른 팀의) 요구 사항에 맞지 않았다(또는 더 일치하는 지원자가 있었다)에 더 가깝기 때문에 크게 낙심할 것은 없다고 생각한다.

팀장을 제외한 추가 심사위원의 경우 당연히 팀의 에이스가 선정되기 마련이다. 간혹 에이스가 시간이 안맞을 경우 그 다음 실력자가 심사위원이다. 이런일에 일도 없는 시간 남는 사람을 보내는 상상을 해 본적은 없다(물론 그런 사람은 우리 팀에 없다). 간혹 경력직 채용의 경우 심사위원을 꾸릴 때 특별한 구성을 짜기도 한다. 예를 들어, 지원자가 저널 및 컨퍼런스 논문을 많이 서류에 작성해 둔 경우, 이를 판별하기 위해 지원자와 유사 수준의 심사위원을 끼워 넣기도 한다. 삼성전자에서 몇번 유사한 경우가 있었는데, 조직장의 성향에 물론 영향을 받겠지만은 박사 학위의 지원자라면 유사 분야의 좀더 상위 학교의 학위자가 면접을 보도록 매칭하는 것을 경험한 적이 있다(간혹 지원자가 이를 모르고 있는 듯하다).

면접 중에, 심사위원이 무례하거나 말도 안되는 질문을 하거나 해도 평정심을 잃지 말자. 그네들은 그래도 그 회사에서 에이스 취급을 받는 분들이고, 그 에이스들이 그 수준밖에 안되는 것은 내가 오늘 운이 안좋은 것에 더해서 밖에서 보던 이 회사의 이미지가 잘못 됐다는 것을 알 수 있었던 좋은 기회라고 생각하면 된다.

서류와 면접 심사

전체 100여명의 서류 심사에 주어진 시간은 약 2일이었다. 이틀을 꼬박 서류만 본다면야 충분한 시간이겠지만, 대부분 각자 하고 있는 업무가 있는 상황에서 업무 시간을 모두 서류심사를 위해 사용할 수는 없다. 이에, 몇가지 기준을 정해 빠르게 서류를 체크해 나갔다. 우리 팀의 경우 (1) 자기 소개, (2) 기술 적합도, (3) 상용 경험, (4) 첨부 파일로 평가를 했는데, 각 항목 별로는 이렇게 평가 했다.

• 자기 소개: 자기 소개서를 하나 써 놓고, 여러 군데 지원을 할 수 밖에 없는 현실을 이해하더라도, 누가 봐도 회사 이름만 교체한 듯한 자기 소개는 좋은 점수를 줄 수가 없었다. 최소한 지원한 회사가 무엇을 하는 회사고, 본인은 인턴을 왜 지원했으며, 인턴 과정을 통해 이런 것을 얻고 싶다가 명확한 자기 소개에 좋은 점수를 줬다. 점수를 잘 받은 분들의 자기 소개는 주로 정말 이회사의 인턴을 하기 위해 자기 소개를 새로 썼다는 느낌을 반드시 준다.

• 기술적합도: 본인이 잘 할 수 있는 개발 기술을 간단 명료하게 쓴 내용에 가장 좋은 점수를 줬다. 그 개발 기술에 대해서는 첨부파일의 프로젝트 진행 내용과 반드시 일치 여부를 확인했다. 적지 않은 분들에게서 만연체로 이것도 해 봤고, 저것도 해 봤는데 최근에는 스터디모임에서 이런것도 관심있어서 참여하고 있다와 같은 내용이 있었다. 또한, 특정 기관에서 주관한 해커톤과 같은 곳에서 수상을 한 내용도 꽤 많았는데, 물론 좋은 경험이지만 이것이 첨부파일에 반드시 보여져야 했고 그 과제에서 본인의 역할이 무엇인지를 반드시 확인할 수 있는 경우에만 점수를 줄 수 있었다. 최근에는 지원자들이 SW경진대회 등의 수상 내역이 대부분 있는데, 본인의 기여를 반드시 기록하고, 만약 기여가 없다면 제외하는 것이 혹시 모를 면접을 위해서라도 더 좋다고 생각한다. 면접에는 이러한 수상 내역과 본인의 역할을 십중 팔구 질문하고, 그 때 대답을 못하면 오히려 마이너스이다.

• 상용경험: 인턴 지원이라는 특성 때문에, 상용 제품에 코드를 반영해 본 경험은 대부분 없었지만, 일부 지원자들의 경우 아르바이트로 혹은 이전 회사의 인턴 경험으로 이러한 상용 제품의 개발 과정을 경험해 본 내용을 기재하였다. 물론 인턴을 채용하면서 또 다른 인턴 경력을 요구하는 것이 가혹한 것이라는 생각을 하지만, 채용하는 입장에서는 어쩔 수 없이 좀 더 플러스를 줄 수 밖에 없었다. 다만, 상용경험 항목의 배점은 낮은 정도의 가산점으로 작용하게 하였고 패널티 형태는 아니었다.

• 첨부파일: 안타까운 부분이다. HR에서도 첨부파일을 선택(Optional) 이라고 공지하는 것으로 알고 있다. 그러나, 학부 텀프로젝트에서 추가로 수행하는 경우 가산점을 주는 것과 같은 것이 아니라, 이것은 TO가 정해져 있는 상대평가의 경쟁 상황이다. 이 때는 아무리 첨부파일의 제출이 선택이더라도, 제출한 사람(물론 내용이 좋아야 하지만)에 비해 제출하지 않은 사람이 다른 내용으로 역전하기란 정말 정말 힘들다. 만약 첨부파일을 업로드 하는 항목이 있다면 반드시 첨부하기를 추천한다. 그러나 뭐라도 첨부만 하면 되는 것은 아니다. 첨부 파일의 내용 역시 중요하다. 주로 실수 하는 분들은 첨부파일의 성격을 오해하고, 본인이 수강했던 코스의 수료증 스캔본, 또는 과제나 SW경진대회의 최종 보고서를 그대로 첨부하는 경우등이 있었다. 특히 정부 기관 SW경진대회의 최종 보고서는 무려 hwp 파일로, 혹시나 싶어 어쩔 수 없이 viewer를 설치해야만 했으나 결국 단순 보고서여서 좋은 점수를 주지 못했다. 가장 좋은 점수를 받았던 분의 첨부파일은 과제 2개 정도를 중심으로 한 3~4장 정도의 깔끔한 자기소개서 였다. 과제가 풀고자 했던 문제와, 해결 방법, 구현 기술, 본인의 맡은 부분이 매우 간결하고 짧게 그러나 이해하기 쉽게 정리되어 있었다.

위 채점 기준과 달리 안타까운 것은, 서류 항목에 지원분야와 일치하지는 않지만 도전했던 사례를 적는 부분이 있었는데, 이부분을 너무 순진하게 적는 분들이 많았던 것이다. 점수를 잘 받으신 분들은 같은 해외 여행이라도, 해외 여행에서 뭔가를 구하기 위해 앱을 설치하고 직거래를 해보는 도전을 해 봤고 거기에서 귀사의 커머스는 어떤 내용이 보강되면 좋겠다는 것을 생각했다라는 어찌보면 뻔히 보이지만 적극적으로 동종 업계의 진출 의지를 어필하는 방식으로 적는 분들이다. 이와는 달리, 정말 일상의 내용을, 예를 들면, 최근에 다이어트를 도전했다라던지, 댄스학원을 끊었다등의 사생활을 적으시는 분들이 있는데 심사위원으로서는 어쩔 수 없이 별로 관심이 가지 않는 내용이다.

학창 시절 문제를 해결 했던 일은, 정말 많은 분들(체감상 80% 이상)께서 팀프로젝트를 할 때 무임 승차하는 분이 계셨고, 이로 인해 팀원의 갈등이 생겼는데 본인의 중재로 과제를 성공적으로 완료할 수 있었다는 내용을 기재하였다. 잘못 됐다는 것은 아니지만, 별로 차별화 되지는 못했다. 그 보다는 기술적으로 어려움이 있었는데, 본인 아이디어로 새로운 라이브러리나, 접근 방식을 제안해서 문제를 해결할 수 있었다는 사례가 좀더 와 닿는 얘기였다.

서류를 보면 어떤 가이드가 있는 것인지는 몰라도 캐치프레이즈 같은 것을 항목별로 적는 분들이 많았다. 감점 요인은 아니었는데, 해당 캐치프레이즈가 뒤에 오는 설명과 부합하지 않으면 이해하는데 오히려 방해가 되었고, 아직 학생처럼 느껴지는 감이 있었다.

위의 동일한 100여명의 지원자에 대하여, 팀내 다른 심사위원 역시 같은 기준으로 점수를 체크하였고, 둘의 점수를 합하여 순위를 책정하였다. 재밌는 것은 기준이 같은 탓도 있겠지만 서류 심사 결과의 순위는 거의 비슷했다. 다른 부분은 점수의 스케일이었다(누구는 좀 짜게 주고, 누구는 좀 후하게 주고). 이것은 후보정을 통해 정리하였다.

한편, 출신 학교와 전공 여부는 크게 고려하지 않았다. 물론 이것은 팀마다 다르겠지만, 우리팀의 경우 이번 인턴 채용에서는 전혀 고려하지 않았고, 평소 경력직 채용의 경우 역시 아주 특별한 경우가 아니라면 크게 신경 쓰지 않는다(IT/개발은 사실 대부분 이럴듯).

면접을 위해서 사전 PT 문제를 두가지 제출하였다. 두 문제 모두, 인턴 과정때 진행했으면 하는 내용과 관련이 있었고, 한 문제는 난이도가 낮지만 완성도를 보는 채점을 하기로 했고, 다른 한문제는 난이도가 좀 있지만 아이디어를 보는 채점을 하기로 했다. 그렇지만, 무엇보다 가장 중요하게 보고자 했던 것은 심사위원과 질문을 주고 받는 도중에 얼마나 토론이 잘 되는지, 본인의 의견을 끝을 흐리지 않고 명료하게 얘기하는지, 생각을 어떻게 수정해 나가는지 였다. 간혹 너무 긴장하시는 분들이 있는데, 어느 정도의 긴장이 심사위원에게 전달되더라도 전혀 감점 요인이 아닌 것을 이해하셨으면 한다(오히려 너무 능글능글할 경우 실력이 없어 보일 수 있다).

코딩 테스트의 내용 역시 중요하다. 물론, 서류 심사과정에서 코딩 테스트의 점수가 일정부분 이상이 되어야 통과가 된다. 그러나, 코딩 테스트는 면접에서도 중요하다. 주로 점수를 잘 받은 지원자들은 본인이 못 풀었던 문제를 기억하고 있었고, 어디가 잘못 되어서 어떻게 고치면 해결 될 것이라는 것을 미리 생각해서 면접에 임했다. 그러나, 일부 지원자의 경우, 문제를 보여주고, 본인이 풀었던 코드를 보여줘도 이를 설명하지 못했다. 본인이 과거에 작성한 코드를 기억못할 수는 당연히 있지만, 인턴 면접과 같이 그래도 중요하다고 생각하는 과정에서는 코딩 테스트 내용을 반드시 기억해 놓고, 만점을 받지 못한 문제는 해결 책을 생각해서 면접에 임하는 것이 유리하다고 생각한다.

앞서, 첨부파일 항목에서도 언급한 바 있지만, 본인이 수행했던 과제에서 맡았던 역할을 정확하게 설명할 수 있어야 한다. 그리고 비록 본인이 일부분을 맡았더라도 (예를 들자면, DAO부분) 과제가 해결하려 했던 문제점과, 해결 방법을 설명할 수 있어야 한다. 그 과제는 왜 시작했냐는 질문에, 본인은 개발담당으로 일부분만 맡았다고 대답할 때 대단히 실망스러웠다. 요즘은 개발자도 비즈니스적인 마인드를 가지는 것이 중요한 시기라고 개인적으로 생각한다. 과제의 나열식도 조금 피했으면 한다. 일부 경력직 지원자의 경우 몇장씩 되는 과제 수행 목록이 있는데, 그 중에 가장 최근 내용에서 기술을 조금만 파고 들어가도 대답을 못하는 경우가 있다. 물론 우리가 과제를 진행하면서 일정에 쫓겨 내용을 공부할 시간은 없겠지만, 본인이 쓰고 있는 기술이 왜 생겼고, 왜 좋은 건지는 설명할 수 있으면 좋겠다. 개인적으로는 그렇게 공부하지 않고 되는 대로 습득했던 기술들은 오래 기억할 수 없었고 또 사용할 때 마다 찾아서 하면서도 왜 동작하는지도 몰랐다. 내가 개발하는게 아니라, stackoverflow가 개발한다는 느낌을 받는 경우가 주로 그렇다. 찾더라도, 왜 이렇게 되는지를 알고 해야 한다. 인턴 지원자에게는 주로 본인이 잘한다는 것을 물어 본다. 특정 기술을 잘 한다면 적극적으로 잘하는 내용을 밝히고, 그 부분을 질문해 달라고 하는 것도 좋은 방법이다.

마지막으로 질문을 하라고 심사위원이 얘기를 할 것이다. 그렇다면 서류 지원시 공고에 있던 분야의 내용과, PT 문제, 그리고 면접 시 나왔던 질문을 종합해 봤을 때 지금 심사를 보고 있는 팀에서 원하는 스킬셑이 무엇일지를 어렴풋이 짐작할 수 있을 것 같다. 그렇다면, 본인이 어필할 차례다. 짐작한 스킬셑이 맞는지를 물어보고, 대답을 잘 했는지 물어보고, 혹시라도 미진한 부분이 있다면 이 때 보충설명을 짧게 하거나 잘 했다면 더 잘할 수 있음을 어필하면 된다.

좋은 인연을 기다리며

우리팀은 결국 마지막까지 세분을 고민하다 한분을 최종 선정하였다. 나머지 두분 역시 매우 우수했고 만족스러웠으나, 우리에게 주어진 TO가 하나였고 원했던 업무에 가장 부합한 분이었다. 그 분께서는 면접 때 비전공자인데 IT개발쪽에서는 이런 것에 대해 차별이 있지 않냐고 물으셨다. 본인이 기술 면접을 매우 잘 보시고서 마지막에 이런 질문을 하시니 신기했지만, 아직 인턴시절에는 이런 것들이 궁금할 수 있겠다 싶었다. 그래서, 처음 신입사원 입사시에는 조금 고려가 되기도 합니다만, 3~4년만 지나시면 본인이 직전 회사에서 어떤 상용 프로젝트를 했는지가 가장 중요하고, 전공은 아무도 묻지 않는다고 대답해 드렸다.

입사시장(입시시장과 더불어)에도 많은 myth가 있는 것을 알고 있다. 나 역시 과거 많은 오해로 자신감을 잃기도 했고, 또한 허황된 자신감을 가지기도 했었다. 그러나 자신 있게 말할 수 있는 것은, 최소한 IT개발 분야에서는 이미 많은 부분이 변했고, 누구나 실력만 있다면 자신있게 도전할 수 있는 길이 충분히 있다는 것이다.

부족한 글이지만, 서두에서 얘기했던 것처럼 어떤 힘든이에게 조그만한 힘이 되는 글이길 바란다.