까다로운 논리 퍼즐-프로그래밍 기술을 평가하는 데 실제로 유용합니까? [닫은]

마지막으로 참석 한 인터뷰에서, 용량이있는 두 개의 버킷 (각각 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 시간 정도의 긴 대화였습니다. 문제 해결 질문, 퍼즐 및 코딩 문제가 없었습니다.

오늘 프로그래밍 작업을 위해 누군가와 인터뷰를한다면 좋아하는 과정을 진행할 것입니다. 광범위한 주제에 대한 의견을 요청하고 깊이 따로 둡니다.

1. 프로그래밍 언어 환경 설정은 무엇입니까? 왜?
2. 예외 처리에 접근하는 방법?
3. 레이어드 디자인의 장점은 신화가 아닌가?
4. 지속적인 통합이 효율성에 대한 부담이 아닙니까?
5. 코드를 작성한 사람은 누구나 코드를 소유해야합니다.
6. "흐름"에 들어가기 위해 무엇을합니까?
7. 보고 된 결함을 프로젝트 계획에 어떻게 포함시켜야합니까?
8. ...

이러한 질문은 둘 이상의 답변이 포함 된 질문이며 소프트웨어 개발자가 정보에 대해 의견을 가져야하는 주제에 관한 것입니다. 대화 주제로 경험 한 이전의 실제 문제 (질문이 아님)에 대한 답변에 전적으로 동의합니다.

Peopleware 이후 효과적인 소프트웨어 개발에 대한 과학적 연구에 따르면 최고의 프로그래머는 IQ가 가장 높지 않더라도 소프트웨어 개발의 역학을 이해하는 사람들이라고합니다. 차라리 n경험을 가진 사람보다 몇 1년의 경험을 반복적으로 반복 하는 사람보다 배우기를 열망하는 신인을 원합니다 n. 내 개인적인 편견은 상자 밖에서 생각하는 경향이있는 후보자에 대한 것이며, 동시에 현재 (내) 상자에 맞는 방법을 알고 있습니다.

문제 해결 기술 을 평가하는 데 유용 할 수 있으며 이는 물론 프로그래밍의 주요 측면 중 하나입니다.

지난 몇 년 동안 많은 사람들의 인터뷰로, 나는 보통 물어 보지 않습니다 잡았다 확실히 당신이 설명하는 것처럼 보이는 것과 같은 유형의 질문에,하지만 난 잘 뭔가를 물어 요청할 수 있습니다 "당신이 해결할 방법 ...".

이 경우 저의 기대는 문제에 대한 귀하의 접근 방식을 명확하게 듣는 것입니다. 다른 어떤 데이터를 수집하려고합니까? 가설 등을 어떻게 테스트하겠습니까?

이들은 단지 부두 고용 관행입니다. 다른 사람들은 이러한 질문을하도록되어 있습니다. 그들은 질문에 대답하지 않는 것이 "나쁘다"고 대답하는 것이 "좋은 것"이라는 것을 알고 있지만, "개발자가 이러한 기술을 필요로하는"과 같은 비 응답 이상의 이유를 알 수 없습니다. 그들은 시간 낭비이며 면접관이 유능한 면접관이 아니라는 지표입니다.

기본 논리 기술이 있어야하는 구식 이론적 근거입니다. 다른 어떤 것도 배울 수 있습니다. 그러나 그것은 사실이 아닙니다. 부울 논리 , 조건 및 루프를 읽는 것은 논리 퍼즐 을 풀 수있는 것과 다릅니다 .

즉, 절차 적 언어 시대에는 이러한 문제를 해결할 수있는 사람이 스위치 측면에서 문제를 적용 할 수있는 성향이 더 높을 것입니다. 그러나 제 생각에는 OO / 기능 프로그래밍에는 엔지니어링 마인드가 필요합니다.

개인적으로, 나는 여전히 논리가 실제 프로그래밍 기술보다 더 중요하다고 생각하는 회사와 일을하고 싶을 지 모르겠다.

면책 조항 : 나는 논리 퍼즐에 매우 능숙하며 아마도이 이론적 근거가 없으면이 작업 라인에서 시작하지 않았을 것입니다.

면접관은 프로그래머의 일상 업무의 일부인 문제 해결 및 논리 기술을 언급하고 있어야합니다. 문제가 발생하면 가장 최적의 접근 방식을 사용하여 문제를 분석하고 세분화하고 이에 대한 솔루션을 작성할 수 있어야합니다.

당신은 이와 같은 퍼즐이 당신의 능력을 얼마나 잘 나타내고 있는지 논쟁 할 수 있습니다. 실제 프로그래밍 문제를 묻는 대신 퍼즐 질문을하는 장점이 없습니다.

프로그래밍은 코드 라인을 작성하는 것이 아니라 다른 사람 (고객, 사용자 등)의 문제를 해결하는 것입니다.

프로그래머에게는 솔루션이 프로그램 형태를 취합니다.

따라서 문제 해결 기능을 갖는 것이 중요하고 테스트되는 이유가 여기에 있습니다.

즉, 까다로운 퍼즐을 푸는 것이 누군가를 평가하는 가장 좋은 방법인지 확실하지 않습니다.

인터뷰에서 퍼즐은 "논리 퍼즐"(예 : 요청한 퍼즐)과 "다른 생각"범주의 두 가지 범주로 분류됩니다. 다르게 생각하는 범주 (측면 퍼즐이라고도 확신하지 않습니까?)는 일반적으로 이러한 유형입니다. 그 나무에는 몇 개의 잎이 있습니까? 또는 귀하의 도시에는 몇 개의 재단사가 있습니까?

나는 "논리 퍼즐"에 능숙합니다. 왜냐하면 그들은 하나 또는 두 개의 솔루션을 가지고 있고 간단한 논리에 의해 도달 할 수 있기 때문입니다. 논리 퍼즐은 풀어야 할 과정이 코더가 실제로 생각하는 방식과 매우 유사하기 때문에 논리 퍼즐이 어느 정도 좋다고 생각합니다.

"다르게 생각하라"는 말은 당신이 가정을하고, 그 가정에 근거하여 계산을하기 때문에 끝이 아닙니다. 간단히 말해, 면접관이 당신의 논리에 동의하지만 당신의 가정에 동의하지 않으면 그 반대도 마찬가지입니다. 면접관이 귀하의 솔루션에 동의하지 않을 여지가 너무 많습니다.

인터뷰를 할 때는 논리적 인 퍼즐을 묻지 않습니다. 이유 : 3-4 년의 경험이있는 대부분의 응시자라도 피보나치 시리즈 나 회문과 같은 간단한 교과서 문제를 코딩하도록 요청하면 실패하거나 포기합니다.

퍼즐의 문제점 중 하나는 좋지 않은 프로그래머가 인터넷에서 이러한 일반적인 퍼즐에 대한 솔루션을 찾는 것만으로도 면접관에게 깊은 인상을 줄 수 있다는 것을 알고 있다는 것입니다. 솔직히 답변을 알고 있다고 말할 수있는 사람은 거의 없습니다.

두 가지 점 :

1. 프로그래밍은 주로 퍼즐 해결과 다릅니다. Steve McConnell은 "Code Complete"에서 설명합니다.

   뭐? 초 지능형 일 필요는 없습니까? 아뇨 컴퓨터를 프로그래밍 할만큼 똑똑한 사람은 없습니다. 평균적인 프로그램을 완전히 이해하려면 세부 사항을 흡수 할 수있는 거의 무한한 용량과이를 동시에 이해할 수있는 동일한 용량이 필요합니다. 지능이 얼마나 많은지에 비해 지능에 집중하는 방법이 더 중요합니다. 5 장에서 언급했듯이 1972 년 튜링 상 강의에서 Edsger Dijkstra는“The Humble Programmer”라는 제목의 논문을 발표했습니다. 프로그래밍에 가장 능숙한 사람들은 뇌가 얼마나 작은 지 깨닫는 사람들입니다. 그들은 겸손합니다. 프로그래밍에서 최악의 사람들은 그들의 두뇌가 작업과 같지 않다는 사실을 받아들이기를 거부하는 사람들입니다. 그들의 자아는 위대한 프로그래머가되지 못하게합니다. 더 당신당신의 작은 두뇌를 보완하는 법을 배우십시오 . 당신이 겸손할수록 더 빨리 향상됩니다.

2. 이러한 퍼즐은 인터뷰 중에 유용 할 수 있지만 인터뷰자가 프로세스를 살펴 보는 경우에만 결과 자체가 아닙니다.

그러나 이상적으로 퍼즐은 더 복잡하고 프로그래밍과 관련이 있어야합니다 (작은 2 시간 프로젝트). 문제는 면접관이 사람이며 완벽한 "면접 기술"을 가지고 있지 않다는 것입니다.

이러한 문제를 검사하는 몇 가지 방법이 있습니다.

1. 이전 솔루션을 알고 있습니다. 영화에서 ... 복수와 함께 열심히 죽어 ... 나에게 이것을 설명 ...? 블라가 각각 4, 3 및 5 인 경우에 대한 해결책을 아는 예이다. 일부 사람들은 과거 솔루션에 대한 내부 지식을 빠르게 활용하고 필요한 경우이를 적용 할 수 있습니다. 이것은 보통 면접관이 좋은 생각 일 수도 있고 아닐 수도있는 것으로 생각합니다.

2. 창의적 즉흥 기술. 이전 솔루션을 모르거나 문제를 Diophantine 방정식으로 모델링 할 수있는 것으로 인식하는 경우에도 마찬가지입니다. 따라서 문제는 주어진 것을 얼마나 빨리 사용하고 문제에 대한 해결책이 있는지에 대한 설명과 함께 창의적인 방식으로 문제에 대한 해결책을 찾을 수있는 방법입니다.

어느 경우 든 만족스러운 방식으로 질문을 지나친 것이 될 수 있습니다. 각 경우에 대한 답변도 시도 할 수 있기 때문에 의사 소통 기술에 대한 약간의 테스트가 있습니다. 이 기술은 언제 마지막으로 사용 되었습니까? " 면접관이 다른 방법이 더 효과적인 것으로 보일 수 있다는 것을 정확히보고 싶어하는 것에 대해 면담자가 열리면 흥미로운 대화로 이어질 수 있습니다.

특히 까다로운 문제는 아닙니다. 세 단계 만 필요하며 각 단계마다 두 가지 선택 만 있습니다. 내 동료 중 누군가가 매우 짧은 순서로 해결할 수 없다면 놀랐습니다. 인터뷰에서 그러한 문제를 제시하지는 않지만 그러한 질문을하는 것이 합리적이라고 생각합니다. 구문이나 라이브러리에 대한 자세한 질문보다 확실히 유용합니다.

OTOH, 프로그래밍 문제가 더 유용하다고 생각합니다.

누군가가 일을 잘할 것이라는 것을 절대 확실하게 알 방법이 없다는 것을 기억해야합니다. 특히 CS 직종에는 작업에 대한 많은 도전이 있기 때문에 예측할 수 없습니다.

따라서 잠재적 고용주는 미래의 성과를 추측해야합니다.

학위, 권장 사항 및 GPA는 시간 / 노력 및 사회 공학을 통해 얻을 수 있으며, 업무 경험을 꾸미거나 틀릴 수 있으며, 표준화 된 시험은 솔직히 너무 기초적인 능력을 나타내기에는 너무 기본적입니다. 따라서 이력서는 당신의 역사에서 노력 / 약정 수준을 나타낼 수 있지만 컴퓨터 과학의 세계에서 발생하는 어려운 문제를 해결하는 실제 능력과는 아무런 관련이 없습니다. 나는 몇 가지 좋은 논리 / 수학 / CSy 퍼즐보다 그런 종류의 능력을 예측하는 더 좋은 방법을 생각할 수 없습니다.

그것은 추측 게임이며, 현실적으로 우리와 동등한 모든 것은 불가능한 퍼즐보다 퍼즐을 풀 수있는 누군가를 고용 할 것입니다.

네, 당신은 면접 퍼즐을 공부할 수는 있지만, 주어진 퍼즐이 당신이 공부 한 퍼즐과 맞지 않으면 화상을 입을 것입니다 ... 퍼즐과 그 해결책을 외우지 않는 한, 퍼즐을 공부하는 것 그 자체가 당신을 실제 교육처럼 실제적으로 똑똑한 사람으로 만들 것입니다.