반응형
오늘 회사에서 면접을 진행하면서 느끼는 것과  이미 수차례 면접을 진행하면서 느끼는 것이 있다.

지원하는 회사에 제출되는 이력서에 본인이 "진행한 일이나 작업에 대해서 명시해라!" 라는 것이다.
막상 이력서를 보고 1차 서류 심사를 통과하고 면접을 진행 해보면 본인이 한 것이 아닌 "팀원과 같이 했다"라는 식의 답변이 많다.
한 두개라도 좋은데 제대로 하고 이해를 제대로 한 것을 명시하면 좋겠다는 생각을 해 본다.


두번째는 어떤 분야에서 일하고 싶은지도 명확히 표현해야 한다고 본다.
이력서상에 보면 여러가지를 닥치는 대로 일을 한 것 같아 보여서 포괄적인 부분을 잘한다고 보아도 좋겠지만 면접때 물어보게 되는 경우가 있다.

"당신은 어떤 분야를 희망합니까?" 
또는 "어떤 분야를 더 잘한다고 생각하십시까?"

질문이 좀 고무적인 질문이라고 하겠지만 이력서를 보고 너무 포괄적으로 일을 진행 했다고 느껴져서 물어보는 의도의 경우 반듯이 저런 비슷한 질문을 하게 된다.

대부분의 면접자들이 하는 답변은 "회사에서 시키는 일을 닥치는 대로 했습니다." 라는 표현을 많이 한다.
물론 틀린건 아니다. 하지만 저 답변 뒤에 그래도 본인이 한다면 "이런쪽의 일을 해보고 싶습니다."  라는 표현이 있다면 적어도 면접자는 의사표현 하나는 확실하구나 하는 강한 이미지를 심어주게 된다.

다시 정리하자면 면접이라는 짧은 시간에 상대방을 모두 파악하기 어렵기에 질문자의 정확한 의도를 파악이 필요하고 거기따른 답변이 명확해야 한다고 본다. 모르면 모른다. 알면 아는 범위에서 답변이 이루어지는 것이 좋겠다. 


가장 중요한 건 하나를 답변 하더라도 질문에 대해서 명확히 이해하고 제대로 표현해야 한다.
만약 질문을 이해 하지 못했다면 오히려 질문자에게 다시 이해할 수 있게 질문을 해달라고 요청을 해라. 이해를 못한 상태의 질문을 긴장해서 횡설수설하다 답변이 점점 목소리가 작아지면서 자신없어지는 답변이 되어 질문자 입장에서 조금 답답함이 느껴지게 된다. 

게임 개발자로써 면접을 받는 사람들이 취해야하는 행동을 정리해보면..

1) 이력서는 본인이 한 것만 명시하고 정확히 이해하고 진행한 일만을 명시한다.
2) 질문자가 어떤 의도로 질문을 하는지를 이해하고 답변하며 이해를 못했다면 반듯이 반문을 해서 정확한 의도가 어떤건지 파악후 정확히 답변한다.
3) 답변을 하는 태도는 정확한 발음과 목소리로 틀려도 좋으니 얼버무리지 말고 명확히 답변을 한다.

크게 3가지를 들수 있겠다. 적어도 목소리의 톤에서 자신감(?)이 있는지가 판단이 되는데 대부분 흐리멍텅하게 이야기하거나 혼잣말로 얼버무리는 경우가 있다. 이런경우  질문자 입장에서 정확히 이해를 하고 답하는 건지 모르고 답변하는지 등이 판단이 서질 않는다.

질문자가 질문을 할 때 정확한 답변을 기대하는 것도 있지만 의중이나 생각 그리고 어떤 스타일인지를 파악하고자 던지는 질문도 면접중에는 있게 마련이다.

그런데 경력자들이 관과하는 오류가 "그냥하니 되던데요"라는 식의 답변을 많이 하는 경향이 있다. 오히려 어떻게든 취직을 해보려는 막 대학을 졸업하고 취직하려는 분들 보다 못한 답변이 대부분이다.

결국 면접관들의 대답은 어떤 결과라는 것은 뻔하게 나오기 마련일 것이다. 

게임 개발사 마다 면접방식의 차이는 있겠지만 최근 면접을 진행하면서 많은 경력자들에게서 느끼는 공통점을 적어본다.



iPhone 에서 작성된 글입니다.
반응형

'개발일지' 카테고리의 다른 글

텐센트의 지클라우드  (0) 2016.07.26
SphereTree 공간 서치  (0) 2010.09.02
반응형

출처 : http://www.talk-with-hani.com/archives/1148


소프트웨어를 개발하는 사람들, 혹은 엔지니어들은 복잡함에 매료되는 경향이 있습니다. 성급한 일반화의 오류일 수 있지만요. ‘과거의 저’나 ‘저와 함께 일했던 일부 분들’은 상당히 복잡한 것을 잘 이해하고 제어할 수 있다는 것을 자랑스러워하거나 좋아했습니다.


