개발자를 잘못 채용하는 방법
'개발문화' 카테고리의 다른 글
| 문서화 딜레마 (20) | 2010/11/11 |
|---|---|
| 내가 지금 하고 있는 일의 가격 (6) | 2010/11/02 |
| 개발자를 잘못 채용하는 방법 (20) | 2010/04/19 |
| Google을 이끄는 힘 (7) | 2009/10/30 |
| SW개발과 Teamwork, 그리고 Review (2) | 2009/10/19 |
| 우리는 다르다. (6) | 2009/10/09 |


|
|
| 문서화 딜레마 (20) | 2010/11/11 |
|---|---|
| 내가 지금 하고 있는 일의 가격 (6) | 2010/11/02 |
| 개발자를 잘못 채용하는 방법 (20) | 2010/04/19 |
| Google을 이끄는 힘 (7) | 2009/10/30 |
| SW개발과 Teamwork, 그리고 Review (2) | 2009/10/19 |
| 우리는 다르다. (6) | 2009/10/09 |
| 우리는 당장 써먹을 수 있는 경력 개발자 위주로 뽑아요. (6) | 2009/02/10 |
|---|---|
| 타이핑이 느린 프로그래머 (14) | 2009/02/06 |
| 개발자 5적 (10) | 2008/12/22 |
| 개발자 채용 시 코딩테스트를 하시나요? (3) | 2008/12/19 |
| 소프트웨어 아키텍처는 어디에서 오는 것일까? (23) | 2008/11/28 |
| 신입 개발자가 들어오면? (5) | 2008/11/13 |
트랙백도 남겼습니다만...
제가 그동안 면접도 꽤 많이 봤는데 국내 회사 중엔 '다음 코드의 결과값은?' 하는 정도의 필기 문제는 있었어도 실제 코딩 테스트를 하는 데는 없었던 것 같습니다.
프로팀에서 투수를 뽑는데 피칭을 안 시켜 보는 것과 마찬가지겠죠? -_-;
Eminency님 안녕하세요.
코딩테스트를 하는 회사가 있기는 합니다. 하지만 그리 많지는 않은 것 같습니다.
대학을 막 졸업한 새내기는 그런 간단한 문제가 도움이 될지는 몰라도 경력 개발자는 제대로된 코딩테스트가 꼭 필요합니다.
이번에 이직한 회사는 두 번째, 세 번째 모두 테스트를 했고, 임원면접때 또 물어보더군요. 잘 코딩을 했긴 했는데, 왜 그렇게 했는지 다시 설명해 보라고... "코딩습관 때문에 그렇게 했다" 라고 해서 떨어질법 했는데, 통과해서 4개월째 잘 다니고 있답니다.
그런데, 개발프로세스가 거의 없고 너무 약했습니다. 팀단위조차도... 그래서 슬슬, 혼자서 환경구축해서 쓰면서 전도나 할까 합니다. ㅎㅎㅎ 말로 하는 것보다 직접해서 구경시켜주면서 장점을 얘기해야겠지요. 근데, 힘들어요. ㅎㅎ
우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..
수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..
'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..
우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..
최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..
우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..
우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..
며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..
프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..
"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..
잘 읽었습니다.
글 내용에는 동의합니다만, 실천하기는 무척 어려운 사항이네요.
안녕하세요. 지킬박수님
사실 평소에 채용을 위해 꾸준히 노력하는 것은 관리자의 의무입니다. 대부분 의무를 태반하는 것이지요. 또는 회사에서 개발자를 무슨 공장에서 부품 고장나면 교체하듯이 결원이 생길 때만 채용할 수 있도록 하는 회사도 있습니다.
사실 그렇게 어려운 것이 아닌데, 회사 정책상 또는 게을러서 못하고 있는 경우도 의외로 많습니다.
댓글 고맙습니다.^^
말씀하신 게 맞습니다. 어려움은 사장님을 어떻게 설득하느냐에 있습니다. 결원이 생기기 전에 좋은 사람을 미리 확보해 두는 식으로 허용되지 않는 경우 말이죠. 정말 참 어렵네요.
개발자를 미리 확보해두는 것은 어렵습니다. 평소에 채용을 위해 노력한다는 것은 개발자를 미리 뽑아 놓는 다는 의미는 아닙니다. 평소에 꾸준히 개발자들을 물색해 놓고 좋은 개발자들과 관계를 유지해 놓다가 기회가 되면 데려 올 수 있도록 하는 것도 한 방법입니다.
평소에 꾸준히 개발자를 물색해 놓는 거, 필요한 일이겠네요. 노력도 해 봐야겠고요. 이 부분은 미처 생각하지 못했습니다.
다만, 이 또한 쉽지 않다는 생각도 함께 듭니다. 앞서 말씀 드린 대로 결원이 생기기 전에 미리 준비하지 않는 문화를 가진 조직에서는 평소에 꾸준히 개발자를 물색해 놓는 노력을 할 만 한 여유(?)를 만들기가 어렵거든요.
이게 개인적으로 노력한다고 해서 가능한 것인지 좀 더 고민해 보겠습니다.
채용에 대한 노력은 관리자의 R&R에 명시적으로 포함이 되어 있어야 합니다. 이를 위한 시간 및 예산이 제공되어야 하며 평가에 반영이 되어야 합니다.
흔히 관리자의 R&R에 개발자 retain만 포함되는 경우가 많지만, 채용을 위한 노력도 그에 못지 않게 중요합니다.
개인이 회사의 지원 및 관심도 없이 혼자서 노력하는 것은 쉽지 않습니다.
예전 개발 환경에서는 기술/업무의 규모가
크지 않았기 때문에 못하는 사람이나 잘하는 사람이나
크게 차이가 없었지만 최근 동향을 보면 그 규모나 난이도가 예전과 비교 했을 경우 엄청난 차이가 납니다.
못하는 사람과 잘하는 사람이 단순 본수로 판단했을 경우
10본이상 차이가 난다고 합니다.
즉 앞으로 회사 경쟁력은 테크니컬 인재를 많이
가지고 있는 회사가 살아 남을 것 같습니다.
최근 프로젝트를 하면 누가 고급이고 누가 중급인지
판단이 애매 합니다.
개발자를 본수로만 따지는 프로젝트가 많죠. ^^
불러주는 사람도 없고..
있어도 항상 망하는 회사에만 있는 저는 능력없는 나쁜 개발자인거군요 ㅠ.ㅠ
이렇게 3년 일하니... 긍정적인 생각도 다 가출해버렸어요 OTL
구차니님 안녕하세요.
운이 없으신 거겠죠. ^^ 제 글이 개발자 입장에서는 오해를 일으킬 수 있는 내용이네요. 죄송합니다.
개발자도 한 회사에 평생 몸 담겠다는 마음가짐 보다는 적절한 때 회사를 잘 옮길 수 있도록 평소에 노력을 해 놓아야 한다고 생각합니다. 그래야 인연이 되는 좋은 회사도 만날 수 있고 그에 필요한 준비도 미리 할 수 있습니다.
님께서 작성하신 글은 제가 보기엔 교과서적인 내용입니다.
저도 여러개발과 수장 노릇도 해봤지만 님의 블로그 내용은 현실적 괴리가 있네요.
특히, 결론부분은 인력시장을 잘 이해하지 못하신 것이 아닌지요?
대기업같이 인력 풀이 잘되어 있는 곳이 적절한 예는 아닌 것같고
그외의 회사를 예로 든다면 개발자를 잘 채용하는 비결은 적정한 보수입니다.
신입을 키워 향후 활용하는 것은 그때뿐이며 다 자기능력에 대응하는 보수를 찾아 나갑니다.
남게되는 경우는 대부분 인맥관계나 그외의 사정때문이지 그 회사가 키워줘서 남아 있는 것이 아니지요.
이런 행태가 솔직히 비난받을 일은 아닙니다.
경력의 경우 가장 필요한 덕목은 역량도 중요하지만, 책임감과 문제해결능력이 신입보다 높다는 것이지요.
당장 발등에 불이 떨어져도 경력자가 위의 조건에 충족한다면 된 것입니다.
제 경험상, 어차피 새로 온 조직에 적응과 업무이해를 위해 가르쳐주는 것은 대부분 경력자가 이해가 더 빠릅니다. 그래서 회사의 신입은 이직하기 전 열심히 배워야 하지요.
그리고 퇴사 전 이미 누가 데려간다는 것은 대기업이 아닌 이상 대부분 다 인맥으로 가는 것입니다. 그런데 아는 사이이다 보니 연봉협상이 편하질 않죠. 누가 데려가지 않아서 실력이 낮을 것이다라는 편견은 아니시겠죠?
대부분의 사람들이 적정한 보수와 하고싶은 분야의 일을 찾아 나온것입니다.
그리고 동일개발자 부분은 저도 동의합니다.
사실 개발자들은 한우물만 파서는 안됩니다. 일례로 Pro*C 부분만해도 그리 어려운 것이 아님에도 일부 금융권에서는 Pro*C 경력자만 뽑더군요. 전산프로젝트는 종합예술같아서 한가지 부분만 가지고 퍼포먼스 향상을 기대하지 못하는데..
다양한 지식과 경험을 겸비한 개발자의 개발 능력은 한우물만 판 사람보다 생각의 틀이 넓습니다.
컨설턴트 하실 때 저와같은 생각을 가지는 사람도 있다는 것을 염두해 두셨으면 합니다.
좋은 의견 감사합니다.
경력직 개발자를 채용하는 첫번째 조건은 연봉 맞습니다. ^^ 그런데 발등에 불떨어진 듯 개발자를 뽑으면 높은 연봉을 주고도 좋은 개발자를 찾기가 어렵죠. 작은 회사들은 개발자를 미리 뽑아 놓는 것은 어렵죠. 그렇다고 하더라도 평소에 채용을 위해서 활동을 해야 할 것들이 많습니다. 그런데 대부분 평소에는 전혀 신경을 쓰지 않습니다. 평소에 준비를 잘 해놔야 필요할 때 좋은 개발자를 채용하기가 용이합니다. 연봉은 필요한 만큼 줘야하지요.
그리고 누가 데러가지 않는 개발자는 실력이 낮다는 것은 아닌데, 제 글을 다시 읽어보니 그런 오해를 할 수 있는 문맥이군요. - -; 당연히 묵묵히 일하는 뛰어난 개발자들도 많이 있죠. 하지만 인력시장에서 좋은 개발자를 찾는 것이 쉽지 않은 것은 경험상 사실이죠. 여전히 여러 인맥을 통해서 뛰어난 개발자를 찾고 꾸준히 관계를 유지해 놓다가 서로 연결을 해서 데려가는 것은 좋은 개발자를 채용하는 효과적인 방법입니다.
어쩔때는 제가 쓴 글을 다시 읽어보면 이번 글과 같이 의도하지 않은 의미로 이해가 될 수 있는 글들이 종종 있습니다. 이글도 관리자나 경영자의 시야에서 작성했었는데, 개발자 입장에서는 기분이 나쁠 수 도 있겠네요. 나중에 개발자 입장에서 이직에 대해서 글을 써봐야겠습니다.
좋은 지적 감사합니다.
참으로 공감하는 내용입니다. 개발자 채용시 기술면접을 외부전문인에게 맡기는 것. 객관성을 유지할 수 있을 것 같습니다. 만약에 개발자 면접을 주관해야 하는 입장이라면 새로 면접하러 온 개발자의 능력을 자신의 능력과 경험에 견주어서 판단할 수도 있겠습니다. 말쓰하신대로 자신보다 뛰어난 개발자가 들어왔다거나, 정치적으로 자신이 위축될만한 인재라고 느낀다면 위축되고 경계하겠죠. 실제로 이런곳 여러군데 봤습니다.ㅎ
장기적인 안목 그것이 중요할것 같네요 ( 참~ 전 이번 병고 이후 새로운 직장에 몸을 담을 예정입니다. 엔지니어링과 IT개발은 취미로 삼고 말이죠. 앞으로 규현님과 비슷한 일을 할 것 같은 예상이 듭니다. 많은 조언 부탁드리겠습니다.
안녕하세요. moova님
몸은 많이 나아지셨나보네요. 다행입니다. 블로그에서 자주 뵙기를 희망합니다.
이글에 추천한표 던집니다.
근데 이런 좋은 글은 저같은 개발자들이 공감하는거 보다도,
각회사 인사담당자들이 좀 읽고 느껴야 하는데 말이죠.
안녕하세요. kevin님
호주에 계시나봐요? 멋진 블로그도 가지고 계시고요. 반갑습니다.
앞으로 종종 들려주세요.
이번에 "프로젝트가 서쪽으로 간 까닭은" 이라는 이름으로 번역되어 나온 책이나, 조엘의 책 등에서도 언급했고, 개인적으로도 그동안 인터뷰를 했던 경험으로 보자면 말씀하신 것과 같이 외부인력이나 CTO만으로는 부족합니다. 팀에서 일할 사람을 뽑는데 외부인력이 무슨 내용을 어떻게 알까요? 실제개발에 손놓은지 오래 된, 회사의 기술적 나갈 방향을 결정하는 CTO가 세세한 기술 인터뷰를 제대로 할 수 있을까요?
함께 일할 사람을 뽑는데 있어 동료들만큼 기술인터뷰를 제대로 할 수 있는 사람들은 없다고 생각합니다.
1차 기술 인터뷰를 동료들이 직접 하고, pass한 사람들에 대해서 CTO나 다른 사람들이 발전가능성/인성/조직 친화력? 등을 점검해야 합니다.
최소한 전화인터뷰 - 팀 기술인터뷰 - 최종인터뷰 의 3가지 정도 과정을 거치는 것이 좋더군요.
자신보다 일을 잘하는 사람을 일부러 떨어뜨린다? 글쎄요, 한명이라도 더 일 잘하는 사람이 들어왔으면 하는 바램으로 가득찬 게 개발자 집단이고, 만약 자신보다 일을 더 잘할 것 같아서 떨어뜨린다면 그 조직은 이미 정치가 난무하는 비효율의 하급 개발자들이 넘친다고 밖에 볼 수 없을 것 같습니다.
A급 인재는 A급이나 S급 인재를 데려오지만, B급 인재는 자신보다 못한 사람들을 데려온다고 했던 조엘의 이야기가 생각나네요. 스타트업부터 시작해서 회사가 존재하는 한 '우수인력 유치'를 지속적인 프로젝트로 진행해야 하는 이유가 여기에 있을겁니다.
안녕하세요. 우울한 딱따구리님
좋은 의견 감사합니다. 사실 CTO만 하더라도 우리나라에서는 상당히 왜곡된 이미지를 가지고 있습니다. 한마디로 우리나라 CTO는 기술을 잘 모르는 사람이 많죠. 그래서 말씀하신 내용이 일리가 있는 것 같습니다.
거의 대부분의 소프트웨어 회사는 B급, C급 인재가 넘쳐나고 A급, S급 인재는 찾기 어렵습니다. 상황이 이러다보니 채용시에도 좋은 개발자를 가려내기 힘든 것 같습니다.
B급, C급 인재에 대한 대책은 없나요?.^^..
안녕하세요. jp님
어느 조직이나 다양한 인재가 필요합니다. 문제는 A급인제인줄 알고 뽑았는데, C급인재인 경우입니다.
보통의 소프트웨어 회사는 A급인재 10~20% 정도, 그 외에는 B, C급 인재로 채워집니다. 물론 B,C급 인재를 키워서 역량을 갖추게 하는 것도 중요하지만, A급인재가 하나도 없는 회사는 또 곤란합니다.
회사 입장에서는 그런 것이고, 개발자 개인 입장에서 자신은 B급, C급이 되겠다고 하는 사람들은 없을 겁니다. 그러므로 자신의 목표도 A급, S급에 맞춰야 겠죠.