기술 인터뷰 중에 얼마나 많은 도움을 주어야합니까? [닫은]

많은 기술 인터뷰 중에 공연을하거나 앉으라는 요청을 받았습니다. 인터뷰 대상자가 종이로 해결할 수있는 논리적 인 질문과 간단한 프로그래밍 문제를 묻습니다. (단지 키보드에 액세스 할 수는 있지만 다른 시간에는 문제가됩니다.) 때때로 사람들은 문제에 접근하는 방법을 알고 있지만 긴장이나 질문에 대한 두 번째 추측에 매달려 있습니다 ( 그들은 트릭 질문이 아닙니다.)

상사가 도움이나 힌트를주는 것을 들어 본 적이 없습니다. 그는 응답에 대해 인터뷰 대상에게 감사의 말을 전하고 (아무리 좋든 나쁘 든) 다음 질문이나 문제로 넘어갑니다. 그러나 나는 패배와 신경이 당신을 이끌어 낼 수있는 토끼 구멍에 대해 알고 있으며 어떻게 그것이 당신의 마음을 무력화시키는 지 알고 있습니다. 지금 약간의 도움을 줄지 궁금해 할 수는 없습니다. 더 실패한 인터뷰.

난민 면접관에게 힌트와 도움을 제공해야합니까 (그렇다면 준비된 응시자들에게 공정한 태도를 유지하면서 얼마나 멀리 가야합니까)?

비슷한 입장에 있었을 때, 나는 인터뷰 대상자에게 다음과 같이 말할 것이다.

한 질문에서 인터뷰 대상자들은 실린더의 부피를 알아낼 수 있어야했기 때문에 누군가가 "실린더 부피에 대한 공식을 구글에 알려야한다고 생각하지 않았다"고 말했다. 나는 그들이 공식을 외우지 않고 문제를 공격하는 방법을 알고 있는지 알고 싶었다. 그 일을 위해, 그들은 실제 세계를 소프트웨어로 번역하는 방법에 대해 잘 알고 있어야했기 때문에 중요한 개념이었습니다.

반면에 나는 그들에게 그 공식이 필요하다고 말하지 않았습니다.

당신은 신경이 문제가 될 수 있다는 것은 맞지만, 여전히 사람들이 긴장하더라도 그들의 사고 과정을 표현할 수있을 것으로 기대합니다. 대답을하지 않으면 받아 들일 수 없었습니다.

문제 해결과 짧은 기술 질문에 모두 적용되는 두 가지 접근 방식이 있습니다.

1. 첫 번째는 상사가 사용합니다. 스트레스가 많은 상황에서 사람의 행동을 테스트하기 위해 도움을 제공하지 마십시오. 그것은 완전히 유효한 접근법이며, 그 사람에 대한 힌트를 줄 수 있습니다. 결국, 당신이이 사람을 고용하면, 그녀는 모든 동료들로부터 지속적인 도움을받을 수 없습니다.

2. 두 번째는 힌트와 지원을 제공하는 것입니다. 지원 수준은 그다지 중요하지 않습니다. 중요한 것은 당신이 그 사람에게 더 많은 도움을 줄수록, 그녀의 성공을 덜 중요하게한다는 것입니다.

개인적으로, 나는 당신이 그 사람이 스스로 문제를 해결할 수 없다는 것을 확신하고 도움 없이는 해결할 수 없다고 느끼도록 충분한 시간을 가져야한다고 믿습니다. 그러나 그 사람에게 답변 자체를 말할 때까지 점진적인 도움을 제공 할 수 있습니다.

예:

C C #에서 읽기 전용 속성, 즉 생성자 내에서만 초기화 할 수 있고 나중에 변경할 수없는 값을 가진 속성을 만드는 방법을 알려줄 수 있습니까?
- 물론이야. 난 그냥 키워드를 사용합니다 readonly.
- 확실합니까? 속성과 필드의 차이점을 설명해 주시겠습니까?
‒ 흠. 속성은 ... 알다시피 ... 가져오고 설정 ...
‒ 좋아. 따라서 필드는 클래스 또는 구조체 내에서 선언되고 클래스 / 구조 범위 내에서 유효한 변수이며 속성은 필드와 유사하지만 값을 읽거나 쓰거나 계산하는 메커니즘을 제공합니다. 이제는 어떻 readonly습니까? 속성과 함께 사용됩니까?
fields 필드에만 사용된다고 생각합니다 ... ...
맞습니다. 그렇다면 속성은 어떻습니까?
‒ 읽기 전용이 아닙니다.
- 확실합니까? 게터 만있는 속성은 어떻습니까?
read 읽기 전용입니다.
their 가치가 항상 동일하게 유지된다는 의미입니까?
- 예.
- 아니 정말. 게터가있는 속성이 있다고해서 클래스 인스턴스의 수명 동안 값이 변하지 않는다는 의미는 아닙니다. getter가 속성에 액세스 할 때마다 증가하는 필드를 참조하면 반환 된 값이 계속 증가합니다.
- 권리.
‒ 그래서? 결코 변하지 않는 값으로 속성을 구현할 수있는 방법에 대한 아이디어가 있습니까?
‒ 아니오.
‒ 글쎄, 당신은 읽기 전용 백업 필드를 사용할 수 있습니다. 후원 분야가 무엇인지 아십니까?
[...]

