생애 첫 기술면접 탈락 후기 및 교훈

1. 들어가며

며칠 전, 어떤 기업에서 첫 기술면접을 봤다. 이전 사전과제가 사측 기준에 적합했는지 기술면접을 보자고 연락이 왔고, 당연히 감사하고 기쁜 마음과 처음이기 때문에 긴장을 많이 한 채 면접을 보게 되었다.

결과적으로는 떨어졌다. 그리고 오늘 포스트에서는 말 그대로 생애 처음이자 마지막이었던 ‘첫 기술면접’에 대한 후기와 깨달은 교훈에 대해 남기고자 한다. 지금 생각하면 정말 별 것 아닌데, 그 순간에는 너무 긴장해서 내가 가진 모든 것을 보여주지 못한 아쉬움이 남는다. 추가로 회사에서 거절 메일을 보내면서 인터뷰에 대한 피드백을 같이 보내줬기 때문에 이에 대해 훑으면 될 것 같다.

포스트에서는 먼저 후기에 대한 이해를 돕기 위해 기술면접에 대한 진행방식을 짧게 살펴본다. 이후 사측에서 나를 좋게 본 면과 아쉽게 본 면을 각각 장을 할애해 살펴본다. 긍정적인 면은 정말 중요하지는 않다. 왜냐하면 그냥 그렇게 앞으로도 살면 되기 때문이다. 하지만 부정적인 면은 이후 면접에도 악영향을 미칠 수 있기 때문에 이에 대해서는 조금 더 고찰해본다. 회사의 나에 대한 평가 두 장은 실제 메일의 문구를 토씨 하나 바꾸지 않고 인용하고 그에 대한 나의 생각과 평가를 적는 방식으로 이루어진다.

다음으로는 면접 전체를 아우르며 느낀 교훈을 정리한 뒤 포스트를 마무리한다.

모두가 겪는 경험이라지만 나에게도 아픈 기억이다. 시작하자 :)

2. 기술면접 진행방식

기술면접은 크게 두 세션으로 진행이 됐다.

첫 세션은 상대적으로 주니어로 판단되는 두 명의 개발자와 함께 내 사전과제의 코드를 리뷰했다. 사전과제에서는 네 가지의 문제가 주어지고 코드를 작성하는 것이었다. 문제는 크게 OS API 사용, 알고리즘, 간단한 객체 시스템 설계로 분류할 수 있었다. 각 코드에 대해 살펴보면서 내가 코드에 대한 설명을 주도하고, 질문에 대답도 했으며, 즉석에서 요구하는 부분을 추가해보기도 했다. 약 1시간 정도가 소요됐다.

두 번째 세션은 앞선 세션에서보다 상대적으로 시니어로 판단되는 다른 두 명의 개발자들의 질문에 대답하는 방식이었다. 앞선 세션이 파이썬의 활용능력에 대한 평가 세션이었다면 이 세션은 실제 웹 개발과 관련된 질문들이 있었다. 데이터베이스 테이블을 작성해본다거나, SQL query를 작성하거나, 배포 단계에서 발생한 문제상황에서의 대응방법을 묻는 식이었다.

3. 사측의 나에 대한 평가: 긍정적인 면

먼저 사측에서 나에 대해 긍정적으로 평가해준 문구들을 살펴보자. 이 부분은 앞서 이야기한대로 길게 다루지는 않고, 문구와 내 평가 정도만 적겠다.

박성환님께 느낀 매력 포인트는 프로그래밍에 대한 열정과 관심 주제에 대한 깊은 학습이었습니다. 사전과제도 많은 고민을 하셨다고 느껴졌고 면접과정에서 차근차근 아시는것과 준비하신 것을 설명해 주셔서 좋았습니다.

여기서 중요한 건 ‘사전과제에 대한 고민’이다. 난 확실히 사전과제에는 자신 있었다. 주어진 요구사항에 맞게 잘 짰다고 생각했다. 그랬기 때문에 기술면접을 보게 된 것 아니었을까?

적극적인 커뮤니케이션 방식은 좋았습니다.

이 문장은 뒤에 살펴볼 ‘부정적인 면’을 말하기 위한 발판 정도의 평가인 것 같다.

파이썬의 기본을 잘 이해하고 계신 것 같습니다.

이력서에서 내가 강조한 부분이기도 하다. 난 파이썬을 좋아하고 파이썬만 팠기 때문에, 사측이 예상한 것보다 더 잘한다고 생각했는지 모르겠다.

