답변:
단점이 보이지 않습니다. 인터뷰에는 많은 부분이 있으며, 후보자는 몇 차례 '사슬 상'을 추천해야합니다.
매주 ~ 10 명을 인터뷰합니다. 저는 정말로 HR이 모든 배경 작업을 수행했으며 많은 메모를 주었다는 사실에 정말로 감사합니다. 그들이 나에게 도착할 때까지, 나는 그들의 시험을 채점 할 시간이다.
테스트는 전적으로 위치에 따라 다릅니다. 일반적으로, 나는 조사하려고합니다 :
일반적인 프로그래밍 기술. 연산자를 효과적으로 사용할 수 있습니까? 기수가 10이 아닌 수치 체계를 상상할 수 있습니까?
우리가 뭘하도록하는지 아십니까?
나열된 오픈 소스 프로젝트에 대한 기여도 평가
나는 짧고 재미있게 유지하려고 노력합니다. 사무실에 들어 오면 답을 잡고 살펴본 후 2 차 면접을 실시합니다. 채용을하려면 일반적으로 3 번의 인터뷰를 거쳐야합니다.
또한 당신을받을 팀과 얼마나 잘 조화를 이루는 지 측정합니다. 그 팀은 저를 효과적으로 수행합니다.
메타 형식으로 질문에 대답하는 것은 실제로 코드를 생성하는 것입니다. 내가 당신을 고용한다면, 나는 당신이 코드를 생산하는 것을 정말로 볼 필요가 있습니다.
저글러를 고용하려고한다면, 그를 저글링하지 않는 것은 미치 겠죠. 또는 오디션을받을 음악가. 그렇지 않으면 당신은 멋진 요요 "마스터"K-strass 같은 것들을 얻습니다 .
화이트 보드에서 무언가를 걷는 것은 프로그래머가 빠른 데모 저글링에 해당합니다.
나는 그것이 매우 유용하다고 생각하며 항상 그렇게하지만 이점이 잘 다루어 졌기 때문에 (명백한) 부정에 대해서만 논의 할 것입니다.
코드 테스트는 잘못된 긍정을 줄 가능성이 거의 없다고 생각합니다. 실제로 코드를 작성할 수없는 사람이 적어도 난이도가 증가하는 질문이있는 경우 인터뷰에서 코드를 위조 할 가능성이 낮습니다. (아마도 가장 대담한 시나리오는 친구와 대면 인터뷰가 아닌 경우 친구에게 물어 보는 바람을 피우는 것일 수 있습니다.)
문제는 거짓 부정적 측면에 있습니다. 코드 테스트로 실제로 가장 좋은 후보자를 거부하게 될까요?
무대 공포증
실제로는 훌륭한 개발자이지만이 인터뷰에 대해 매우 불안한 사람이있을 수 있습니다. 압박을받는 것은 어느 정도 중요하지만, 무대 공포증을 다루는 것이 프로그래머가되는 데있어 중요한 부분은 아니며 (다른 직업과 비교하여), 심하게 고통받는 사람을 거부하는 것은 불행한 일입니다. 이 질문은 복합적 일 수 있습니다. 그 사람이 자신이 대답해야하는 질문에 대답 할 수없는 경우, 사람들은 더 빡빡해질 수 있습니다. 또는 이 질문에서 와 같이 그들은 동시에 대화하고 코딩 할 수 없다고 생각합니다.
완화 : 기술적 인 질문으로 넘어 가기 전에 배경, 목표 등에 대해 알아야 할 몇 가지 질문으로 시작하십시오. 아마도 더 쉬운 기술적 인 질문으로 시작하여 모멘텀을 얻을 수 있습니다. 인터뷰 중에 성가 시게하지 마십시오 (세미콜론 등에 대한 문제).
시끄러운 측정입니다
흥미로운 코드 질문에는 둘 이상의 정답이있을 수 있습니다. 한 사람이 정답을 쓰고 다른 사람이 정확하고보다 효율적인 답을 쓰면 얼마나 많은 무게를 두어야합니까?
어느 정도는 "퍼즐"질문에 대한 문제와 어느 정도 같습니다. 그 사람은 통찰력이 있거나 거의 이진 결과를 얻습니다. 지능은 아마도 그 통찰력을 가질 확률에 영향을 주지만, 몇 번만 샘플링하면 훌륭한 측정 값을 얻을 수 있습니다.
이것은 코드 질문에 대해 귀찮게합니다 (아직도 여전히 사용하고 있습니다). 내가 생각할 수있는 가장 좋은 완화 방법은 가능한 해결책을 최대한 많이 확보하는 것입니다. 사람은 적어도 거친 무차별 대항 답변 또는 문제의 일부. 그것이 무엇보다 낫다는 것을 깨닫는 것은 좋은 징조입니다. 그런 다음 더 많이 발견하면 더 효율적이거나 우아한 코드로 만들 수 있습니다. 가능한 한 이진 응답을받는 질문을하지 마십시오.
실제로 대표하지 않습니다
프로그래밍은 10 분의 알고리즘 문제를 차례로 해결하는 일이 아닙니다. 대인 관계 기술은 말할 것도없이 더 큰 시스템을 이해하고 설계하고 오랜 기간 동안 집중하는 작업이 더 많습니다. 코드 질문은 실제로 이것을 테스트하지 않습니다.
그러나 코드 질문 만이 당신이 묻고 자하는 유일한 질문은 아닙니다 : 당신은 그들의 배경, 그들의 참조, 그들의 오픈 소스 작업 (있는 경우)을보고 지속적인 노력, 창의성, 대인 관계 기술의 증거를 찾을 수 있습니다.
작은 알고리즘 문제를 해결하는 방법과이를 코드로 줄이는 방법을 아는 것은 필요하지만 충분하지 않은 조건입니다. 작은 문제를 해결할 수없고 사소한 코드를 작성할 수없는 경우 세계의 모든 큰 그림 사고가 아닙니다 생산적인 개발자가 되겠습니다.
누구나 해결할 수 있습니다
아뇨. 으로 유명한 FizzBuzz 포스트는 지적, 당신이 생각하는 문제는 업계 경험의 년 사소한 트랩 졸업생하지만 사람들뿐만 아니라이다. 이유를 모르겠습니다. 코드 테스트는 좋지 않은 측정 (가능하지는 않지만 가능할 수도 있음)이거나 이력서의 프로젝트에 크게 기여하지 않았거나 복사 및 붙여 넣기를 통해 많은 작업을 수행했습니다. 알고리즘 코드 (가능한)
알고리즘 코드를 작성하지 않고도 실제로 많은 작업을 수행 할 수 있음을 인정할 가치가 있습니다. 사람들은 "프로그래밍"이라고 부르지 않는 그래픽이나 비즈니스 로직에 가치가있는 앱에서 많은 돈을 벌고 있습니다. 그러나 실제로 프로그래머가 필요하다면 적합하지 않습니다.
잘 보정되지 않았을 수 있습니다
궁금한 점이 있으면 답변이 매우 쉬운 것 같습니다. 그러나 파란색에서 다른 유사한 질문을 받거나 자신의 특정 관심사와 배경에 비뚤어지지 않는 질문이 있으면 훨씬 어려울 수 있습니다.
완화 : 이미 알고있는 일부 개발자에 대해 테스트를 실행하고 수행 방식을 확인하십시오. 아마 당신이 이미 당신의 팀에 매우 똑똑한 누군가가 그들 중 하나에 문제가있을 수 있고 당신은 그것을 조정하는 것을 고려할 수 있습니다. 아마도 그들은 더 나은 또는 다른 대답을 생각할 것입니다.
사소한 것 같아요
사람들이 마음에 모호한 API를 알고 있거나 구문을 완벽하게 얻거나 사소하지 않은 알고리즘의 정확한 정의를 기억한다고 주장하면 코드 질문이 분명히 사소한 일에 빠질 수 있다고 생각합니다. 그것들은 문서, 웹 검색 또는 컴파일러 오류에 의존하여 선택하는 것이 합리적이며 실제 전문 성과는 거의 관련이 없습니다. API가 어디에 있는지 알지 못하는 것은 아마도 최근에 API를 사용하지 않은 단서 일 수도 있지만, 이력서에 누워 있지 않는 한 반드시 문제는 아닙니다.
따라서 이에 대한 대답은 매우 간단합니다. 사소한 질문을하지 말고 사소한 실수에 매달리지 마십시오. 응시자에게 API가 호출 된 것을 상기 시키거나 그들이 찾게하십시오. 구문 오류를 수정하십시오. 데이터 구조 정의를 암기하는 사람들을 테스트하지 마십시오.
당신은 어떻게 비교합니까?
두 명의 응시자가 있고 질문에 잘 대답하면 어떻게 선택합니까? 가장 빨리 끝내는 사람을 선택할 수 있지만 거북이에서 토끼를 선택하기 시작했을 것입니다. 당신은 다른 라운드를 할 수 있고 훨씬 더 어려운 질문을 할 수 있지만 나는 그것에 대해 확실하지 않습니다. 아마도 당신은 그들에게 A +를주고 다른 기준으로 그들 사이에서 선택하려고 노력할 것입니다 (또는 둘 다 고용 할 돈을 찾으려고 노력하십시오).
내가 생각할 수있는 한 가지 단점은 다른 사람들 앞에서 "큰 소리로 코딩하기"어렵다는 것입니다. 나는 내 어깨 너머로보고있는 누군가와 타이핑하는 것이 어렵다는 것을 안다. 나는 혼자가 아니다. 누군가 나를 도와달라고 자신의 워크 스테이션으로 전화를 걸면 갑자기 오타를 시작하고, 잘못된 코드 완성을 선택하고, 실수를 범하기도합니다. 지옥, 나는 사람들이 관찰 중이기 때문에 잘라 내기 및 붙여 넣기 작업에 메뉴를 사용하기 시작하는 것을 보았습니다. 이것은 정상적인 동작이 아니며, 내가 말하는 코더는 뛰어난 프로그래머이며 똑똑합니다.
최근에 면접관이 특정 작업을 어떻게 코딩 할 것인지 물었고 인터뷰에서 "수학을 보여줘"라고 말했습니다. 글쎄, 나는 그 문제를 수학하기 전에 먼저 문제에 대해 생각해야 했으므로 헤밍과 헤이 밍이 발생했습니다. 처음에 화이트 보드에 내려 놓은 것은 당황 스러웠으며, 그 시점에서 내가지고 있다고 느꼈습니다. 나는 결국 A-ha 순간을 얻었고 그 답을 찾았습니다. (실제로 그가 실제로 요청한 것이 실제로 나에게 생겼을 때 ), 제가 도착하기 전에 제가 만든 "메스"는 매우 불편한 느낌을주었습니다. 그럼에도 불구하고, 나는 직업을 얻었지만 면접관이 환자가 적었다면 나는 가지고 있지 않을 수도 있습니다.
인터뷰 대상자에게 코딩 작업을 제공하는 경우 컴퓨터에서, 심지어는 익숙한 IDE에서도 혼자서 작업 할 수있는 시간을 주어야한다고 생각합니다. 그들이 당신을 위해 코드를 작성하고 그것에 대해 이야기하게하십시오. 그들이 어떤 방식으로 일을했는지, 다른 방법으로 나아지지 않는지 물어보십시오. 당신은 그들 앞에서 바로 컵에 오줌을 요구하는 것보다 그런 종류의 과정에서 더 많은 것을 발견 할 것입니다.
단점 :
장점 :
당신은 정말 인터뷰에서 사람 쓰기 코드를 갖고 싶어 - 더 나은, (당신이 편안하게 시간 / 인력으로 감당할 수있는 무엇이든) 시간의 X 금액에 대한 팀의 구성원으로 페어 프로그램으로 그들을 얻을.
그 사람이 코딩 할 수 있는지 아닌지를 알 수있는 유일한 방법 중 하나입니다.
팀 작업을 보여주고, 작업 할 실제 IDE를 제공하고, '실제'문제에 대해 작업 할 수 있도록 페어 프로그래밍을 선호합니다. 결코 합리적으로 알 수 없었습니다).
우리는이 채용 정책을 사용하기 시작했으며 결과에 정말 만족합니다.
내가 말할 것:
찬성
단점
Reverse메소드 또는 이와 유사한 것이 있거나, 필기 테스트를 위해" 클래스 의 Foo메소드에 대한 논거는 무엇인가 "와 같은 것들 Bar, 어떤 멍청이도 구글이 문서를 사용하거나 문서를 사용할 수있을 때) 응시자는 업무를 수행 하고 비즈니스 문제를 해결할 수 있습니다 .한 가지 전문가는 누군가 프로그래밍에 대한 기본 지식이나 그 밖의 것을 알고 있음을 보여줍니다 (마지막으로 만났을 때 SQL 질문이 얼마나 기본적인지 놀랐습니다). 또한 후보자가 왜 그렇게했는지, 어떻게 개선 할 수 있는지를 묻는 기술적 토론의 기초가 될 수 있습니다.
인터뷰에는 시간이 걸리며 다른 것들에 사용될 수 있습니다. 또한 화이트 보드에 코드를 작성하는 것은 자연스러운 환경이 아니며 일부 사람들은 점점 심각한 문제를 겪을 것입니다. 일반적인 도구 나 참조없이 긴장한 개발자를 그리워 할 수 있습니다.
프로그래밍은 분명한 "제공 가능"항목을 가진 고도의 기술입니다. 응시자는이를 전달하거나 전달할 수 없습니다. 따라서 기술적 인 질문을하는 것에 대한 "의견"은 없습니다. "이 응용 프로그램에 대한 코드를 보여 주거나"이미 작성된 응용 프로그램에 대한 코드를 보여줘 "라고 전적으로 말합니다.
그렇게하지 않으면 다음과 같은 결과를 초래할 수 있습니다. 부자는 한 교사를 면담하여 자녀들에게 체스를하도록 가르치고 있습니다 (마음 확장 운동). 튜터는 체크 무늬 보드를 열고 64 개의 사각형에 대해 이야기하기 시작했지만 체스 조각을 건드리지 않았습니다. 시간이 지남에 아버지는 어쨌든 교사를 고용했다. 그리고 교사는 아이들에게 CHECKERS를하도록 가르쳤다.