모든 경우에 답을주는 것이 좋습니다. 인터뷰 대상자가 흥미로운 답변으로 내 답변에 댓글을 달았을 때 처음에 질문에 대답 할 수 없더라도 관련 내용을 알고 있음을 보여주는 몇 가지 사례가있었습니다.

또한, 단지 더 이상의 도움으로 질문을함으로써, 당신은 그 사람에 대해 너무 많은 정보, 그녀가 알거나 답을 알고하지 않는 것을 제외하고는 사실을 가지고 있지 않습니다 . 점진적인 도움을 제공하면 그 사람이 문제에 대해 어떻게 생각 하는지 알 수 있습니다 .

또한 그 사람이 모르는 다른 것들을 보여줄 수도 있습니다. 위의 예를 보자. 첫 번째 답장에서 그만두면 그 사람이 필드와 속성의 차이를 설명 할 수 없거나 지원 필드가 무엇인지 모른다는 것을 알지 못했을 것입니다.

사람이 즉시 대답하면 괜찮습니다. 그녀가 도움이 필요하다면 이것에 아무런 문제가 없습니다. 질문에 스스로 대답하면 나쁜 징조이며 인터뷰 대상자가 다른 질문에 대답 할 수 있기를 바랍니다.

나는 인터뷰 대상자들이 (단지 어떤 패턴인지 정확히 알고 있다면 특정 패턴의 이름과 같은) 간단한 것에 고착하고 데이터베이스 연결 설정의 세부 사항과 같은 것들에 대해 글을 쓰면 항상 도움을주고 싶다. 그들이 무언가를 디자인하려고 노력하고 있다면, 나는 그들이 가고있는 곳이 아닌 다른 것에 대해 생각하고 있다면 그들을 인도하거나 버리기를 원하지 않기 때문에별로 말하지 않습니다.

매우 구체적인 결과를 염두에 둔 면접관에게 특정 문제 해결 질문을 받았지만 그 질문을 명확하게 전달할 수 없었습니다. 이것은 많은 인터뷰 대상자들이 처한 상황을 설명합니다. 때때로 빈 응시는 그 사람이 좋은 문제 해결자가 아니기 때문에 질문을하는 사람이 그들이 요구하는 것에 대해 명확하지 않기 때문입니다. 이 경우, 말하고 행동하는 동료의 접근 방식은 후보자가 동료처럼 생각하지 않거나 동료의 머리 속에 있지 않다는 것을 증명합니다. 다른 단어로 질문을 명확하게 설명하면 관련된 모든 사람들에게 더 나은 결과를 제공 할 수 있다고 생각합니다.

프로그래머들 (적어도 우리 중 대부분)은 진공 상태에서 일하지 않으며, 인공적인 한계없이 면담이 충분히 스트레스가된다는 점을 감안할 때, 면담자가 요구하거나 요구하는만큼 많은 도움을 줄 수있는 경향이 있습니다.

그러나 지원자의 실제 역량 수준에 대한 최종 판단을 내릴 때는 모든 사항을 고려하십시오.

고위 직책을 찾고 있지만 많은 도움이 필요한 사람은 알람 벨을 울릴 것입니다.

"고령자"는 짧고 개방적인 질문을 제공하며 답변보다 질문에 더주의를 기울입니다. 나는 듣고, 의사 소통하고, 적극적인 경청을 사용하고, 명확히하고, 그런 다음 해결책이 내가 좋아하는 유형을 제공하는 노인들을 찾습니다.

"라인 엔지니어"의 경우, 지원자에게 컴퓨터와 문제를주고 몇 시간 동안 프로그래밍 테스트를 수행하는 기술을 사용했습니다. 그러한 상황에서, 우리는 신청자에게 그들이 선호하는 OS와 툴 (프로그래머의 전문 지식의 흥미로운 부분)을 사전에 요청했습니다. 그들이 끝났을 때, 그룹으로서 우리는 그들에게 해결책을 제시하라고 요청했고 그것이 왜 다른 해결책보다 더 나은지, 코드 검토였습니다. 숙련 된 엔지니어가 1 일에 기대하는 모든 기술.

