A developer's guide to interviewing : 개발자를 위한 질문

출처 : https://blog.rhostem.com/posts/2019-01-05-developer-guide-for-interview

[번역] 개발자를 위한 면접 지침

 

이 글은 A developer’s guide to interviewing의 번역입니다. 기본적으로 구직자로서 면접관을 대상으로 할 수 있는 질문들을 정리한 글입니다. 글쓴이가 거주하고 있는 것으로 보이는 미국과 한국의 기업 환경에는 차이가 있기에 조심스럽게 해야 할 질문도 있겠습니다. 하지만 경력이 쌓이면 자연스럽게 면접관의 역할을 하게 될 것이므로 개발자로서, 관리자로서, 그리고 경영진으로서 가져야 할 업무 능력, 지식, 가치관에 대한 조언이라 생각하고 읽어도 좋을 것 같습니다.

 

구직을 위해 면접을 본 적이 있다면, 면접관으로부터 테이블 너머에서 “더 궁금한 것이 있으신가요?”라는 질문을 받은 적이 있을 것이다. 당신이 만약 “음, 아니오. 없습니다”라고 대답했다면 면접은 단방향이라는 관점을 가지고 있을 가능성이 크다.

 

구직자로서의 당신은 결과를 만드는 일에 집중하는 것이 당연하다. 하지만 면접은 단방향이 아니다. 회사가 당신을 면접하는 일에 집중하는 것처럼 당신도 회사를 면접하는 일에 집중해야 한다.

 

그런데 무슨 질문을 해야 하나?

 

이직을 준비하는 많은 개발자는 나에게 이 질문을 한다. 나는 지난 15년간 7개의 회사에서 일했고(2번의 인턴쉽과 스타트업에서의 6개월 포함) 그동안 많은 사람과 면접을 진행했다. 그리고 다른 이들에게 도움이 되길 바라는 마음에 지금까지 면접에서 했던 질문들을 정리하기로 했다.

 

나는 이 글이 계속 업데이트되길 바란다. 만약 당신이 제안하고 싶은 내용이 있다면 트위터를 통해 알려주길 바란다. 모두에게 도움이 되기 위해 기꺼이 함께할 것이다.

 

누구와 얘기를 하게 될까?

면접을 보는 동안 만나게 되는 사람들의 역할은 보통 세 종류로 나뉜다. 회사의 규모에 따라 한 사람이 세 가지 역할을 모두 할 수도 있고, 많은 사람이 그 역할을 나눠 맡을 수도 있다.

• 개발자
• 관리자 (기술 책임, 중간 관리자, 기술 감독)
• 경영진 (VP, CTO, CEO, 부서장)

나는 저들에게 할 수 있는 서로 다른 질문이 있으며, 이 글에서 하나씩 언급할 것이다. 그리고 답변들을 비교하기 위해 때로는 서로 다른 대상에게 같은 질문을 하기도 한다는 사실을 알고 있었으면 한다.

 

이 글은 제법 길다. 쭉 읽어낼 수 있는 글이라기보다는 참고서에 가깝다. 만약 내가 오늘 면접이 있다면 이 글을 가져가서 조심스럽게 면접을 진행하는 동안 (조심스럽게) 참조할 것이다.

 

질문 대부분은 “옳고” “그른” 대답이 없다. 질문들은 당신이 회사의 문화, 업무 프로세스, 그리고 조직에 대해 파악할 수 있도록 도와줄 것이다. 그리고 면접을 보는 동안 당신의 머리가 멍해졌을 때 대화를 이어나가기 위한 도구로서도 요긴하게 쓰일 수 있다.

 

예를 들어, 나는 면접을 시작할 때 면접관들에게 몇 가지 질문을 해도 되느냐고 물어보곤 한다. 이는 면접관들이 일정에 맞게 면접을 진행하는 데 도움을 줄 것이다. 보통은 면접이 끝날 때 질문을 할 기회를 주기 때문에 질문을 하고 싶다는 당신의 의도를 면접관들에게 일찍 전달해야 한다. 하나의 질문이 끝나고 나면 멈춘 후 다른 질문을 계속해도 되는지, 그들이 시간을 얼마나 더 가졌는지 물어봐야 한다.

 

1. 오늘 해야 할 일을 어떻게 파악하십니까?

