인터뷰 중에“화이트 보드 코딩”이 부적절합니까? [닫은]

이것은 다소 주관적인 질문이지만 주제에 대한 인터뷰 담당자 / 인터뷰 담당자의 의견 / 의견을 듣고 싶습니다.

기술 인터뷰를 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 분은 많은 시간입니다.

다른 질문으로 대답하겠습니다.

화이트 보드에 코드를 작성하면 컴퓨터에서 코드를 입력하고 실행하는 것과 비교하여 프로그래밍 기능을 평가할 때 실질적인 이점이 있습니까?

응시자에게 인터뷰에서 코드를 작성하도록 요청하는 것이 절대적으로 적절하다고 생각합니다. 그러나 나에게 코드를 실행할 수 있다는 것은 프로그래밍을 구성하는 피드백 루프의 중요한 부분입니다. 화이트 보드에서는 한 손을 등 뒤로 묶어 문제를 해결하는 방법에 대한 전체 그림을 얻지 못하고 있습니다.

아니요, 그러나 IMO의 더 나은 접근 방식은 화이트 보드를 원래 목적으로 사용하고 가상의 프로젝트에 UML / 스케치 / 노트를 사용하는 것입니다. 예전의 "모든 레코드를 얻기 위해 SQL 쿼리를 작성하십시오"또는 " 문자열을 반대로 바꿉니다. "

내가했던 최고의 인터뷰 중 하나는 20 분 동안 수석 개발자와 미친 과학자 저택 (비밀 은신처, 데스 레이 및 개 사육장으로 완성)에 대한 아키텍처 (소프트웨어가 아닌)를 논의하는 데 소비되었습니다. 그는 문제 해결에 대한 나의 접근 방식을 보았습니다. 문제는 현대 언어로 천 번 이상 해결 된 101 가지 물건을 프로그래밍하는 것이 전형적인 재미없는 것이 었습니다. 우연히도 전에 이와 같은 코드를 작성했지만 아키텍처 부분보다 훨씬 압박감을 느꼈습니다.

요즘에는 많은 프로그래밍이 팀에서 이루어집니다. 팀이 일하기 위해서는 사람들이 의사 소통 할 수 있어야합니다. 이것의 큰 부분은 화이트 보드 앞에서 소통 할 수있는 것입니다 (브레인 스토밍, 멘토링, 코드 검토 제안 수정 등).

지원자가 화이트 보드 코드를 사용하여 프로그래밍 문제에 대한 솔루션을 어떻게 해결해야하는지 설명했습니다. 설명이 충분하면 회의실의 다른 좋은 프로그래머가 보드의 오타 / 실수를 정신적으로 자동 수정합니다.

대부분의 팀 직책의 경우, 응시자가 솔루션에서 자신의 시도를 설명하고 낙서 할 수 있다고 기대하지 않는 것은 합리적입니다.

아니요, 인터뷰를 위해 코딩하는 것이 좋지만 일반적으로 원하는 언어로 코더를 얻는 것보다 다른 언어로 코더를 훈련시키는 것이 더 쉽기 때문에 합리적인 언어로 코드를 허용해야합니다. 유능한 수준으로.

나는 그것이 적절하다고 말하지만, 대부분의 경우 누가 프로그래밍에 능숙하고 누가 그렇지 않은지를 알아내는 효율적인 방법은 아닙니다. 일을하고 싶다면 (= 유능한 사람을 고용하십시오), 인터뷰는 실제 기술을 측정하는 데 중점을 두어야합니다. 지금까지 내가 한 최고의 인터뷰는 다음과 같습니다.

• 인사, 인사 환영합니다.
• 나에 대해, 회사 등에 대해 몇 마디 말했고 그녀는 나머지 인터뷰에 대해 설명했습니다.
• 그녀는 부품이 부족하고 그로 인해 단위 테스트에 실패한 프로그램이있는 노트북을 나에게주었습니다. 누락 된 부분은 텍스트로 주석 처리되었으며 몇 가지 클래스 간의 연결 만들기 및 간단한 비즈니스 논리를 도입하는 것과 같은 기본 작업을 구현하는 것이 었습니다.
• 모든 것이 잘 되었다면 단위 테스트는 녹색이되었습니다.
• 작별 인사와 며칠 만에 다시 합의했습니다.
• 그날 지도자는 저를 만나고 완성 된 프로그램, 내가 무엇을했는지, 왜 그런지 물었습니다.
• 또한이 지도자는 나의 과거 경험과 다른 질문에 대해 물었습니다.

요약하자면 : 프로덕션 코드에서 인력을 찾고 있다면 실제 환경에서 기술을 테스트하십시오. 그들의 이론적 지식에 대해 궁금하다면, 이것에 대해 물어 보는 것이 좋습니다. IDE에서 벗겨 졌거나 누군가 앞에서 화이트 보드에 프로그래밍해야하기 때문에 긴장한 경우, 특히 IT 사람들이 내 향적이며 많은 사람들이 이러한 상황을 잘 처리 할 수 ​​없다는 것을 이해할 수 있습니다. 우리의 효율성은 실제보다 나빠질 것입니다.

인터뷰 대상자에게 나쁜 필체가 없거나 보드에 글을 써야하는 경우가 아니면 합리적이지 않습니다. :-). 접근 방식의 유일한 차이점은 보드와 마커를 사용하는 것입니다. 어떤 경우에는 면접관이이 일을하지만 대신 종이와 펜을 제공합니다. 인터뷰를하는 사람이 3-4 명인 경우, 귀하의 접근 방식이 훨씬 나아지고 적합 할 것입니다.