중요한 것은 인터뷰 팀 전체가 오후에 동일한 테스트를 수행 했으므로 테스트가 공정하다는 것을 알았습니다. 인터뷰 대상자와 마찬가지로 각 사람의 접근 방식을 조사하는 데 한 시간을 보냈습니다.

이 두 번째 기술은 내가 찾은 최고의 "성능이없는"프로그래머 (이력서, 이력서 인터뷰 기술) 중 일부를 발견했습니다.

후보자가 프로세스에 익숙해 지도록 쉬운 자신감 구축 질문으로 인터뷰를 시작하는 것을 선호합니다. 이것이 효과가있을 때 직업 관련 자료보다 신체 언어를 더 잘 이해하는 응시자에게 도움을주지 않으면 서 이후 질문에서 가능한 많은 정보를 얻을 수 있습니다.

때때로 minor hints구술 면담 중에 제공 하면 응시자가 주제를 얼마나 잘 이해하는지 알 수 있습니다. 그러나 no hints각 응시자가 요구하는 표준 시험 이 있어야합니다 .

기본적으로 two main things잠재적 후보에 대해 알고 싶을 수도 있습니다.

a) 개인 특성 -회사 나 팀에 잘 맞습니까?

b) 기술 능력 -그는 좋은 기술적 배경을 가지고 있으며 새로운 물건을 집어 올리는 데 관심이 있습니까?

이러한 언급 된 사항에 대해 배우려면 잠재적 후보를 대화에 참여시켜야합니다. 또한 후보자가 comfortable during the interview자신의 현재 기술 (부드럽고 기술적 인 기술)과 작업 수행 가능성을 최대한 이해하도록 하는 것이 중요합니다 .

또한, 잠재적 후보의 의사 소통 기술은 문제를 해결하기위한 그의 기술과 능력 만큼 중요 합니다.

살펴 봐야 할 부분 중 하나는 의사 소통 기술입니다. 응시자가 질문에 대해 명확하지 않은 경우 질문을 명확하게해야합니다. 제 생각에는 이것이 좋은 것입니다. 사양을 읽을 때 또는이 경우 인터뷰 질문을 처리 할 때 특정 가정이 이루어 지므로 잘못된 결정이 너무 자주 내려집니다. 응시자는 이러한 가정에 근거하여 대답하고 의도 한 요점을 완전히 놓칠 수 있습니다. 질문에 결함이 있거나 후보 일 수 있습니다. 두 경우 모두, 커뮤니케이션을 통한 설명을 허용하면 고용주가 찾아봐야 할 소중한 기술이됩니다.

나는 이것이 면접관으로서 당신의 성격에 달려 있다고 생각합니다. 그리고 당신이 생각하는 것이 중요하고 따라서 실제로 후보자를 채점하고 있다고 생각합니다.

개인적으로 나는 학문적 / 비밀 한 사소한 것보다 실용적 / 실용적 능력을 중요하게 생각합니다. 나는 입후보하고, 일하고, 그들이 일하고있는 어떤 프로젝트 (들)에 어떤 귀중한 방법으로 효과적으로 기여할 수있는 후보자에게 훨씬 더 관심이 있습니다.

따라서 후보자가 난해하거나 거의 사용되지 않는 뉘앙스 또는 메이크업 인터뷰 질문과 관련이있을 수 있지만 실제와는 관련이없는 최첨단 사례에 갇혀 있으면 조금 코치 할 것입니다. 특히 Google에서 몇 분 또는 편리한 책상 참조를 사용하거나 "설정하여 잊어 버릴 수있는"유형의 항목으로 얻을 수있는 모든 항목입니다.

그러나 나는 실제, 공통, 주류, 기본, 일상 업무에 대해서는 코치하지 않을 것입니다. 이것들은 내가 그들에게 타고난 것을 원합니다.

나는 그것이 인터뷰 상황과 질문에 달려 있다고 생각합니다. 나는 두 가지 기술을 모두 사용했다.

후속 질문을하고 싶지 않은 이유는 무엇입니까? 스트레스에 대한 사람의 반응을 찾으려고 할 때. 나는 스트레스가 많은 환경에있는 사람들에 대해 사람들을 인터뷰했으며 스트레스를 얼마나 잘 처리 할 수 ​​있는지가 우리 평가에서 중요한 요소 였으므로 스트레스 없이는 아무도 대답 할 수없는 매우 어려운 질문을했습니다.

