이것은 다소 주관적인 질문이지만 주제에 대한 인터뷰 담당자 / 인터뷰 담당자의 의견 / 의견을 듣고 싶습니다.
기술 인터뷰를 4 개 부분으로 나누었습니다. 화이트 보드에서 코드 작성, 코드 읽기 및 분석, 디자인 세션 및 코드
인터뷰 대상자에게 요청하는 마지막 부분은 화이트 보드에 작은 코드 스 니펫 (4-5 줄)을 작성하고 진행 과정을 설명하는 것입니다. 사람들을 사로 잡는 것이 아니라는 점을 분명히하겠습니다. 우리는 완벽한 구문을 찾고 있지 않습니다. 그것은 심지어 의사 코드 일 수도 있습니다. 그러나 요점은 그들에게 매우 간단한 문제를 제시하고 그들의 두뇌가 솔루션을 우리에게 전달할 수 있는지 확인하는 것입니다. 간단한 문제로 “문자열 반전”, “FizzBuzz”등을 의미합니다.
우리는 항상 명시 적 언어를 먼저 요구합니다. 우리는 .NET C # 하우스입니다. 우리는 누군가가 코드를 비우거나 실제로 어려움을 겪고있는 “의사 코드”라고 말했습니다.
내 질문은 “프로그래머가 인터뷰 중에 화이트 보드에 코드 스 니펫을 작성하는 것이 부적절하거나 비합리적입니까?”입니다.
답변
내 견해로는 매우 적절하다. 직업이 특정 기술을 수행하기를 원하는 경우 인터뷰에서 해당 기술을 입증하는 것이 전적으로 적합합니다.
이 기술이 채용 프로세스에 미치는 영향은 매우 두드러집니다. 응시자의 90 %가이 작업에 실패했습니다. 그러나 채용 된 개발자는 훌륭하며 회사 내에서 개발자를 존중할 것입니다.
이 기술에 직면 한 후보자라면 우선 휴식을 취하십시오. 프로그래머로서의 평가와 사고 과정에 관한 것입니다. 완벽한 구문에 관한 것이 아닙니다. 구문 오류가 발생하면 컴파일러의 역할을 수행하고 코드가 특정 줄에서 컴파일에 실패하고 오류 메시지를 표시하고 응답 방법을 알 수 있습니다. 마찬가지로;를 추가하면; 컴파일 할 루프 또는 if 문에 디버거를 재생하고 코드를 통해 단일 단계를 안내합니다. 다시 한 번, 실수에 관한 것이 아니라, 실수에 대처하는 방법에 관한 것입니다.
답변
내 질문은 “면접 중 프로그래머가 화이트 보드에 코드 스 니펫을 작성하는 것을 기대하는 것은 부적절하거나 비합리적입니까?”입니다.
매우 합리적입니다. 프로그래머는 화이트 보드보다 키보드에서 코드를 작성하는 데 더 익숙하기 때문에 화이트 보드의 대안은 랩톱 및 비머 일 수 있습니다. 후보가 시작될 때 Eclipse 또는 VS 또는 유휴와 같은 개발 환경이 빈 프로젝트로 이미 실행 중인지 확인하면 설치된 애플리케이션을 검색하는 데 시간을 낭비하지 않아도됩니다.
답변
부적절한 것은 아니지만 인터뷰하는 사람의 프로그래밍 또는 문제 해결 능력에 대한 진정한 통찰력을 항상 밝힐 수는 없습니다. 그리고 나는 그것이 당신이 추구하는 것과 정확히 일치한다고 생각합니다.
둘째, 항상 실패에 대한 두려움이 있으며, 사람의 두뇌를 끊임없이 쐐기풀 게합니다. “내가 실수하면 어떡해?”, “어리석은 실수를하면 어떡해”. 뇌의 많은 부분이 끊임없이 어떻게 나오는지 검사하는데 바쁩니다. 신경을 유지할 수있는 사람은 거의 없습니다.
따라서 이런 상황에서는 최고조차도 쇠약해질 수 있습니다.
마지막으로 인터뷰 대상자들에게 화이트 보드에 작은 코드 스 니펫 (4-5 줄)을 작성하고 진행 과정을 설명합니다.
괜찮아. 그러나 다시, 누군가가 무언가를 제대로 설명 할 수 없다고해서 그것을 잘 모른다는 것을 의미하지는 않습니다. (설명은 연설의 예술입니다).
내가 당신이라면, 나는 이것을 할 것입니다 마지막 부분을 위해 …
매우 작지만 현실적인 프로젝트를 위해 그들을 고용하십시오. 그들이 어떻게 코딩하고, 결정을 내리고, 근무 조건과 팀원 등을 동화 한 다음,이를 바탕으로 최종 결정을 내립니다.
답변
부적절하지는 않지만 일부 사람들 (아마도 프로그래머 군중의 더 큰 비율)은 인터뷰에서 매우 스트레스를받을 수 있습니다. 우리 대부분은 훌륭한 코더이자 믿을만한 사람인 사무실 직원을 알고 있지만 그런 상황에서 녹아 버릴 것입니다. 그의 테스트는 그러한 테스트에서 측정 될 수 없었으므로, 이것을 go / no go 테스트로 만들지 마십시오.
답변
나는 이것이 당신이 할 수있는 가장 좋은 일 중 하나라고 생각합니다. 당신이 말한 것처럼 올바른 구문이나 이와 유사한 것을 찾지 못한다면 여기에서 가장 중요한 부분은 누군가가 의사 소통 할 수 있는지 확인하는 것입니다 … 나는 자신의 공간 안에서만 혼자 일할 수있는 많은 훌륭한 개발자를 보았습니다 … 불행히도 이것은 엄청나게 많은 경우에 가능하지 않기 때문에 자신이 생각하는 것을 명확하고 간결하게 말할 수있는 숙련 된 사람을 갖는 것이 팀의보다 가치있는 구성원이라고 생각합니다. “그들은 그것을 이해할 수 없습니다. 어쨌든, 나는 그것을 스스로하고 나중에 보여줄 것이다 “.
모든 중소형 프로젝트의 기초가되는 커뮤니케이션, 커뮤니케이션, 커뮤니케이션
답변
나는 그것이 합리적인 것이 아니라고 생각합니다. 우리는 우리가 원하는 일에 능숙한 후보자를 찾으려고 노력합니다. 화이트 보드에 코드를 작성하는 것은 그중 하나가 아니며 좋은 후보를 찾는 데 유효한 필터라고 생각하지 않습니다.
- 좋은 코드는 작성되지 않고 다시 작성됩니다. 화이트 보드는 한 번 작성한 후에는 변경하기 어렵 기 때문에 거의 변경할 수 없습니다. 문제를 더 잘 이해하자마자 마음을 바꾸는 것이 쉬워야합니다.
- 인터뷰에 참석하는 것은 스트레스가 많은 상황이므로 후보자에게 추가 압력을 가할 필요가 없습니다. 많은 컴퓨터 사람들이 필기를 잘하지 못합니다. 최신 IDE는 익숙한 많은 도구를 제공합니다. 그리고 필요한 순간에 무언가를 구글로 검색 할 수 있다는 것은 대부분의 프로그래머의 작업 스타일의 일부입니다. 왜 이러한 모든 것들을 빼앗아 인공 환경을 조성하면 그들이 제안을하더라도 결코 일하지 않아도 될까요?
- 우리는 또한 좋은 테스트를 작성하는 능력에 관심이 있으며 TDD를 할 수도 있습니다. 화이트 보드 코딩 중에는 볼 수 없습니다.
화이트 보드 코딩 세션에서 나올 수있는 대부분의 실마리도 페어링 세션에서 나올 수 있습니다. 그리고 페어링은 느낌을 얻는 데 훨씬 더 좋은 도구입니다. 그는 자신의 컴퓨터를 가지고 자신이 편한 환경에서 일할 수 있습니다. 또한 일단 가입하면 원하는 작업에 적용하기가 훨씬 쉽습니다. 예를 들어 레거시 코드 기반이 크므로 실제 프로젝트를 위해 추출 된 코드를 리팩터링하도록 요청합니다. 그리고 우리는 실제로 일상 업무에서 가능한 한 많이 짝을 이루기 때문에 적합합니다.
화이트 보드 세션은 나쁜 후보를 걸러내는 데 도움이되지만, 많은 훌륭한 프로그래머를 걸러 낼 수도 있습니다.
답변
개인적으로 FizzBuzz를 요청하는 면접관이 나왔습니다. 이것이 언제 새로운 산업 표준이되었는지는 모르겠지만 실제로 시간 낭비입니다. FizzBuzz는 인터뷰 전에 사용할 수있는 필터입니다. 개인적으로 공개 소스 코드 나 블로그를 볼 수있는 N 후보자를 선택해야한다면 필터로 선호합니다. .
간단히 말해서, 나는 프로그래밍 위치에 대한 인터뷰에서 (주니어 나 인턴쉽을 제외하고) 인터뷰 대상자가 프로그래밍 할 수 있다고 이미 설정 / 결정되어 있어야합니다.
그러나 그렇습니다. 화이트 보드는 완벽하지만 다른 문제를 고려해야한다고 생각합니다. 그들에게 실제 문제를 던져서 그 문제를 해결하기위한 그들의 전반적인 전략을 설명하기 위해 UML-ish squibbles를 그리게하십시오. 그들에게 인터넷이있는 컴퓨터를 제공하여 그들이 squibblescape에서 블랙 박스로 사용할 수있는 서드 파티 라이브러리를 찾을 수 있도록합니다.
몇 분 안에 문제를 해결하는 방법을 실제로 알 수 있습니다. 실제로 해결해야 할 문제가 아닌 문제를 골라 “함께 해결”하여 의사 소통이 잘되고 입력을 얼마나 잘 통합 할 수 있는지 확인함으로써 실제로이 문제를 매우 흥미로운 것으로 만들 수 있습니다. 너무 세게 밀지 마십시오. 일부 사람들은 멈출 수도 있습니다. 그런 다음 몇 가지 요구 사항을 즉시 추가하십시오. 이것은 구현이없는 소프트웨어 개발과 디버깅이없는 소프트웨어 개발과 비슷합니다. 따라서 15 분은 많은 시간입니다.