[Essay] 기술면접에서의 질문방법에 대한 단상

다음은  SW Engineer 경력 사원 기술 면접 내용 중 일부이다.
면접 진행은, 대화가 꼬리를 무는 문답 thread가 아니라 "질문->답" 형태였다.
즉, 지원자의 답에 따른 면접관의 이어지는 관련 질문이 없었다는 뜻이다.

(*1) C/C++에 자신이 있다고 하셨는데, 그렇다면 C++에서 'virtual'은 왜 존재하는가?
-> 몇번의 communication끝에, 위 질문의 정확한 의도는 "C++에서 virtual member function은 어떨때 쓰이고 왜 쓰이는가?" 였음이 밝혀졌고, 면접관이 요구한 답은 "base class로 type casting해서 사용할 때의 문제점을 해결하기 위한 방법" 이였다.

(*2) semaphore와 mutex의 차이는 무엇인가?

(*3) thread와 process의 차이는 무엇인가?

(*4) singleton 은 무엇인가?

* 기타 등등...

난 개인적으로 위의 질문들의 수준이 높다고 보지는 않는다. 물론 이건 전적으로 내 개인적인 생각이므로 보는 사람에 따라 다를 수 있다는 것은 인정한다.
따라서 쓸데없는 딴지는 사양한다. 전부 내 개인적인 생각이니까..

그럼 왜 위의 질문들이 소위 "수준 높은 질문"이 될 수 없는가? 인터넷에서 10분만 검색해 보면 전부 답을 알 수 있는 내용들이기 때문이다.
물론 위의 질문들을 통해서 턱없이 부족한 실력의 지원자를 골라낼 수도 있겠다.
그렇지만, SW engineer의 경력분야에 따라서 실질적인 내용은 전부 알고 있음에도 불구하고, 위의 질문들에 제대로 대답하지 못하는 경우도 발생할 수 있다.

예를 들어, low tier embedded분야에서만 장시간 일해온 사람이라면, singleton 이라는 design pattern의 용어는 생소하게 들릴 것이다.

또한, context간 - 굳이 thread라는 용어를 사용하지 않았다. 왜냐하면, 'task'라는 용어 역시 가끔 'thread'와 동일 개념으로 사용되기도 하기 때문이다. - 동기화에 대해서는 잘 알고 있지만, semaphore와 mutex의 차이 역시  별 관심이 없을 수도 있다.
그냥 interrupt disable/enable로 동기화를 해야하는 SW system에서 일해 왔을 수도 있기 때문이다.
즉, '동기화' 라는 실질적인 내용은 잘 알고 있지만 - 사실 이 부분이 핵심이다 - 'semaphore'라든가 'mutex'라는 용어에 익숙치 않을 수도 있다는 뜻이다.
이는 그 사람의 지식 체계가 'semaphore'와 'mutex'를 사용하는 곳에서 쌓여진 것이 아니라, interrupt disable/enable을 사용하는 '체계'이기 때문이다.

마지막으로, 위의 면접형태의 가장 큰 문제점은, 계속되는 문답을 통한 지원자의 실질적인 지식을 측정하지 않고, 질문에 대한 정답을 요구하는 '주관식 시험 문제'와 같은 형태라는 것이다.
따라서, 그 사람의 실질적인 기술 지식(용어를 많이 안다는 것을 뜻하는게 아니다,) + 지식체계를 판단하기에는 다소 미흡하다고 생각한다.

위의 질문들은, 뛰어난 실력에도 불구하고 위에서 사용된 용어들과 맞지 않는 지식체계를 가진 사람들을 배제시킬 가능성이 있다.
또한, 실질적인 내용은 잘 모르고 용어의 뜻만 알고 있는 사람을, 실질적인 내용을 알고 있는 사람으로 오해할 여지도 있다.
그렇다면 어떤식으로 질문이 이루어져야 하는가? 위의 질문들을 가지고 다시 한번 재구성해 보자.

먼저 위의 질문은 크게 *1, *4  (A 그룹) 그리고 *2, *3  (B 그룹) 두 가지로 분류할 수 있고, 각 그룹은 하나의 문답 thread로 연결 시킬 수 있다.
필자가 생각하는, 각 그룹에 대한 문답 thread는 아래와 같다.

[ A그룹 ]

* SW architecture design에서 중요한 것들은 어떤 것들이 있을까?
-> 대화중, 모듈화나 information hiding에 대한 이야기를 유도한다.

* information hiding에 대해서 이야기 해 보면?
-> 여기서, "interface와 implementation의 분리"에 대한 이야기를 이끌어 낸다.