그들의 기술적 지식을 찾으려고 할 때, 내가 찾고있는 것에 대한 힌트를 포함 할 수있는 후속 질문을합니다. 모든 사람에게 동일한 질문을 공정하게 요구해야한다는 관리자의 생각과 달리, 나는 여러 조건이 충족되는 한 이것이 공정하다고 생각합니다. 먼저 모든 사람이 동일한 기본 질문을받습니다. 둘째, 한 사람 만 돕기 위해 후속 질문을하지 않아야합니다. 다른 사람들이 도움없이 flo 치게한다면, 모든 under 치가 도움없이 let 겨 져야합니다. 둘째, 문제에 대한 응시자의 성과를 최종 답변뿐만 아니라 답변에서 끌어내는 것이 얼마나 어려운지 비교해야합니다. 이 과정은 여전히 ​​모든 사람을 공정하게 대우합니다.

원하는 프로그래머 종류에 따라 다릅니다. 종이에 20 줄의 훌륭한 코드를 작성할 수있는 내향적인 사람은 당신에게 상사에게 좋을 것입니다. 좋은 소프트웨어를 효율적으로 생산하기 위해 팀 내에서 백만 개의 라인 코드 기반으로 작업 할 수있는 소프트웨어 개발자는 그다지 좋지 않을 것입니다. 나는 이런 종류의 인터뷰를 후보로 좋아합니다. 그들은 상사가 직원을 어떻게 대하는지와 직장 문화가 무엇인지에 대해 많은 것을 말해줍니다. 이와 같은 경우에 인터뷰를 떠날 때 "감사합니다. 전화하지 않으면 조금 시간을 절약 할 수 있습니다."라고 말했습니다. 이유를 물었을 때, 나는 나를 실패하게 만든 회사에서 일하고 싶지 않다고 지적했다.

당신은 소프트웨어 개발을 위해 더 나은 선택을 할 것입니다. 당신의 보스 접근 방식은 쓰레기 수집가와 도로 공사에서 Stop / Go 막대 사탕을 들고있는 사람들에게 잘 작동합니다.

소프트웨어 개발은 ​​팀 노력이며 솔로 / 마음 읽기 / 비대화 형 게임이 아닙니다. 소프트웨어가 원하는 작업이 아니라 요청 된 작업을 수행하기 때문에 실패한 프로젝트 수입니다.

나는 최근 비슷한 상황에 있었다. 관리자와 HR로부터받은 방향은 6 명의 인터뷰 대상자 모두에게 공정하게 대해야했기 때문에 각 인터뷰 대상자가 수행하는 방식을보기 위해 최소한의 도움으로 동일한 기술 관련 질문을해야했습니다. 때때로 그들은 대답을 알고 있었지만 기술적 인 용어 나 무언가로 고착했을 때 그 용어로 인도하는 몇 가지 질문을 간접적으로 도왔습니다. 그들이 1 라운드를 통과했을 경우 성격과 행동 특성에 관한 기술 라운드 후 2 차 인터뷰가있었습니다.

직원에게 원하는 것은 팀의 나머지 부분과 상호 작용할 수있는 사람입니다. 필요한 기술을 갖춘 사람이 필요합니다. 그러나 도움을 청해야 할 때를 알고 있으며이를 위해 자기 지식과 사회적 기술을 갖춘 사람도 필요합니다. 후자의 문턱 세트는 장기적으로 특정 컴퓨터 언어 Du-jour보다 회사를 더 잘 구축 할 것입니다.

내가 보는 방식으로, 인터뷰는 시험이 아닌 시험 협력 세션 입니다. 나는 주로 "이 사람과 함께 일하는 기분이 어떻습니까?"라는 질문에 대답하려고합니다. 나는 때때로 운동에 대한 협력 감을 느끼기 위해 질문에 대한 답 을 잊어 버린 척 하기도한다 .

문제가 생길 때마다 같은 페이지에 접근 할 수 없는 사람과 함께 일한 적이 있습니까? 아니면 문제를 해결하는 대신 너무 많은 질문을 한 사람이 있습니까? 인터뷰에서 나는 주로 내가 이야기하는 사람이 그들 중 하나가 아닌지 확인합니다. 거기에는 강력한 화학 요소가 있습니다.

물론 과정에서 "깨끗한 코드를 작성합니까?", "필요한 개념을 잘 알고 있습니까?", "통찰력을 얻기 위해 현명하게 문제를 제기 할 수 있습니까?" 후보자는 여전히 "운전"및 작성 코드가 될 것입니다. 그러나 그 길을 따라 그녀는 더 편안해질 것이고, 나는 실제로 매일 동료로 볼 수있는 것에 더 가까운 그녀의 버전을 보게 될 것입니다.