1. 무엇을 어떻게 확인할 것인가?

생각이 없으면 베끼지도 말자

기존 기술 면접은 2~3시간 동안 회의실에서 진행했다. 1시간은 경험 및 기술 관련 질문을 몰아서 한 뒤 답을 들었고, 1시간 반은 과제, 알고리즘을 구현하는 코딩 테스트를 진행했다.

이렇게 기술 면접을 설계한 이유? 놀랍게도 없었다. 큰 회사들이 그렇게 한다니까 똑같이 따라갔을 뿐이다. 한 가지 웃긴 것은, 나도 이런 면접들을 본 후 엄청 기분 나빠했으면서, 막상 입장이 바뀌니 똑같은 문제를 답습했다는 점이다.

이 면접에서, 지원자는 이야기를 나누고 공감할 지점과 시간이 없었을 것이다. 압박감으로 느껴졌을 것이고, 역량이 있어도 실력을 드러내지 않는 문제와 잘못된 부분을 검증하는 두 가지 문제도 동시에 일어났다.

무엇을 어떻게 검증할 것인지, 어떤 이미지로 지원자들에게 기억될 것인지, 아예 다 뒤집어 엎고 면접의 과정, 경험 등을 모두 처음부터 다시 설계하기로 결심했다.

무엇을 확인할 것인가?

