좋은 프로그래머를 인식하는 방법? [닫은]

우리 회사는 새로운 프로그래머를 찾고 있습니다. 그리고 여기에 문제가 있습니다-인터뷰를 정말 잘보고, 필요한 기술을 알고 있고 좋은 직업 배경을 가지고있는 것처럼 보이는 많은 개발자가 있지만 2 개월의 작업 후에는 일할 수 없다는 것을 알게됩니다 팀에서 일부 코드를 작성하면 시간이 오래 걸리며 결과는 좋지 않습니다.

공식화 된 테스트를 사용합니까? 좋은 프로그래머와 좋은 사람을 어떻게 인식합니까? 미래의 문제를 드러 낼 수있는 간단한 '좋은'질문이 있습니까? ... 또는 그 사람에 대한 '느낌'(즉, 주로 당신의 경험)과 그 / 그녀를 시험해 보는 것입니까?

편집 : Manoj의 답변에 따르면, 다음 은 면접에서 코딩 작업과 관련된 질문입니다.

그들이 관심있는 것에 대해 이야기하게하십시오. 아직 프로그래밍에 관해 이야기 할 때 열정적이지만 실제로는 코드를 작성할 수없는 개발자를 만나지 못했습니다. 물론 물론 존재할 수도 있으며 인터뷰에서 역량도 확인해야하지만 열정은 내 경험에서 좋은 지표입니다. (이것은 유행어 측면에서 "이야기"를 할 수있는 것과는 다릅니다.)

그들이 좋아하는 언어 나 플랫폼에 대해 싫어하는 점을 물어보십시오. 그들은 어떻게 문제를 해결하겠습니까? 다음 버전에서 무엇을보고 싶습니까? 그들은 취미 프로젝트가 있습니까? 그들이 블로그를 가지고 있다면 그것을 읽으십시오. 일반적인 온라인 상태를 확인하십시오.

좋은 사람들을 고용하는 것은 어렵다 .

내가 더 나아지기까지는 실수가 많이 걸렸다. 처음 몇 번은 신뢰하지 않고 후회 한 후에 장을 훨씬 더 신뢰하기 시작합니다.

나는 Steve Yegge의 전화 화면 질문에 대해 큰 존경심을 가지고 있으며이를 성공한 사람들을 인터뷰하기위한 기초로 사용했습니다.
또한 게릴라 인터뷰에 대한 Joel의 가이드를 읽은 후 사람들을 인터뷰하는 데 더 나아 졌다고 생각합니다 (현재 3.0 버전에서는 웹 버전보다 앞서 있으며 모든 것이 좋을 것입니다).

인터뷰로 태그가 지정된 Software Engineering Stackexchange 에 대한 57 개의 다른 질문들 ( 2008 년 11 월 20 일 현재)이 있으며 그중 일부 는 매우 관련성이 있으므로 확인하십시오.

몇 가지 아이디어 :

• 여러 가지 각도에서 여러 가지 개방형 질문을하십시오.

  • 일부 코드를 검토하십시오. 무엇이 식별 되었습니까? 기술적 오류, 스타일 불일치, 주석, 알고리즘, 유지 관리 성 등
  • 코드를 작성하십시오. 프로세스, 방탄, 가독성 등을 찾으십시오.
  • 소규모 시스템을위한 고급 디자인을 만듭니다. 문제, 접근 방식, 커뮤니케이션, 완전성, 세부 사항에 대한 이해를 찾으십시오.
  • 소프트웨어 개발 프로세스를 설명하십시오. 디자인, 협업, 검토, 테스트, 좋은 / 나쁜 습관 및 전반적인 경험을 찾습니다.

• 후보자가 잘 알고 있다고 주장하는 것을 선택하십시오. 간단한 질문을 한 다음 답변에 따라 약간 더 자세한 질문을 한 다음 응시자의 지식 한계에 도달 할 때까지 "발굴"을 계속하십시오. 이것은 당신에게 아이디어를 제공합니다 :

  • 정직 : 청구 한만큼 알고 있습니까?
  • 지식의 깊이 : 얼마나 잘 배우는가?
  • 의사 소통 : 당신에게 익숙하지 않은 것을 얼마나 잘 설명합니까? 사고 과정은 논리적입니까?
  • 스트레스가 많은 상황에 대한 반응 : 대답하기가 얼마나 어려운가요? 그는 가짜입니까? 피할 수없는 "모르다"가 쉽지 않습니까?

• 후보자가 이전 작업 (팀워크, 기한이 지난 프로젝트, 디버깅 등) 과 같은 다양한 상황을 어떻게 처리했는지 묻습니다 . 답변이 긍정적이거나 부정적입니까? 열렬한? 지능형? 거만한?

나는 최고의 후보자가 열성적이고, 노련하고, 자신감이 있지만 예의 바르고, 가장 중요하고, 현재 존재하는 것으로 나타났습니다 . 안에 누군가가 있다는 것을 알아야합니다. :-)