이 질문의 목적은 업무 프로세스가 제대로 구축되어 있는지 확인하기 위한 것이다. 나는 2~3명의 개발자에게 질문의 답변을 들었으면 한다. 운영진들이 특정 프로세스를 따른다고 말하더라도 개발자들이 아무런 얘기를 하지 않는다면 그건 부정적인 신호다. 개발자들이 서로 다른 얘기를 한다면, 그 또한 부정적인 신호로 볼 수 있다.

 

높은 수준의 팀에서는 이 질문에 대해 일관적인 대답을 들을 수 있다. 그것은 모든 개발자가 업무 프로세스를 잘 알고 있으며, 프로세스가 단순해서 개발자들에게 부담되지 않고 도움이 되고 있음을 의미한다.

 

좋은 대답의 예: “우리는 새로운 기능과 버그를 고치기 위한 (몇) 주 단위의 스프린트를 진행하며 매일 서로에게 했던 일을 공유합니다. 우리와 함께 일하는 제품 관리자는 고객 대응에 임하면서 개발자들에게 새 기능과 버그 수정의 우선순위를 잘 조정해줍니다.”

 

나쁜 대답의 예: “회사에 오면 어떤 문제가 터졌는지 살펴봅니다. 거의 매일 비상사태입니다.”

 

내가 “스크럼”이나 다른 특정한 방법론을 언급한 것이 아님을 분명히 했으면 좋겠다. 나는 회사가 사용하는 개발 프로세스의 이름에는 관심이 없으며 그들이 매일매일 “어떻게 업무를 진행하는지”를 더 중요하게 본다.

 

2. 버전 관리 도구로는 무엇을 사용합니까?

좋은 도구의 사용은 좋은 팀의 지표가 된다. 어떤 팀이 구시대적인 버전 관리 도구를 사용하고 있다면, 아마 그것 말고도 철 지난 도구를 많이 사용하고 있을 것이다. 게다가 그들은 좋은 도구를 사용함으로써 얻는 효율을 그다지 중요하게 여기지 않을 것이다.

 

이 질문 다음으로는 업무 진행 방식에 대해 질문을 하면 좋다. “분기점(branch)을 사용하나요?” “재배치(rebase)와 병합(merge) 중 무엇을 선호하십니까?” 이런 질문은 그들이 사용하는 도구에 얼마나 전문적인 지식을 가졌는지, 그리고 그들에게 무엇을 기대할 수 있는지를 알 수 있다. 예를 들어 그 회사에 가면 리누스 토르발즈1처럼 뛰어난 사람을 만날 수 있다는 확신을 얻을 수도 있지만, 오히려 내가 “지역 Git 전문가” 역할을 하게 될 것 같다는 예감을 하게 될 수도 있다.

 

이 질문은 개발 도구에 대한 전반적인 토론을 시작할 수 있도록 있도록 하며, 종종 당신에게 좋은 통찰을 가져다줄 것이다.

 

3. 여기서 일하면 어떤 점이 좋습니까?

• 확신에 찬 대답: 내가 하는 일에서 아주 큰 만족감을 느낍니다.
• 확신에 찬 대답: 우리는 일에서 아주 큰 재미를 느끼고 있습니다.
• 확신에 찬 대답: 나는 똑똑하고 친절한 우리 동료들과 일하는 것이 무척 좋습니다.
• 확신에 찬 대답: 관리 부서는 개발자들을 존중합니다.

긍정적 대답은 많을수록 좋다. 면접을 보는 회사에 좋은 점수를 주기 위해 위에 있는 모든 대답을 들어야 할 필요는 없다. 어떤 사람들은 선천적으로 자랑을 잘하지 못한다는 사실을 염두에 둬야 한다. 그러니 이 질문에서 아주 긍정적인 대답을 듣지 못하더라도 괜찮다.

 

하지만 다음에 오는 대답을 들으면서 확신에 찬 대답을 조금밖에 듣지 못한다면, 고민이 될 것이다.

 

• 확신 없는 대답: 월급은 잘 줍니다.
• 확신 없는 대답: 열심히 일할 필요가 없습니다.
• 확신 없는 대답: 배포를 위한 압박감이 그리 크지 않습니다.
• 확신 없는 대답: 내가 큰 실수를 해도 별문제가 되지 않습니다.
• 확신 없는 대답: … (침묵)

