프로그래머 면접, 나 라면 이렇게?

IT밸리에 프로그래머 면접으로 부터 촉발된 문자열 뒤집기 및 관련된 포스팅들. 재미있다. 오랫만에 정말 프로그래머들 끼리 놀 만한 주제가 아닐까.

재미있는건 약간 집어치우고, 내가 면접관이라면 실무면접(?)을 이런 식으로 해 보고 싶다.

1. 대충 아무 문제나 낸다.
   
2. 커피 한잔 마시고 오면 대충 풀었겠지.
3. 답안지를 보자. 단, 그냥 대충 보자.
   
4. 코드가 잘 돌아가는지 문법 에러는 없는지 등은 신경쓰지 말자. (pseudo 수준으로 봐야겠지)
   
5. 코드를 이해하지 말고 대충 면접자에게 물어보자. '이 코드는 왜 이렇게 짰어요?'
6. 응답자의 대답을 듣고 코드가 제대로 이해되는지 생각해보자.
7. 면접자의 설명을 듣고 코드의 목적과 방법이 이해가 된다면 실무에선 합격선이라고 판단하자.
8. 코드 동작에 문제가 있을 것 같다면 그 문제를 찾을 수 있는지 물어보자.
9. 문제를 찾아서 해결하는지 확인해보자.
10. 해결했는가?
11. 난해한 코드라면 난해하다고 이야기 해 주고 그 내용을 이해하는지 확인해보자.
12. 이해했는가?
13. 나이스 가이~~~~
    

- 이 사람이 처음 제출한 답이 틀렸다고 하더라도 이 사람은 충분히 발전할 가능성을 가지고 있다. - 라는 판단 방법으로 이런식의 생각을 해 봤지.

실무에 있어서 이해하기 좋은 직관적인 코드를 짠다면 정말 좋은 프로그래머 라고 생각한다. 하지만 경력이 많아야 그게 가능하겠지 대학이나 대학원 갓 졸업한 이들을 대상으로 그런것까지 요구하기엔 세상에 사람이 너무 없을 것 같다. (학교 다니면서 이것 저것 다 해본 베테랑급 프로그래머라면 이런거 신경 쓸 필요도 없겠지)

그렇다면 단순하게, 그 사람이 만든 코드가 막상 보기엔 난해하더라도 설명을 통해(혹은 주석을 통해) 이해가 가능할 정도의 코드를 만든다면 그 사람은 여러 사람들과 프로젝트를 진행하는 능력의 기본은 된다고 생각한다.

문제의 답이 틀렸냐 맞냐를 크게 따지는 건 중요한 걸 놓치는 거라고 생각한다. 문제를 발견하고 발견한 문제를 고칠 수 있다면 오류를 신경쓰지 말자. 머릿속의 생각을 코드로 제대로 풀어내지 못 한다면 그것이야 말로 진짜 오류다.

물론 실무에 관한 이야기다. 면접에서 다른 여러가지 요건이 있어서 이것 만으로 사람을 판단하는건 무리겠지.