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