나는 딜레마가있다. 선임 소프트웨어 개발자 직책에 후보자가 있습니다.

그 사람은 그와의 첫 대화에서 유능한 것처럼 보였고 그는 정확하게 묻는 질문에 대답하고 자신의 작업에 대한 증거를주었습니다. 또한 그는 일부 신뢰할 수있는 동료들로부터 강력히 추천되었습니다.

이 경우 공석을 최대한 채워야하므로 HR에 필요한 기술 테스트를 건너 뛰고 싶습니다. 당신의 경험을 공유하십시오.

편집하다:

더 나은 판단에 반대하여 나는 시험을 주었다. 그가 자랑하지 않은 주제에 이르기까지 거의 모든 질문에 대한 최고 점수. 그러나 나는 시험 문제를 보았을 때 그에게 약간의 아이러니를지지했습니다.

그래서 우리는 제안했다.

통찰력을 가져 주셔서 감사합니다.

평소와 같이 ...

그것은 달려있다

역량을 입증 한 기술 테스트를 본 적이 없습니다. 나는 테스트 메이커와 테스트 테이커의 부분에서 무지를 입증 한 많은 기술 테스트를 보았다.

기술 테스트에 대해 얼마나 확신하십니까? 가져 갔어? 공정하다고 생각하십니까?

자신감있게, 나는 온라인 기술 테스트를 잠시 동안 클라이언트에게 호의적으로 보냈고 (신규 채용에 대한 '기준선'으로 점수를 원했다) 실패했다 . 주로 테스트 질문은 특정 구문에 대한 구문과 함수 이름으로 만 구성 되었기 때문이다. 특정 언어의 버전. 나는 언어를 항상 사용하고 몇 년 동안 가지고 있지만 특정 기능은 없습니다 . 이것들은 내가 필요할 때 / 필요할 때 찾아 볼 수있는 모든 것들이었습니다.

실제로 테스트에 달려 있습니다. 기술 테스트가 중요하다고 생각되면 반드시 관리하십시오. 당신이 그때 그것을 제거 하지 않으면 . 개인적인 면담과 신뢰할 수있는 동료의 추천에 근거한 인상은 어느 시험보다 훨씬 가치가 있습니다.

기술 테스트 결과에 따라 채용 결정에 차이가 있습니까? 귀하와의 대화의 강점과 신뢰할 수있는 동료의 추천이 기술 시험 결과와 관련이 없을 정도로 강력합니까?

테스트에서 차이가 없으면 건너 뛰십시오.

나는 하지 않는 테스트를 건너 뛸 강한 인수를 참조하십시오. 따라서 보관해야 합니다.

응시자가 시험을 치러야한다고 생각한다면, 그 자체로 말하고 있습니다.

테스트가 관리 결정에 시간이 오래 걸리고 채용 결정이 지연되었음을 의미하는 경우 테스트 자체를 검토해야합니다.

반대로, 결과에 관계없이 사람을 고용하려는 경우 그 결과없이 계속 진행하지만 테스트 정책을 다시 방문하여 명시 적으로 선택적으로 만들어야합니다.

기술 테스트가 일반적으로 유용한가요 아니면 BS입니까? 당신이 원하는 고용으로가는 길을 막는 것을 두려워하거나, 그를 화나게 할까봐 두려워 그를 빨리 고용하기를 원하기 때문에 그것을 건너 뛰고 싶습니까?

일반적으로 규칙 규칙을 만드는 것이 좋습니다. 한 사람에 대한 예외를 만들기 시작하면 화상을 입을 때까지 점점 더 많은 예외를 만들기 시작하고 규칙이 존재하는 이유를 알아야합니다. 그리고 나쁜 고용은 정말 고통스러운 실수입니다. 그러나 규칙이 유용한 경우에만 해당됩니다. 이 규칙이 유용한 지 여부 는 기술 테스트에 따라 다릅니다.

둘째, 고용에 대한 압력이 아무리 커도 급한 결정을 내릴 수 없습니다. Haste는 우리가하지 말아야 할 때 경고 신호 등을 무시할 때 예라고 대답합니다. 실제로 압력이 가해질수록 올바른 결정을 내릴 수 있도록 압력을 더 강요해야합니다.

셋째, "당신이 다른 모든 것에도 불구하고 그가 시험을 통과하지 못할 까봐 두렵습니다"라고 말하는 잔소리가 들리면 시험을 건너 뛰지 마십시오. 이것은 올바른 고용이 아닐 수도 있습니다.

