코딩 인터뷰에서 질문에 대처하는 우리의 자세

개요

코딩 면접을 치루다가 간혹 면접관이 이상해 보이는 질문을 할 때가 있다. 그럴 때 어떻게 대응하면 좋을지 정리해보자.

상황 1: 구현이 조금 틀린 것 같은데요

면접관이 내가 푸는 맥락을 잘 따라가고 있으면서 뭔가 지적하는 상황이라면 xyz한 데이터에 대해선 어떻게 작동하게 되나요? 하는 식으로 구체적인 상황에 대해서 물어보기 마련이고 그럴 땐 그냥 상황에 맞춰서 생각해보고 고치거나 하면 되는데, 문제는 면접관이 구체적이지 않게 그냥 틀리지 않았냐는 식으로 물어보는 경우다.

  • 면접관이 내 구현에 대해 잘 모르는 데 일단 자기가 아는 정답과 다른 경우, 혹은
  • 어딘가 틀린 부분이 있긴 한데 구체적으로 지적하기 전에 한번 확인해 보는 경우

정도의 원인을 생각해 볼 수 있다.

옵션 1: 맞대응

딱히 현재의 구현이 틀리지 않았다고 생각한다면 이렇게 대응할 수 있다.

“아, 사실 어느 부분이 잘못됐는지 잘 모르겠는데, 한번 예제 데이터를 가지고 시뮬레이션을 해 보면 어떨까요?”

몇가지 포석이 있는데,

  • 예제 데이터를 돌리는 과정에서 발견될 문제라면 시뮬레이션 하면서 자연스럽게 “아 맞다” 하면서 고칠 수 있고,
  • 시뮬레이션 과정에서 문제가 없다면 면접관 입장에서도 부드럽게 이해하면서 넘어갈 수 있다.
  • 만약 예제 데이터에서 나오지 않는 문제가 있다면 면접관이 해당 문제를 발견할 수 있는 데이터를 제시할 수 있는데, 이렇게 하면:
    • 직접적으로 “어디가 틀렸다” 라고 하지 않으면서도 피드백을 줄 수 있으니 일단 점수를 덜 깎인다.
    • 고치는 과정에서 면접관 입장에서도 면접자가 문제 상황의 대응을 어떻게 하는지 평가하는 셈이라 괜찮게 넘어갈 수도 있다.

근데 만약 시뮬레이션 과정에서 별 문제가 없었는데 여전히 면접관이 “뭔가 틀렸는데”를 계속 주장한다면 이미 망했으니 다음 옵션으로 넘어가자.

옵션 2: 읍소

내가 보기에도 뭔가 자신이 없다면 걍 솔직히 인정하고 힌트를 받아 해결하자.

“ㅠㅠ 잘 모르겠는데 어디가 틀렸나요?”

하지마라: 싸움

“어디가 틀렸는데? 난 안틀렸어!”

상황 2: 최적화를 한다면 어떻게 할 수 있을까요?

  • 구현이 이미 잘 돼서 시간이 남아 그냥 물어보는 경우, 혹은
  • 시간복잡도를 조져서 완전히 새로 짜야 하는 경우

일단 어느 사례인지 확인하는 게 중요

사실 시간복잡도를 조진 경우라면 이미 머리가 안돌아갈 것이기 때문에 (이미 정신이 O(N^2) 풀이에 팔려있는 상황에서 O(N log N)이나 O(N) 알고리즘을 새로 생각하는게 쉬운 노릇은 아니다) 이 부분을 확실히 하는 편이 좋다.

“제 생각엔 abc한 이유 때문에 최소한 O(def) 이상의 시간이 소요될 것 같은데 다른 접근방법이 있을까요?”

abc def를 제시할 수 있으면 베스트인데 이것도 쉬운 노릇은 아니다.

하지마라: 마이너한 최적화들을 적용해보기

큰 맥락의 시간복잡도를 유지하면서 적용할 수 있는 마이너한 최적화들이 있는데, 사실 이런 것들을 얘기한다고 해서 코딩 면접의 점수가 크게 오를 수는 없는 노릇이다. 이런 부분은 과감하게 스킵하는 편이 낫다.

상황 3: 문제의 조건이 ZZZ하게 바뀐다면 어떻게 해야 할까요?

  • 문제를 풀 때 미리 확인했어야 할 조건을 확인하지 않아서 구현이 망한 경우
  • 문제를 잘 풀어서, 심화과정으로 넘어간다는 뜻

예를 들면 Sum(A[i:j]) == K를 만족하는 i, j를 찾는 문제를 푼다고 치자. 만약 A[i]가 항상 음수가 아니다라는 조건이 붙어있으면 sliding window를 써서 해결할 수 있겠지만 음수일 수도 있다는 조건이 붙으면 prefix sum으로 해결해야 하는 문제가 된다. 따라서 A[i]가 음수일 수 있는지 아닌지 꼭 확인해야 하는데, 확인하는 것을 빼먹고 구현했다면… (끔찍)

여튼 전자의 경우라면 이미 면접시간이 절반 이상 지나있을 것이고 새 구현을 그자리에서 바로 생각하기엔 이미 망한 느낌이 든다. 이땐 구현을 다시 하려고 노력하기보단 차라리 생각할 수 있는 다른 접근방법들을 정리해서 논의하는 것이 차라리 낫지 않나 싶긴 한데, 구체적인 성공/실패 사례가 있는 것은 아니라서 자세한 논의는 생략한다.

결론: 그냥 Dynamic Programming은 버리고 Memoization으로 접근해라

경험해보니까 문제의 최적 풀이가 Dynamic Programming일 때 위의 상황들을 자주 겪게 되던데, 다시 생각해보니까 그냥 Dynamic Programming만 봉인하면 위의 상황들을 훨씬 적게 경험할 것 같다는 생각이 들었다. 같은 문제를 Memoization으로 접근하면 면접관이 훨씬 쉽게 이해할 수 있기 때문에 쓸데없는 고통을 받을 일이 줄어들 것 같다는 거지.