_{* ‘면접 전에 채용하는 이유에서' 파트에서 정리한 내용을 바탕으로 한다.}

어디를 가도 개발을 할 수 있다면, 어느정도 내가 관심이 있으면서, 나에게 잘 대해주는 곳을 가는 것이 맞다. 회사 규모나 연봉, 처우, 사무실 인테리어 등을 보는 것은 당연한 일이다.

하지만, 아무리 내게 잘 해줘도 어긋나는 부분이 있다. 산업에 관심이 없으면 능률이 줄어든다. 산업을 모르고 개발을 하면 끔찍한 결과물이 나온다. 이는 모두에게 영향을 준다. 끔찍한 코드, 답답한 커뮤니케이션, 그 사람만 아는 신기술 등...

그렇기 때문에 가장 기초적으로 ‘도메인 지식(Domain Knowledge)’을 중심으로 생각하고 움직이는지 확인해야한다.

두 번째로 확인해야하는 것이 ‘직무 능력’이다. 현업에서 프로덕트를 만들면서 느끼는 점이지만, 현업 개발자의 일은 크게 3가지로 추상화할 수 있을 것 같다.

기반부터 새롭게 만들고 쌓아올리는 일
기존 레거시를 이해하고 리팩토링, 마이그레이션하는 일
내가 한 일을 남들에게 (가끔은 스스로에게...) 설명하는 일

대다수의 부트캠프도 그렇고 다들 1번을 주로 생각한다. 하지만 막상 뚜껑을 열어보면 2번이 대부분이다. 특히 잘 나간다면(네카라쿠배당토), 돌아가는 서비스가 있다면 더욱 그렇다.

설명은 ‘지금’, 그리고 ‘혼자’ 하는 일이 아니다. ‘사이드이펙트는 없을까요?’ 라는 말에 상상력이라는 그래픽카드를 최대한으로 돌려 이야기를 해야한다. 가까운 팀원과 말로 할 수도 있다. 코드로 커뮤니케이션을 한다. 퇴사 후 내 코드를 보는 사람, 오랜 시간이 흘러 지금 짠 코드를 볼 미래의 나... 갑자기 눈물이 난다...

마지막으로 ‘성장 가능성’이다. 여전히 가장 어려운 일이다. 본인의 의지도 필요할 것이고, 많이 알려줄 자신도 있다. 하지만 누구든 밑빠진 독에 물을 붓고 싶지는 않을 것이다.

나만의 성장을 하려면, 나름대로 성장을 위한 패턴이나 루틴을 가지고 있어야한다. 모르면 알면 된다. 그렇게 알고 났을 때, 지적 만족감을 채우고 버리지 않는지 확인해야 ‘밑 빠진 독에 물 붓기’를 안 할 수 있다.

📌 정리하면?

도메인 지식 (Domain Knowledge)

우리 회사가 무슨 일을 하는지 알고 있는 사람인가?
문제를 파악하고, 이를 해결하기 위해 기술을 사용하는 사람인가?
자매품: 기술 만능주의자가 아닌가?

직무 능력

(개발) 직무에 필요한 기초적인 지식을 가지고 있는가?
(개발) 레거시를 이해하고 리팩토링, 마이그레이션을 할 수 있는가?
(개발) 의도를 가지고 코드를 작성하는가?
(커뮤니케이션) 상황을 얼마나 꼼꼼하게 구체화할 수 있는가?
(커뮤니케이션) 기분을 상하게 하지 않으며 함께 일을 할 수 있는가?

성장 가능성

성장하는 것에 얼마나 많은 관심을 가지고 있는가?
본인만의 성장을 위한 패턴 혹은 루틴이 있는가?

면접 과정 설계의 딜레마

면접 과정은 새로운 방법으로 부를 수 있는 것이 없다. 기술 질문을 하거나, 과제를 구현하거나, 알고리즘 테스트를 진행하는 것이 전부이다. 다만, 각 방법들은 장점과 단점이 너무 극명하게 갈린다.

예를 들어, 쉴 새 없이 기술 질문의 문답을 진행한다면?

O와 X가 상대적으로 명확하기 때문에, ‘N개 맞추면 합격’이라는 기준을 세우기에 좋다. 그리고 개인이 많이 해봤다면 경험 관련 질문들도 잘 대답할 수 있다.

하지만, 결국 외워버린다면 할 말이 없다. 인터넷에 ‘프론트엔드 개발자 면접 질문'이라고 검색하면 나오는 수십개의 사이트를 외울 수도 있는 것이다. 외워서 술술 답하는 사람이 실무를 잘 수행하고 협업을 잘 하는지 확인할 수 없는 것이다.

그렇다면, 과제 구현을 한다면?

과제 구현은 상대적으로 현업과 가까운 환경을 제시할 수 있다. 회사에서 쓰는 기술 스택, 간소화된 기술 과제 등을 보며, 면접자는 회사에서 어떤 일을 하게 될지 가늠할 수 있게 된다.

하지만, 결국 규모와 난이도 조정이 매우 어렵다. 면접자가 많은 시간을 쓰기 어렵다면 제한적인 과제를 준비해야 한다. 면접 진행자마다 관점이 다를 수도 있다. 예를 들어, 과제에 "디자인을 100% 구현하세요" 라는 조건이 있을 때, 과제 Figma의 Inspect에 있는 line-height를 코드에 안 넣는 것을 불합격 사유로 볼 수 있는가?

돌고 돌아 알고리즘 테스트도 고민하게 된다.

알고리즘 테스트만큼 O와 X가 명확한 것은 없다. 문제 은행에서 가져와 문제를 준비할 수 있고 검증에 소요되는 시간도 짧다는 것이 큰 장점이다.

하지만, 이 역시 현업에서 필요로 하는 요소들과 거리가 있다. 알고리즘 문제 풀이에 최적화된 코딩 방식은 종종 프로덕트의 코딩 방식과 충돌한다. 높은 성능보다 가독성을 추구한다던가...

그래서 면접 준비 과정은 항상 모두에게 스트레스가 된다. 표준화된 것도 없고 면접을 진행한 후에는 이유 모를 찝찝함이 남는다. 우리의 상황에 맞으면서도 즐거운 면접은 없을까.

🏁 기조 설정하기

잘 모르는 일을 할 때는 불변의 원칙보다 일련의 사고방식, 즉 '기조'를 세우는 것이 큰 도움이 된다. 사고방식은 접을 수 있고 돌아볼 수 있으며 쉽게 공유할 수 있기 때문이다.

하나, 면접은 아래와 같은 행위이다.

같이 일을 했을 때 서로에게 도움이 될 수 있는지를 확인 (기술, 업무, 문화)
같은 개발자로서 이야기를 나누는 기회 (관심사, 엔지니어링 관점과 중요도 산정, 장애나 문제 해결 경험 등)
좋은 인상 및 감정을 남기기 위한 강한 마케팅 기회 (이직 = 그로스)

둘, 면접은 주관적 행위이다.

다만, 합리적으로 설명할 수 있는 주관을 추구할 뿐이다.
면접이 잘못되었을 가능성을 항상 열어놓고 피드백을 받는다. (ex. 면접 후에 연락할 수 있는 수단 제공)

셋, 면접은 아래의 기조로 진행한다.

면접을 통해 서로의 성장에 도움이 될 수 있어야 한다.
구체적인 상황이나 문제를 제시한 뒤, 이를 해결하는 과정을 본다.
모르는 것은 알아가면 된다.

hiddenest