마지막으로, 후보자가 좋은 경우, 기술 테스트를 받아야해서 후보자를 불쾌하게하지 않을 것입니다. 후보자는이를 조직에 대한 좋은 신호 로 볼 수 있습니다. 널리 인용 된 Joel 테스트 의 항목 11입니다 . 결국 그들은 기술 테스트를 통과하지 않았으며 아마도 그 경험을 반복하고 싶지 않은 개발자들과 일하는 것에 불만을 느꼈습니다.

그 모든 이유를 들어 당신은 테스트를 제공해야 하는 경우를 (그리고이 경우 중요) 테스트는 교체해야 BS의 명백한 조각없는 유용한 기술 시험.

우리는 최근에 같은 상황에 처해있었습니다. 우리는 초기에 모든 올바른 책을 읽고 모든 올바른 유형의 프로젝트를 수행하는 것처럼 보였으므로 깊은 기술을 건너 뛰었습니다. 그는 정말 좋아 보였다.

몇 주 후에 그는 인터뷰에서 그가 말한 수준에서 실제로 코드를 작성할 수 없다는 것이 분명해졌습니다. 그의 성격은 팀에 맞지 않았습니다. 그를 제거하고 그가 한 일을 정리하는 것은 엉망이었습니다.

누군가를 고용하기 전에 기술을 수행하십시오.

공정성을 위해 테스트를 유지하십시오. 다른 신입 사원이 나중에 시험을 치러야한다는 것을 알게되었지만이 사람은 그렇지 않은 경우 분노를 유발할 수 있습니다.

이 시험은 모든 사람 또는 아무도에게 적용되어야합니다. 선택적으로 적용하려면 포기할 수있는시기를 설명 하는 명확하고 서면 정책 이 있는지 확인하십시오 .

기술 테스트의 가치는 다양하며 테스트가 수석 개발자가 고용 한 역할과 얼마나 잘 일치하는지에 따라 크게 달라집니다. 내 말은 오라클 개발자에게 임베디드 시스템 엔지니어링에 대한 질문 목록을 제공 할 것입니다 (이 점을 입증하기에는 나쁜 예입니다).

기술 테스트에서 선임 개발자의 점수가 낮더라도 응시자를 고용하는 데 장애가됩니까?

당신이 시간에 압박을 받았다고 언급 했으므로 그 결정 때문에 서두르지 마십시오. 선임 개발자가 자신의 책임 영역에 미치지 못하는 사람으로 판명되면 프로젝트가 일정보다 뒤처지게됩니다.

돌아서

귀하가 신뢰하는 사람들의 추천을받는 영구적 인 선임 고용인 인 경우, 향후 면담 팀을 찾게 될 수도 있습니다. 이 잠재적 인 선임 개발자에게 가장 좋아하는 기술 인터뷰 테스트 질문과 다양한 답변의 강점과 약점을 어떻게 평가할 수 있는지 문의하십시오. 어쩌면 그것들을 테스트하기 위해 새로운 나쁜 답변을 만들어 낼 수도 있습니다. 이 시간을 사용하여 많은 것을 배울 수도 있습니다 (또는 적기를 발견 할 수도 있습니다).

그런 다음 자신의 질문에 대한 답변 중 일부를 "기술 테스트 완료"로 표시하십시오.

이런 식으로 생각하십시오-당신보다 조금 더 훌륭한 사람을 고용하거나 지금 당장 끔찍한 사람을 고용하는 것의 차이점은 무엇입니까?

또한이 테스트가 평가하도록 설계된 작업을 얼마나 수행하고 있다고 말할 수 있습니까?

저는 약 99 %의 후보자가 프로그래밍 테스트를 통과해야하는 회사에서 일합니다. 통과하지 않아도되는 1 %는 두 가지 범주로 나뉩니다. 첫 번째 카테고리는 우리가 적극적으로 채용 한 "rockstar"유형입니다. 두 번째, 그리고 아마도 더 관련, 카테고리는 프로세스가 매우 강력한 실적 고용이 고위 인사에 의해 면제 된 누구를 위해 사람들 과 그들이 고용하고있는 작업을 수행 할 수있는 사람을.

개인적으로, 나는 이것이 좋은 정책이라고 생각하며 귀하의 상황에 권장합니다.

어쨌든 나는 시험을 할 것이다. 그는 여러 가지 이유로 추천 될 수 있습니다 (일부는 당신에게 유익하지 않을 수도 있습니다 ...). 기술 인터뷰의 한 가지 이점은 다른 팀 구성원과의 유대 프로세스를 시작하는 것입니다. 채용 프로세스에 팀을 구매할 필요성을 과소 평가하지 마십시오.

HR의 제한 사항이 주어지면 사이버 도조 사본을 다운로드 할 것이라고 생각합니다. 로컬 서버에 설치하고 해당 서버에만 액세스 할 수있는 웹 브라우저 앞에 후보자를 앉아 여러 카타를 선택하도록 요청합니다 (선택) 그들이 선택한 언어로 (카타마다 다른 언어가 이상적임).