* interface와 implementation의 분리를 실제로 어떤 식으로 구현할 수 있을까? C++를 잘 안다고 했는데, C++를 예로 설명해 보면?
-> 이때, 상속, 다형성 등의 이야기가 나올 것이고, 자연스럽게 'virtual' 에 대한 이야기를 끄집어 낼 수 있다. 또한 instantiation에 대한 이야기도 이끌어 내도록 하자.

* 특정 class/모듈에 대해서는 instance를 여러개 만드는 것을 막고 싶은데 어떻게 하면 될까?
-> singleton에 대한 이야기를 끄집어 낼 수 있다. 이때, singleton이라는 용어를 알고 모르고는 중요하지 않다. 실질적인 내용과 개념을 정확히 알고 있는지 파악하는게 중요하다.

* 계속진행...
(각종 design pattern에 대한 이야기들, C++이 아니라 C에서 구현하는 design pattern의 개념들 - C로 상속, singleton, 다형성의 구현 등 -  등으로 이야기를 진행시킬 수 있다.
사실 C로 information hiding, OOP의 개념들을 구현하는 것에 대한 대화는, 해당 분야에 대한 지원자의 이해도를 측정하기에 굉장히 좋은 방법 중에 하나이다.)

[B 그룹]

* OS란 무엇인가? OS의 가장 핵심이 되는 기능은 무엇인가?
-> context관리에 대한 이야기를 끄집어 낼 수 있다. 혹은 대부분의 경우, 이미 thread와 process라는 용어가 등장했을 것이다.

* 무엇이 thread고 무엇이 process인가?
-> 사실, 위의 질문 자체는 괜찮은 시작점이 될 수 있었다. 문제는 이어지는 후속 질문들이 없었다는 것이다.

* 어떤 경우 thread/process를 사용해야 할까? 각각의 장단점은?
-> context switching, scheduling등의 개념과 더불어,  race condition에 대한 이야기를 끄집어 낼 수 있다.

* race condition문제는 어떤식으로 해결해야 할까?
-> 이때, context간 동기화에 대한 이야기를 이끌어 내면서, semaphore, mutex 등의 개념의 이해를 판단할 수 있다.

* 계속 진행... (deadlock, mutex의 구현 방법 (atomic instruction, interrupt disable/enable), Out-of-order optimization, Memory Barrier 등등으로 이야기를 계속 진행시켜 나갈 수 있다.)

이런 식으로 대화를 진행하면, 단지 용어만을 알고 있는 어설픈 실력자를 구별해 내면서, 지원자의 실질적인 지식과 지식 체계까지 파악할 수 있다.
면접관이 지원자에게 하는 질문의 이상적인 형태는 소크라테스의 '문답법'과 같아야 한다고 생각한다.
지원자의 대답과 거기에 이어지는 꼬리를 무는 질문들... 이런 식의 질문이 정말 "제대로 된 면접 질문" 이라고 생각한다.
물론, 동의하는 사람도 있고... 그렇지 않은 사람도 있겠지만... -_-;

이제 이 문제를 조금 더 확장해 보도록 하겠다.

보통 면접관은 지원자의 '대답'을 통해서, '질문'이 의미하는 특정 분야에 대한 지식/역량/기술을 알아보고자 한다.
그래서 일반적인 면접은 "질문(면접관)->대답(지원자)"이 연속하는 과정이다.
그런데 무언가 빠진 것 같지 않은가?
이런 과정에서는 '지원자' 가 어떤 것에 관심이 있고, 어떤 것을 중요하게 생각하는지는 알 수 없다.
어떤 사람과 함께 일하기 위해서는 그 사람의 관심분야,  중요하게 생각하는 분야, 가장 잘 하는 분야 등도 굉장히 중요한 고려사항이다.
비록 지금 당장 필요한 부분의 역량은 조금 부족하다고 생각되는 지원자라도, 의외로 다른 중요한 부분에서 굉장한 두각을 나타낼 수도 있기 때문이다.
물론, 단도직입적으로 "당신은 어떤 분야에 관심이 있나요?" 혹은 "어떤 분야를 잘 할 수 있나요?"라는 추상적인 질문을 통해 이를 파악할 수도 있을 것이다.
그렇지만, SW는 엄청나게 많은 분야에 걸쳐 세분화 되어 있으므로, 추상적인 "질문 -> 대답" 으로 명확한 답을 얻기란 쉽지 않다.
예를 들면, "전 OS에 관심이 있습니다."라는 대답하는 지원자가 있다고 가정하자.
이 대답으로 '관심분야'와 '중요하게 생각하는 분야'에 대한 파악이 다 되는가?
아마도 추가적으로 "OS중에 구체적으로 어떤 분야에 관심이 있나?" 식의 추가적이고 연속적인 질문이 뒤따라야 할 것이다.
그리고 대부분의 경우 이런 추가적인 질문들을 통해서도 원하는 만큼의 관련 정보를 얻기는 쉽지 않을 것이다.

