신입 면접에서 느낀 점들

벌써 올해의 반이 지나가 버렸다. 그래서 요즘 글또(개발자 글쓰기 모임)에는 상반기 회고 글이 많이 올라오고 있다.
나의 2020년 상반기는 학교 생활 + 취준의 비중이 컸다. 졸업 후 먹고살 길을 찾기 위해 여기저기 지원서를 흩뿌리고 다니면서 여러 기업에서 코딩 테스트와 면접을 경험했다. 라이브 코딩 면접, 발표 면접, 과제 면접, 평범한 면접 등 신입이 겪을 수 있는 면접 유형을 여러 가지 겪어봤다.

신입 면접은 평가라는 개념에서 벗어나서 생각해보면, 나름 특별한 기회다. 채용을 위해서이긴 하지만, 팀장 급으로 경력이 많은 분들이 한두시간을 할애해서 연고가 없는 지원자랑 기술적인 대화를 나누는 자리다. 경력 같은 신입이 아니라면 보통은 정신적으로 여러 자극 후회 깨달음 등 복합적인 감정을 얻어간다.

나의 2020년은 상반기 회고라는 간지나는 단어를 붙일만한 결실은 딱히 없어서, 내 경험을 바탕으로 면접에서 나 자신에게 아쉬웠던 점과 느낀 점을 회고해보려 한다.

이 글은 인터뷰이의 관점에서 매우 주관적으로 작성되었다. 나는 면접관을 해본 적이 없고, 세상엔 내가 못겪어본 회사가 훨씬 더 많다. 그래서 내가 오해하고 있거나 잘못 생각하는 부분이 포함되어 있을 수 있다.

인터뷰이(自)에게 아쉬웠던 점

잘 못본 면접에서 나에게 아쉬웠던 점과 원인을 분석해보자.
즉, 면접 끝나고 나서 아 그거 이렇게 대답할걸 ㅜㅜ 하고 후회한 부분을 나열해 본다.

모르는건 모르는거다.
기술 면접을 보면 모르는 질문이 나올 때가 있다. 첫 면접에서는 어설프게라도 추리해서 설명하려 했는데 그랬다가 한층 더 수렁에 빠진 적이 있다. 그냥 모르면 모른다고 나의 무지를 밝히는 게 나은 거 같다. 보통은 틀린 대답을 하거나 잘 모르겠다하면 이걸 모른다고?! 자네는 탈락일세. 이러진 않고 돌려서 힌트를 주신다. 그래도 모르면... 집가서 공부해서 다음엔 그러지 않는 수밖엔...

알고있다 생각해도 한번 더 파보기
코틀린의 확장함수가 무엇인가요? 라는 질문을 받았다고 가정해보자. 써본 사람은 알고있듯 기존 클래스를 직접 수정하거나 상속받지 않아도 함수를 추가할 수 있게 해주는 코틀린의 기능이다. 그럼 확장함수가 실제 자바로 디컴파일 되면 어떻게 바뀔까? 나중에 확장하는 클래스를 매개변수로 받는 static 메서드로 바뀐다는 것을 알게 됐지만, 이런 질문을 받았을 당시엔 실제 구현까지는 생각을 못해봤기 때문에 제대로 대답을 못했다. api가 됐든 문법이 됐든 사용법을 알고있다고 넘어가지 말고 '어떻게 구현되어 있을까?'를 한번 더 공부해보면 큰 무기가 된다.

이력서/자소서는 이후에 들어올 질문의 초석이 된다.
다른 것보다도, 내가 공부해봤거나 경험해본걸 제대로 설명을 못하면 제일 후회막심이다.
신입은 경력란을 채울게 없다보니 개발 경험이나 관심사를 어필하려면 개인 프로젝트가 있어야 한다. 프로젝트를 소개할 때 일단 풍성하게 이것저것 적으면 낭패를 볼 수 있다. 어떤 면접을 가든 이력서/자기소개서 내용이 그대로 면접 질문으로 나온다. 언어든 라이브러리든 프레임워크든 내가 커버할 수 있는 범위로 적자. 그리고 적어도 내가 이력서에 쓴 내용 만큼은 제대로 공부를 해가야한다.

