마지막으로 참석 한 인터뷰에서, 용량이있는 두 개의 버킷 (각각 blah 및 blal 리터)이 주어 졌을 때 정확히 blal 리터의 물을 측정 할 수있는 퍼즐을 풀어야했습니다. 주어진 시간 (~ 5 분)에 퍼즐을 풀지 못했습니다.
면접관은 약간 실망했고 프로그래머가 “이들”기술을 가지고 있어야한다고 말했다. 나는 그가 말하는 기술을 얻지 못했습니다.
나는 항상 취업 면접을 프로그래밍 할 때 이런 종류의 퍼즐에 대해 이상하게 느꼈다. 나는 그러한 퍼즐과 프로그래밍 사이의 연결이 무엇인지 전혀 이해하지 못한다. 면접관은 그러한 퍼즐로 어떤 기술을 평가하려고합니까?
답변
어떤 사람들은 문제를 해결하는 능력과 접근 방식을 측정하려고 시도합니다. 개인적으로, 나는 그러한 퍼즐이 정확한 지표를 제공한다고 생각하지 않습니다. “실제 세계”에서는 빈 포장 과 백팩 문제를 다룰 때 5 분 이상 걸릴 수 있습니다. 처음에는 잘못된 솔루션을 적용 할 때까지 당면한 문제를 이해하기 쉽습니다. 이것은 1, 5, 10 또는 20 년의 경험을 가진 사람들에게 발생합니다.
최고의 인터뷰 ‘퍼즐’은 전문 지식을 주장하는 영역에서 문제를 해결하기 위해 컴퓨터에 앉아있는 것입니다. 또한 “글쎄, 프로그래머 가 할 수 있어야한다 …”라는 생각을 싫어한다 . 이미 스트레스를받는 환경에서 예기치 않은 무언가에 부딪 칠 때 사람들이 불안해한다는 점을 고려하지 않기 때문이다. 확실히, 당신 은 그것에 대해 생각할 시간이 있다면 그것을 해결할 수 있습니다. 그리고 당신이하지 않으면 당신의 인생이 끝날 것임을 깨달았을 때 더 빨리 해결할 수 있습니다. 5 분 안에 문제를 해결할 수 없다면 인생이 끝나는 곳에서 일하고 싶 습니까? 당신이 할 수 없다면 당신 은 해고 됩니까?
모든 위대한 프로그래머도 챔피언 스도쿠 솔버 여야합니까? 나는 많은 것이 확실하지만 역량에 대한 전제 조건과는 다릅니다.
나는 당신이 어떻게 문제에 접근 하는가에 대해 시험을해서는 안된다는 것이 아니라, 시험이 재미 있어야하고 전문 지식의 영역을 고려하여 신청자가 제공해야하는 ‘최고’를 초대해야한다는 것을 말하는 것은 아닙니다 . Bruce Willis가 묘사하는 캐릭터만큼 똑똑하다는 것을 증명하는 것은 프로듀서가 그 장면 을 올바르게 얻기 위해 꽤 많은 돈을 썼다는 것을 고려할 때 무의미 해 보입니다 .
다시 말해서, 당신이 실제로하고있는 것에 대해 거의 이해하지 못하는 사람이 당신을 인터뷰하고있는 것을 발견하면 , 화장실에 가서 절대 돌아 오지 말라고 변명하십시오.
답변
Microsoft는 1980 년대 초에 이러한 질문을 사용하기 시작했습니다. Microsoft가 눈에 띄게 성공함에 따라 다른 회사도이를 복사하기 시작했지만 몇 가지 핵심 사항이 번역에서 사라졌습니다.
당시 마이크로 소프트는 기술적 인 작가, 테스터, 전화 지원 등과 같은 많은 기술적이지만 비 프로그래밍적인 입장을 채우려 고 노력하고있었습니다. 이것은 일상적인 일이 아니었고,이 분야에 대한 실제 경험이있는 사람들은 어려웠습니다. 검색. 대안으로서 마이크로 소프트는 똑똑하고 영리하며 유연한 직원을 고용하고 업무를 수행 할 수 있다고 생각했습니다. 이 사람들은 프로그래밍 배경이 없었기 때문에 인터뷰에서 프로그래밍 질문을하는 것은 무의미했습니다. 수수께끼는 영리하고 뛰어난 분석 기술을 가진 사람들을 찾아서 찾기 위해 선택되었습니다. 프로그래머는 일반적으로 화이트 보드 프로그래밍 문제를 겪었지만 점심이나 저녁에 수수께끼를 물을 수도 있습니다.
이 질문들은 결코 실패로 여겨지지 않았습니다. 문제를 해결하는 방법과 이전에는 보지 못했던 문제에 대해 어떻게 생각했는지에 대한 대화의 시작이었습니다. “실패”하는 유일한 방법은 문제 해결을 거부하는 것입니다. 당시이 전략은 참신한 전략 이었으므로 Google에서 질문을 찾아 볼 수 없었습니다.
편집하다:
이 답변을 쓴 후 언젠가 1950 년대와 1960 년대의 제도 컴퓨팅 역사 인 Computer Boys Take Over를 읽었습니다 . 분명히 프로그래밍 작업을 위해 두뇌 티저와 수수께끼를 요구하는 관행은 1950 년대로 거슬러 올라갑니다. 미국은 방공 시스템을 전산화하려고했으며 IBM은이 작업을 수행하려면 수천 명의 프로그래머가 필요하다고 추정했습니다. 그 반응은 충격과 충격이었습니다. 전 세계에는 수십 명의 “전문 프로그래머”가있었습니다. 추상적 프로그래밍 적성 테스트, 프로그래머로서 수학자 모집, 체스 플레이어 및 크로스 워드 퍼즐 해결사 모집, 수수께끼와 뇌 맛보기로 지원자 선별 등 여러 가지 접근법이 시도되었습니다.
그들은 결국 프로젝트를 완료하기에 충분한 프로그래머를 모집하는 데 성공했지만, 그 결과 선별 방법 중 어느 것도 프로그래머로서 성공을 거둔 신입 사원을 식별하는 것보다 더 좋은 방법은 없다는 결론을 내 렸습니다.
답변
그들은 유용합니까? 아니 정말. 그들은 한때 마이크로 소프트에서 너무나 흔했으며 심지어 “마이크로 소프트 질문”이라고 불리기도했으며, 이에 관한 책들이있었습니다 .
그들에게는 두 가지 문제가 있습니다. 첫째, 신청자가 연구를하고 책을 읽는다면 어쨌든 알게 될 것입니다. 비록 그들이 그것을 해결할 수 있다고해도 어떻게하면 좋은 개발자 / 테스트 / PM이 될 수 있는지 알 수 있습니다.
이러한 이유로 그들은 더 이상 Microsoft에 묻지 않습니다. “트릭”답변이 필요없는 코딩 문제 또는 문제 해결 질문을하는 것이 훨씬 좋습니다. 다시 말해, 문제를 시도하고 해결할 때 지원자의 기술과 행동을 탐구 할 수있는 질문을해야합니다. 면접관으로서 질문을하고 해결책을 찾은 다음 그들이 알아낼 때 추적하기를 원합니다. 문제는 아마도 그들이 가진 시간에 해결책을 찾지 못할 수도 있지만 적어도 합리적인 방법으로 해결해야 할 것입니다. 그것은 실제 작업을 반영합니다. 나는 2 개의 양동이와 닭고기 (또는 문제가 무엇이든)를 사용하여 3 개의 파인트를 측정 할 필요가 없었습니다.
즉, 나는 당시에 몇 가지 까다로운 질문을 받았으며 이제는 작은 보트에서 닭과 여우를 운송하고 기차에 사는 파리의 수명을 계산하는 전문가로 자신을 생각합니다. 나는이 정보를 사용할 필요는 없었지만 누가 알겠는가? 언젠가는 …
답변
후지산을 어떻게 움직일 것인가? 책을 읽고 싶을 수도 있습니다 . . 그것은 많은 사람들이 인터뷰에서 수수께끼를 사용하는 것이 추론에 가고, 내 의견으로는화물 숭배 동작의 조합 (점이다 “MS는 않습니다가, 우리는 그들이만큼 성공하고 싶다면, 우리가 더 잘 할 무엇을 do “ )와 형제애가 흥을 돋우고 있습니다 .
인터뷰 연습으로서의 이러한 질문의 역사 는 1950 년대 윌리엄 쇼클리 와 함께 시작되었습니다 . 그들은 다른 면접관들이 그것을하고 있었기 때문에 면접관들이 묻는 실리콘 밸리의 일종의 면접 질문이었다. Shockley는이를 지능 테스트로 의도했으며 2 개의 버킷에 대한 질문 은 1916 년에 원래 Stanford Binet IQ 테스트 중 하나에있었습니다 .
아마도 인터뷰를하는 사람들은 실제로 당신이 답을 찾는 방법을보고 싶어하기 때문에 당신의 도시에 얼마나 많은 가스 펌프가 있는지와 같은 질문을 계산하는 것은 불가능할 것입니다. 이러한 종류의 문제는 페르미 문제 입니다. 이 주제에 관한 Jeff의 흥미로운 두 개의 블로그 게시물은 가장 어려운 인터뷰 퍼즐 질문
과 평가자가 얼마나 좋은가요? 파트 III .
개인적으로, 나는 이런 종류의 질문에 대해 자신이하는 일이 무엇인지 모르거나 개발자를 찾는 방법을 모르는 면접관이 일반적으로 사용하는 이런 종류의 질문에 대해 낮은 의견을 가지고 있습니다. 퍼즐 / 수수께끼를 만드는 회사에서 일하지 않는 한, 그들은 “당신의 가장 큰 약점은 무엇입니까?”(이것에 대한 진실에 대답하고 나쁜 방식으로 인터뷰를 끝내십시오)와 함께 역사의 먼지 더미에 속합니다. 맨홀 뚜껑이 둥글다 “
답변
기타의 난의 문제로 upvoted 한 답변 제공 한 해야합니다 . 내가 다른 대답을 쓰는 이유는 내가 말하고 싶은 것이 주석에 맞지 않을 것이고, 좋은 프로그래밍 면접이 어떻게 이루어질 수 있는지에 대해 말해야하기 때문입니다.
내가 기억하는 첫 번째 좋은 인터뷰에서, 우리는 서두르지 않고 많이 이야기했습니다. 전화로 객체 지향 디자인과 C ++로 구현하는 장단점에 대해 전화로 한 시간 동안 먼저하십시오. 그런 다음 현장에서 여러 사람들과 소프트웨어 개발 실무, 통합, 테스트, 버전 관리 및 구성 관리, 팀 및 책임, 기술 및 디자인에 대해 이야기했습니다. 저를 인터뷰 한 사람들과 점심을 포함한 하루 종일 인터뷰였습니다. 뒤늦은 시각에서, 그들이 이미하고있는 것에 생산적으로 적합 할 것인지에 대한 모든 것이 중요했습니다.
그 이후로 좋은 인터뷰는 소프트웨어 개발에 관한 1 시간에서 2 시간 정도의 긴 대화였습니다. 문제 해결 질문, 퍼즐 및 코딩 문제가 없었습니다.
오늘 프로그래밍 작업을 위해 누군가와 인터뷰를한다면 좋아하는 과정을 진행할 것입니다. 광범위한 주제에 대한 의견을 요청하고 깊이 따로 둡니다.
- 프로그래밍 언어 환경 설정은 무엇입니까? 왜?
- 예외 처리에 접근하는 방법?
- 레이어드 디자인의 장점은 신화가 아닌가?
- 지속적인 통합이 효율성에 대한 부담이 아닙니까?
- 코드를 작성한 사람은 누구나 코드를 소유해야합니다.
- “흐름”에 들어가기 위해 무엇을합니까?
- 보고 된 결함을 프로젝트 계획에 어떻게 포함시켜야합니까?
- …
이러한 질문은 둘 이상의 답변이 포함 된 질문이며 소프트웨어 개발자가 정보에 대해 의견을 가져야하는 주제에 관한 것입니다. 대화 주제로 경험 한 이전의 실제 문제 (질문이 아님)에 대한 답변에 전적으로 동의합니다.
Peopleware 이후 효과적인 소프트웨어 개발에 대한 과학적 연구에 따르면 최고의 프로그래머는 IQ가 가장 높지 않더라도 소프트웨어 개발의 역학을 이해하는 사람들이라고합니다. 차라리 n경험을 가진 사람보다 몇 1년의 경험을 반복적으로 반복 하는 사람보다 배우기를 열망하는 신인을 원합니다 n. 내 개인적인 편견은 상자 밖에서 생각하는 경향이있는 후보자에 대한 것이며, 동시에 현재 (내) 상자에 맞는 방법을 알고 있습니다.
답변
문제 해결 기술 을 평가하는 데 유용 할 수 있으며 이는 물론 프로그래밍의 주요 측면 중 하나입니다.
지난 몇 년 동안 많은 사람들의 인터뷰로, 나는 보통 물어 보지 않습니다 잡았다 확실히 당신이 설명하는 것처럼 보이는 것과 같은 유형의 질문에,하지만 난 잘 뭔가를 물어 요청할 수 있습니다 “당신이 해결할 방법 …”.
이 경우 저의 기대는 문제에 대한 귀하의 접근 방식을 명확하게 듣는 것입니다. 다른 어떤 데이터를 수집하려고합니까? 가설 등을 어떻게 테스트하겠습니까?
답변
이들은 단지 부두 고용 관행입니다. 다른 사람들은 이러한 질문을하도록되어 있습니다. 그들은 질문에 대답하지 않는 것이 “나쁘다”고 대답하는 것이 “좋은 것”이라는 것을 알고 있지만, “개발자가 이러한 기술을 필요로하는”과 같은 비 응답 이상의 이유를 알 수 없습니다. 그들은 시간 낭비이며 면접관이 유능한 면접관이 아니라는 지표입니다.