자바 백엔드 4년차 N사 경력 면접 후기(부제 : 면접을 이끄는 건 누구인가?)

쓸데없는 서론

지금 다니는 회사 동료분들 중 몇 분이 내 블로그를 알고 있기 때문에 면접 봤다는 이야기가 알려지면 좋을 것이 하나도 없지만, 면접이 주는 영감? 동기부여?가 있기도 하고 공유하는 것을 즐기는 성향 때문인지 공유 욕구가 더 강해 위험(?)을 무릅쓰고 포스팅을 하려고 한다.

4년 차 백엔드 개발자 면접 후기

우연한 기회로 N사 계열사 면접(1차 기술 면접)을 보게 되었다.

결과부터 말하면 탈락이다.

그렇기에 이 후기는 패착을 분석하는 후기다.

시간 아까운 사람을 위한 결론

• 코딩 테스트는 경력 채용이라 어렵지 않았음 (공부 하나도 안 하고도 주어진 테스트 케이스는 솔(solve)하는 수준? 절대 온전한 정답은 아니겠지만?)
• 컴퓨터 사이언스나 주니어 수준에 어울리는 기술 질문보다는 경력 즉, 어떤 경험을 가졌는지를 더 중요하게 보고 집중적으로 질문함
• 입 코딩, 손 코딩 없음

면접 경험을 공유하기 이전에 알아야 기초 정보도 공유한다.

간단한 내 소개

이번 면접에 임한 사람(필자)의 상태다.

• 총 경력 3년 8개월 (2021-09-08 현재 기준 4년 차)
  • 직원 수 30인 미만 반도체 솔루션 회사 (2년 7개월)
    • java, springboot 환경의 솔루션을 개발 (반도체 장비에서 발생한 데이터를 모니터링 시스템으로 전송하는 에이전트(agent)성격의 애플리케이션을 개발함)
  • 직원 수 500명 내외 그룹웨어 솔루션 외 기타 비즈니스 애플리케이션 개발 회사 (1년 1개월)
    • java, spring, postgresql, solr, activeMQ, ... 환경의 그룹웨어 솔루션(+서비스) 유지 보수

좋은 개발자가 되기 위해서 노력하는 평범한 개발자라고 생각하면 좋을 것 같다.

면접은 어떻게 이루어지는가?

면접은 일정 상 1시간이 잡혀있었지만 실질적으로 면접을 보는 시간은 40분 정도였다.

그 40분 간 이뤄지는 절차는 다음과 같았다.

아이스 브레이킹 > 간단한 자기소개 > 자기소개나 이력/경력기술서에 기반한 질문 몇 가지 > 꼬리 무는 질문 및 기술 이해도 파악 > 면접자와 평가자 상호 간 궁금한 점 > 면접 종료

일반적으로 생각하는 면접 국룰(?)대로 진행을 한다.

국룰(?)이기 때문에 특별히 준비해야 하거나 어려울 만한 것은 없다.

하지만 몇 가지 주요 질문에 어떻게 대답하느냐에 따라 합/불이 결정되기에 면접 준비를 따로 하기도 한다.

필자는 무슨 깡인지 아무런 준비를 안 했다. 일을 다니고 있다는 핑계로... 시간이 많지 않다는 핑계로...

그래도 예상하는 주요 질문들은 조금 생각을 해봤다. 🤔

예를 들면 JPA N+1문제 발생 원인부터 해결 방법이라든지, 대용량 트래픽에 대한 주요 대응 방법과 특징(장단점)이라든지 하는 것들 말이다.

그러나 예상대로 이뤄지지 않았다. (예상대로 됐으면 잘 봤겠다는 얘기는 아니다...)

위와 같은 일반적인 기술 질문 이전에 경험에 대해서 소개하는 부분부터 순탄치는 않았다.

아무래도 평가자(면접관)가 대뜸 미리 준비한 기술 질문 리스트를 기준으로 쭉 물어보는 것이 아닌, 면접자의 경험에서 관심이 있는 부분을 캐치하고 질문하는 게 일반적인 절차라고 생각되는데 그런 경험 자체가 잘 공감하기 어려운 방향으로 흘렀기 때문이다.