꾸며낸 말이 결코 아니다. 나는 실제 면접에서 저런 대답을 들었던 경험이 있다.

 

확신 없는 대답을 하나 들었다고 해서 바로 그 회사가 나쁘다고 판단하지는 않는다. 하지만 세 번째 질문에 대한 답이 모두 저런 식이라면, 나는 보통 다른 곳을 알아본다.

 

4. 유닛 테스트를 작성하십니까?

어떤 팀을 유닛 테스트 활용 사례를 바탕으로 평가할 때는 신중해야 한다. 유닛 테스팅에 대한 질문을 했을 때 기분이 좋아 보인다면 그것은 일반적으로 좋은 신호다. 그에 반해 왜 유닛 테스트를 작성해야 하는지, 유닛 테스트의 결점은 무엇인지에 대해 설명하지 못한다면 눈먼 양 도그마(dogma, 독단적인 신념 또는 가치관) 에 빠져 있다는 징후로 볼 수 있다. “시간이 없다”는 등의 변명을 들며 테스트를 작성하지 않는다고 말한다면, 나는 좋지 않은 신호로 받아들인다.

 

5. 지속적 통합(CI) 프로세스를 갖추고 있습니까?

내가 아는 최고의 개발팀은 Jenkins, Travis, 그리고 BuildBot 같은 도구를 사용한다. 그 팀이 CI 도구를 사용하고 있지 않다면 관련 개념을 알고 있는지 알아본다. 만약 모른다면 이건 내 경험상 좋지 않은 신호다. CI 시스템을 갖추고 있다는 것은 그 팀이 자동화에 대한 믿음을 가지고 있다는 의미이며, 이는 매우 좋은 신호가 될 수 있다.

 

어떤 팀에게 이 질문은 지속적 배포(CD)에 대한 토론으로 이어지게 한다. 지속적 배포는 지속적 통합과 관련은 있지만 다른 개념이다. 웹 개발자 직군이라면 나는 적어도 CD에 대해 들어봤길 기대한다. 그리고 건강한 개발팀은 CD를 시스템에 부분적으로라도 적용하려고 시도한다.

 

이어질 수 있는 질문:

 

• 당신의 팀은 CI가 실패했다는 알림을 받으면 오류를 수정하기까지 보통 얼마나 걸립니까?
• 구축된 CI 시스템에서 좋은 점 / 안 좋은 점은 무엇입니까?
• CI가 실행되는 데 시간이 얼마나 걸립니까? 더 빠르게 만들 수 있습니까?
  
  

6. 어떤 지표를 측정합니까?

이 질문은 정답이 없으며, 그 팀이 소프트웨어의 성능을 측정하기 위한 노력을 하고 있는지 파악하기 위한 것이다. 웹 개발팀은 보통 서버 응답 시간이나 요청 처리량, 사용자 수, 클라이언트 사이드의 반응성 등의 성능 지수에 대한 답변에 치중하는 경향이 있다. 하지만 이와 관련된 토론은 서로 다른 언어를 사용하는 사용자의 수, 브라우저 오류, 캐시 히트/미스 비율, 그리고 무수히 많은 다른 주제들로 이어질 수 있다. 만약 팀이 지표 측정에 시간을 들이고 있지 않다면, 이는 그들이 데이터에 기반을 둔 결정을 내리지 않음을 가리킨다. 나는 실제로 측정된 진짜 데이터를 기반으로 성능을 판단하는 팀에 좋은 점수를 매긴다. 하지만 이는 성능 측정뿐 아니라 다른 많은 것들에도 적용될 수 있다.

 

만약 면접관이 이 질문과 관련된 많은 대답을 할 수 있다면 그 팀은 높은 수준을 가지고 있다는 좋은 신호로 볼 수 있다. 만약 그들이 왜 굳이 그런 지표를 측정해야 하는지 모르겠다고 말한다면, 부정적인 신호로 보면 된다.

 

다시 도그마에 대한 법칙이 여기에서 적용된다. 그 팀이 굳이 가치 있고 활용 가능한 정보를 제공하지 않는 데이터를 측정하고 있으면서도 당신에게 만족할 만한 대답을 주지 못한다면, 그것은 경고 신호일 수 있다.

 

이어질 수 있는 질문:

 

• 제품의 가장 중요한 지표는 무엇입니까?
• 성능 측정 시스템으로 무엇을 사용합니까? (예, MixPanel, statsd, 기타)
  
  