4. 사측의 나에 대한 평가: 부정적인 면

이제 핵심이다. 부정적인 평가는 크게 두 부분으로 나눌 수 있다.

4.1. 커뮤니케이션 능력의 부족

협업 시 구성원과 다른 의견을 가졌을 경우, 청자를 이해시키기 위한 커뮤니케이션이 아쉬웠습니다.

이 평가는 정말 예상 못했고 당황스러웠다. 왜 이런 평가가 나왔을까? 난 이런 평가를 남겼을 법했던 상황을 다시 생각해야 했다. 내가 봤을 때, 이런 평가를 내리게 했던 정황은 기억나는 것은 두 가지가 떠오른다. 물론 이 두 가지 정황증거는 철저히 나의 주관적인 분석이며 사측의 공식적인 입장은 아님을 밝힌다.

리눅스에서 directory가 file인지

당시 상황은 다음과 같다.

첫 세션 코드리뷰에서 문제 중 하나가 경로에 있는 모든 파일에 대해 조건에 맞는 파일의 이름만을 화면에 출력하는 함수를 짜는 것이었다. 근데 문제에서 directory 또한 file로 포함해서 결과를 내야하는지에 대한 조건이 없었고, 난 옵션으로 받을 수 있게 했다. 관련 이야기를 하면서 난 두 명 중 나와 눈 맞는 분에게 ‘리눅스에서는 디렉토리도 파일이잖아요?’라는 질문을 던졌다. 그분은 0.5초의 뜸을 들이고 ‘네’라는 말로 동의를 표하셨다. 근데 이때 나는 주관적으로 이 분이 이런 명제를 들어본 적이 없는 것 같다는 뉘앙스를 느꼈다. 저 명제는 나에게는 ‘박성환은 대한민국 국적의 호모 사피엔스다’ 정도의 확실한 참이기 때문에 이에 대해 확신에 차서 다시 한 번 그렇다고 한 후 이야기를 진행했다.

클래스 속성 또한 CAP_WORDS 형식의 naming을 해야하는지

파이썬에서는 상수 이름은 ‘CAP_WORDS’ 형식으로 짓고, 변수 이름은 ‘small_words’ 형식으로 짓는다. 난 사전과제의 객체 시스템 설계 문제에서 초기화 이후 변하지 않을 클래스 속성을 상수 형식으로 정의했다. 개발자 한 분이 이 부분에 대해 질문하셨다. 속성도 상수 형식으로 정의하느냐고. 난 변수, 상수의 구분은 값이 속한 스코프가 아니라 이 값이 변할지 말지에 대한 개발자의 믿음이 결정한다고 보기 때문에 조금 단호하게 그렇다고 이야기했다. 사실 이전 문장을 말했어야 했는데 너무 긴장해서 말하지 못했다. 너무 단호했던 것일까?

대충 생각나는 건 이 정도이다. 만약 커뮤니케이션의 부족함을 느꼈다고 한 부분이 위의 두 상황이었다면 조금 아쉽다. 이 분들이 추가적인 질문을 하지 않았기 때문이다. 첫 번째 상황에서 내가 그분에게 왜 리눅스에서는 디렉토리 또한 파일인지 구구절절 설명해야 했을까? 두 번째 상황에서는 만약 자신과 나의 practice가 다른 점이 있다면 무엇이 더 바람직한 방식인지에 대해 왜 화두를 꺼내지 않았을까? 내가 꺼냈어야 하는 것인가? 더 좋은 것을 위해 토론을 하자면 그 자리에서 두세 시간이고 얼마든지 토론도 할 수 있는데 그쪽에서 별다른 말없이 넘어갔다고 생각한다.

난 과학의 묘미는 연구자가 아무리 시간과 노력, 정성을 쏟은 분야라도 틀렸다는 것이 명백하면 얼마든지 그 매몰비용을 인정하고 다시 학습하는 데 있다고 생각한다. 그런 과학자가 멋있고 진심으로 나도 그런 생각을 할 줄 아는 사람이 되고 싶다. 만약 생각이 달랐다면, 좀더 적극적으로 질문해주면 어땠을까 하는 생각이 든다. 얼마든지 토론하고, 내가 틀렸으면 반드시 고쳐냈을 것이다.

물론 위의 문단은 나의 생각이다. 실제 면접자들이 느낀 부분은 다른 상황일 수 있고, 내가 워낙 긴장해서 좀더 차분하게, 부드럽게 대답하지 못한 것도 있으며, 내가 인지 못한 내 소통의 문제가 있을 수 있다.