그래서 이번에 배운 것은 경력 면접은 "면접을 이끌 방법, 기술 소통"에 대한 준비를 해야 한다는 것이다.

통상적으로 신입사원 면접에서는 평가자가 면접을 이끈다.

물론 신입사원도 자신이 공부한 것이나 인턴 경험이나 수상 경험, 교육 수료, 프로젝트 경험을 통해 어필하고 면접의 방향을 이끌 수 있다.

하지만 신입사원은 실무 경험이 부족하기 때문에 잘못하면 과유불급이 되기 마련이다.

그리고 결국은 책임으로 보나 역할로 보나 평가자가 주도해야 한다.

평가자는 회사 또는 팀을 대표해서 채용과정에 면접자의 기술적인 수준을 파악해야 하고, 이를 위해서 주어진 시간 내에 면접자의 역량을 최대한 끄집어내 보여줄 수 있도록 해야 하는 책임을 갖는다.

경력사원 면접도 평가자가 비슷한 책임과 역할을 갖지만 무게가 다르다.

경력사원과 신입사원의 가장 큰 차이점은 경력이 있다는 것이고 경력 즉, 어떤 경험을 했는지는 면접자가 더 잘 알기에 더 잘 어필할 수 있을뿐더러 경험에서 공감을 해야 서로 얘기해볼 만한 가치 있다고 느낀다.

때로는 소프트웨어 개발 업계 밥(?)을 먹었기 때문에 기술 얘기를 할 때 어떻게 소통하는지가 바로 보일 때도 있다.

신입사원은 직무 외적으로 아직 경험이 부족하기 때문이라고 이해해줄 수 있으나, 경력사원은 N년을 해본 사람이 소통이 잘 안된다면? 조금 이상하다고 볼 수도 있는 것이다.

이런 이유로 경력사원 면접은 평가자가 아닌 면접자가 면접을 이끈다.

면접 '절차'는 여전히 평가자가 주도하겠지만 적어도 대화의 주제, 토픽은 면접자가 이끈다.

따라서 제대로 어필하고 입사를 위해서는 내가 자동화 경험이 있으면 자동화 쪽으로 이끌고, 리팩토링 경험이 있으면 리팩토링 쪽, 테스트 커버리지를 올린 경험이 있으면 테스트 쪽, 성능 최적화 경험이 있으면 성능 최적화 쪽으로 이끌어야 한다.

근데 필자는 그렇게 하지 못했기 때문에 패착은 여기에 있다고 생각한다. (뭐 물론 평가자분들은 이 때문만이 아니라할 수 있지만?)

패착

경력 이직을 했기에 경력 면접에 대한 경험이 있음에도 불구하고 어려운 기술 질문에 대한 답변만 생각했었다. 그렇기 때문에 면접을 주도적으로 하지 못했다.

이번 면접 질문 중에 이런 게 있었다.

*"업무적으로 내가 가장 감명받았던 경험이나 크게 성장했던 경험 또는 평가자가 혹시라도 모를 수 있는 나만의 경험이 있다면 설명해줄 수 있는가?"*

지금에서 생각해보면 대화의 주도권을 어느 정도 주는 질문이었지만 면접 당시에는 질문 내용만으로 상당히 부담되는 질문이었다.

내가 공부하고 경험한 내용, 자신 있는 방향으로 말했으면 좋았겠으나 질문 곧이곧대로 정말 내가 한 경험 중에 제일 특별했던 걸 찾으려 하다 보니 서로 공감할 수 없는 주제로 넘어간 것이 패착이었다. (평가자 입장에서는 오히려 '이런 주제 또는 분야에서 얘기하기를 원하는구나'로 오해할 수밖에 없다.)

필자는 해당 질문에 대한 답변으로 버그를 찾아서 if문 같은 로직 몇 개 수정한 것(유지보수 이슈 처리)을 가장 결정적인 경험이라고 하기도 뭐하고, 단순 기능 추가한 거나 젠킨스 아이템 하나 추가해서 스크립트 조금 작성한 거로 자동화라고 하기도 뭐하고, ... 뭐 이런 느낌이었다.