좋은 프로그래머를 알아 보려면 좋은 프로그래머 가되어야 합니다. 즉, 인터뷰에서 말하고 행한 내용을 살펴 보려면 프로그래밍을 잘 알고 있어야하며 어떤 질문을해야하는지 알아야합니다.

나는 인터뷰에서 응시자들이 오답을 보인 것을 보았지만 그들의 설명은 그들이 그 주제를 알고 있다는 것을 보여 주었고 (따라서 인터넷을 검색하여 쉽게 정답을 얻을 수 있음). 이를 확인하려면 질문을하는 주제를 잘 알아야합니다.

또 다른 것은 쉽게 구글 검색 할 수있는 세부 사항에 대한 질문을 피하는 것입니다. 이 질문은 후보자가 실제로 알고있는 지식과 이해력이있는 것이 아니라 사물을 기억하는 것이 얼마나 좋은지를 보여줍니다.

저의 추천은 인터뷰를 도울 수 있도록 많은 프로그래밍을 알고 있고 훌륭한 기술을 가진 사람의 도움을받는 것입니다.

편집 : 나는 또한 인터뷰에 대한 코멘트 썼다 여기를 .

프로그래밍 능력이 전부는 아닙니다. 세계 최고의 프로그래머가 당신을 위해 일할 수는 있지만 다른 사람들과 일하는 것을 싫어한다면 그다지 유용하지 않을 것입니다.

프로그래머의 성격은 대부분의 고용주가 순위를 매기는 것보다 목록에서 더 높아야합니다. 현재 직장에서는 올바른 유형의 사람을 고용하는 데 매우 신중합니다.

사람들은 일반적으로 더 나은 프로그래머가되는 법을 배울 수 있고 사람들은 더 나은 사람이되는 법을 배울 수 없습니다.

코드를 작성하십시오. 4 시간 또는 5 시간 내에 해결 될 수있는 문제를 제시하고 문서화, 코딩 스타일, 실제로 코딩을 시작하기 전에 솔루션을 계획 한 방법 등을 검사합니다. 실제로 문제를 해결할 필요는 없습니다. Jon Skeet이 언급했듯이 프로그래밍, 선택한 언어 및 이와 유사한 것에 대해 이야기하게하십시오. 좋은 프로그래머에 대한 열정을 조정할 수 있습니다. 그들이 얼마나 많은 프로그래밍 관련 사이트를 따르는 지 물어보십시오. 그들이 팔로우하는 블로그는 좋은 지표가 될 수 있습니다.

나는 열정적 인 대답을 좋아한다. 나는 당신이 실제로 그것을 잘하기 위해 당신이 일하는 것에 열정적이어야한다고 믿습니다.

일 이외의 측면에서 좋은 프로그래머 프로그램 (적어도 한 번은). 프로그래밍 문제를 해결하는 것을 좋아합니다. 그리고 집에서 특정 요구를 해결하는 프로그램을 찾을 수 없을 때는 일반적으로 스스로 해결하려고합니다.

그러나 몇 가지 유형의 프로그래머가 있습니다.

• 문서화를 좋아하는 사람이 있습니다. 개인적으로 나는 문서화가 싫어. 그러나 수행 된 내용을 문서화하는 것이 중요 할 수 있습니다.
• "해커"가 있습니다. 복잡한 퍼즐을 푸는 데 어려움을 겪는 사람들은 구글을 ​​어디에서 구해야하는지에 대한 해결책을 찾지 못할 것입니다. 필요한 도구를 갖추면 "모든"문제를 해결할 수 있습니다.
• 당신은 시장이 프로그래밍을 위해 고용되기에 좋았 기 때문에 스스로 프로그래머가되도록 교육하는 사람들이 있습니다. 그들은 열정이 없기 때문에 보통 평범합니다.
• 당신은 의사 소통에 능숙한 사람들을 가지고 있고 그들은 "무엇이든 해결할 수 있습니다". 그러나 일단 그들이 일을 마치면 그들은 해결하고있는 문제에 대한 도움을 얻기 위해 다른 모든 사람들에게 매달립니다.

문서를 잘 작성하고 의사 소통 능력이 뛰어난 "해커"를 찾으면 대박을 쳤다고 생각합니다.

아, 그리고 마지막 것. 리더 야망을 가진 프로그래머는 아마도 프로그래밍을 사용하여 시작하기 때문에 원하지 않을 것입니다. 즉, 해당 리소스를 조만간 잃게됩니다.

프로그래머를 고용 할 때 물어볼 질문은 "왜 프로그래머로서 자신을 교육 했는가?"입니다. 그들이 주저한다면 그것은 죽은 선물이 될 것입니다.

내 의견이다.

