개발자 입장을 인터뷰 할 때 가능한 고용주에게 물어 보는 것이 좋은 질문인지 궁금합니다.
개발 팀의 가장 큰 강점과 약점은 무엇입니까?
면접을 볼 때 우리 모두이 질문을받습니다. 답을 물어 보지 않겠습니까? 팀에 대해 알 수 있고이 강약이 어떻게 우리에게 영향을 줄 수 있는지에 대해 매우 좋은 질문이라고 생각합니다.
개발자 입장에서 인터뷰 할 때이 질문을하는 데 단점이 있습니까?
개발자 입장을 인터뷰 할 때 가능한 고용주에게 물어 보는 것이 좋은 질문인지 궁금합니다.
개발 팀의 가장 큰 강점과 약점은 무엇입니까?
면접을 볼 때 우리 모두이 질문을받습니다. 답을 물어 보지 않겠습니까? 팀에 대해 알 수 있고이 강약이 어떻게 우리에게 영향을 줄 수 있는지에 대해 매우 좋은 질문이라고 생각합니다.
개발자 입장에서 인터뷰 할 때이 질문을하는 데 단점이 있습니까?
답변:
나쁜 질문은 아니지만 개인적으로 그렇게 말하지는 않습니다.
먼저 개발 팀과 프로세스에 대해 질문하고 그들 자신에 대한 강점과 약점을 선택하려고 노력합니다. 주어진 답변, 지원하는 직종, 개발 팀에서 가장 중요하게 생각하는 내용에 따라 달라지기 때문에 좋은 질문을하기는 어렵습니다.
내가 줄 수있는 가장 좋은 조언은 질문이 대화처럼 들리도록하고 심문보다는 덜 소리 내도록 노력하는 것입니다. 또한 미리 알고 싶은 일의 목록을 계획하십시오.
그런 식으로 말하지 마십시오. 모두는 가짜 (IMHO) "강점과 약점"문제를 미워합니다. 뒤집어서 다시 사용할 필요가 없습니다.
동일한 정보를 얻는 훨씬 더 좋고 확실한 질문은 다음과 같습니다.
팀의 역사, 시작 방법, 팀원은 어디에서 왔습니까? 이전 팀원들은 떠날 때 어디로 갔습니까?
왜 x 위치를 채우려 고합니까?
귀하와 팀이 직면 한 가장 어려운 과제는 무엇입니까?
이 팀이 작업 한 프로젝트의 수명주기를 안내해 줄 수 있습니까? 어떻게 시작하고 끝냈습니까? 이해 관계자, 테스터 (있는 경우), 운영 (있는 경우) 및 유지 관리와 팀의 관계는 무엇입니까?
문제가 발생하면 팀은 어떻게 대응합니까? 마지막 / 현재 / 가장 큰 위기에 대해 말씀해 주시겠습니까?
이러한 질문에 대한 답을 얻으면 해당 팀과 함께 일하는 것이 어떤 모습인지 알 수 있습니다. 이것은 고용 관리자가 업무 환경의 장단점을 실제로 설명 할 수있는 편안한 기회입니다. 숨겨진 질문이 있음을 나타내는 그러한 질문에 대한 가짜 답변을 탐지하는 것도 쉽습니다.
당신 (그리고 다른 사람들)을 고용함으로써 그들은 팀의 역 동성을 변화시키고 있기 때문에 물어볼 가치가 얼마나 있는지 모르겠습니다. 그들은 특정 기술이 부족하거나 다른 개발자가 작업을 수행해야 할 필요가 있는지 여부에 관계없이 현재의 약점을 분명하게 식별하고 그 약점을 수정하려고합니다. 사람들이 팀에 사람을 추가하자마자 역학이 바뀌었고 그들의 대답은 더 이상 유효하지 않을 수도 있습니다.
현재 팀 관행과 원하는 프로세스 개선에 대해 묻는 것이 더 통찰력이있을 것입니다. 팀이 현재 작업 수행 방식에있어 인터뷰와 잠재적 시작 날짜 (시작 날짜가 몇 개월이 지난 경우 제외) 사이에 급격히 변하지 않을 것이며 프로세스, 방법론 및 도구에 대한 개선 사항을 요구하는 경우 이러한 노력에 도움이 될 기술이나 지식이 있음을 나타낼 수있는 기회를 제공 할 수 있습니다.
예,이 질문을하는 데에는 몇 가지 단점이 있습니다. 우선, 귀하가 요청하는 사람이 실제로이 질문에 대답 할 수있는 능력이 얼마나 있습니까? HR 담당자에게이 질문을한다면 합법적 인 답변이 무엇인지 전혀 모를 수도 있습니다. 관리자조차도 팀이 여전히 비교적 새롭고 사회적 역학 및 일을 끝내는 것에 대해 잘 알려져 있지 않은지 알 수 없습니다. 다른 쪽은 당신이 후속 질문 방법을 알지 않는 한 어떤 답이 유행어 또는 모호한 것으로 가득 차있을 가능성이 약간 있기 때문에이 질문으로 시작할 수있는 언어 체조를 위해 어떻게 준비되어 있습니까? 더 어려운 질문이 있습니다. 예를 들어 그들이 협력하고 힘을 잘 전달한다고 주장한다면 더 심문 할 준비가되어 있습니까?
반대로, 나는 약간의 팀 역사를 요구하고 싶었다.
그것은 내 마음에 오히려로드 된 것으로 인식 될 수있는 질문보다 내 마음에 훨씬 더 유용 할 것입니다. 노력에 감탄할 수는 있지만, 어떤 회사가 팀 역학을 연구하여 팀의 강점과 스타일을 공개 할 수 있는지에 대해 얼마나 잘 연구했는지 궁금합니다.
그들이 "언어 체조"에 얼마나 잘 응답하는지 알지 못한 채이 질문을하는 것에 대한 의견은 위에서 언급 한 "언어 체조"에 익숙해지면서 "우리는 여기에서 최고만을 고용한다"또는 보일러 플레이트 인 다른 것을 쉽게 예측할 수 있기 때문에 답을 발견하기위한 조사가 필요한 답은 정확한 답을 제시하기보다는 예의를 지키려고 노력하는 사람이었습니다. 또 다른 일반적인 대답은 "모두가 잘 지내고있다"는 것이며, 적대감이 숨겨져 있는지 또는 팀이 실제로 함께 일하는 많은 성숙한 사람들인지 궁금해 할 수 있습니다.
나는 약점을 요구하기보다는 "개발팀의 가장 큰 도전은 무엇입니까?"라는 질문을 되풀이하고 싶습니다. 고의적으로 문제를 일으키려고 노력하는 것이 아니라 팀이 어떻게 보이는지에 대한 통찰력을 얻으려고 노력하는 것이 아닙니다.
어떤 시점에서, 그들은 당신이 팀에 합류하도록 격려하고 싶다면 적어도 긍정적 인 문제를 해결해야합니다. 모든 품질 관리자 / 팀 리더는 매일이 질문을해야합니다. 아무도 완벽하지 않습니다. 인식 할 수없는 경우 계속 작동하지 않을 수 있습니다.
그들이이 공세를 찾거나 그러한 질문을하는 것이 당신의 장소라고 생각하지 않는다면, 당신은 그 일을 원하지 않을 수 있습니다. 질문에 대한 혐오감은 불안하거나 최소한의 의사 소통의 징후 일 수 있습니다.
개인적으로, 나는 문제를 기꺼이 인식하기 때문에 문제를 공격하는 사람들을 좋아합니다 (12 단계 중 1 단계가 아닙니까?).
예산, 레거시 코드, 직원 수, 유능한 직원이 고임금 일자리로 떠나는 경우, 업무의 성격으로 인해 개발자가 다른 시간대의 팀원을 수용해야하는 경우가 종종 있습니다. 소액 관리 성향, 복장 규정, 근무 시간 등과 같은 회사 차원의 정책.이 중 어느 것도 팀에 부정적인 영향을 미치거나 제한 할 수 있습니다.
나는 그것이 정말로 이상한 질문이라고 생각합니다. 어떤 답변이나 정보를 기대하십니까?
개발 직책을 신청하는 경우 기술적 인 측면에 대해 더 많이 문의하시기 바랍니다. 예를 들어 "어떤 방법을 사용하고 있습니까?", "어떤 도구를 사용하고 있습니까?"등
팀에게 자신에 대한 의견을 묻는 것은 사건에 대한 그들의 반응이 어떻게 결과를 가져 왔는지에 대한 질문 만큼은 아닐 것입니다. 이러한 유형의 질문은 행동 문제 라고하며 과거 행동이 미래 행동을 가장 잘 예측할 수 있다는 생각에 근거합니다.
행동 유형 질문을 준비 할 때 일반적인 모델 방법은 STAR 방법을 사용하는 것입니다. 즉, 질문이 특정 상황, 작업, 행동 및 논의 된 상황의 결과에 대한 토론을 이끌어내는 방식으로 구성됩니다.
예를 들어, "팀에 합류 한 후 팀의 가장 큰 성공은 무엇이며, 그 기회는 무엇이며, 팀 활동은 팀 활동에 가장 큰 영향을 미쳤으며,이 성공이 회사에 미치는 영향은 무엇입니까?"