7. 어떻게 버그를 찾고 수정합니까?

좋은 팀은 보통 전용 테스터를 가지고 있으며 개발자는 서비스의 품질에 공을 들인다. 진짜로 수준 높은 팀은 놀랄 만한 테스트 자동화를 갖추고 있다. 어떤 팀은 전용 테스터나 테스트 자동화를 갖추기에는 너무 작지만 그게 나쁜 팀이라는 의미는 아니다. 나는 그 팀이 가진 프로세스가 어떤지 확인하기 위해 이 질문을 한다. 개발자들이 너무 바빠서 다른 일을 할 수 없을 정도인가? 버그를 찾고 우선순위를 매기기 위한 제대로 된 프로세스를 가지고 있는가? 사용자에게 버그를 찾게 놔두고 있는 건 아닌가? 라는 질문에 답을 얻기 위해서다.

 

이어질 수 있는 질문:

 

• 버그 수정 우선순위를 어떻게 매깁니까?
• 어떤 버그 트래킹 도구를 사용합니까? (그 도구는 어떤 점에서 마음에 들지 않습니까?)
• 버그 트래킹에 Excel을 사용합니까? (Nooooo~~!)
• 현재 버그 트래킹 도구에는 몇 개의 버그가 있습니까?
• 버그 수정에 얼마나 걸립니까? (최소/최대/일반적으로)
  
  

8. 협업 도구로 무엇을 사용합니까?

내 경험상 높은 효율은 가진 팀은 다양한 협업 도구를 사용한다. 그들은 주로 협업을 위해 채팅 서비스(Slack, IRC, HipChat, Jabber)와 코드 리뷰 서비스(Gerrit, GitHub, GitLab, Review Board)를 사용한다. 물론, 유서 깊은 서비스라고 할 수 있는 Email도 사용한다. 나는 이 질문을 통해 개발자들이 서로 하는 일을 알고 있는지 알아보려 한다. 물론 내가 여기서 말하는 ‘안다’의 기준은 일반적인 의미의 ‘안다’이며 서로를 아주 자세하게 속속들이 알고 있다는 의미는 아니다. 또 협업 도구를 잘 활용하고 있는지도 확인한다. 가장 간단한 예는 자동 빌드 시스템에서 실패가 발생했을 때의 이메일 자동 발송 여부 같은 것이다. 그리고 웹 개발팀이라면 시스템에서 심각한 오류가 발생했을 때, 일정 수준 이상의 네트워크 처리량이 발생했을 때 채팅방에 자동으로 알림이 오는 것 같은 사례가 있을 수 있다.

 

9. 어떤 프레임워크를 사용합니까?

프레임워크에 대한 나의 취향은 2가지로 나뉜다:

 

1. 나는 현대적인 것을 좋아한다.
2. 나는 새로운 것을 좋아한다.

어떤 팀이 Motif로 AIX 데스크톱 앱을 만들고 있다면 나는 거기에 흥미를 느끼지 못할 것이다. 하지만 당신은 아닐 수 있다. 이건 무척 개인적인 차이라서 이 주제에는 당신이 가진 취향에 대한 확실한 이해를 바탕으로 접근해야 한다.

 

당신이 가진 프레임워크에 대한 취향에는 상관없이, 그 팀이 왜 그 프레임워크를 선택했는지 이해하는 것이 중요하다. 시대를 너무 앞서간 기술을 사용하고 있는가? 그들은 프레임워크를 마치 속옷을 갈아입듯이 바꾸지는 않는가? 그들의 코드가 매달 바뀌는 프레임워크로 인해 산산조각이 나 있지는 않은가? 너무 오래된 프레임워크를 버리지 못하고 있는 건 아닌가?

 

왜라는 관점에서, 나는 얼마나 많은 개발자가 그들이 사용할 기술을 결정하는 데 관여하고 있는지를 이해하려 한다. 관리자들이 기술 결정 권한을 독점하고 있는가? 관리자들이 개발자들에게 결정을 양보하고 있는가? 이 주제에 대한 답을 확실히 이끌어내기 위해 나는 보통 이런 질문을 한다. “프레임워크 X를 어떻게 도입하게 되었나요?“. 만약 개발자들이 답을 하지 못한다면 나쁜 신호이거나, 아니면 그들이 그 회사에 온 지 얼마 되지 않아서 잘 모르는 것일 수도 있다.

 