그래서 내 커뮤니케이션을 돌아보게 되었다. 내가 주로 스터디하는 채원과 해든 씨, 내가 이 분들과 토론하면 나는 독단적인가? 이 부분은 포스트를 마치고도 더 고민해보겠다.

4.2. 프로젝트 및 데이터베이스 지식 부족

웹 개발과 데이터베이스 지식을 더 쌓으실 필요가 있다고 생각했습니다.

이건 변명의 여지가 없다. 채원과 내가 인정하는 내 포트폴리오의 약점은 프로젝트 경험이 적으며, 데이터베이스 지식이 적다는 것이다. 난 TCP/IP, HTTP 등에 대해 공부하는 것이 즐거웠고 면접에서 강점으로 들이밀었지만 그쪽에서는 별로 흥미가 없었나보다. 확실히 제품 생산능력이 부족하면 노동상품의 매력이 떨어지는가 보다.

또 데이터베이스를 좀더 공부해야겠다는 생각이 든다. 난 데이터베이스가 중요한 것은 인정하지만 결국 데이터를 효율적으로 저장, 탐색하기 위한 소프트웨어이고(물리 데이터베이스 서버 제외), SQL은 그에 대한 API이지 않나 생각했다. 우리가 흔히 하는 다른 작업들과 크게 다르지 않은 일이 아닌가 하고. 하지만 그중에서 데이터베이스는 조금 더 중요한가 보다. 반성했다.

5. 교훈

생애 첫 면접은 그렇게 날아갔다. 거의 3시간이 걸린 면접이었고 이렇게 허망할 수가 있나 싶은데 그래도 수확이 꽤 크다. 위의 내용들과 추가적인 경험을 통해 얻은 교훈은 다음과 같다.

자신감을 가져라
- 이건 당연한 거지만 난 그렇게 행동하지 못했다. 너무 긴장해서 오히려 필요 이상으로 단호했는지 모른다.
기술면접에서는 내가 좋은 팀원인지도 광고해야 한다.
- 기술면접이라고 내 기술력만 광고해서는 안 된다. 입사해서는 결국 팀 작업을 하기 때문에 내가 소통에서 문제가 없다는 인상을 주어야 한다.
프로젝트, 데이터베이스 등 필수지식을 더 연마해야 한다.
- 이 약점들은 당연히 내가 모르는 바가 아니었다. 하지만 눈감았다. 다른 걸 하고 싶어서. 이제는 좀더 냉정하게 공부를 할 필요도 있는 것 같다.
\(O(n)\)이 언제나 최고는 아니다.
- 두 번째 세션에서 데이터베이스 인덱스에 대한 질문이 나왔다. 난 인덱스 자체를 잘 몰라서 질문을 했고 면접자 분이 데이터베이스 인덱스란 레코드를 조회할 때 \(O(n)\) 순차탐색은 성능이 안 좋기 때문에 사용하는, 조회를 위한 트리 형태의 자료구조라고 말씀해주셨다. 이에 난 당연한 것이지만 잊고 있던 것을 떠올렸다. 알고리즘의 시간복잡도의 적절함은 문제상황에 따라 다르다는 것을. 내가 푸는 알고리즘 사이트들에서 제출하는 거의 모든 알고리즘이 시간복잡도가 \(O(n log n)\) 정도만 되어도 모든 테스트를 씹어먹는다. 그래서 \(O(n)\) 정도만 되어도 만능이라고 의심없이 생각했다. 하지만 레코드가 매우 많을 수 있는 데이터베이스에서는 순차탐색도 성능이 안 좋다. 그래서 다시 마음에 되새기게 되었다. 이 세상에 절대라는 것은 없으며 언제나 문맥을 파악해야 한다는 것을.

6. 마치며

생애 첫 기술면접에 대한 기록을 마쳤다. 아쉽다. 난 조금 더 잘할 수 있었을 것 같은데. 그리고 알게 됐다. 난 많이 부족하다는 것을. 프로는 결과로서 모든 것을 말한다. 난 불합격했고 그게 내 실력이다. 지금 내가 할 수 있는 것은 결과를 인정하고, 나중에 그 회사가 결정을 후회할 수 있도록 잘해보는 것, 그것뿐일테다.

결과 메일을 받고 한 2시간 정도 서글펐다. 근데 포스트로 정리하고 보니, 그냥저냥 괜찮은 것 같다. 분명 다음에 더 잘할 수 있을테다.

이상 포스트를 마칩니다.