[번역] 개발자를 위한 면접 지침
또 다른 제목: 면접에서 회사를 상대로 질문하는 방법
이 글은 A developer’s guide to interviewing의 번역입니다. 기본적으로 구직자로서 면접관을 대상으로 할 수 있는 질문들을 정리한 글입니다. 글쓴이가 거주하고 있는 것으로 보이는 미국과 한국의 기업 환경에는 차이가 있기에 조심스럽게 해야 할 질문도 있겠습니다. 하지만 경력이 쌓이면 자연스럽게 면접관의 역할을 하게 될 것이므로 개발자로서, 관리자로서, 그리고 경영진으로서 가져야 할 업무 능력, 지식, 가치관에 대한 조언이라 생각하고 읽어도 좋을 것 같습니다.
구직을 위해 면접을 본 적이 있다면, 면접관으로부터 테이블 너머에서 “더 궁금한 것이 있으신가요?”라는 질문을 받은 적이 있을 것이다. 당신이 만약 “음, 아니오. 없습니다”라고 대답했다면 면접은 단방향이라는 관점을 가지고 있을 가능성이 크다.
구직자로서의 당신은 결과를 만드는 일에 집중하는 것이 당연하다. 하지만 면접은 단방향이 아니다. 회사가 당신을 면접하는 일에 집중하는 것처럼 당신도 회사를 면접하는 일에 집중해야 한다.
그런데 무슨 질문을 해야 하나?
이직을 준비하는 많은 개발자는 나에게 이 질문을 한다. 나는 지난 15년간 7개의 회사에서 일했고(2번의 인턴쉽과 스타트업에서의 6개월 포함) 그동안 많은 사람과 면접을 진행했다. 그리고 다른 이들에게 도움이 되길 바라는 마음에 지금까지 면접에서 했던 질문들을 정리하기로 했다.
나는 이 글이 계속 업데이트되길 바란다. 만약 당신이 제안하고 싶은 내용이 있다면 트위터를 통해 알려주길 바란다. 모두에게 도움이 되기 위해 기꺼이 함께할 것이다.
누구와 얘기를 하게 될까?
면접을 보는 동안 만나게 되는 사람들의 역할은 보통 세 종류로 나뉜다. 회사의 규모에 따라 한 사람이 세 가지 역할을 모두 할 수도 있고, 많은 사람이 그 역할을 나눠 맡을 수도 있다.
- 개발자
- 관리자 (기술 책임, 중간 관리자, 기술 감독)
- 경영진 (VP, CTO, CEO, 부서장)
나는 저들에게 할 수 있는 서로 다른 질문이 있으며, 이 글에서 하나씩 언급할 것이다. 그리고 답변들을 비교하기 위해 때로는 서로 다른 대상에게 같은 질문을 하기도 한다는 사실을 알고 있었으면 한다.
이 글은 제법 길다. 쭉 읽어낼 수 있는 글이라기보다는 참고서에 가깝다. 만약 내가 오늘 면접이 있다면 이 글을 가져가서 조심스럽게 면접을 진행하는 동안 (조심스럽게) 참조할 것이다.
질문 대부분은 “옳고” “그른” 대답이 없다. 질문들은 당신이 회사의 문화, 업무 프로세스, 그리고 조직에 대해 파악할 수 있도록 도와줄 것이다. 그리고 면접을 보는 동안 당신의 머리가 멍해졌을 때 대화를 이어나가기 위한 도구로서도 요긴하게 쓰일 수 있다.
예를 들어, 나는 면접을 시작할 때 면접관들에게 몇 가지 질문을 해도 되느냐고 물어보곤 한다. 이는 면접관들이 일정에 맞게 면접을 진행하는 데 도움을 줄 것이다. 보통은 면접이 끝날 때 질문을 할 기회를 주기 때문에 질문을 하고 싶다는 당신의 의도를 면접관들에게 일찍 전달해야 한다. 하나의 질문이 끝나고 나면 멈춘 후 다른 질문을 계속해도 되는지, 그들이 시간을 얼마나 더 가졌는지 물어봐야 한다.
개발자를 위한 질문
1. 오늘 해야 할 일을 어떻게 파악하십니까?
이 질문의 목적은 업무 프로세스가 제대로 구축되어 있는지 확인하기 위한 것이다. 나는 2~3명의 개발자에게 질문의 답변을 들었으면 한다. 운영진들이 특정 프로세스를 따른다고 말하더라도 개발자들이 아무런 얘기를 하지 않는다면 그건 부정적인 신호다. 개발자들이 서로 다른 얘기를 한다면, 그 또한 부정적인 신호로 볼 수 있다.
높은 수준의 팀에서는 이 질문에 대해 일관적인 대답을 들을 수 있다. 그것은 모든 개발자가 업무 프로세스를 잘 알고 있으며, 프로세스가 단순해서 개발자들에게 부담되지 않고 도움이 되고 있음을 의미한다.
좋은 대답의 예: “우리는 새로운 기능과 버그를 고치기 위한 (몇) 주 단위의 스프린트를 진행하며 매일 서로에게 했던 일을 공유합니다. 우리와 함께 일하는 제품 관리자는 고객 대응에 임하면서 개발자들에게 새 기능과 버그 수정의 우선순위를 잘 조정해줍니다.”
나쁜 대답의 예: “회사에 오면 어떤 문제가 터졌는지 살펴봅니다. 거의 매일 비상사태입니다.”
내가 “스크럼”이나 다른 특정한 방법론을 언급한 것이 아님을 분명히 했으면 좋겠다. 나는 회사가 사용하는 개발 프로세스의 이름에는 관심이 없으며 그들이 매일매일 “어떻게 업무를 진행하는지”를 더 중요하게 본다.
2. 버전 관리 도구로는 무엇을 사용합니까?
좋은 도구의 사용은 좋은 팀의 지표가 된다. 어떤 팀이 구시대적인 버전 관리 도구를 사용하고 있다면, 아마 그것 말고도 철 지난 도구를 많이 사용하고 있을 것이다. 게다가 그들은 좋은 도구를 사용함으로써 얻는 효율을 그다지 중요하게 여기지 않을 것이다.
이 질문 다음으로는 업무 진행 방식에 대해 질문을 하면 좋다. “분기점(branch)을 사용하나요?” “재배치(rebase)와 병합(merge) 중 무엇을 선호하십니까?” 이런 질문은 그들이 사용하는 도구에 얼마나 전문적인 지식을 가졌는지, 그리고 그들에게 무엇을 기대할 수 있는지를 알 수 있다. 예를 들어 그 회사에 가면 리누스 토르발즈1처럼 뛰어난 사람을 만날 수 있다는 확신을 얻을 수도 있지만, 오히려 내가 “지역 Git 전문가” 역할을 하게 될 것 같다는 예감을 하게 될 수도 있다.
이 질문은 개발 도구에 대한 전반적인 토론을 시작할 수 있도록 있도록 하며, 종종 당신에게 좋은 통찰을 가져다줄 것이다.
3. 여기서 일하면 어떤 점이 좋습니까?
- 확신에 찬 대답: 내가 하는 일에서 아주 큰 만족감을 느낍니다.
- 확신에 찬 대답: 우리는 일에서 아주 큰 재미를 느끼고 있습니다.
- 확신에 찬 대답: 나는 똑똑하고 친절한 우리 동료들과 일하는 것이 무척 좋습니다.
- 확신에 찬 대답: 관리 부서는 개발자들을 존중합니다.
긍정적 대답은 많을수록 좋다. 면접을 보는 회사에 좋은 점수를 주기 위해 위에 있는 모든 대답을 들어야 할 필요는 없다. 어떤 사람들은 선천적으로 자랑을 잘하지 못한다는 사실을 염두에 둬야 한다. 그러니 이 질문에서 아주 긍정적인 대답을 듣지 못하더라도 괜찮다.
하지만 다음에 오는 대답을 들으면서 확신에 찬 대답을 조금밖에 듣지 못한다면, 고민이 될 것이다.
- 확신 없는 대답: 월급은 잘 줍니다.
- 확신 없는 대답: 열심히 일할 필요가 없습니다.
- 확신 없는 대답: 배포를 위한 압박감이 그리 크지 않습니다.
- 확신 없는 대답: 내가 큰 실수를 해도 별문제가 되지 않습니다.
- 확신 없는 대답: … (침묵)
꾸며낸 말이 결코 아니다. 나는 실제 면접에서 저런 대답을 들었던 경험이 있다.
확신 없는 대답을 하나 들었다고 해서 바로 그 회사가 나쁘다고 판단하지는 않는다. 하지만 세 번째 질문에 대한 답이 모두 저런 식이라면, 나는 보통 다른 곳을 알아본다.
4. 유닛 테스트를 작성하십니까?
어떤 팀을 유닛 테스트 활용 사례를 바탕으로 평가할 때는 신중해야 한다. 유닛 테스팅에 대한 질문을 했을 때 기분이 좋아 보인다면 그것은 일반적으로 좋은 신호다. 그에 반해 왜 유닛 테스트를 작성해야 하는지, 유닛 테스트의 결점은 무엇인지에 대해 설명하지 못한다면 눈먼 양 도그마2에 빠져 있다는 징후로 볼 수 있다. “시간이 없다”는 등의 변명을 들며 테스트를 작성하지 않는다고 말한다면, 나는 좋지 않은 신호로 받아들인다.
5. 지속적 통합(CI) 프로세스를 갖추고 있습니까?
내가 아는 최고의 개발팀은 Jenkins, Travis, 그리고 BuildBot 같은 도구를 사용한다. 그 팀이 CI 도구를 사용하고 있지 않다면 관련 개념을 알고 있는지 알아본다. 만약 모른다면 이건 내 경험상 좋지 않은 신호다. CI 시스템을 갖추고 있다는 것은 그 팀이 자동화에 대한 믿음을 가지고 있다는 의미이며, 이는 매우 좋은 신호가 될 수 있다.
어떤 팀에게 이 질문은 지속적 배포(CD)에 대한 토론으로 이어지게 한다. 지속적 배포는 지속적 통합과 관련은 있지만 다른 개념이다. 웹 개발자 직군이라면 나는 적어도 CD에 대해 들어봤길 기대한다. 그리고 건강한 개발팀은 CD를 시스템에 부분적으로라도 적용하려고 시도한다.
이어질 수 있는 질문:
- 당신의 팀은 CI가 실패했다는 알림을 받으면 오류를 수정하기까지 보통 얼마나 걸립니까?
- 구축된 CI 시스템에서 좋은 점 / 안 좋은 점은 무엇입니까?
- CI가 실행되는 데 시간이 얼마나 걸립니까? 더 빠르게 만들 수 있습니까?
6. 어떤 지표를 측정합니까?
이 질문은 정답이 없으며, 그 팀이 소프트웨어의 성능을 측정하기 위한 노력을 하고 있는지 파악하기 위한 것이다. 웹 개발팀은 보통 서버 응답 시간이나 요청 처리량, 사용자 수, 클라이언트 사이드의 반응성 등의 성능 지수에 대한 답변에 치중하는 경향이 있다. 하지만 이와 관련된 토론은 서로 다른 언어를 사용하는 사용자의 수, 브라우저 오류, 캐시 히트/미스 비율, 그리고 무수히 많은 다른 주제들로 이어질 수 있다. 만약 팀이 지표 측정에 시간을 들이고 있지 않다면, 이는 그들이 데이터에 기반을 둔 결정을 내리지 않음을 가리킨다. 나는 실제로 측정된 진짜 데이터를 기반으로 성능을 판단하는 팀에 좋은 점수를 매긴다. 하지만 이는 성능 측정뿐 아니라 다른 많은 것들에도 적용될 수 있다.
만약 면접관이 이 질문과 관련된 많은 대답을 할 수 있다면 그 팀은 높은 수준을 가지고 있다는 좋은 신호로 볼 수 있다. 만약 그들이 왜 굳이 그런 지표를 측정해야 하는지 모르겠다고 말한다면, 부정적인 신호로 보면 된다.
다시 도그마에 대한 법칙이 여기에서 적용된다. 그 팀이 굳이 가치 있고 활용 가능한 정보를 제공하지 않는 데이터를 측정하고 있으면서도 당신에게 만족할 만한 대답을 주지 못한다면, 그것은 경고 신호일 수 있다.
이어질 수 있는 질문:
7. 어떻게 버그를 찾고 수정합니까?
좋은 팀은 보통 전용 테스터를 가지고 있으며 개발자는 서비스의 품질에 공을 들인다. 진짜로 수준 높은 팀은 놀랄 만한 테스트 자동화를 갖추고 있다. 어떤 팀은 전용 테스터나 테스트 자동화를 갖추기에는 너무 작지만 그게 나쁜 팀이라는 의미는 아니다. 나는 그 팀이 가진 프로세스가 어떤지 확인하기 위해 이 질문을 한다. 개발자들이 너무 바빠서 다른 일을 할 수 없을 정도인가? 버그를 찾고 우선순위를 매기기 위한 제대로 된 프로세스를 가지고 있는가? 사용자에게 버그를 찾게 놔두고 있는 건 아닌가? 라는 질문에 답을 얻기 위해서다.
이어질 수 있는 질문:
- 버그 수정 우선순위를 어떻게 매깁니까?
- 어떤 버그 트래킹 도구를 사용합니까? (그 도구는 어떤 점에서 마음에 들지 않습니까?)
- 버그 트래킹에 Excel을 사용합니까? (Nooooo~~!)
- 현재 버그 트래킹 도구에는 몇 개의 버그가 있습니까?
- 버그 수정에 얼마나 걸립니까? (최소/최대/일반적으로)
8. 협업 도구로 무엇을 사용합니까?
내 경험상 높은 효율은 가진 팀은 다양한 협업 도구를 사용한다. 그들은 주로 협업을 위해 채팅 서비스(Slack, IRC, HipChat, Jabber)와 코드 리뷰 서비스(Gerrit, GitHub, GitLab, Review Board)를 사용한다. 물론, 유서 깊은 서비스라고 할 수 있는 Email도 사용한다. 나는 이 질문을 통해 개발자들이 서로 하는 일을 알고 있는지 알아보려 한다. 물론 내가 여기서 말하는 ‘안다’의 기준은 일반적인 의미의 ‘안다’이며 서로를 아주 자세하게 속속들이 알고 있다는 의미는 아니다. 또 협업 도구를 잘 활용하고 있는지도 확인한다. 가장 간단한 예는 자동 빌드 시스템에서 실패가 발생했을 때의 이메일 자동 발송 여부 같은 것이다. 그리고 웹 개발팀이라면 시스템에서 심각한 오류가 발생했을 때, 일정 수준 이상의 네트워크 처리량이 발생했을 때 채팅방에 자동으로 알림이 오는 것 같은 사례가 있을 수 있다.
9. 어떤 프레임워크를 사용합니까?
프레임워크에 대한 나의 취향은 2가지로 나뉜다:
- 나는 현대적인 것을 좋아한다.
- 나는 새로운 것을 좋아한다.
어떤 팀이 Motif로 AIX 데스크톱 앱을 만들고 있다면 나는 거기에 흥미를 느끼지 못할 것이다. 하지만 당신은 아닐 수 있다. 이건 무척 개인적인 차이라서 이 주제에는 당신이 가진 취향에 대한 확실한 이해를 바탕으로 접근해야 한다.
당신이 가진 프레임워크에 대한 취향에는 상관없이, 그 팀이 왜 그 프레임워크를 선택했는지 이해하는 것이 중요하다. 시대를 너무 앞서간 기술을 사용하고 있는가? 그들은 프레임워크를 마치 속옷을 갈아입듯이 바꾸지는 않는가? 그들의 코드가 매달 바뀌는 프레임워크로 인해 산산조각이 나 있지는 않은가? 너무 오래된 프레임워크를 버리지 못하고 있는 건 아닌가?
왜라는 관점에서, 나는 얼마나 많은 개발자가 그들이 사용할 기술을 결정하는 데 관여하고 있는지를 이해하려 한다. 관리자들이 기술 결정 권한을 독점하고 있는가? 관리자들이 개발자들에게 결정을 양보하고 있는가? 이 주제에 대한 답을 확실히 이끌어내기 위해 나는 보통 이런 질문을 한다. “프레임워크 X를 어떻게 도입하게 되었나요?“. 만약 개발자들이 답을 하지 못한다면 나쁜 신호이거나, 아니면 그들이 그 회사에 온 지 얼마 되지 않아서 잘 모르는 것일 수도 있다.
나는 개발팀이 그들이 사용하는 오픈소스에 직접 참여(contribute)하는 것을 좋아한다. 이는 그들이 그저 단순히 코드를 사용하기만 하는 것이 아니라 참여를 할 수 있을 만큼 충분히 잘 알고 있다는 말이기 때문이다. 이런 활동을 하는 사람들이 내가 함께 일하고 싶은 사람들이다. 만약 그 회사가 개발자들의 오픈소스 활동을 적극적으로 지원한다면 더욱 좋다. 왜냐하면, 그 회사는 오픈소스 진영의 일부가 된다는 것의 의미를 잘 이해하고 있다는 말이기 때문이다.
만약 그 팀이 개발에 도움을 줄 수 있는 도구가 이미 있는데도 새로운 도구를 처음부터 새로 만들고 있다면, 나는 걱정을 할 것이다. 물론 여기에는 예외가 있긴 하다. 예를 들어 Facebook은 도구를 직접 만들어서 사용해오고 있었다. 나는 거기에는 토를 달지 않았으며, 앞으로도 그럴 것이다.
10. 함께 작업해볼 수 있습니까?
만약 그 팀과 일하는 형태가 어떤 것인지 확실히 알고 싶다면, 실제로 함께 일해보길 바란다. 개인적으로 나는 이런 시도를 해 본 적은 없지만, 내 친구는 해 본 적이 있다. 나는 이게 아주 멋진 아이디어라고 본다. 만약 그 팀에 대한 모든 것을 알 수 있길 원한다면, 그 회사에 가서 반나절만 함께 일해보길 바란다. 함께 일해보기 위해 기밀유지 서약서에 사인해야 할 수도 있다. 만약 그 팀이 당신의 제안을 기꺼이 수용한다면 매우 좋은 신호로 볼 수 있다고 생각한다.
아마 이런 시도를 위해서는 관리자나 경영진의 누군가와 약속을 잡아야 할 것이다. 그래서 이 질문은 개발자들의 반응을 얻어내는 데 더 초점이 맞춰져 있다. 그들은 아마 이 아이디어를 들으면 관리자와 함께해야 한다는 생각에 진저리를 칠 것이다.
11. 다음 작업 마감은 언제입니까?
이 질문은 그 회사가 실제로 적용하고 있는 개발 프로세스에 대해 당신에게 더 많은 것을 알려주기 위해 고안되었다. 이 질문 자체로서는 그렇게 많은 정보를 얻을 수 없지만, 여기에 아래의 질문들을 추가한다면 많은 흥미로운 사실을 알 수 있게 된다.
- 누가 마감 기한을 결정합니까?
- 저번 마감 기한은 지켰습니까? 만약 그러지 못했다면, 이유는 무엇입니까?
높은 수준의 팀은 마감 시간을 지키는 것에 모두 동의한다. 제대로 지켜지지 않는 마감 기한은 그 팀이 제대로 굴러가고 있지 않다는 신호다. 또는 최소한 그 개발자는 일정을 결정하는 회의에 참석하지도 않았다는 의미다
12. 새로운 개발 환경을 세팅하는데 얼마나 걸립니까?
이 질문은 그 회사가 개발자 경험을 위해 얼마나 많은 노력을 하고 있는지를 측정할 수 있게 도와준다. 개발자가 컴퓨터를 세팅해서 코딩을 시작하기까지 몇 시간, 며칠, 몇 주가 걸리는가? 그 과정은 자동화가 되어 있는가 아니면 수동으로 직접 해야 하는가? 이는 그 팀이 소프트웨어 개발에 직접 관련되어 있지는 않지만 도움을 주는 “보조 활동”에 얼마나 능숙한지를 당신에게 말해줄 것이다. 그리고 그런 활동에 얼마나 큰 가치를 두고 있는지도 알려줄 것이다.
어떤 회사들은 개발 환경 설정 프로세스가 너무나 빨라서 개발자들이 입사 첫날에 코딩을 시작할 수 있다는 사실에 자부심을 가지고 있기도 하다. 이는 그 회사가 개발자들에게 깔끔한 개발 경험을 제공한다는 사실을 무척 중요하게 여기고 있다는 말이다.
관리자를 위한 질문
1. 언제 마지막으로 코드를 작성해 보셨습니까?
나는 관리자가 탄탄한 기술 기반이 있길 바란다. MBA 학위를 가진 내 친구들을 나무라는 것은 아니지만, 내가 정말로 좋아하는 관리자들은 내가 하는 일을 해 본 경험이 있는 사람들이라는 사실을 알 수 있었다.
2. 어떻게 관리자가 되었습니까?
나는 억지로 관리자가 된 사람보다는 그 일을 좋아하고 잘해서 관리자가 되기로 스스로 선택한 사람을 더 좋아한다. 또 그들의 팀을 지원하는 일에 집중하는 관리자를 더 좋아한다. 내가 가장 좋아하는 관리자는 팀원들의 삶이 더 나아지기 위해 노력하는 사람이지 관리 그 자체에만 신경을 쓰는 사람이 아니다. 내가 좋아하는 관리자는 자신이 팀의 조력자이며 보호자라고 생각한다. 그들은 봉사하는 태도를 보이고 있으며 자신의 가장 중요한 일은 팀원들이 하는 일이 더 나아지게 만드는 것으로 생각한다.
3. 팀원들은 자신이 오늘 무엇을 해야 하는지 어떻게 확인합니까?
이 질문을 개발자에게 했기 때문에 관리자에게도 같은 질문을 해서 답을 비교해 본다. 서로의 답이 일치하지 않는다면 뭔가 잘못된 것이 있다는 의미다. 나는 이런 종류의 불일치를 바로잡는 것은 관리자의 역할이라고 믿는다.
4. 지금 당신의 팀이 가지고 있는 가장 큰 과제는 무엇입니까?
관리자들은 보통 인원 부족이 가장 큰 문제라고들 한다. 이는 흔하고 뻔한 대답(결국에는 부족한 사람을 다 고용하게 된다)이기 때문에, 그럼 나는 두 번째로 가장 큰 과제는 무엇이냐고 물어본다. 이 질문을 통해 일정이 지연되고 있거나, 품질 관리에 문제가 있거나, 팀원들 사이의 인간관계에 문제가 있다거나 하는 경고 신호를 찾는다. 어떤 팀이든 문제를 가지고 있다. 그러기에 당신이 받게 될 답변은 다음과 같은 여러 가지 정황에 영향을 받는다:
- 관리자의 문제에 대한 인지 여부
- 관리자가 당신에게 솔직히 대하려는 의지 정도의 차이
- 그 팀의 문제의 심각성의 정도
5. 개인 성과 측정은 어떻게 합니까?
뛰어난 매니저는 이를 위한 좋은 기술을 가지고 있다. 가장 훌륭한 매니저는 팀원들의 개인 성과를 측정할 때, 팀 전체로부터 조심스럽게 피드백을 수집한다. 나쁜 매니저는 팀원들의 얘기는 듣지 않고 개인적인 관점에서 판단을 내린다.
6. 공식적인 성과 리뷰를 가집니까?
나는 팀원들이 성장할 수 있도록 피드백을 주는 일을 중요하게 생각하는 매니저와 함께 일하는 것을 좋아한다. 성과 리뷰는 고통스러울 수도 있고 긍정적인 경험이 될 수도 있다. 내 개인적인 경험에 의하면, 사람 대부분은 그것을 끔찍한 일로 여긴다. 정말로 훌륭한 관리자는 이 점을 잘 알고 있다. 그리고 좋은 방법을 사용해서 개인 성과 리뷰가 팀원에게 좋은 인상을 남길 수 있도록 하며, 자신과 함께 일하고 싶어지게 만들 것이다.
이어질 수 있는 질문:
- 개인 성과 향상을 위해 도움을 줬던 일에 관해서 얘기해 주실 수 있을까요?
- 리뷰를 하는 동안 사람들에게 어떤 식으로 조언합니까?
7. 해마다 연봉을 올려주고 있습니까?
나는 내가 회사에 이바지를 한 만큼 보상을 받을 수 있는지 알고 싶다. 이 질문에 긍정적인 답을 주는 회사라면, 나는 형평성에 대해 질문한다. 나에게 스톡옵션을 줄 것입니까? 매년 스톡옵션을 더 지급해 줄 것입니까?
어떤 개발자들은 이런 금전적인 질문을 하는 것을 불편해한다. 그러지 마라. 일반적으로 개발자들은 이 주제에 대한 생각을 너무 적게 한다. 하지만 관리자들은 이런 종류의 대화를 일하는 내내 한다. 이런 질문들은 관리자에게는 불편한 것이 아니어야 한다.
- 임금 인상을 위한 예산은 어떻게 잡습니까?
- 지난해 당신의 팀의 연봉 인상 금액의 중간값은 얼마입니까? (또는 인상 비율)
- 1년 후 저는 얼만큼의 연봉 인상을 기대할 수 있습니까? 최고와 최악의 경우는 어떻게 됩니까?
나는 이 질문을 연봉 인상에 대한 확실한 보장을 받기 위해서 하는 것이 아니다. 대신 그 회사가 어떻게 연봉을 관리하는지를 이해하기 위해서 한다. 이 회사에서는 연봉 인상을 위해 내 방식대로 밀고 나가야 할 것인가? 아니면 이미 표준화된 프로세스가 정립되어 있는가?
8. 회사의 복지를 설명해주는 자료를 가져갈 수 있을까요?
나는 사람 대부분이 이 질문은 알고 있다고 생각하지만 완벽함을 위해 언급할 가치가 있을 것 같다. 회사 대부분은 그들의 복지를 소개해주는 한 뭉치의 서류를 건네주거나 웹 사이트를 소개해 줄 것이다. 복지 혜택에 대해 알고 있는 것은 중요하다. 왜냐하면, 당신이 얻는 보상에서 무척 큰 부분을 차지하기 때문이다. 이 질문은 미국에서만 해당하는 사항일지도 모른다. 나는 다른 나라에서는 기업에서 제공되는 의료보험이 어떻게 작동하는지 잘 모른다.3
9. 당신은 직원들의 순위를 매깁니까?
어떤 회사들은 급여 인상과 보너스를 직원들의 순위를 매겨서 결정한다. 직원들의 순위로 정렬된 긴 목록을 일정 비율로 “좋음”, “평균”, “나쁨”으로 잘라버린 후 결정하는 식이다.
나는 저런 방식을 좋아하는 개발자를 만나 본 적이 없다. 큰 회사에서는 이런 방식을 일반적으로 사용한다. 저 방법은 당신에게 함께 일하는 동료가 언젠가는 보수를 위해 경쟁해야 할 상대라는 인식을 심어줘서 직원 사이의 소통에 문제가 생기게 만들 수 있다.
면접을 보는 회사가 저런 정책을 시행하고 있다고 해서 그 회사가 일하기에 끔찍한 곳이라고 판단해야 한다는 의미는 아니다. 저런 회사에서는 다른 생각을 하는 멋진 사람들이 조금씩 있게 마련이다. 면접관들에게 저런 정책을 어떻게 생각하느냐고 물어보라. 어떤 관리자는 꽤 솔직하게 회사의 시스템에 대한 비호감을 드러내기도 할 것이다. 그리고 몇몇은 자신의 팀을 위해 어떻게 시스템을 잘 활용하는지 알려주기도 한다. 만약 그런 관리자를 만난다면 직원들의 순위를 매기는 시스템은 눈감아 줄 수도 있을 것이다.
그리고 모든 사람이 저런 시스템을 싫어하지 않는다는 사실을 명심해야 한다. 내가 어떤 종류의 사람들을 만나지 못했다고 해서 아예 그런 사람이 없는 것은 아니기 때문이다.
이어질 수 있는 질문:
- 당신은 정말로 “X%“의 직원들이 “나쁨”이라고 생각합니까? 그들은 당신의 채용 프로세스에 대해서 뭐라고 얘기하나요? (이는 다소 대담한 질문이다. 신중히 하길 바란다)
- 성과가 높은 사람을 가려내기 위해 상대적인 평가를 진행합니까?
- 직원들의 순위를 매기기 위해 어떤 지표를 측정합니까?
- 측정한 지표들의 정확도는 어떻게 판단합니까?
- 이 지표들로 실제로 성과가 높은 직원들을 파악했는지는 어떻게 보장합니까?
10. 주기적인 팀 회고를 진행합니까?
만약 한다면, 어떤 방식입니까? 팀원들에게 얼마나 자주 피드백을 받습니까? 언제 마지막으로 직원들의 피드백을 바탕으로 당신의 관리 방식을 조정했습니까?
이런 질문들은 관리자가 직원들에게 얼마나 민감하게 반응하는지, 그리고 직원들은 얼마나 피드백을 잘 전달하면서 관리자와 소통하는지를 알 수 있도록 해준다.
회고가 이루어지지 않는다면 팀에게 있는 문제를 파악하기 어려우며 문제 해결을 위해 홀로 노력해야 한다. 그리고 만약 관리자가 팀의 발전을 위해 피드백을 받는 것을 좋아하지 않는다면, 그 팀은 아마도 문제가 있어도 모른 척하거나 피드백을 주는 것에 부담을 느끼는 분위기가 조성되어 있을 것이다.
경영진을 위한 질문
면접을 볼 때 항상 회사의 고위층과 얘기를 나눌 수 있는 것은 아니지만, 특히 큰 회사라면 더욱, 그래도 만약 그런 기회가 주어진다면 나는 그것을 그 회사의 재정적 생존력을 판단할 기회로 삼는다. 나는 그런 판단을 할 자격이 있는 사람은 아니지만, 면접을 통해 파악할 수도 있는 명백한 문제들이 있다. 그리고 나는 회사의 수직 문화가 어떠한지 알고 싶어한다. 왜냐하면, 그 정보는 회사가 개발자를 어떻게 평가하는지 알 수 있기 때문이다. 그것이 긍정적인 방향이든, 부정적인 방향이든 말이다.
1. 어떻게 투자를 받았습니까?
나는 회사를 지탱하는 자금의 실체를 파악하려고 한다. 자금을 조달한 곳이 벤처캐피털인지, 사모펀드인지, 주식인지, 회사의 이윤에 의한 것인지 알고 싶기 때문이다. 인터뷰 전에 쉽게 찾아볼 수 있는 내용이기도 하지만, 회사 고위층은 내가 구글이나 CrunchBase를 통해서는 알 수 없는 내용을 알려줄 수 있다.
2. 수익이 나고 있습니까?
만약 그렇다면, 문제없다! 만약 아니라면, “수익을 내기 위한 어떤 계획을 하고 있습니까?”라는 질문을 할 수 있을 것이다. 어떤 스타트업들은 수익을 내기 위한 계획을 하는 반면, 어떤 곳은 합병이나 IPO를 할 방법을 찾고 있기도 하다.
이어질 수 있는 주제:
- 지난 몇 분기/년 동안의 수익 증가 추이
- 수익에 위험이 될 수 있는 경쟁자, 가격, 적자
- 추가 자금을 조달하기 전까지 회사가 운영될 수 있는 기간
3. 외주에 대해서는 어떻게 생각합니까?
나는 내가 지원하는 직무가 장차 외주화될 수 있는지, 또는 외주 개발자를 관리하는 직무로 변경될 가능성이 있는지 알고 싶다. 여기서 말하는 것은 해외 외주만이 아니며 계약자도 포함한다.
4. 기업 문화에 대해서 알려주십시오.
이 질문은 경영진의 관점과 개발자의 관점의 차이를 조정하기 위해 사용하는 또 다른 방법이다. 관점의 차이는 문제의 신호가 될 수 있기 때문이다. 만약 경영진과 개발자가 같은 대답을 한다면 상하 소통이 잘 되고 있다고 볼 수 있다. 나는 고위층과 말단 직원들 사이에 접점이 있는지 알고 싶다. 그리고 경영진이 미래에 대한 비전을 잘 공유하고 있는지도 알고 싶다. 내가 가장 일하고 싶은 회사는 경영진과 직원들이 뚜렷한 비전을 공유하고 있는 곳이다.
5. 이 회사의 성공에 대해 어떤 확신이 있습니까?
이 질문을 통해서는 영업을 위한 수사가 아닌 진짜 근거를 얻으려 한다. 만약 경영진이 수익, 시장 규모, 자본과 관련된 실제 수치를 들려준다면 이는 좋은 신호다. 또 이 수치를 다른 소스를 통해 검증할 수 있다면 훨씬 더 좋은 신호다. 하지만 그 수치들이 매우 좋지 못할 수도 있다.
6. 보고 구조에 대해서 알려주십시오.
나에게 가장 좋은 대답은 단순한 형태다. 간단한 조직도를 그리면서 보고 구조를 설명할 수 있다면 나는 만족한다. 개인적으로 선호하는 업무 형태는 구조적인 소통에 드는 비용이 적은 작고 민첩한 회사에서 일하는 것이다. 당신이 선호하는 형태는 다를 수 있다. 그것은 그대로 괜찮으며, 이 질문은 회사에 대해 정보에 기반을 둔 판단을 내리는 데 필요한 정보를 얻는 데 도움을 주기 위해서 고안되었다.
결론
면접은 양방향이다. 합격이라는 좋은 결과가 있을 수 있으니 면접을 볼 때 회사에 대한 제대로 된 판단을 내리기 위한 모든 정보를 얻도록 하자. 행운을 빈다!