== 개발자를 판단하기 위한 단 한가지 질문 == === 김태진 === * 당신에게 있어서 마감이란 무엇이고 왜 그렇게 생각하는가? 프로젝트 마감이 제시간에 이루어지는게 절대적으로 힘들다는 가정을 갖고 서술해보라. * 디버깅을 며칠간해도 해결되지 않다가, ;하나에 해결되었다면 어떤 느낌이들거라 생각하는가? * 으아아 - [송치완] * 나는 이따위 프로그램(개발툴)을 만들지 않겠다. - [김수경] === 송치완 === * 만약 로또에 당첨된다해도 당신은 하던 개발을 멈추지 않을 자신이 있습니까? * 로또가 당첨되어도 그 돈으로 평생 먹고 살 수는 없다. 평생 먹고 살려면 일해야 한다 - [지원] * 당신이 경쟁 유료제품을 위협할만한 만큼 고품질의 프로그램을 만들어 일반에 무료로 배포하고 있다는 가정을 해봅시다. 만약 경쟁회사에서 큰돈을 주며 프로그램을 폐기하라고 유혹한다면 당신은 어떻게 하시겠습니까? * 내가 이 프로그램을 유료화하면 그보다 많이 벌 수 있다고 뻥쳐서 더 큰 돈을 받는다. - [김수경] === 권순의 === * 어떠한 프로젝트를 만들어 달라고 요구하는 사람들에게 그 프로젝트의 진행 결과가 눈에 보이지 않아(뚜렷한 소스가 없다던지 해서) 어서 빨리 그것을 보여 달라고 한다면 그 상황을 어떻게 헤쳐 나갈 것인지? * 이럴 때 Unit Test를 이용하는 겁니다. - [지원] * 아니면 TDD라던가 === 송지원 === * 가장 어려운/힘든 프로젝트는 어떤 것이었고 왜 어려웠는가? * 동료가 주장한 방식보다 자신이 생각한 방식이 옳다고 생각한다면 어떻게 하겠는가? === 박정근 === * 자기가 (여기서) 하고싶은 프로젝트에는 어떠한 것이 있는가? * 뭘 하던간에 그 프로젝트에서 배워가고 싶다 - [지원] // 실제로 면접 때 이렇게 대답함. * 자신이 주변 사람들과 친하게 지낸다고 생각하는가? === 윤종하 === * 당신이 진행중인 프로젝트가 팀원간의 불화로 파탄 직전까지 갔다고하자. 그리고 이 이유가 기술적인 문제로 인한 팀원간의 불화라고 가정하자. 이 문제를 어떻게 해결하겠는가? * 형진이형이 말씀하신 정체된 개발자, 사람과의 관계가 가장 중요하다는 점에서 생각했습니다. 기술적인 문제로 인함에서 정체된 개발자와 정체되지 않은 개발자는 다른 관점으로 접근할 것으로 생각되기 때문이며, 이 문제를 어떻게 해결하겠는가는 팀원들의 의견을 조율하는데 있어 중요한 점이라고 생각했기 때문입니다. === 김수경 === * 가장 힘들었던 프로젝트(기술적으로든 다른 문제든 해결하기 어려웠던) 경험을 묻고 그 당시 문제를 해결하기 위해 어떻게 행동했는지, 지금 그 프로젝트를 다시 한다면 어떻게 행동할 것인지. === 임상현 === * 너가 가장 하고 싶은 프로젝트가 무엇이고 그를 위해 시도 한 것은? === 서민관 === * 지금까지 겪어 본 버그들 중에서 어떤 것이 가장 처리하기 어려웠는가. * 버그를 발견하고 수정하기까지 어떤 식의 발상을 했으며 잘 모르는 분야일 경우 어떻게 자료를 찾았고 그걸 어떤 방식으로 적용했는가. * 그리고 버그를 처리한 후에 전체 처리 과정을 문서화 하였는가. === 서영주 === * 평소에 당신에게 프로그래밍에 대해서 질문하러 오는 사람이 많이 있는가. 있다면 그에 대해서 당신은 어떤 방식으로 도움을 주는가. 평소에 질문하러 오는 사람이 많다는건 그만큼 프로그래밍쪽에 관해서 아는 것이 많으며 사람들에 대한 인간관계도 괜찮기 때문일 것이라 생각해볼 수 있을 것이므로 실력과 인간관계 양쪽을 다 생각해볼 수 있다. 또 어떤 방식으로 도움을 주느냐에 따라서 주변 사람들의 실력 발전에 도움이 되는지 아닌지의 여부도 고려. 과제를 다 해주거나 하면 상대의 발전은 생각해볼 수 없다 등. * 프로그래밍에 대해서 질문하러 오는 사람이 많다. 내가 알고있는 것이라면 바로 대답해주고 그렇지 않다면 어느정도 시간뒤에 찾아보고 대답해준다. 어느정도 시간은 10분 내외 - [김준석] * 내가 아는 것일 때 적극적으로 도와주려 노력한다. 문제는 내가 모를 때 그에 대해 공부해보지 않는다는 점이다 (찾아보다 포기하는 경우가 많다) - [지원] === 김준석 === * 개발한 개수와 그때 그때 가졌던 직책의 권한 범위 - 개발한 프로그램의 개수를 통해 그 사람의 내공을 알아볼수 있다. 능동적인지 수동적인지 시키는데로만 했던건지 직책과 권한을 통해 이 사람이 무엇을 했는지 알아볼 수 있다. 만약 개발한 프로그램이 수십개가 넘는데 일개 개발자, 일개 개발자, 일개 개발자에 불과하다면 수동적인 사람으로 의심 할 수 있을것이다. 정해진 루틴따라 개발하는 일에서는 그만큼 편하긴 하겠지만 지속적인 변화가 요구되는 분야에서는 힘들것이다. * 일개 개발자라도 프로젝트에 대한 문제점 지적이나 의견, 방향성을 제시할 수 있지 않나요? 저는 진정한 리더란 한발 물러나는 사람이라고 생각합니다. 앞에 나서기 좋아한다고 능동적이고 그래서 좋은 프로그램을 짤 것인가는 알수없을 것 같아요~ - [서지혜] === 정진경 === * 스스로 필요에 의해서 만든 소프트웨어가 있는지? * 있다면 소프트웨어의 규모가 어느정도 인지? 아직도 쓰고 있는지? === 서지혜 === * 프로젝트 진행중에 이 프로젝트가 산으로 가고 있음을 깨달았을 때 당신이 할 수 있는 일은? * 산에서 내려온다. - [김수경] * 내려오기 전에 그 산에서는 뭘 얻었나를 생각한다 - [지원] * 야호~ 하고 소리치는건 어때요? 나 지금 산에 올라왔어요ㅋㅋ - [서지혜] * 프로젝트의 원활한 진행을 위해 자신이 기여할 수 있는 것이 무엇일지 한가지만 말해보아라. ---- [데블스캠프2011/첫째날]