출처 : http://www.gpgstudy.com/forum/viewtopic.php?t=4735&postdays=0&postorder=asc&start=30

imc 의 neolith 입니다  
재미있는 글이어서 보다보니 저희 회사 이름도 나오네요. 황송할 따름입니다.

서로 감정상하는 일 없이 조심조심 의견을 교환했으면 하는 바램입니다.

참고로 imc 의 프로그래머 구인 방식에 대해 말씀드릴까 합니다.


저는 프로그램을 디자인 하는 일보다는, 프로그램팀을 디자인하는 일을 하고 있습니다. 잘 돌아가는 프로그램팀

이라는 것은 잘돌아가는 프로그램보다 더 어렵고도 보람찬 일입니다. 완벽한 논리에 따라 돌아가는 프로그램과

달리 여러가지 소프트한 팩터에 영향을 받습니다. 단적인 예로, 같은 능력을 지닌 사람도 어떤 환경에서 어떤

임무, 어떤 동료와 같이 일하느냐에 따라 극과 극을 오갈정도의 결과를 보여줍니다. 무조건 실력자만 모셔온다

고 해서 되는 것이 절대 아니라는 점을 수없이 느꼈습니다.

또한, 초반에 회사에 입사했을때 어떻게 회사에 적응하게 만드는가도 상당히 중요한 요소인 것 같습니다.

이력서나 면접시험 같은 것으로 사람의 한 단면을 볼 수는 있을지 몰라도, 수십년동안의 이성과 감성이 응집된

한 프로그래머라는 존재를 파악하긴 참 힘들죠. 그렇다고 해서 일단 뽑아보고 아니면 빨리 내쫓는 식의 회사

편의적인 행동도 결코 바람직하지 않다고 생각합니다.


암튼 imc 에 면접을 보면 묻는 것은, 무엇을 제일 하고 싶은가 (imc 나 현재 프로젝트와 전혀 관계없이) 를

중점적으로 물어봅니다. 다른 조건이 좋아도 사람이 하고싶은 일과 회사에서 제공하는 일에 차이가 많이

나는 경우에는 결과가 좋지 않은 것을 종종 확인한 바 있습니다.

프로그래머 면접의 경우에는 pragmatic programmer 를 읽어보았는지, 그 책의 교훈에 대해 얼마나 체감하고

있는지에 대해 많이 물어봅니다. pp 의 내용이 그냥 읽었다고 술술 이해되는 내용은 아니고, 자신이 마이너스

체험을 한 후에 아 이런 방법이 있었구나 하고 깨닫는 순간 읽는 이의 능력을 향상시켜주는 책이라고 생각합니다

면접 후에는 과제 프로젝트를 내어줍니다. 프로젝트의 내용은 현재 개발에 도움이 될 수 있으면서, 요구사항을

어느정도 명확히 제한할 수 있는 소재의 것들입니다. 내부적으로 판단하기에 한달 내에 완성할 수 있는 것들을

주로 과제로 내줍니다. 과제이기도 하지만 실제 활용이 가능한 것을 내어주기 때문에 외주 프로젝트 발주로 처

리 해서, 완성시에는 그 댓가를 지불합니다. (댓가는 희망급여의 1달분을 완성한 일자에 비례)

과제 프로젝트의 수행에 있어서 중요시 하는 것은, 얼마나 최초의 요구사항을 충실하게 반영하였는가, 모자란

요구사항에 대해 얼마나 적극적으로 의문점을 제시하고 중간 피드백을 유도했는가를 중요하게 생각합니다.

어차피 완벽한 요구사항을 만들기란 불가능하고, 서로 피드백을 잘 할 수 있는 동료끼리 협력하는 것이 당장

지금 갖고 있는 능력보다 더 중요하다고 믿기 때문입니다.

비단 프로그래머뿐만 아니라, 다른 파트의 사람들도 이러한 실무 테스트를 적용하여 보다 만족스러운 결과를

얻고 있습니다. 이러한 테스트 프로젝트를 수행하면서 이 회사가 어떤 곳이고 어떤 가치를 요구하는가에 대해

자연스러운 사전교육이 이루어지기 때문입니다. 사실 웬만한 게임회사에서 사람을 뽑아 따로 교육연수기간을

두는 경우는 거의 없다고 보았을 때, 이러한 기간의 의미는 회사에서도 부담을 줄일 수 있고, 구직자의 입장에

서도 자신이 원하는 직장을 신중하게 선택할 수 있다는 점에서 장점이 있는 것 같습니다.

이만 글을 줄입니다.

김학규
neolith

-------------------------------------------------

가장 힘든 방법으로 구인을 하시는군요.
그렇지만 저 방법이 쵝오죠..

아참 혹시라도 무단으로 올려서 문제가 된다면 자삭하겠습니다.(근데 GPGStudy에서도 그냥 비회원도 읽을수 있으니..)