답이 없는 질문일 수록 근거는 확실해야 한다.
최종결정권자(?) 분들의 면접은 답이 정해져 있지 않은 질문이 주로 나온다. 나는 이런 질문들이 기술 질문보다 훨씬 어렵게 느껴진다. 솔직히 순발력 있게 대처하는 게 어렵고 여전히 언어능력에 버퍼링이 온다.
단순한 예시로 싱글톤 패턴이 쓰이는 이유는 보편적으로 공감하고 있는 배경지식이 있는데, 상사가 불합리한 지시를 내리면 어쩌겠느냐? 같은 건 개인의 가치관에 의존적인 질문이다. 나는 이런 질문에 대해 추상적인 근거를 조리있게 말하기가 참 힘들다... 날 처음 본 사람이라도 납득할 수 있는 무난하고 확실한 근거가 필요해 보인다. 개발자가 되기 위한 노력으로 '꾸준히 공부를 하고, 학습한 내용을 공유하고 있다'를 뒷받침하려면 뭐 블로그를 한다던가, 학회에서 발표를 매주 했다던가, 하는 대중적이고 확실한 근거가 있어야 한다.

뭐 이건 내 생각일 뿐이고, 실제로 어떻게 하면 좋은지는 지금도 잘 모르겠다.

자문자답

느낀 점 + 자체적으로 내린 판단들

학력사항에 어디까지 써야 하지?
처음엔 대학교/학과/졸업 예정일만 써두고 학점은 폼에서 필수 입력이 아닌 이상 굳이 안 적었다. 그랬더니 면접에서 먼저 물어보는 경우가 있더라. 그 후로는 학점까지 적고 있다.
그리고 나 같은 경우 내년 2월 졸업인데, 풀타임 근무랑 학업 병행이 가능하냐고 결과 발표 전 인사팀에서 먼저 물어본 적이 두어 번 있다. 만약 졸업을 안 했다면 학력사항에 취업계 가능 여부 등을 먼저 적어두면 서로 편하지 않을까? 싶다.

의외로 많이 물어보는 것
자기소개, 스레드 vs 프로세스처럼 당연하게 많이 물어보는 것들은 이미 인터넷 세상에 널리 공개되어 있다.
내가 겪었던 면접에서 의외로 많이 받은 질문은 '쉴 때는 주로 뭐하는지'다. 어려운 질문은 아닌데 생각 외로 여러 번 받은 질문이었다. 이런 걸로도 그 사람의 성향을 파악할 수 있기 때문인 걸까?

블로그 하면 면접에 도움이 되나?
내 생각은 예스다. 물론 블로그 자체가 큰 도움이 된다기 보단 블로그 하는 습관이 도움이 됐다. 개인적으로 느끼기에, 지원자의 블로그 글이나 개인 프로젝트 등을 하나하나 보고 온듯한 면접은 드물었다. 면접관 분도 많은 지원자를 평가해야 하고, 바쁜 업무 시간 중 짬을 내서 오시는 거일 테니 당연한 일이다. 블로그의 존재 유무보다는 블로그를 통해 내가 알고 있는 바를 남한테 설명하는 연습을 꾸준히 해본 게 도움이 됐다.

좋은 기억으로 남은 면접
나한텐 합불 여부와 무관하게 크게 두 가지 포인트가 있었는데 1. 피드백 2. 비언어적 표현 이렇게 두 가지였다.
면접에서 보충이 필요하거나 이상한 내용에 대해 구체적인 피드백을 받는 게 좋았다. 그리고 면접관 분들이 내 얘기를 듣고 있다는 비언어적 표현이 있으면, 설명하기 어렵지만 한층 더 안심되는 그런 느낌이 있다. 예를 들면 면접 중 계속 노트북으로 무언가를 쓰시는 것과, 마주 보고 얘기를 하는 게 다르게 느껴졌다. 한 번은 다대일 면접에서 한분이 계속 눈을 감고 있는.. 경우가 있었는데.. 눈감고 경청하신 거라 스스로 위안을 하고 있다..

앞으로의 계획

구구절절 글을 썼지만 결론적으로 나는 여전히 취준생이라는 것. 그래도 모든 것이 막연하게 느껴졌던 작년과 달리, 지금은 경험치가 조금은 쌓이게 됐다.
그리고 취준하면서 든 개인적인 생각으로, 앱 개발, 특히 안드로이드는 신입 공고가 큰 회사 몇군데를 제외하면 잘 없다. 지원 가능한 회사는 분야를 막론하고 항상 있기야 한데, 내 나름대로? 세워둔 기준을 충족하는 회사의 개수에서 확연히 차이가 난다. 상반기에 자소설 닷컴을 들여다보면서 놓친 공고가 많아서 솔직히 아쉽다. 그래서 앞으로의 전략은 기본기에 충실하게 공부하면서, 클라이언트 개발에만 치중되지 않는, 서버~프론트를 통틀어 다뤄보는 프로젝트를 하나 만들어보는 거다.