그래서 전 직장에서 프로토콜 변경하고 자료 구조 조금 바꿔서 네트워크 페이로드 크기를 줄여서 약간의 성능 개선 경험을 말해버렸다.

전 직장에서의 경험이라 오래되기도 하고 그렇게 드라마틱한 성과도 아닐 뿐더러 일반적인 서비스를 제공하는 회사가 경험하는 내용(프레임워크, DB, 캐시 관련된 트러블슈팅 경험, 설계 경험 등)도 아니었다.

그렇기에 공감하기 어려웠을 것이며 소통이 어렵다고 느꼈을 것이다.

도메인의 영향력

패착을 분석하면서 새롭게 느낀 것은 바로 전직장 커리어이자 도메인이다.

존재 자체로 발목을 잡을 줄은 몰랐다.

물론 어느 도메인이든 최선을 다하고 좋은 경험을 하기도 하고 기술을 학습하고 하면 되기에 하나의 핑계일 수 있지만, 평범한 신입사원이 어떻게 그렇게 열정적으로 커리어를 생각하며 최선을 다할 수 있을까 싶기도 하다. (주어진 업무 처리하는데 급급했던 것 같은데...)

혹시라도 신입 개발자분이 이 글을 본다면 함부로 아무 도메인, 아무 데나 취업해서 이직해야지 같은 생각은 말기를 바란다.

다시 돌아와서 채용하는 입장에서는 비슷한 기술 경험을 했거나 비슷한 도메인에서 경험했기를 기대한다.

전 직장에서 일했던 것은 자바, 스프링 개발이긴 했지만 엔드유저에게 서비스하는 애플리케이션이 아니라 데이터 중개 애플리케이션이었고 표현이 적절하진 않지만 정형화된 앱 아키텍처(Spring MVC 같은 웹 서버, RDB, 캐시저장소, ...등)로 이뤄진 것도 아니었다.

반도체라는 다른 도메인, 다른 프로토콜, 다른 용도의 웹 애플리케이션 개발, ...등이 경력으로 어필하고 공감하기는 비교적 어려운 것 같다. 그래서 이에 대한 대비책도 필요하다.

결론

경력 면접에는 준비해야 할 것이 있다.

"면접을 어떻게 이끌 것인가"다.

아주아주 중요하다. 본격적으로 이직을 하려고 만반의 준비를 하고 진행한 것이 아니라서 한 편으로는 다행이다.

업무를 하면서도 커리어에 강점으로 내세울 만한 것을 만들기 위해 노력을 좀 해야 하고 그것을 온전히 내 경력으로 만들고 면접에서 주제를 이끌거나 유도를 해야 하지 않을까 한다.

조금 과장하면 경력 면접은 인터뷰가 아니라 오디션이다. 내가 뭘 잘하는지를 주어진 환경에서 스스로 어필을 해야 한다.

뭐 기술적, 인성적으로 아주 훌륭하다면 오디션은 커녕 인터뷰도 안되고 모셔가겠지만...

기술 질문

의외로 기술 질문은 너무도 간단한 게 나왔다. (N사 기술면접이 상당히 어렵다고 들었는데...)

자바 스프링 개발자 면접 국룰인 transaction, lock, isolation level, index, JPA N+1문제, DI, AOP, application context, 3 way hanshake 등의 CS지식이 많은데 스프링이 제공하는 DI 방법과 장단점 같은 특징이 무엇인가?에 대해서 물어본 질문 딱 1개였다.

개인적으로 양심 없지만 합불을 떠나서 뭐라도 얻어갈 생각이었다만 첫 단추를 잘 못 꿰어서 그런지 기술 질문을 많이 받지 못해 조금 아쉬웠다. (아마 제 역량을 많이 못 보여준 대해서 많이 지체되어 그런 게 아닐까 한다.)

---

약간 허무하게 마무리되는 경우긴 한데 이렇게 면접 후기를 마친다.