면접을위한 쌍 프로그래밍 [폐쇄

https://stackoverflow.com/questions/596426

09-09-2019
|

문제

우리 회사는 인터뷰 절차를 폐기하고 각 후보자를 일부 프로그래머들과 4-5 시간 동안 자리에 데려오고 일부 프로그래밍을 수행하는 것에 대해 생각하고 있습니다.

나는 이론적으로 아이디어를 좋아하지만 각 후보자에게 어떻게 공정하게 만들 수 있는지 잘 모르겠습니다. 어떻게 평가 하시겠습니까? 그들의 의견은 그날 각 프로그래머가 무엇을하고 있는지에 달려 있지 않습니까?

이것이 좋은 아이디어/나쁜 아이디어인지 또는 그것을 작동시키는 방법에 대한 생각은 내가 여기서 찾고있는 것입니다.

건배!

편집하다:

결과 - 요청에 따라

우리는 인터뷰의 첫 단계를 이전과 동일하게 수행 할 것입니다. 전화를 한 다음 얼굴을 마주 보았습니다. 세 번째이자 최종 그릴을 위해 그들을 다시 데려 오는 대신, 우리는 3 명의 개발자가 팀의 7 명 모두와 함께 앉게 할 것입니다. 우리는 팀이 누가 고용 된 사람을 결정하게하기로 결정했습니다.

우리는 몇 가지 이유로이 결론에 도달했습니다. 우리는 이것이 그들이 일하는 사람의 선택을 제공함으로써 개발자들에게 힘을 실어 줄 것이라고 믿는다. 두 번째 이유는 그룹 동적입니다. 우리는 좋은 그룹 역학을 갖는 것이 정말로 중요하다고 생각하며, 사람을 고용 한 후에 그들이 적합하든 아니든 말할 때까지 말하기는 어렵습니다.

따라서 최종 결과는 우리는 쌍 프로그래밍 세션을 계속 진행하지만 완전히 다른 방식으로 원래 의도 한 것과 완전히 다른 방식으로 진행될 것입니다.

이 접근법에 대한 모든 생각이나 비판은 환영받는 것 이상입니다 !! (이 편집은 아래에 답변으로 게시되므로 이것이 최선의 접근 방식이 아니라고 생각되면 자유롭게 다운 투표하십시오).

해결책

나는 당신이 이것보다 앞서 많은 발걸음을 내딛기를 바랍니다. 이것이 작동하려면 훌륭한 이력서와 전화 화면이 필요합니다. 당신은 처음에 이야기하지 말아야 할 후보자들에게 시간을 보내고 싶지 않습니다.

그래서 당신은 초기 인터뷰를 제안하고 아마도 쌍 프로그래밍 세션으로 두 번째 인터뷰를 할 수 있습니까? - 테드 스미스 (1 분 전)

응. 당신은 같은 것을 사용하여 웹을 통해 간단한 코딩 인터뷰가 발생한다고 생각할 수도 있습니다. 부조종사.

다른 팁

실제 개발에서 쌍 프로그래밍을 광범위하게 사용하지 않는 한, 나는 이것을 사용하는 것을 매우 주저 할 것입니다. 나는 프로그래밍을 짝을 이루는 강력한 혐오감을 언급했으며 그러한 과정에서 잘 판단되지 않는 많은 고품질 전문 개발자를 만났습니다.

가장 쉬운 방법은 각 사람에게 동일한 프로그래머와 함께 일할 수있는 동일한 코드와 동일한 코드를 제공하는 것입니다.

당신이 뛸 문제는 고용이 프로그래밍과 같지 않다는 것입니다. 누가 고용 해야하는지에 대한 정답으로 이어지는 단계별 프로세스가 없습니다. (결정을 더 쉽게하기 위해 여러 단계를 가질 수 있습니다). 당신은 그들의 강점 등에 대해 각각을 평가해야하며, 본질적으로 고용하기에 가장 적합한 교육을받은 추측을해야합니다. 때때로 당신은 잘못 추측합니다.

당신이 조심해야 할 페어 프로그래밍에 대한 또 다른 점은 해당 단계의 각 후보자가 그러한 종류의 테스트를 거치는 데 필요한 시간입니다. 내가 일자리를 찾고 있다면, 나는 회사에서 인터뷰를하는 것을 주저 할 것입니다. 왜요? 그것은 많은 시간이기 때문에 여러 곳에서 인터뷰를하면 문자 그대로 며칠 동안 일자리를 위해 인터뷰를 할 수 있습니다. Google이나 MS와 같은 일부 플레이는 예외이지만 대부분의 장소는이 두 곳과 다릅니다. (실제 코드 작업을 수행하고 있다면 본질적으로 누군가의 일을 무료로 요구하고 있다는 사실은 말할 것도 없습니다).

방금 샌프란시스코에 기반을 둔 회사와의 인터뷰를 통해 민첩한 방법 등을 자랑스럽게 생각했습니다. 나는 CEO 자신을 인터뷰해야했다. 저는 업계에서 약 20 년의 경험을 가지고 있지만 TDD 접근법을 사용하여 프로그래밍 또는 개발 한 적이 없습니다. 나는 그것이 "프로그래밍 인터뷰"라고 들었지만 무엇을 기대 해야할지 알지 못했고, 우리가 시작하기 전에 모든 인터뷰가 이런 식으로 이루어져야한다는 데 동의 할 것이라고 생각했다. (돌이켜 보는 것은 오만한 진술에 지나지 않았다).

어쨌든, 인터뷰에서 연습은 TDD를 사용하여 수업을 개발하는 것이 었습니다. 프로그래밍하거나 TDD를 한 번도 한 번도하지 않았기 때문에 전체 과정에서 내 생각을 조정하는 데 1 초가 걸렸습니다. 내가 여기저기서 걸려 넘어지는 동안 나는 결국 괜찮았다. 그러나 그의 대답은 내가 쌍 프로그래밍 환경에 필요한 공격적인 앞뒤 특성을 전시하지 않았다는 것입니다. 이제, 그것은 또한 "나는 당신이 위대한 일을했다고 생각하지 않았다"고 말하는 과소의 방법 일 수도 있습니다.

운 좋게도 나는 직업이 필요하지 않았고 솔직히 말해서, 경험에 따르면, 나는 개발에 관해 하루 종일 일 해야하는 소프트웨어 엔지니어가되어야한다는 것과는 다른 경력을 찾을 수 있다는 것을 깨달았습니다. 암호. 이상한 점은 때때로 다른 사람과 코드로 동시에 일 했으므로 모든 것이 가능하다는 것입니다.

결국 나는 그들이 내가 잘 맞았다 고 생각하지 않았고 그들의 작업 방법을 신경 쓰지 않았기 때문에 좋은 결과라고 생각합니다. 그러나 우리는 내가 나 자신에 대해 몇 분 더 이야기를 나누고 그들이 그들의 일에 대한 방법에 대해 조금 더 많은 정보를 주었다면 우리는 같은 결론에 도달했을 것입니다. 즉, 완전한 낯선 사람과 쌍 프로그래밍의 스트레스를 겪는 것보다 좋은 후보자를 찾는 다른 방법이 있습니다. 역량을 측정하는 가짜 방법 IMO.

개인적인 일화로서, 나는 이와 같은 기술 때문에 인터뷰에서 때렸다. 나는 그들의 인터뷰 과정에서 멀리 갔다. 이력서 검사, 코드 제출을 통과했으며 이는 인터뷰의 직접적인 부분이었습니다.

나는 대학에서 신선했고 TDD 전에 프로그래밍하거나 한 번도 짝을 이루지 못했습니다. 그들은 카드 운동 덱을하기 위해 나를 앉히고 퍼져 나갔다. 심하게! 나는 면접관이 왜 그렇게 멍청한 것처럼 보이는 테스트를 작성하고 있는지 이해하지 못했고 (예 : "return null;") 그들은 왜 그런지, 물론 TDD에 대한 외국인 이유를 설명하지 않았다. 나는 어떤 질문을 해야하는지 몰랐다. 최종 결과는 종이 봉지에서 내 길을 프로그래밍 할 수없는 것처럼 보였습니다.

이런 유형의 운동을하려는 경우, 그들은 적성과 다른 지점에있을 것이기 때문에 인터뷰 대상자에게 수용해야합니다. 이것은 실제 인재를 기반으로하지 않을 수있는 다른 평가를받을 수 있으며 따라서 크게 편향 될 것임을 의미합니다.

** 이제 나는 TDD를 이해하기 때문에, 나는 이와 같은 테스트와 그것이 어떻게 작동 해야하는지 이해하지만, 그 당시에는 어리석은 것처럼 보였습니다!*

나는 며칠 전에 쌍 프로그래밍 인터뷰를했고 솔직히 말하면 정말 마음에 들지 않습니다. 나는 인터뷰 직전에 이것에 대해 알림을 받았으며, 면접관은 쌍 프로그래밍이 결국 어쨌든 직장에서 할 일이라고 말했다. 나는 사무실에 들어가서 매우 선임 소프트웨어 엔지니어 인 사람과 짝을 이루었습니다. 이 회사는 샌프란시스코에 있으며 쌍 프로그래밍을위한 유명한 회사이며 모든 사람은 사무실에서 프로그램을 페어링합니다. 처음에는 괜찮은 것처럼 보였습니다. 그는 그들이 사용한 모든 도구, 그들이 구축하는 자체 단위 테스트 프레임 워크 및 약간의 프로젝트에 대해 설명했습니다. 그런 다음 기본적으로 많은 단위 테스트를 작성했으며 구현을 위해 노력하여 통과하기를 원했습니다. FYI와 마찬가지로 이미 존재하는 코드 기반은 거대합니다. 10K 라인은 말할 것입니다. 그것은 슈퍼 복잡한 프로젝트와 다르지 않지만 누군가가 클래스 계층 등을 사전 이해하지 않고 코드를 작성하는 것은 복잡합니다. . 나는 그가 이미 존재하는 10K 소스 코드로 바로 뛰어 올라가는 것을 기대한다고 믿기가 어렵다는 것을 알게되었습니다. 쌍 프로그래밍 인터뷰와 일치하지 않으며 더 작은 코드 기반이 도움이 될 것입니다. 나는 이미 존재하는 클래스/코드의 양에 압도 되었기 때문에 수업을 탐색하고 앞뒤로 나아가는 데 약간의 어려움을 겪었습니다. 솔직히 말해서, 이것은 실제로 인터뷰 과정에서 끔찍하게 만들었습니다. 결국 나는 그것에 대해 정말 기분이 좋지 않았습니다. 나는 전에 쌍 프로그래밍을 한 적이 없었습니다. 대부분 대학 연도에 과제를 수행하는 중입니다.

나에게 이미 쌍에 능숙하거나 편안하지만 인터뷰에 적합하지 않은 경우 쌍 프로그래밍의 힘을 활용할 수 있습니다. 때때로 나는 쌍에 질문하고 싶지만 너무 많은 질문을하면 내가 바보라고 생각하고 수행 할 수 없다고 생각했습니다. 이것이 이미 진짜 직업에 있다면, 나는 주저하지 않을 것입니다. 그러나 인터뷰에서는 어렵습니다 .. 당신은 당신이 붙어있을 때 당신의 쌍을 도울 수 있기 때문에 묻고 싶습니다. 그러나 동시에 인터뷰입니다. , 그래서 당신은 정말로 많이 묻지 못합니다.

그것은 쌍 프로그래밍 인터뷰에서 얻은 나의 경험 일뿐입니다. 당신이 정말로 이것을하고 싶다면 내 제안입니다.

후보자에게 대형 코드 기반으로 일할 수있는 후보자에게 더 작은 코드베이스와 협력하여 최대의 기술을 보여줄 수 있는지 확인하십시오.
한 쌍 프로그래밍 인터뷰 전에 후보자와 앞으로 나아가십시오. 갇혀있을 때 질문을 할 수 있습니까?
가능한 한 자세히 설명하십시오

결국, 나는 그것을 제안하지 않을 것입니다. 쌍 프로그래밍에서 후보자의 성과를 측정하기는 어렵고 편향 될 수 있습니다.

특정 회사는 호출되는 기술을 사용합니다 극단적 인 인터뷰. 극단적 인 인터뷰를 위해 그들은 30 명의 개발자를 데려와 15 쌍으로 그룹화 할 것입니다. 그들은 다른 사람들과 잘 일하는 사람들을 찾고 있다고 설명 할 것입니다. 그들은 다른 사람들과 함께 일할 수있는 능력만으로 고용 결정을 내릴 것입니다.

그들은 쌍이 해결하기 위해 문제를 제공 할 것입니다. 그들은 각 프로그래머가 다른 사람들과 함께 일할 수있는 능력에만 관심이 없다는 것을 강조 할 것입니다. 각 쌍에 대해 그들은 쌍의 관찰자를 제공합니다. 운동 중 (약 2 ~ 4 시간 지속 시간), 관찰자는 솔루션이 아닌 사람을 페어링 할 수있는 능력에 대한 메모를합니다.

그들은 얼마나 많은 프로그래머가 협업 대신 문제를 해결하는 데 집중하는지 놀랐습니다. 15 쌍 중 두 번째 인터뷰를 위해 약 4-6 명의 개발자를 식별 할 것입니다. 그 개발자들은 돌아와서 팀과 함께 일주일을 보내도록 요청받을 것입니다 (그들은 돈을받습니다). 일주일 후, 그들은 누가 지켜야할지 결정합니다. 일반적으로 그 중 절반 (2 ~ 3 명의 개발자).

완료되면 공동 작업을 할 수있는 개발자가 있으며 일주일 후 다양한 쌍으로 작업 한 후에는 소프트웨어를 효과적으로 개발할 수있는 강력한 표시가 있습니다. 프로세스는 혁신적이고 효과적입니다. 그들은 고용 한 사람들과 높은 성공률을 보였습니다.

나는이 아이디어를 좋아한다. 그러나 후보자가 당신이 그와 짝을 이루는 프로젝트에 대한 지식을 가져야하기 때문에하기가 어려울 수 있다고 생각합니다. 또한 4 ~ 5 시간이 조금 길어 보입니다. 만약 당신이 그것이 효과가 없다는 것을 즉시 보면, 후보자와의 전체 세션을 통해 앉을 것입니까?

그래도 좋은 질문입니다. 생각할 것들.

왜 안 돼? 또한 인터뷰가 항상 (또는 항상) 박람회와는 다릅니다. 전통적인 인터뷰 기반 접근 방식에 대한 새로운 접근 방식의 최종 결과를 평가해야합니다.

또한, 쌍 프로그래밍 세션 전 미니 인터뷰는 좋지 않은 사람들과 프로그래머의 시간을 낭비하는 데 도움이 될 수 있습니다.

제한된 경험에서 내 감정이 혼합되어 있습니다. 나는 인터뷰의 일환으로 짝을 이루는 아이디어를 좋아한다. 회사가 페어링을 자주 사용하는 경우, 착용감에 더 나은 느낌을주기 때문입니다. 후보자로서, 나는 종종 몇 시간 동안 질문에 대답하는 방에 앉아있는 인터뷰를 겪었지만 그 후에는 환경에서 일하는 것이 실제로 어떤 것인지에 대해 좋은 느낌을주지 못했습니다. 면접관이 누군가를 통해 누군가를 일하는 데 능숙하지 않으면 페어링은 무작위 코딩 운동보다 더 유익 할 수 있습니다. 그리고 나는 양쪽에서 기술적 인 내용을 논의 할 수있는 것을 좋아합니다. 그리고 후보자로서, 나는 단지 질문에 답하거나 코드 문제를 스스로 해결하는 것보다 누군가와 상호 작용하고 싶습니다.

그러나 다른 사람들이 지적했듯이 필요한 시간은 문제가 될 수 있습니다. 나는 며칠간의 페어링 인터뷰를 겪고 일부 기간이 좋았고, 다른 사람들은 몇 시간이 낭비되는 것처럼 느꼈습니다. 하나는 개발자가 페어링에 빌려주는 일을하지 않았기 때문에 (내 배경을 주어 졌음), 다른 하나는 ENV 문제가 한동안 많은 유용한 작업을 방해했기 때문입니다. 일자리가 해결되지 않으면 하루나 이틀을 쉬는 것은 실망 스러울 수 있습니다.

이 접근 방식을 시도하는 한 곳은 회사 외부의 누군가가 고객 프로젝트를 수행 해야하는지 확실하지 않았습니다. 그들은 또한 도메인과 작업을 설명하는 것이 너무 오래 걸릴 것이라고 걱정했지만, 후보자가 그다지 기여하지 않을 수도 있습니다. 그래서 그들은 직원이 작업하고있는 오픈 소스 프로젝트를 선택했습니다.

이것은 핵심 요점 인 것 같습니다. 후보자가 신속하게 이해하고 기여할 수있는 잘 선택된 과제가 필요합니다. 후자의 부분은 후보자의 기술에 다소 달려 있습니다. 또한이 접근법을 가진 사람을 평가하는 직원의 능력도 핵심입니다. 모든 사람이 정상적인 인터뷰에서 훌륭하지는 않으며, 아마도 페어링 인터뷰에서 더 사실 일 것입니다.

또한 회사가 많은 짝을 이루지 못하면 이런 종류의 인터뷰는 유용하지 않을 수 있습니다. 누군가 코드를 보는 데 도움이되는 것처럼 보이며 (Joel Spolsky의 노트와 같이) 이것이 좋은 방법 일 수 있습니다. 그러나 페어링이 작업의 전형적인 부분이 아니라면 전체 페어링 세션이 적절하지 않을 수 있습니다. 수정 된 버전 일 수도 있습니다.

이 접근 방식을 취한 회사가 결과를 어떻게 생각하는지 궁금합니다. 이 질문에 대한 다른 답변 중 일부를 읽는 것은 후보자의 견해에서 항상 이상적 인 것처럼 보이지 않는다는 것을 보여줍니다.

공정하게 유지하려면 모든 참여 직원이 후보자를 평가하기 위해 준비된 문제를 가져야합니다. 바람직하게는 무언가가 회사 경험에서 현실 세계를 형성하지만 이미 해결 된 무언가를 형성합니다. 이것은 문제에 대한 지식을 평가하고 프로그래밍 기술뿐만 아니라 평가할 수있는 좋은 기회입니다.

너무 구체적인 질문에 답할 때 나는 그것을 싫어합니다. 나는 프로그래머가 광범위하게 사용한 STL에 대한 지식을 테스트 한 곳에서 한 번 인터뷰를했으며 맞춤형 할당자가 필요하다는 답을 얻으려고 노력했습니다. 나는 그들에 대해 들었지만 결코 그들을 사용하지 않았으며 (창문에서) 멍청한 느낌으로 만들어졌습니다. Iow, 판단을 피하십시오.

요점은 "쌍 프로그래밍"아이디어를 사용하는 경우보다 질적 인 성격 및 문제 해결 방법을 평가할 수 있으므로 프로그래밍 지식 테스트에 대해 그리 많지 않은 실질적인 질문을합니다.

좋은 질문!

솔직히, 그것은 좋은 생각처럼 들리지만, Jason Punyon은 확실히 컬러에 많은 개발자의 시간을 낭비하기 전에 많은 잡초를해야한다는 것이 옳습니다. 당신은 인터뷰에서 거의 볼 수없는 중요한 지표를 엿볼 수 있습니다.

나는 당신이 올바른 평가 태도를 유지한다면 주제에 따라 "공정"이거나 다른 후보자들에게 일관된 상황을 제시하려고하는 것에 대해 걱정할 필요가 없다고 생각합니다. "정답을 얻었습니다"또는 올바른 후프 세트를 뛰어 넘었지만 어떤 종류의 노력, 문제 해결, 의사 소통 적성 및 유연성이 보여주었습니다. 당신은 운동의 이점을 인공 시험으로 바꾸어 운동의 대부분을 잃을 것입니다. 개발자가 어떤 혜택을 얻을 수 있는지 (또는 적어도 일부 작업을 수행하는 동안)의 대규모 낭비로 바꾸는 것은 말할 것도없이 운동의 대부분을 잃을 것입니다. 그들의 시간.

Joel Spolsky는 훌륭합니다 인터뷰에 대한 게릴라 가이드 무엇보다도 프로그래밍 작업에 대해 이야기합니다.

Trivia : Joel Spolsky는 Stackoverflow.com의 공동 설립자입니다

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow