기술 인터뷰는 어렵습니다. 인터넷은 유감스럽게도 기술적 인터뷰 프로세스에 관한 이야기와 함께 화이트 보드, 숙제 또는 다른 어떤 것을 통해 후보자를 적절히 평가하는 것이 얼마나 어려운지에 대한 이야기로 가득합니다. 인터뷰 엔트리 레벨 엔지니어는 이론적으로 소프트웨어 작성에 대한 기본적인 이해가 부족하기 때문에 훨씬 더 어려울 수 있습니다.
작년에 클로버 엔지니어링 (Clover Engineering)은 준회원 프로그램을 만들었고 엔트리 레벨 엔지니어를 인터뷰하는 방법을 알아 내야했습니다. 다른 엔지니어에게 사용했던 것과 동일한 인터뷰 프로세스를 사용하는 것이 합리적입니까? 우리가 효과적으로 후보자들을 끌어 들이기 위해 얼마만큼 "바를 낮춰야합니까?
우리는 인터뷰 프로세스를 변경하거나 바를 많이 줄이지 않아도된다는 결론을 얻었습니다.
첫째, 우리는 어소시에이츠가 갖기를 원하는 특성을 결정했습니다.
엔지니어 팀은 우리 동료가 가져야한다고 생각한 일련의 특성을 연구했습니다. 프로그램이 성공적으로 완료되면 어소시에이트 (Associates)는 풀 타임 엔지니어로 졸업 할 것이므로 이러한 특성을 나머지 팀원들과 일치 시키려고했습니다. 특히 동료들에게서 찾은 몇 가지 특성은 다음과 같습니다.
- 탄력성 : 직장에서의 학습은 어렵고, 동료들은 어려운 개념을 통해 실수를하고 투쟁 할 것이라고 생각했습니다. 우리는 이러한 투쟁을 견뎌 낼 수 있고 다음 도전에 대비할 수있는 사람들이 필요했습니다.
- 배우고 자하는 의도와 그렇게하기위한 이니셔티브 : 클로버는 어소시에이트의 성장을 도울 것이며, 교사와 멘토가 길을 돕기 위해 제공하지만, 들어오는 어소시에이트는 자신의 성장에 책임을 져야합니다.
- 겸손 : 이것은 모든 클로버 엔지니어들에게 중요한 특징이지만 Associates에서는 특별한 관심을 보였습니다. 그들은 주변 사람들로부터 배우고, 다른 사람들을 존중하고, 은혜로 어려운 피드백을 가져야합니다.
둘째, 각 특성을 평가하는 방법을 결정했습니다.
우리가 Associate 형질의 목록을 얻었 으면, 각 형질을 평가할 수있는 구체적인 방법뿐만 아니라 각각을 조심스럽게 정의했습니다.
좋은 의도로 잘못된 신호를 얻는 것이 매우 쉽기 때문에 "평가하지 않는 방법"을 정의하는 것도 중요했습니다. 예를 들어, 겸손을 평가할 때 면접관이 실수로 "복종"을 찾길 원치 않았습니다. 우리는 방어력없이 의견을 수렴하고 면접관을 지휘관이 아닌 잠재적 공동 작업자로 취급하기를 원하는 사람들을 원했습니다. 우리는 그들이 어려운 질문을하고, 뭔가를 이해하지 못하거나 제안에 동의하지 않을 때 면접관에게 도전 할 것을 권장했습니다.
마찬가지로 개인 GitHub 프로필에서 독립적 인 프로젝트의 수를 기반으로 "배우려는 의지와 이니셔티브"를 평가하기를 원하지 않았습니다. 이것은 사람이 부업 프로젝트를 수행 할 수있는 여유가 있음을 나타낼 뿐이며 반드시 기존의 역할에서 새로운 도전을 감당할 준비가되어 있다는 것을 의미하지는 않습니다. 우리는 직장 동료가 자신의 삶을 직장 밖에서 살 수 있다고 느끼고 싶었고, 어떤 방식 으로든 최선의 방법으로 배우기를 원했습니다.
각 특성에 대해 후보자는 3 점 척도 (Fail, Pass 또는 Exceed)로 평가되었습니다. 우리는이 시스템을 선택하기가 쉽기 때문에 주어진 영역에서 특히 강했던 후보자에게 신용을 부여하는 동시에 이사회 전반의 우수성이 완전히 필요하지 않다는 것을 인정했습니다. 주목할 만하게, "잠재력"은 규모에 아무데도 없습니다. 많은 게시물은 엔트리 레벨 엔지니어를 "잠재력"에 대해 고용하는 것에 대해 이야기하지만 거의 정의되지는 않습니다. 대부분의 사람들은 후보자가 현재 자율적 인 기술자가 될 수는 없지만 언젠가는 미래에있을 수 있다는 의미를 설명하기 위해 "잠재력"을 사용합니다. 우리는 후보자의 미래를 예 측하려고 시도하지 않았지만 인터뷰를 통해 발표 한 내용을 평가했습니다.
좋은 의도로 잘못된 신호를 얻는 것이 매우 쉽기 때문에 "평가하지 않는 방법"을 정의하는 것도 중요했습니다. 예를 들어, 겸손을 평가할 때 면접관이 실수로 "복종"을 찾길 원치 않았습니다. 우리는 방어력없이 의견을 수렴하고 면접관을 지휘관이 아닌 잠재적 공동 작업자로 취급하기를 원하는 사람들을 원했습니다. 우리는 그들이 어려운 질문을하고, 뭔가를 이해하지 못하거나 제안에 동의하지 않을 때 면접관에게 도전 할 것을 권장했습니다.
마찬가지로 개인 GitHub 프로필에서 독립적 인 프로젝트의 수를 기반으로 "배우려는 의지와 이니셔티브"를 평가하기를 원하지 않았습니다. 이것은 사람이 부업 프로젝트를 수행 할 수있는 여유가 있음을 나타낼 뿐이며 반드시 기존의 역할에서 새로운 도전을 감당할 준비가되어 있다는 것을 의미하지는 않습니다. 우리는 직장 동료가 자신의 삶을 직장 밖에서 살 수 있다고 느끼고 싶었고, 어떤 방식 으로든 최선의 방법으로 배우기를 원했습니다.
각 특성에 대해 후보자는 3 점 척도 (Fail, Pass 또는 Exceed)로 평가되었습니다. 우리는이 시스템을 선택하기가 쉽기 때문에 주어진 영역에서 특히 강했던 후보자에게 신용을 부여하는 동시에 이사회 전반의 우수성이 완전히 필요하지 않다는 것을 인정했습니다. 주목할 만하게, "잠재력"은 규모에 아무데도 없습니다. 많은 게시물은 엔트리 레벨 엔지니어를 "잠재력"에 대해 고용하는 것에 대해 이야기하지만 거의 정의되지는 않습니다. 대부분의 사람들은 후보자가 현재 자율적 인 기술자가 될 수는 없지만 언젠가는 미래에있을 수 있다는 의미를 설명하기 위해 "잠재력"을 사용합니다. 우리는 후보자의 미래를 예 측하려고 시도하지 않았지만 인터뷰를 통해 발표 한 내용을 평가했습니다.
셋째, 기술적 인 질문을 디자인했습니다.
평가할 기술을 결정하는 것은 오랜 과정이었습니다. 우리는 동료 직원들에게 그들이해야 할 기술적 인 능력 대부분을 가르치기를 기대했지만, 완전히 비어있는 후보자는 받아 들일 수 없었습니다. 우리는 동료들에게서 찾아야 할 자질이 다음과 같다고 결정했습니다.
- 논리적으로 문제를 생각할 수있는 능력
- 일부 언어 (기본 요소, 배열, 해시 테이블, 루프, if 문)에서 기본 명령 프로그래밍 및 데이터 구조에 대한 확실한 이해
우리가 다른 후보자들과 같이 시험하지 않을 것이라고 결정한 것은 :
- 문제를 정의 할 수없는 문제에 기초하여 문제를 정의하는 능력
이러한 요구 사항을 감안할 때 표준 인터뷰 질문을 사용했지만 후보자가 공간 및 범위 문제를 정의하는 데 도움이되는 비계를 사용했습니다.
우리는 Associates의 일반 엔지니어링 후보자에게 우리가 사용하는 표준 전화 화면 질문을 유지했지만 일반 기술 후보자에게는 빈 편집기가 제공되는 샘플 기능 서명과 기본 테스트를 제공했습니다.
또한 화이트 보드 코딩을 완전히 고치고 대신 숙제를 할당했습니다. 일반 엔지니어를위한 숙제는 현실 세계의 문제를 모방하고 후보자가 그 문제에 대한 검증 된 해결책을 찾아올 것으로 기대합니다. 응시자는 응시자가 문제의 범위를 이해하고 응답의 범위를 적절하게 정해야했기 때문에 Associates에 동일한 질문을 사용하지 않았습니다. 대신, 이전에 화이트 보딩 (white-boarding) 운동으로 사용한 알고리즘 질문을 사용했습니다. 우리는 문제에 대한 테스트 케이스를 작성하여 응시자가 예상되는 사항을 알게되고 새 프로젝트 및 테스트 케이스를 설정하는 것에 대해 걱정할 필요가 없습니다.
시스템 설계에 대한 읽기를 얻으려면 일반 후보들에게 광범위한 문제를 제시하고 시스템을 솔루션으로 그려 줄 것을 기대합니다. 우리는 Associates에 대해 동일한 질문을 사용했지만 시스템의 기본 구성 요소에 대해 설명하고 구성 요소 중 어떤 것이 보이는지 설명하도록 요청했습니다. 시간이 있었다면 다른 구성 요소로 이동하게 할 수 있습니다.
우리는 Associates의 일반 엔지니어링 후보자에게 우리가 사용하는 표준 전화 화면 질문을 유지했지만 일반 기술 후보자에게는 빈 편집기가 제공되는 샘플 기능 서명과 기본 테스트를 제공했습니다.
또한 화이트 보드 코딩을 완전히 고치고 대신 숙제를 할당했습니다. 일반 엔지니어를위한 숙제는 현실 세계의 문제를 모방하고 후보자가 그 문제에 대한 검증 된 해결책을 찾아올 것으로 기대합니다. 응시자는 응시자가 문제의 범위를 이해하고 응답의 범위를 적절하게 정해야했기 때문에 Associates에 동일한 질문을 사용하지 않았습니다. 대신, 이전에 화이트 보딩 (white-boarding) 운동으로 사용한 알고리즘 질문을 사용했습니다. 우리는 문제에 대한 테스트 케이스를 작성하여 응시자가 예상되는 사항을 알게되고 새 프로젝트 및 테스트 케이스를 설정하는 것에 대해 걱정할 필요가 없습니다.
시스템 설계에 대한 읽기를 얻으려면 일반 후보들에게 광범위한 문제를 제시하고 시스템을 솔루션으로 그려 줄 것을 기대합니다. 우리는 Associates에 대해 동일한 질문을 사용했지만 시스템의 기본 구성 요소에 대해 설명하고 구성 요소 중 어떤 것이 보이는지 설명하도록 요청했습니다. 시간이 있었다면 다른 구성 요소로 이동하게 할 수 있습니다.
마지막으로 우리는 그들을 인터뷰했습니다.
엔지니어링 팀은 '통과'가 적용되지 않는 것으로 보이는 벤치마킹에 관심이 있었으며 인터뷰는 일반적인 엔지니어링 후보와 크게 다를 것입니다. 이러한 문제를 완화하기 위해 우리는보다 쉬운 비교를 위해 엔지니어링 팀의 일관된 부분과 인터뷰를했습니다. 또한 모호성을 줄이기 위해 합격 및 불합격 상태를 명확하게 정의했습니다.
어떻게 되었습니까?
놀랍게도. 우리는 우리의 모든 후보자들의 전반적인 질에 깊은 인상을 받았으며 어소시에이츠 중 어떤 사람이 우리를 이끌어 낼 수 있을지 결정하기가 어려웠습니다. 결국 우리는 7 명으로 구성된 코호트에 정착했으며, 그 중 4 명은 인터뷰 프로세스를 통해 선발되었으며, 누구나 프로그램을 완료하고 클로버 엔지니어를 "성장"시키고 있습니다. 가장 중요한 점은 "기술적 인 문제를 줄이거 나"우리 표준을 손상시키지 않으면 서 일군의 엔지니어들과 인터뷰, 선상 및 성장할 수있었습니다.
최신 정보:
나는이 기사에 대한 반응에 너무 놀랍고 겸허하다! 읽어 주셔서 감사합니다. Clover 's Associate 프로그램에 대한 자세한 이야기를 기대해주십시오.
똑똑하고 사려 깊은 사람들과 팀을 이루어야한다는 아이디어가 마음에 들면 클로버는 샌프란시스코와 저지 시티의 두 곳에서 일하게됩니다. 우리는 당신과 이야기하고 싶습니다. 한 번 봐 가지고 우리의 채용 페이지를 자세한 내용은.
마지막으로 기사에 대한 수정을하고 싶습니다. 우리는 7 명의 동료들로 구성된 최종 코호트로 끝났으며 그 중 4 명은 인터뷰 과정을 거쳤습니다. 다른 이들은 이전 인턴이나 다른 팀의 전학이었습니다. 정확성을 위해 원본 문장을 업데이트했습니다
By AB3S
0x6306752FFCB7F1e13d6dd2134750ac9655eD4200
Comments
Post a Comment