그런 다음 신호등 순서를 확인하십시오. 그들이 좋은 TDD 개발자라면 반복적으로 빨강 / 녹색 진행이 반복되어야합니다.

^{사이버 도조와 함께 플레이하고 싶다면 저자는 여기에 멋진 온라인 버전이 있습니다 .}

또 다른 질문-HR 부서에 얼마나 많은 신뢰가 있습니까?

여기에 환각적인 KoolAid를 너무 많이 마시고있을 수도 있지만, 채용에 대한 특정 보호 조치를 구현할 때 HR 부서가 좋은 계획을 가지고 있다는 것을 알게되어 기뻤습니다. 예를 들어, 수석 직원이 C #이 아닌 Oracle에 필요할 것 같으므로 C # 테스트는 관련이없는 것 같습니다. 그러나 HR 부서가 여러 프로젝트에서 점수를 낼 수 없을 때 누군가를 해고하는 것이 얼마나 어려운지에 매우 민감한 경우, 장기적으로 모든 사람이 단기적으로 필요로하는 사람이있을 수 있습니다. 개발자는 널리 사용되는 프로그래밍 언어에서 최소한의 역량을 충족 할 수 있습니다.

그것은 모두 현재 채용 방법론, 회사를 관장하는 법률 및 전반에 걸친 기술 능력의 필요성과 관련이 있습니다. 일부 회사에서는 보호 관찰 기간과 같은 설정을 통해 누군가와 함께 시범 운영을 시작한 다음 처음 3 개월 동안 문제가 해결되지 않으면 놓아 둘 수 있습니다. 다른 회사에서는 누군가가 영구 직원으로 출입하는 순간 엄청난 공정 치료 보호를 받으므로 측정하지 않는 사람을 제거하기 전에 오랫동안 유지하고 재교육해야합니다. 쪽으로.

귀사를 둘러보고 단기적으로 이러한 기술을 보여줄 필요는 없지만 어느 정도의 부지런히해야 할 이유가 있는지 확인해 보겠습니다. 특히 수석 엔지니어의 급여에 따른 장기적인 영향은 엄청날 수 있습니다.

마감일이 다가오고 있다는 사실을 여러 번 반복했습니다. Brook의 법칙에 대해 알고 있다고 가정합니다.

여기에서 실제 인터뷰 과정에서 어떤 지연이 발생할 수 있는지 확인할 수 있습니다. 그가 유능한 후보자로서 뛰어 들어 마감 시한 문제를 해결할 수 있다고 생각하면 인터뷰 / 페어 프로그래밍에 몇 시간을 소비하는 데 아무런 문제가 없어야합니다. 고려해야 할 또 다른 요소는 현재 동료입니다. 당신은 사람들이 당신의 변덕에 따라 들어오고 떠나는 느낌을 더 큰 팀에게 느끼고 싶지 않습니다. 왜냐하면 남자가 빠져 나오면 보통 나쁜 것을 반영하기 때문입니다. 이것이 HR이 여러 인터뷰를 고집하여 한 사람이 suc에 동요하지 않는 주된 이유입니다.

채용 및 프로젝트에 행운을 빕니다!

일반적으로 계약의 일부로 고용 시작시 시험 기간으로 6 개월이 있습니다. 응시자가 완전히 무능한 경우, 처음 몇 개월 동안은 분명해지며 적어도 시험 기간 후에 종료 할 수있는 옵션이 있습니다. 또한 아무도 모든 것을 알 수 없으며 사람들이 종종 역할을 수행하는 데 시간이 필요하고 실제로 경력 사다리를 세우고 있기 때문에 판단을 내리기 전에 약간의 시간이 걸릴 수 있다고 지적합니다. 파티!)

솔직히 말해서 (또 다른 질문에 대한 답을 반복하기 위해) 나는 기술 인터뷰를하지 않은 상점에서 고용되는 것에 대해 조심할 것입니다. 나는 기술적 인 우수성에 대한 그들의 의지를 의심하며, 결정을 내리기 전에 팀과 "상점을 나눌 수있는"기회를 갖지 않을 것이라는 점을 좋아하지 않습니다.

기술 면담을 통해 팀원이 그 사람을 알게되고, 그 사람을 알게 될 기회를 가지십시오. 그 사람은 선임이기 때문에 기술적 인 문제에 관해 명확하게 의사 소통 할 수있는 것이 매우 중요합니다. 심층적 인 기술 인터뷰없이 어떻게 테스트 하시겠습니까?

요컨대, 표준 기술 인터뷰를 포기할만큼 중요하다면, 그와 특별한 기술 인터뷰를 수행 할만큼 중요합니다.