저의 친구는 회사에서 일하면서 채용 과정에서 추가 단계를 밟습니다. 초기 선별 및 인터뷰 후에 신청자는 며칠 동안 "작업을 테스트"해야합니다. 그는 때문에 그들이 그를 고용하지 않았다하더라도 하나 개의 후보가 모든 기술과 재능이 필요했다라고 나에게 이야기 하는 A 와 함께 작동하지 않는 좋은 사람이.

면접만으로 프로그래머를 알아 보는 것은 매우 어렵습니다.

누군가가 좋은 프로그래머라고 결정하는 것은 다음과 같습니다.

• 팀에서 일할 수있다
• 이해하기 쉽고 좋은 코드를 작성합니다
• 새로운 기술에 대해 배울 수 있습니다

인터뷰에서 알아볼 수있는 몇 가지 힌트가 있습니다.

• 응시자는 하나의 기술 / 프로그래밍 언어를 알고 있거나 여러 언어를 알고 있습니까? 그가 다른 언어를 안다면 새로운 것을 배울 수있을 것 같으며 현재 선호하는 기술 / 언어의 단점을 알고있을 것입니다. 따라서 회사에서 사용하는 기술 외에 지식을 요구하십시오.
• 그가 이미 일한 프로젝트, 특히 취미 프로젝트 및 오픈 소스를 요청하십시오. 취미 프로젝트는 프로그래밍을 좋아하고 여가 시간에도 프로그램을 수행한다는 것을 보여줍니다 (이 방법은 그의 기술을 향상시킵니다). 오픈 소스 프로젝트에서 그가 작성한 코드를 찾을 수 있습니다. 프로젝트에 한 사람 이상이 참여하는 경우 팀 기술에 대한 힌트를 얻을 수 있습니다. OS- 프로젝트에서 메일 링리스트 아카이브를 조회하여 자세한 내용을 알 수 있습니다.

인터뷰에서 몇 가지 테스트를 수행 할 수 있습니다.

그러나 작업 환경 자체에도 여러 가지 문제가 있습니다. 분명히 이것은 조직의 경우가 아닐 수도 있지만 소프트웨어 산업 분야에서는 기술 부채가 너무 커지는 것이 일반적입니다. 그런 다음 새로운 사람들을 고용 할 때, 빚 때문에 그들이 좋은지 아닌지는별로 도움이되지 않습니다. 프로그램 코드의 가독성과 이해성을 극대화하면 새로 온 사람들이 일을 시작하는 데 도움이됩니다.

또한 많은 사람들이 협력 할 수 있지만 때로는 협력 할 방법이 없습니다. 예를 들어, 모든 사람들이 개발자라면 그들은 일을해야합니다. 글쎄. 그러나 개발 프로젝트를 이끌고 회의를 계속하는 건축가가 있습니까? 정상적인 개발자는 회의를 시작하는 데 필요한 권한이 없다고 생각할 수 있으며 지금은 다른 사람들을 방해하는 것이 아니라고 생각할 수 있습니다.

서로 의사 소통하는 것이 최종 목표가되어서는 안됩니다. 의사 소통이 적을수록 더 좋을 수 있지만 가능한 적은 경우에만 가능합니다. 건축가가 있으면 덜 가능해집니다. 총 통신량은 양호하지만 동일한 통신량에 대해 더 많은 결과를 얻을 수 있습니다.

먼저 나는 보통의 인터뷰 자료부터 시작해서, 내 앞에있는 사람이 무언가 가치가 있는지를보고, 자신의 기술과 지식을 결정하는 것이 매우 중요하다고 생각합니다.

그 후 저는 Java 분야에서 몇 가지 기술을 사용합니다. 주로 효과적인 Java에서 가져온 몇 가지 원칙을 논의하는 것과 같습니다.

이 단계에서 내 앞에 좋은 프로그래머가 있다고 생각하면 코드 검토를 위해 코드 조각을 제공합니다. 내가보고 싶은 것은 코드의 위험한 부분을 찾아 내고, 개선에 대한 몇 가지 지침을 제시하고, 멀티 스레딩 성능에 대한 함정을 발견하고, 중요한 발언과 "맛-발언"을 구별 할 수 있다는 것입니다. 이 모든 것이 더 유능한 직원을 찾는 데 도움이됩니다.

그러나 결국 나는 항상 고용이 일종의 도박이라는 것을 기억합니다.

나는 이것이 당신이 요구하는 것에 대한 답이 아니라는 것을 알고 있지만, 법이 허용하는 법은 항상 (일차에 따라 2 주 또는 한 달) 항상 임시로 고용하는 것이 좋습니다. 그 사람이 소금의 가치가 있다면 그는 반대하지 않을 것입니다. 두 사람 모두를위한 보호 수단입니다 (당신이 그를 놓아 줄 수 있고 결국 직장을 좋아하지 않고 떠날 수도 있습니다).