나는 개발팀이 그들이 사용하는 오픈소스에 직접 참여(contribute)하는 것을 좋아한다. 이는 그들이 그저 단순히 코드를 사용하기만 하는 것이 아니라 참여를 할 수 있을 만큼 충분히 잘 알고 있다는 말이기 때문이다. 이런 활동을 하는 사람들이 내가 함께 일하고 싶은 사람들이다. 만약 그 회사가 개발자들의 오픈소스 활동을 적극적으로 지원한다면 더욱 좋다. 왜냐하면, 그 회사는 오픈소스 진영의 일부가 된다는 것의 의미를 잘 이해하고 있다는 말이기 때문이다.

 

만약 그 팀이 개발에 도움을 줄 수 있는 도구가 이미 있는데도 새로운 도구를 처음부터 새로 만들고 있다면, 나는 걱정을 할 것이다. 물론 여기에는 예외가 있긴 하다. 예를 들어 Facebook은 도구를 직접 만들어서 사용해오고 있었다. 나는 거기에는 토를 달지 않았으며, 앞으로도 그럴 것이다.

 

10. 함께 작업해볼 수 있습니까?

만약 그 팀과 일하는 형태가 어떤 것인지 확실히 알고 싶다면, 실제로 함께 일해보길 바란다. 개인적으로 나는 이런 시도를 해 본 적은 없지만, 내 친구는 해 본 적이 있다. 나는 이게 아주 멋진 아이디어라고 본다. 만약 그 팀에 대한 모든 것을 알 수 있길 원한다면, 그 회사에 가서 반나절만 함께 일해보길 바란다. 함께 일해보기 위해 기밀유지 서약서에 사인해야 할 수도 있다. 만약 그 팀이 당신의 제안을 기꺼이 수용한다면 매우 좋은 신호로 볼 수 있다고 생각한다.

 

아마 이런 시도를 위해서는 관리자나 경영진의 누군가와 약속을 잡아야 할 것이다. 그래서 이 질문은 개발자들의 반응을 얻어내는 데 더 초점이 맞춰져 있다. 그들은 아마 이 아이디어를 들으면 관리자와 함께해야 한다는 생각에 진저리를 칠 것이다.

 

11. 다음 작업 마감은 언제입니까?

이 질문은 그 회사가 실제로 적용하고 있는 개발 프로세스에 대해 당신에게 더 많은 것을 알려주기 위해 고안되었다. 이 질문 자체로서는 그렇게 많은 정보를 얻을 수 없지만, 여기에 아래의 질문들을 추가한다면 많은 흥미로운 사실을 알 수 있게 된다.

 

• 누가 마감 기한을 결정합니까?
• 저번 마감 기한은 지켰습니까? 만약 그러지 못했다면, 이유는 무엇입니까?

높은 수준의 팀은 마감 시간을 지키는 것에 모두 동의한다. 제대로 지켜지지 않는 마감 기한은 그 팀이 제대로 굴러가고 있지 않다는 신호다. 또는 최소한 그 개발자는 일정을 결정하는 회의에 참석하지도 않았다는 의미다

 

12. 새로운 개발 환경을 세팅하는데 얼마나 걸립니까?

이 질문은 그 회사가 개발자 경험을 위해 얼마나 많은 노력을 하고 있는지를 측정할 수 있게 도와준다. 개발자가 컴퓨터를 세팅해서 코딩을 시작하기까지 몇 시간, 며칠, 몇 주가 걸리는가? 그 과정은 자동화가 되어 있는가 아니면 수동으로 직접 해야 하는가? 이는 그 팀이 소프트웨어 개발에 직접 관련되어 있지는 않지만 도움을 주는 “보조 활동”에 얼마나 능숙한지를 당신에게 말해줄 것이다. 그리고 그런 활동에 얼마나 큰 가치를 두고 있는지도 알려줄 것이다.

어떤 회사들은 개발 환경 설정 프로세스가 너무나 빨라서 개발자들이 입사 첫날에 코딩을 시작할 수 있다는 사실에 자부심을 가지고 있기도 하다. 이는 그 회사가 개발자들에게 깔끔한 개발 경험을 제공한다는 사실을 무척 중요하게 여기고 있다는 말이다.