오늘은 코딩 인터뷰를 어떤 순서로 보는지, 고려해야 할 사항이 무엇인지에 대해서 이야기를 해 보려고 한다.
다른 것을 모두 갖추었다고 해도 인터뷰 볼 때 그래도 가장 중요한 코딩 실력이다. 여기서 잊지 말아야 하는 것은 이전 글에서 언급한 커뮤니케이션 스킬이다. 왜 그런지 하나씩 살펴보자.
Topcoder, ACM-ICPC 에서 나오는 문제가 인터뷰에서 나오지 않는다. 오히려 대회에서 수상 경력이 있다고 하더라도 인터뷰를 위한 코딩 연습을 게을리하면 떨어지기 쉽다. 인터뷰는 문제를 빨리 풀고, 잘 푸는 게 목적이 아니다. 코드를 가지고 동료와 효과적으로 커뮤니케이션을 하는지 보려고 하는 것이다. 인터뷰에서 보고자 하는 것은 회사에 와서 동료와 함께 얼마나 잘 협업하며 성과를 내는지를 보려고 하는 것이다. 회사에서 학교에서 하던 작은 프로젝트 규모의 프로젝트를 하는 게 아니라면 항상 동료와 함께 진행해야 한다. 따라서 동료들과 코드를 가지고 토론을 할 수 있는 능력이 있는지를 인터뷰에서 측정하려고 하는 것이다.
그럼 그 능력을 어떻게 인터뷰에서 보여줄 것인가?
다음의 순서대로 인터뷰 시간에 진행하면 조금 수월할 것 같다. 코딩 인터뷰 세션에 국한된 이야기이다. 설계, OOP 등의 인터뷰 세션은 이것과 조금 다르며, 다음에 이야기하려고 한다.
- 문제를 듣고, 생각을 먼저 정리하고, 바로 생각나는 간단한 솔루션을 이야기한다. 이건 정답은 아니다. 그런데 반드시 이 과정을 거쳐야 한다. 두 가지 이유가 있다. 첫 번째로 조용히 혼자서 생각하면 면접관은 내가 무슨 생각을 하고 있는지 알 수가 없다. 두 번째로 마지막으로 최종 솔루션과 첫 번째 제시한 솔루션이 어느 정도 진전이 되었는지를 판단한다. 이러한 과정을 통해서 지원자가 생각의 확장이 가능한지를 판단한다.
- 보통의 경우 면접관과 문제에 관해서 이야기하면서 두세 번의 최적화가 가능한 문제를 면접관은 가지고 온다. 혼자서 스스로 최종 솔루션을 생각하기도 하지만, 대부분 면접관과 이야기하면서, 피드백을 받으면서 최적의 솔루션을 찾게 된다. 여기서 면접관이 보고자 하는 것은 어려운 문제를 받았을 때 토론이 가능한지 확인을 하고자 하는 것이다. 혼자서 최적의 솔루션을 찾았을 때랑 비교하면 점수에 크게 영향을 미치지 않는다.
- 토론을 어느 정도 하다 보면 면접관이 코딩해 보라고 한다. 그러면 어느 정도 솔루션은 찾았다고 생각하면 된다. 더 좋은 솔루션은 없을까 고민하지 말고, 찾은 솔루션을 어떻게 구현하면 좋을까에 초점을 맞추면 된다. 여기서 유의해야 할 점은 바로 코딩을 하면 안 되고, 전체적인 설계를 먼저 이야기하고, 면접관이 코딩을 해도 좋다고 할 때 코딩을 시작해야 한다.
- 경험상 코딩을 하는데, 메인 코드가 20라인을 넘어가면 최적화된 코드가 아니고, 답이 틀린 경우가 많다. 이런 경우 반드시 중간에 맞는지 면접관과 확인을 하면 피드백을 보통을 받을 수 있다. 확인할 때에는 정답을 알려주세요가 아니라 내가 생각하고 있는 이런 이런 것인데 맞는지, 먼저 내 생각을 공유하는 것이 중요하다.
- 코드를 작성하는데, 20~30분 정도를 소비하는 것이 적당하다. 그것보다 빨리 코드를 작성하는 경우에는 설명하지 않고, 코드만 작성하는 경우가 많으므로 설명을 좀 더 상세하게 할 필요가 있다. 생각보다 시간이 많다. 조급해하지 말고, 천천히 변수 하나하나 모두 설명을 하면서 코딩하면 좋다. 면접관도 코드에 대한 설명 없이 보면 이해하기 어려운 경우도 있고, 언어가 다른 경우 좀 더 어려워하기도 한다. 유념해야 할 점은 면접관이 코드를 이해하지 못하면 좋은 점수를 받기 어렵다.
- 코드 작성 후에는 반드시 테스트를 해야 한다. 테스트코드 작성이 가능하다면 테스트코드를 작성하면서 코너 케이스를 확인하고, 그렇지 않은 경우에는 코너 케이스를 대입해서 예외가 발생하지 않는지 확인해야 한다. 10분 정도의 시간을 할애하는 것이 적당하다고 생각한다. 시간이 부족하더라도 대충하면 안 되고, 반드시 모든 케이스가 다 커버 가능한지 확인해야 실제 업무에서도 버그를 발생하지 않은 것이라고 믿는다.
- 좀 더 성능을 개선할 방법은 없는지에 대해서 이야기한다. 최적의 솔루션까지 찾지 못한 경우에는 최적의 솔루션에 대해서 이야기하면 되고, 그렇지 않은 경우에는 다음의 두 가지에 대해서 언급하면 된다. hard-code를 통해서 코드의 가독성은 떨어지지만, 성능을 향상 시킬 부분은 없는지, 분산 처리 환경에서는 어떻게 성능을 향상시킬 수 있는지에 대해서 이야기하면 된다.
한마디로 요약하면, 회사에서 일하듯이 함께 토론하며, 막히는 부분은 질문하며 코딩한다. 라고 생각하면서 인터뷰에 보면 좀 더 편하게 볼 수 있지 않을까 생각이 된다.
다음 포스트에서는 인터뷰를 대비해서 어떻게 코딩 연습하면 좋은지에 대해서 이야기해 볼께요.
이전글: 소프트웨어 개발자 인터뷰 에서 무엇을 보려고 하는가?
Facebook: 소프트웨어 개발자 인터뷰