‘고약한 문제 합당한 해결’에서도 폭포수 방법의 문제점을 지적하면서 이런 점을 언급합니다.


둘째, (폭포수 방법에서) 프로세스로의 입력은 출력보다 덜 복잡한 경향이 있다. 입력은 출력보다 더 짧고, 대개 출력보다 더 쉽게 이해할 수 있는 용어로 표현되는 경우가 흔하다.
셋째, 이상하게도 출력의 어떤 항목은 입력보다 덜 복잡하게 보이기도 하는데 전체를 놓고 보면 출력이 입력보다 복잡하다. 프로세스를 더 단순한 요소로 분해해보면, 우리는 이상하리만치 전체적으로 일을 더 복잡하게 만들고 있는 셈이다.

‘고약한 문제 합당한 해결’에서



왜 이런 현상이 일어날까요? 그 이유를 이렇게 이야기하시는 분들도 있더군요. “너무 쉽게 혹은 이해하게 결과물을 내면 고객들이 이것 바꿔 달라 저것 바꿔 달라고 하더군요” 고객의 무리한 요구를 받아들이지 않으려고 일을 복잡하게 한다는 것도, 나름 설명이 되지만 이것만으로 우리가 복잡성을 탐미하는 이유를 찾기는 부족한듯 보입니다.


복잡성과 비슷한 맥락의 것이 있습니다. 프로젝트를 하다 보면, 팀원들은 상당히 많은 일을 하려고 합니다. 물론 고객이 찾아와서 이것 바꿔 달라 저것 추가해 달라고 하면 질색을 하던 분들도, 스스로 일을 더 찾아서 하려는 경향이 있습니다. 특히 프로젝트 초반에는 이런 경향이 심하죠. 하지만 스스로 일을 벌리다 보면, 프로젝트 끝무렵에 가서 벌린 일을 수습하려고, ‘품질’과 ‘일의 양’을 등가교환하는 경우가 생기죠.


이런 문제를 미연에 방지하려면, “어떻게 하면 더 많은 걸 만들어 낼까?”하는 긍정적인 상상에서 “어떻게 하면 일을 더 적게 할 수 있을까”하는 보수적인 실행을 해야 한다고 생각합니다. 크지 않지만, 이건 발상의 전환이라고 볼 수 있죠. 이런 마인드로 접근하는 게, 고객의 정당한 요구를 거절하는 걸 뜻하지 않습니다. 단 고객의 정당한 요구라도, 적은 노력을 들여서 할 수 있는 방법이 없는지 혹은 그런 요구가 정말로 프로젝트 성공에 필요한 것인지, 항상 반문하는 자세가 필요합니다.


지금 참여하는 프로젝트 팀원들은 PM포함해서 모두 산전수전을 겪은 고참들이죠. 그래서 이런 마인드가 창궐합니다. 그렇다고 해서 프로젝트 품질이 떨어지지 않죠. 반대로 고객의 희망적인 기대에 현실을 인식하게 하고, 결국 훌륭한 품질의 결과를 인도할 것으로 생각합니다. 여러분도 프로젝트에서 ‘더 많이’가 아닌 ‘더 적게’의 사고로 접근해 보시길 바랍니다. 조금 난해한 문제가 쉽게 풀리지도 모르죠. ‘더 적게’의 사고를 재미나게 소개한 일화로 글을 마무리합니다.


학교를 졸업하고 나서 이번이 두 번째 프로젝트입니다. 첫 번째 프로젝트에서 관리자는 코딩에 필요한 시간이 어느 정도인지 듣고 나서 이렇게 말했습니다. “이번이 처음 맡은 프로젝트니까, 개발이 끝날 무렵에 자네가 짠 소스를 코드와 통합하는 데 시간을 더 주는 게 어떨까?” 저는 관리자가 바보 같은 소리를 하다고 생각했지만, 시간을 조금 더 준다는 건 괜찮았습니다. 저는 열심히 일했고, 데드라인을 지켰지만 전체 시스템이 실제로 어떻게 작동하는지 피드백을 얻으면서 코드를 변경해야 했습니다. 저는 관리자가 준 여분의 시간을 모두 써버렸고 시간이 조금 더 필요했죠. 하지만 제가 정말로 당황한 것은 이 일 때문입니다. 저는 문제를 해결하려고 코드를 작성하지 않았습니다. 단지 코드를 간단히 만들려고 코드를 제거했죠. 그랬더니 제가 작성한 코드가 모두 사라져 버렸습니다.


두 번째 프로젝트에서 지속적인 통합을 사용했고, 진행하면서 리팩터링을 했습니다. 진행하면서 설계를 바꾸지 않았지만 간단하게 만드는 작업과 정리 작업을 수행한 덕분에 제가 무슨 일을 했고 얼마나 빨리 개발하는지 알게 됐습니다. 하지만 제가 작성한 코드는 여전히 사라져 버렸습니다.


Manage it!에서

반응형
반응형

반응형

+ Recent posts