내 개인적인 면접 준비 전략과, 그리고 그동안 여러 동아리에서 면접 과정을 경험하면서 느꼈던 점들에 대해서 정리해보았다.
회사 면접에 대한 글은 아니다. 개발 동아리를 기준으로 한다. 또한 내가 면접 응시 경험이 그렇게 많지 않아서 신뢰성은 낮을 수 있다.
하지만 학교 내에서 여러 개발 동아리에 속해 있었다. 피면접자로 개발 동아리에서 면접에 응하기도 했고, 내가 운영진이자 면접관으로 면접에 참여하기도 했다.
내가 면접을 보는 면접관의 입장에서, 질문을 준비해야 할 일들도 많았다. 면접을 준비할 때 이런 질문들을 고려해보면 어떨까, 혹은 내가 면접에 응시해야 하는 일들이 있을 때 이런 질문들을 대비해보면 어떨까라는 내 개인적인 생각들, 혹은 들어봤던 면접 질문 중 좋은 질문들을 공유해보고자 한다.
참고로 여기에 등장하는 모든 예시들은 내가 다니는 학교 기준이고, 22-23년까지의 기준이었다. 연합 동아리의 경우 학교마다 성격이 천차만별일 수 있다(특히 GDSC같은 경우 학교마다 그 성격이 완전히 다르다). 또한 연도별로 운영진마다 운영 방침이 달라지면서, 동아리 성격 자체가 바뀔 수도 있다. 예시는 그저 참고이다.
또한 나도 면접을 잘 보는 편은 아니기에, 나한테 전하는 글이기도 하다. 면접을 보기 직전, 이런 것들을 내 스스로 상기하고자, 전략을 정리하였고, 내가 그동안 느낀 점들을 정리해보았다.
그리고 면접자의 입장에서, 동아리에 합격하기 위한 전략들
그리고 면접관의 입장에서, 좋은 면접자를 가려내기 위한 전략들
두 시선이 이 글에 혼재되어 있다. 그래서 ‘면접자’, ‘면접관’의 시선을 글 머리에 구분해두었다.
면접자의 입장에서 느낀 점들
개발 지식에 관한 질문들
면접자의 입장에서 어떤 개념들을 미리 준비해야 할 지, 고민이 되는 경우가 많다.
회사가 아니므로, 개발 동아리의 특성상 이제 막 개발을 시작하는 사람들이 모이기 때문에, 그렇게까지 높은 개발 지식을 요구하지는 않을 것이다. 그러나 개발 동아리가 학교는 아니기에 완전히 무지한 사람을 뽑아서 교육을 시킬 수는 없으므로, 개발 동아리에서 요구하는 최소한의 기본기들이 있을 것이다.
어떤 동아리들은 이제 막 처음 개발을 시작하는 입문자들을 많이 모집한다. 이런 경우 동아리 내에서 자체적인 교육 시스템을 갖추고 있는 경우가 많아서, 면접 때 요구하는 기본 수준이 많이 낮은 편이다. 잘 알려진 멋사같은 경우가 대표적이다. 유명세에 비해서 개발 지식에 관한 질문이 그렇게까지는 어렵지 않은 것으로 알려져 있다(그렇기에 인성 면접이 중요하다). UMC같은 경우도 비슷하다(학교마다 다를 수 있다).
반면 어떤 동아리들은 어느 정도 개발을 할 줄 아는 사람들을 요구하기도 한다. 이런 경우 면접 시 개발 지식을 미리 꼼꼼히 체크해서, 입문자들을 필터링하기에 꽤 높은 레벨을 요구한다.
기본적으로는 그 동아리에서 사용되는 지식들을 물어본다. 예를 들어 아두이노 동아리라면 C에 대한 질문을 물어볼 지언정, 뜬금없이 HTTP에 대한 질문을 물어보진 않을 것이다. 블록체인 동아리라면 블록체인에 관련된 질문을 물어볼 것이다. 뜬금없이 Java의 멀티쓰레딩에 대해 물어보진 않을 것이다.
아래는 통상의 웹/앱 개발을 주제로 하는 동아리에 지원할 때를 기준 삼았다.
입문자 레벨의 경우
입문자 레벨의 경우, 보통 학교에서 1, 2학년 때 가르칠만한 개념을 그대로 내는 경우가 많아서, 수업만 잘 들었다면 대답할 수 있는 것들을 보통 질문한다. 적어도 다음 표에 나오는 개념 정도는 미리 숙지하는 게 좋다.
| 개념 | 중요도 | 비고 |
| 객체지향의 개념 | ★★★ | 객체지향의 3원칙 등 |
| 클래스의 개념 | ★★★ | 객체와 클래스의 차이에 대해서 물어볼 수도 있음 |
| MVC 패턴 | ★ | 보통 토이플젝이라도 한 번 해봤던 사람들에게 물어봄 |
| 간단한 언어 문법 | ★ | |
| HTTP 개념 | ★★ | 백엔드 모집 시 물어볼 수 있음 |
| 깃허브 사용 가능 여부 | ★★☆ |
중요도는 개발자들 기준에서의 중요도가 아니라, 입문자를 상대로 면접을 볼 때 자주 나올만한 순위로 매겼다. MVC 패턴같은 경우 실제론 매우 매우 중요한 개념이지만, 보통 입문자를 상대로 물어보는 경우가 그렇게 많지는 않으므로 중요도를 낮게 평가했다. 동아리에서 가르쳐주기 때문이다. 반면 객체지향의 개념의 경우 입문자라고 하더라도 대부분 물어볼 것이다. 아무리 교육 시스템이 좋아도, 객체지향의 개념을 모르는 사람들을 데리고 갈 수 있을 정도의 동아리는 많지 않기 때문이다.
보통 일반적으로 이정도 개념 외에는 잘 안 물어본다. 처음 개발하는 사람들에게 높은 수준을 요하지 않으므로, 인성, 경험 관련 질문들을 잘 대비하는 게 더 좋다.
Github 사용에 대해서는 지식을 물어보는 질문은 아니긴 하지만, 입문자의 경우 Github 아이디조차 없는 경우가 있어서 서류에 github 아이디를 제출하게 하거나, 혹은 Github를 어느 정도까지 사용 가능한 지 물어보는 경우가 있다.
경험자 레벨의 경우
유경험자, 혹은 높은 수준의 지식을 요하는 동아리에 지원하는 경우, 보통 지원자가 했던 프로젝트, 혹은 서류를 바탕으로 별도의 개별 질문을 통해 기본기를 확인한다.
사실 이런 동아리에 지원하는 경우 이미 이 글이 의미가 없을 정도로 탄탄한 기본기를 갖췄을 것이다.
예를 들면, 어떤 면접자가 django로 한 프로젝트를 만들었다고 해보자. 이 프로젝트의 깃허브 등을 참고해서 개별 질문들을 이어갈 수 있다.
- 서비스의 구조에 대해서 설명해주세요
- 프로젝트에서 어떤 기술 스택을 사용하셨나요?
- 여기서 왜 그런 기술 스택을 사용하셨나요?
등등의 질문들이 있을 것이다.
한 가지 꼭 당부하고 싶은 말이 있다. 프로젝트의 구조(아키텍처)에 대해서 묻는 질문에, 은근히 많은 사람들이 이상하게 답변을 한다.
면접관이 묻고 싶은 건 서비스의 전반적인 아키텍처인데, 여기에 코드 레벨의 구조에 대해서 설명한다면, 상당히 곤란해질 것이다. 아래는 내가 겪은 실제 사례다.
Q. 이 서비스의 전반적인 아키텍처에 대해서 설명해주세요. 각 부분에 어떤 기술이나 프레임워크 등을 썼는지 설명해주세요.
→ 내가 궁금했던 건 서비스 레벨에서의 전반적인 구조이다. 이런 티키타카를 원했다.
A. 프론트엔드는 React, 백엔드는 Spring을 사용했습니다. 저는 백엔드를 맡았고, 백엔드의 경우 CQRS 구조를 비슷하게 채용했습니다. 통신 요청/응답은 전부 RabbitMQ를 통해서 전달되구요, 쿼리, 응답에 각각 싱글 스프링 서버를 둬서 리퀘스트를 처리합니다. 한편 디비의 경우 쿼리, 응답 디비 모두 Mongo DB를 사용했습니다. 즉 스프링 서버 두 개, 디비가 두 개, 그리고 RabbitMQ 메시징 큐 하나를 연결해서 사용합니다. 전부 GCP에 올라가있구요.
Q. 엇, CQRS 패턴을 적용하신 특별한 이유가 있을까요? 또한 이 부분을 연결할 때 메시징 큐(Rabbit MQ)를 사용하신 이유도 궁금합니다.
A. (이유 설명. 굳이 이유가 없더라도, 배웠으니 실제 프로젝트에 적용해보고 싶어서라는 답변도 괜찮을 것이다).
Q. 외부 API를 사용하기도 하는데, 이런 API 요청은 어느 서버에서 언제 날리나요?
A. 아, 외부 API의 경우 유저의 리퀘스트와는 별개로, ㅇㅇ 서버에서 30초마다 한 번 씩 날려서 디비를 갱신합니다.
Q. 문제점은 없었나요?
A. (이런 저런 문제점이 있었고 이렇게 해결되었다는 답변)
그런데 실제로 진행된 답변은, 코드 레벨에서의 설명이었다.
면접자: 아, 네… 음, 일단 스프링에서 기본 제공하는 모델, 레포지토리를 사용했구요. 모델에 (모델 이름) 모델과 DTO를 만들고, 각 서비스에 필요한 이런 저런 레포지토리를 이렇게 만들었습니다.
면접관: 앗, 제가 물어본 건 코드 레벨에서의 설명이 아니라 서비스 레벨에서의 구조였습니다. 혹시 전체 프로젝트가 어떻게 설계되었는지 알 수 있을까요? 예를 들어 이 서버는 어떤 역할을 하고, 기술 스택은 어떻게 되는 지 등의 전체적인 브리핑이요.
면접자: 서버는 장고를 사용했는데... 질문을 잘 이해하지 못 하겠습니다.
면접관: … 넘어가겠습니다.
참고로 여러 면접 관련 유튜브 영상에, 비슷한 사례가 많이 나온다. 내가 베낀 게 아닐까 의심할 수도 있다. 하지만 정확히 1년 전 개발 동아리 모집 시 면접관이었던 내가 겪은 그대로의 사례다!
심지어 면접자는 이미 장고로 몇 가지 프로젝트를 진행했다고 서류에 써놓은터라, 해당 프로젝트에 대해서 이야기를 나누려고 처음 건넨 질문이 바로 저거였다. 면접 전날에 내가 미리 깃허브에 들어가서 어떻게 돌아가는 지 파악하고서, 이렇게 답변하겠구나라고 생각하고서 물어봤다. 그랬더니 저런 엉뚱한 답변이 나와 서로 당황했었다.
왜 이런 소통의 문제가 발생했을까? 아키텍처를 물어보는 경우, 요구하는 설명의 범위가 어디까지인지를 파악해야 한다.
코드 레벨 아키텍처를 물어보는 경우, MVC, MVVC, 혹은 CQRS 패턴 등 코드 레벨에서의 구조 패턴을 설명하라는 질문일 가능성이 높다. 이런 경우 코드 레벨에서의 답변을 하면 된다. 클린 아키텍처 설계를 적용했다, 혹은 도메인 모델은 이러이러하게 만들었다 등의 설명 말이다.
그보다 큰 범위를 물어보는 경우, 이에 맞게 답해야 한다. 특히 전체 프로젝트 구조에 대해서 설명하는 경우, 각 서버 등이 어떤 역할을 하는 지 등, 전체적인 시스템을 물어보는 경우일 것이다.
보통 대부분의 학생 레벨에서의 토이 프로젝트의 경우, 배운 내용을 일부러 적용하지 않는 이상 1 프론트엔드, 단일 서버, 그리고 단일 데이터베이스를 쓰는 경우가 대부분일 것이다. 이 경우에도 간단하게 이런 기본적인 구조를 사용한다고 답변하면 될 것이다. 외부 API를 쓰는 경우 같은 서버에서 요청해서 날리고, 유저의 응답이 올 때마다 DB를 갱신한다. DB는 RDBMS를 쓴다. 서버는 django를 썼다 등등의 답변이다. 거기서도 면접관이 흥미가 있다면 질문거리를 쏟아낼 것이다.
보통 개발 동아리에서 질문을 하진 않는데, 비즈니스 로직(비즈니스 구조)를 물어보는 질문의 경우는, 유저의 관점에서 이 서비스를 어떻게 이용하는 지 로직을 물어보는 것이다. ‘비즈니스 로직’이라는 용어를 몰라서 답변을 못하는 경우도 있다. ‘유저가 앱을 이용할 때 이 버튼을 누르고 이 화면에 들어가서, 이렇게 요청을 날릴 수 있다. 응답이 들어온 후에는 이런 식으로 확인이 가능하다…’ 이런 유저 입장에서의 사용 로직이 비즈니스 로직이다.
서비스 로직, 비즈니스 로직, 아키텍처에 대한 질문은 무엇을 물어보는 지 범위와 용어를 정확히 알도록 하자.
단순히 지식을 나열하기보다, 그 안에 경험과 논리를 포함해보는 건 어떨까?
단순히 지식을 나열하기보다, 그 안에 논리를 포함할 경우 더 좋은 답변이 되는 경우가 있다.
예컨대 ‘C언어와 C++의 차이점은 무엇이 있죠?’라는 질문이 있다고 해보자.
C++에는 클래스가 있어요! 그리고 new와 delete로 동적 할당을 해요!
이런 식으로 답변을 할 수도 있지만, 나라면 아래와 같이 답변할 것 같다.
제가 C와 C++을 사용해본 결과, 자원 관리의 측면에서 가장 큰 차이점을 느꼈습니다. C++은 객체 지향 언어입니다. 객체 지향의 혜택 중에는 일반화된 디자인 패턴(설계)을 적용할 수 있다는 점이 있습니다. C++에서 자원 관리를 할 때 가장 두드러지는 설계 중 하나는 바로 RAII 설계 방식이 있습니다. 자원을 직접 관리하는 것이 아닌 객체를 통해서 관리하는 기법으로, 객체의 파괴 시 자원의 반환을 보장할 수 있습니다.
자원을 직접 관리해야 했던 C와 달리 C++에서는 객체를 통해 자원을 관리함으로써, 보다 용이하게 자원을 관리할 수 있습니다. 이는 NULL 포인터 에러, 기타 메모리 에러를 방지함은 물론 쓰레드, 파일 스트림 등 거의 모든 수동으로 관리해야 했던 자원을 자동으로 관리하는 규칙을 만들 수 있습니다.
이로써 개발 시 팀간의 의사소통이 분명해집니다. 굳이 RAII가 아니더라도, C++에서는 이러한 자원을 관리하는 정형화된 방법론이 많이 개발되었고, 이러한 방법론을 적용한다면 개발 시 오버로드를 상당히 줄일 수 있습니다. 이러한 규칙이 없다면 참조하는 리소스가 파괴된다거나, 코루틴이 돌 때 돌아올 쓰레드가 닫히는 등의 사고가 발생할 수 있습니다.
C에서는 각 팀마다 이런 규칙을 상호 합의해야 하고, 또 규칙이 있더라도 휴먼 에러에 의해 실수가 발생할 수 있죠. 특히 이런 경우 어디서 문제가 발생했는 지, 디버깅하기가 굉장히 곤란한 경우가 많습니다.
이를 제외하고도 에러 처리 기법 등, 휴먼 에러를 방지하고 문제 발생 시 이를 더 빠르게 수정할 수 있도록 하는 여러 안전 장치들을 언어 설계 단계에서부터 적용하였습니다.
TMI 대방출이여서 중간에 끊킬 수도 있지만, 위의 답변의 경우 내가 직접 사용해본 결과 얻어진 경험, 혹은 ‘객채지향이 도입됨 → 디자인 패턴을 적용할 수 있게 됨(RAII가 예시) → 여러 안전 장치들을 설계할 수 있게 됨(자원 관리가 예시)’ 이러한 결론에 대한 근거를 마련해서 답변하고 있다.
만약 지원하고자 하는 동아리의 성격이 두드러진다면, 질문에 대한 니즈에 맞춰서 답변하는 전략도 좋을 것이다.
사실 지식을 물어보는 질문의 경우 그 동아리에서 진짜로 필요한 지식일 가능성이 매우 높기에, 원하는 니즈 역시 있을 것이다. 예를 들어 자바 스프링을 쓰는 백엔드 동아리에서 뜬금없이 리액트에 대한 질문을 할 가능성은 대단히 낮다. 이 동아리 면접에서 Java에 대한 어떤 질문을 받는다면, 백엔드 개발에 필요한 지식일 가능성이 매우 높으므로, 백엔드 개발자의 관점에서 답변을 이어가는 게 좋을 것이다.
그리고 결국에 이런 답변을 준비하려면 평소에 많이 공부해두는 수 밖에 없다. 모르는 데 유려한 답변을 달 수는 없기 때문이다.
경험에 대한 질문들
사실 위에서 나열한 질문들(본인이 이런 프로젝트를 했는데, 어떻게 아키텍처를 설계하셨나요 등)이 결국 경험에 대한 질문이다.
또는 본인이 했던 프로젝트에서 어떤 역할을 맡았는 지, 혹은 문제가 있었다면 어떻게 해결했는 지 등을 물어볼 수도 있다. 이런 질문들의 경우 보통은 내가 직접 경험을 쌓아야 하므로, 평소에 열심히 뭔가를 해보는 수 밖에 없다.
한 가지 추천해보고 싶은 건, 무언가를 할 때, 블로그처럼 기록을 해두는 게 상당히 좋은 것 같다. 회고록이든 개발 일지 등 형태는 상관 없다. 혹은 README의 형태로 적어두거나, 개인 노션에 저장해두는 것도 괜찮다. 어떻게 설계했고 무엇이 문제였는 지, 그리고 어떻게 해결했는 지, 아쉬움은 무엇이고 어떻게 개선할 것인지, 배운 점은 무엇인지 등등 다양한 내용이 들어갈 수 있다. 간단히 하나의 글로 정리할 수도 있고, 메모처럼 파편적으로 남길 수도 있다. 물론 파편적으로 남기기보다는, 어딘가에 정리를 해두면 상당히 좋다.
이렇게 정리를 해두면 몇 가지 장점이 생기는 데,
- 일단 자기가 한 것의 내용 증명이 되기도 하고(내가 기록한 게 결국 내 역할이자 했던 경험이니)
- 또한 시간이 지나서 기억이 잘 안 날 때도, 정리한 글들을 보면서 면접을 준비하거나 할 수 있다.
당장 나도 한 일주일만 지나도 대체 이걸 왜 이렇게 개발했을까 싶을 정도로 기억도 안 나고, 주석 없으면 코드 읽히지도 않는데, 보통 면접을 준비하게 되면 수 개월, 수 년 전 프로젝트를 기억해야 하는 경우도 많다.
‘내가 이런 걸 했었나…? 뭐 했지?’를 당하기 싫으면, 평소에 꼼꼼히 기록해두고 정리해두자.
인성에 대한 질문들
어느 직종에 가든 인성 면접은 나올 수 밖에 없는 것 같다.
개발 직종에 한해서는 이런 질문들은 간간히 물어보는 것 같다.
- (문제 상황을 주고) 팀으로 활동할 때 이러이러한 문제는 어떻게 해결할 것이냐
- (문제 상황을 주고) 개발자와 디자이너, 그리고 기획자와 갈등이 생겼을 시 어떻게 해결해나갈 것인가
- 이런 것을 개발할 때, 협업자와 나와 의견이 다르다면 어떻게 해결할 것인가?
- 예를 들어 상태 관리를 할 때, 둘이 서로 다른 방법으로 상태를 관리하고자 할 때
- 혹은 어떤 페이지를 만들 때, 객체의 상하 관계를 어떻게 구성할 지에 대해 의견이 나뉠 수 있다
이런 식으로 주로 팀 내에서 협업할 자세가 되어 있는 지, 혹은 팀 외부적으로도 디자이너, 기획자 등과 협업할 자세가 되어 있는 지를 물어볼 수 있다. 여기에 ‘난 협업할 생각 없어요’라고 답할 사람은 없으므로, 사실 대부분 면접자들은 비슷한 답변을 내놓는다. 다 잘 대답하는 것 같기도 하다. 본인의 성향에 맞춰 잘 답변하자.
결국 평소에 잘 준비해야 하더라
지식의 대한 질문은 평소에 미리미리 CS 등의 공부를 많이 해두어야 하고
경험에 대한 질문은 평소에 미리미리 경험을 쌓고, 이를 잘 정리해야 한다.
인성에 대한 질문은 어차피 모든 사람들이 다 잘 대답할 것이다.
그렇기 때문에 결국 중요한 건 ‘평소에 잘 해두는 것’ 같다. 사실 이미 서류와 포트폴리오에서 합격 당락이 결정되는 경우가 많은 것 같다. 면접은 단지 이 사람이 팀에 잘 맞고, 적응을 잘 할 지, 이상한 사람은 아닐 지, 우리 사람이 될 수 있을지를 검토하는 마지막 과정일 뿐이란 게 내 생각이다.
코딩 테스트를 통과하지 못 하거나, 서류 단계에서 불발되었으면 면접 준비를 아무리 한다 한들 소용 없다.
그러니 결국 평소에 잘 준비하자.
면접관에 입장에서 느낀 점들
누구를 뽑아야 하는 가
이거는 면접자가 아닌, 단체의 운영자의 입장에서 누굴 뽑을까에 대한 내 생각이다.
내가 다시 동아리 운영진을 하게 될 지는 잘 모르겠다. 그런데 느낀 건, 결국에 제일 중요한 건 사람이여서, 정말 신중하게 뽑아야 하는 것 같다. 단순히 포트폴리오가 좋다고, 혹은 말을 유려하게 잘 한다고 해서 뽑는 게 좋은 건 아닌 것 같다.
어디서 봤는 지 정확히 기억은 나지 않는데, 이게 성공하는 스타트업의 특징이라고도 한다. 보통 스타트업의 경우 사람을 정말 신중하게 뽑는다고 한다. 아마존이었나? 잘 기억은 안 나는데 한 회사의 경우 초기에 4명으로 운영되는데, 새로운 사람이 필요해서 뽑는데 6개월이 걸렸다고 한다.
옛날에는 사람이 많으면, 그 중에 좋은 사람들이 있을 가능성이 높아지므로 더 좋지 않을까? 라는 생각이 있었다. 그런데 특히 초창기 스타트업의 경우, 정말 일에 열정이 있고 리스크를 감수할 수 있는 사람들만 모여야 단체가 굴러갈 수 있기에, 오히려 잘 맞지 않는 사람들이 많아질 경우 그대로 공중분해되는 경우가 대부분이라고 한다. 오히려 지금 잘 나가는 IT 기업들 중 많은 기업들이, 창업 시절에는 4명, 6명 등 극소수의 인원으로 수 개월에서 몇 년은 버텼다고 한다. 맞는 말인 것 같다. 분위기가 정말 중요한 게, 한 번 김이 빠지는 순간 내 스스로 열정을 순식간에 잃고, 정도 떠나간다. 한 번 정 떠난 집에 다시 발 들이기 쉽지 않다.
우리 학교에 비록 내가 속해있지는 않았지만 내가 봤던 단체 중 가장 분위기가 좋고, 실제로 결과물도 가장 좋았던 단체가 하나 있었다(현재까지 운영되는 지는 모르겠다). 이 단체는 기수제로 운영되지 않고, 주위 사람들을 오랫동안 지켜보다가 정말 좋았던 사람들 한 두 명 정도만 데려가는 식으로 운영됐었다.
기수제로 운영되는 동아리의 경우, 사실 매 기수마다 최소 인원 이상은 뽑아야 하기에, 이런 부분에서 사실 아쉬움이 생길 수 밖에 없다. 실제로 이런 경우는 내가 있던 거의 모든 동아리에서 발견하는 문제점이었다. 역사가 오래된 동아리의 경우 노하우가 생겨서 슬기롭게 해결하는 경우도 있었고, 새로 생긴 동아리의 경우 대부분 이런 취약점에 치명적으로 데미지를 입는다. 내가 운영할 때는, 사실 이런 문제를 슬기롭게 극복하지는 못 했다.
면접관의 입장에서는 항상 이런 문제를 생각해야 한다. 경험상 단순히 말을 유려하게 잘한다고 해서 뽑는 건 그리 좋은 선택은 아닌 것 같다. 하다보면 이 사람이 진솔한 지, 그리고 열정이 있는 지가 느껴지는 데, 이런 경우 심하게 포트폴리오나 경험에 하자가 있지 않은 이상 높은 평가를 주어도 나쁘지 않은 것 같다. 심지어 답변에 문제가 있을 지라도 말이다.
그래서 회사처럼 점수제로 평가하는 게, 동아리 면접에서는 그다지 좋은 방법은 아닌 것 같다. 어설프게 A는 몇 점, B는 몇 점 점수를 매겨서, A는 인성 면접에서 별로 좋아보이지는 않지만 지식이나 경험 면에서 높은 점수를 받아 B보다 총합 점수가 높으므로 A를 뽑겠어! 이런 접근 방식은 좋지 않은 것 같다.
새로운 신입 직원을 뽑는데 6개월이 걸렸다는 스타트업의 사례를 생각하자. 정말 마음이 가는 상대방을 뽑아야 한다. 여기에 점수제를 적용하는 건 어찌보면 공정성을 지키는 것일 수도 있지만, 면접이 단체가 필요로 하고 원하는 사람을 뽑는거지, 공정을 지키려고 하는 건 아니지 않은가. 정말 필요하고 원하는 사람을 뽑자.
사실 요새는 전통적인 질문과 답변이 오가는 딱딱한 면접 대신, 커피챗 형태의 면접이 유행하고 있는 듯 하다. 오히려 이런 형태가 더, 진솔한 사람을 뽑는데 장점이 있을 수 있다. 나도 한 번 해보고 싶은데, 아쉽게도 아직까지 커피챗 형태의 면접을 경험해본 적이 없다. 나중에 받게 된다면 꼭 후기를 남기고 싶다.
면접은 쌍방의 평가 과정이다
다시 말해, 면접관이 면접자를 평가할 때, 역으로 면접자 역시 면접을 통해서 그 단체를 평가한다는 것을 반드시 잊지 말자.
이는 단순히 면접자를 존중해야 하는 것 뿐만 아니라, 면접 준비를 면접관 역시 꼼꼼하게 해두어야 함을 뜻한다. 개별 질문을 꼼꼼하게 준비하고, 답변을 경청해야 한다.
이게 중요한 게, 내가 면접자로 들어갔을 때도, 면접관이 내 말을 귀기울여 듣고 있는 지 바로 보인다. 물론 면접자 입장에서는 너무 긴장해서 그게 눈에 바로 들어오지는 않지만, 상대방이 심퉁하게 듣고 있다면 면접자 입장에서도 그다지 좋게 보이지 않는다. 이는 곧 그 단체에 대한 불신으로 이어진다.
보통 원하는 인재는, 그 단체 뿐만 아니라 다른 단체에서도 러브콜을 받는 경우가 대부분이다. 면접을 통해서 면접자를 가려내는 것 뿐만 아니라, 우리 동아리/단체에 들어와달라고 구애를 하기도 해야 한다. 그러니 면접관 역시 꼼꼼히, 준비하자.
가장 기본이 되는 게 서류는 꼭 다 읽자. 개별 질문을 하기 위해서도 기본이 된다. 한 번에 수 백 명의 지원자가 몰리는 회사라면 모를까, 동아리는 기껏 해야 수 십 명의 지원자가 몰리지 않는가? 이 사람들이 소중하게 고민해서 쓴 서류는 꼭 읽고 면접에 들어가자.
왜 이런 말을 쓰냐면, 이런 서류를 아예 안 보고 면접에 임하는 동아리가 실제로 꽤 많다. 이런 경우 면접자 입장에서 단체에 분위기가 머릿속에 바로 그려지면서, ‘내가 왜 이런 동아리에 들어가야 하지?’라는 생각이 들 수 밖에 없다. 동아리 운영진을 했던 사람으로써, 실제로 서류조차 읽지 않고 사람을 뽑는 동아리의 사례를 종종 봤다. 그러지 말자….