다시 한번 정리해 보자.
일반적으로 사용되어지는 "질문(면접관) -> 대답(지원자)"의 면접 방법은 "면접관이 관심있고, 중요하게 생각하는 분야에 대한 지원자의 역량을 파악하기 위함"이라고 봐도 좋다.
그런데, 이 과정은 "지원자의 관심/중요 분야, 그리고 지원자가 가장 잘 할 수 있는 분야에 대한 파악"에는 적합하지 않다.

여기서 난 다음과 같은 방법을 제안해 본다. (아직 개인적으로 시험해 볼 기회가 없었기 때문에 실제적인 '실험(?)' 결과는 제시할 수 없지만, 기회가 되어서 실질적으로 적용해 볼 기회가 생기면 결과를 추가적으로 기재하도록 하겠다.)

"지원자 스스로가 질문하고 대답하는 것이 주(main)가 되고, 면접관의 질문은 이를 조정(control)하는 역할을 하는 면접"

(예) <지원자(홍길동) 에 대한 기술 면접>
홍길동씨 자신이 면접관이라고 생각하고, 자기 자신과 같이 일할 사람을 뽑는 다고 생각합시다.
그리고, 홍길동씨가 면접볼 사람은 홍길동씨 자신힙니다.
다시 말하면, 홍길동씨 스스로가 질문하고 대답하는 것입니다.
시작해 볼까요.

어떤가?
면접관이 다양한 분야 충분한 기술적인 지식이 있다면 위와 같은 면접은 기술적인 분야에서 지원자의 성향/가치관/비젼 등에 대한 세세한 파악을 가능하게 해 준다.
그리고, 문답의 진행 분야/방향 역시 지원자의 역량을 파악하기 위한 중요한 정보가 될 수 있다.
만약 문답의 진행이 엇나가거나, 면접관이 생각하기에 무언가 부족한 부분이 있다면(면접관이 꼭 알아보고 싶은 분야가 빠졌다던가...), 진행 중간에 이를 조정해 주면 된다.
단, 이때에도 구체적인 질문의 형태를 통해서 이를 조정하고자 하면 안된다.
예를 들면, thread 동기화에 관한 '문답'이 진행되고 있는데, 이 과정에서 'deadlock'에 대한 내용이 빠져 있고, 이를 알아볼 필요가 있다고 면접관이 생각한다면,
"deadlock 에 대한 부분은 어떻게 생각합니까?"
라는 지원자의 직접적인 '답'을 유도하는 질문 보다는
"무언가 빠진거 같은데, 동기화 관련해서 몇몇 문제들이 있지 않나요? 거기에 관련해서 지원자의 역량을 좀더 파악해 보도록 합시다."
라는 식으로, 관련 분야에 대해서 지원자가 다시 '질문 -> 답'의 과정을 시작할 수 있게 해 주어야 한다.
즉, 면접관에 대한 지원자의 반응이 '답'으로 끝나는 형태의 조정이 아니라, 지원자 자신에 대한 '질문 -> 답'이 되는 형태의 조정을 해 주어야 한다.
주제를 바꿀 때도 마찬가지다.
"이제 OOP에 대한 주제로 바꾸어 봅시다. "
식으로 '문답'을 유도해 나가면 된다.

단, 이런 식의 면접은 다양한 분야에 충분한 양의 기술적인 지식을 가진 면접관을 필요로 한다.
특정 분야에 편중된 지식을 가진 면접관의 경우, 이런 식의 면접은 오히려 시간 낭비가 될 수 있다.
운이 좋아서 지원자의 '문답' 진행 방향과 면접관의 지식 분야가 일치하면 더 없이 좋겠으나, 그렇지 않은 경우는 그냥 일반적인 '질문(면접관) -> 대답(지원자)'와 별반 다를 게 없어진다.

괜시리 이야기가 길어졌는데...
어쨌든... 일단 내 개인적은 경험/생각 에서 정리된 내 나름대로의 방법을 정리해 보았다.
음... 실제로는 어떤 결과를 보여줄지 궁금하기도 하고...
기회가 되면 꼭 이 방법을 적용해 보리라...