후배를 길들이는 방법?

후배라면 대기업에 어떻게 들어갈 수 있나요? 대기업이라면 괜찮은 후배를 어떻게 채용하나요? 아래에서는 프런트 엔드에서 초보자를 채용한 이야기를 들려드리겠습니다. 테스트 작업을 어떻게 진행하고, 인터뷰를 준비하고, 신입 사원의 개발 및 온보딩을 위한 멘토링 프로그램을 구축했는지, 표준 인터뷰 질문이 왜 필요하지 않은지 알려드리겠습니다. 작동하지 않습니다.

주니어를 길들이려고 해요

안녕하세요! 제 이름은 Pavel이고 Wrike 팀에서 프론트엔드 작업을 하고 있습니다. 우리는 프로젝트 관리 및 협업을 위한 시스템을 구축합니다. 저는 2010년부터 웹 작업을 해왔고, 해외에서 3년 동안 일했으며, 여러 스타트업에 참여했고, 대학에서 웹 기술에 대한 강의를 했습니다. 회사에서는 후배들을 위한 기술과정 개발과 Wrike 멘토링 프로그램 개발에 참여하고 있으며, 직접 채용도 하고 있습니다.

우리는 왜 후배 채용을 생각하게 되었나요?

최근까지 우리는 온보딩 후 제품 작업을 수행할 수 있을 만큼 독립적인 프런트엔드를 위한 중간 또는 고위급 개발자를 모집했습니다. 올해 초에 우리는 이 정책을 변경하고 싶다는 것을 깨달았습니다. 지난 한 해 동안 우리 제품 팀의 수가 거의 두 배로 늘었고 프런트엔드 개발자의 수가 2명에 가까워졌으며 가까운 시일 내에 이 모든 것이 이루어질 것입니다. 다시 두 배로 늘려야 합니다. 일이 많고 자유로운 손이 거의 없으며 시장에는 그 수가 훨씬 적습니다. 그래서 우리는 이제 막 프런트 엔드에서 여정을 시작하는 사람들에게 의지하기로 결정하고 그들의 분야에 투자할 준비가 되었음을 깨달았습니다. 개발.

후배는 누구입니까?

이것이 우리가 스스로에게 던진 첫 번째 질문입니다. 다양한 기준이 있지만 가장 간단하고 이해하기 쉬운 원칙은 다음과 같습니다.

주니어에게 어떤 기능이 있고 어떻게 하는지 설명해야 합니다. 중간에서는 어떤 기능이 필요한지 설명해야 하며, 중간에서는 구현 방법을 직접 알아낼 것입니다. 서명자는 왜 이 기능을 전혀 수행할 필요가 없는지 설명할 것입니다.

어떤 식 으로든 후배는 특정 솔루션을 구현하는 방법에 대한 조언이 필요한 개발자입니다. 우리가 구축하기로 결정한 것:

1. 주니어는 발전하고 싶어하고 이를 위해 열심히 노력할 준비가 되어 있는 사람입니다.
2. 그는 자신이 어떤 방향으로 발전하고 싶은지 항상 아는 것은 아닙니다.
3. 조언이 필요하고 리더, 멘토 또는 커뮤니티 등 외부로부터 도움을 구합니다.

우리는 또한 다음과 같은 몇 가지 가설을 세웠습니다.

1. June의 입장에 대한 반응이 폭풍처럼 쏟아질 것입니다.. 이력서를 보내는 단계에서 무작위 응답을 필터링해야 합니다.
2. 기본 필터는 도움이 되지 않습니다. — 더 많은 테스트 작업이 필요합니다.
3. 테스트 작업은 모두를 놀라게 할 것입니다 - 필요하지 않습니다.

물론 우리에게는 다음과 같은 목표가 있었습니다. 4주만에 후배 3명.

이 깨달음으로 우리는 실험을 시작했습니다. 계획은 간단했습니다. 가능한 가장 넓은 유입경로에서 시작하여 흐름을 처리할 수 있도록 점진적으로 범위를 좁히되 주당 1명의 후보자로 줄이지는 마세요.

공석을 게시합니다

회사를 위해: 수백 개의 응답이 있을 것입니다! 필터를 생각해 보세요.

주니어용: 이력서와 시험 과제를 보내기 전에 설문지를 두려워하지 마십시오. 이는 회사에서 귀하를 배려하고 프로세스를 잘 구성했다는 신호입니다.

첫날 우리는 "JavaScript에 대한 지식이 있는" 지원자로부터 약 70개의 이력서를 받았습니다. 그리고 다시. 그리고 더. 우리는 물리적으로 인터뷰를 위해 모든 사람을 사무실에 초대할 수 없었고 그중에서 가장 멋진 애완동물 프로젝트, 라이브 Github 또는 최소한 경험이 있는 사람들을 선택했습니다.

그러나 첫날 우리가 스스로 내린 결론은 폭풍이 시작되었다는 것이었습니다. 이제 이력서를 제출하기 전에 설문지를 추가할 차례입니다. 그녀의 목표는 이력서를 제출하기 위해 최소한의 노력을 기울일 의지가 없는 지원자와 최소한 Google에서 정답을 찾을 수 있는 지식과 맥락이 없는 지원자를 제거하는 것이었습니다.

여기에는 JS, 레이아웃, 웹, 컴퓨터 과학에 대한 표준 질문이 포함되어 있습니다. 프론트엔드 인터뷰에서 무엇을 물어볼지 상상하는 사람이라면 누구나 그 질문을 알고 있을 것입니다. let/var/const의 차이점은 무엇입니까? 너비가 600px보다 작은 화면에만 스타일을 적용하려면 어떻게 해야 합니까? 우리는 기술 인터뷰에서 이러한 질문을 하고 싶지 않았습니다. 실습에 따르면 개발을 전혀 이해하지 못한 채 2~3번의 인터뷰 후에 답변을 얻을 수 있는 것으로 나타났습니다. 그러나 그들은 처음에 후보자가 원칙적으로 맥락을 이해하고 있는지 여부를 우리에게 보여줄 수 있었습니다.

각 카테고리마다 3~5개의 질문을 준비했으며 가장 무난하고 가장 어려운 질문을 제거할 때까지 매일 응답 양식의 질문 세트를 변경했습니다. 이를 통해 흐름을 줄일 수 있었습니다. 3주 만에 우리는 후보자 122명, 이를 통해 더 많은 작업을 수행할 수 있습니다. 이들은 IT 학생들이었습니다. 백엔드에서 앞쪽으로 이동하고 싶은 사람들; 근본적으로 직업을 바꾸고 자기 교육, 과정 및 인턴십에 다양한 노력을 기울이고 싶어하는 25~35세의 근로자 또는 엔지니어.

서로를 더 잘 알게 됨

회사를 위해: 테스트 작업은 지원자를 단념시키지 않지만 퍼널을 단축하는 데 도움이 됩니다.

주니어용: 테스트 항목을 복사하여 붙여넣지 마십시오. 눈에 띕니다. 그리고 github을 순서대로 유지하세요!

기술 인터뷰를 위해 모든 사람에게 전화를 걸면 후배들과 프론트엔드에 대해서만 일주일에 약 40번의 인터뷰를 진행해야 합니다. 따라서 우리는 테스트 작업에 대한 두 번째 가설을 테스트하기로 결정했습니다.

테스트에서 우리에게 중요한 것은 무엇입니까?

1. 확장성이 뛰어난 아키텍처를 구축하되 과도한 엔지니어링은 피하세요.
2. 하룻밤 사이에 공예품을 모아 "꼭 끝내겠습니다"라는 코멘트와 함께 보내는 것보다 시간이 오래 걸리지만 잘하는 것이 더 낫습니다.
3. Git 개발의 역사는 엔지니어링 문화, 반복 개발, 그리고 솔루션이 노골적으로 복사되지 않았다는 사실입니다.

우리는 하나의 알고리즘 문제와 작은 웹 애플리케이션을 살펴보고 싶다는 데 동의했습니다. 알고리즘은 이진 검색, 정렬, 철자 바꾸기 확인, 목록 및 트리 작업 등 초등 수준 실험실 수준에서 준비되었습니다. 결국 우리는 첫 번째 시험 옵션으로 이진 검색을 선택했습니다. 웹 애플리케이션은 프레임워크를 사용하거나 프레임워크 없이 tic-tac-toe여야 했습니다.

나머지 직원 중 거의 절반이 테스트 작업을 완료했습니다. 그들은 우리에게 솔루션을 보냈습니다. 후보자 54명. 놀라운 통찰력 - 복사하여 붙여넣을 수 있는 tic-tac-toe 구현이 인터넷에 얼마나 많이 있다고 생각하시나요?

얼마나 많이?실제로는 3개만 있는 것 같습니다. 그리고 대부분의 결정에는 정확히 이 3가지 옵션이 있었습니다.
싫어하는 것 :

• 복사-붙여넣기 또는 자체 아키텍처 없이 동일한 튜토리얼을 기반으로 개발
• 두 작업 모두 서로 다른 폴더의 동일한 저장소에 있습니다. 물론 커밋 기록은 없습니다.
• 더티 코드, DRY 위반, 형식 부족;
• 모델, 뷰, 컨트롤러를 수백 줄의 코드로 하나의 클래스로 혼합한 것입니다.
• 단위 테스트에 대한 이해 부족;
• "정면" 솔루션은 승리 조합의 3x3 매트릭스로 구성된 하드코드이며, 예를 들어 10x10으로 확장하기는 매우 어렵습니다.

우리는 또한 이웃 저장소에도 주의를 기울였습니다. 멋진 애완동물 프로젝트는 장점이었고 다른 회사의 여러 테스트 작업은 경각심을 불러일으키는 역할에 가까웠습니다. 후보자가 왜 거기에 도달하지 못했을까요?

그 결과 React, Angular, Vanilla JS에서 멋진 옵션을 찾았는데 그 중 29개가 있었고 그의 아주 멋진 애완동물 프로젝트에 대해서는 테스트하지 않고 한 명의 후보자를 더 초대하기로 결정했습니다. 테스트 작업의 이점에 대한 가설이 확인되었습니다.

기술면접

회사를 위해: 당신을 찾아온 중/선배가 아닙니다! 좀 더 개별적인 접근 방식이 필요합니다.

주니어용: 이것은 시험이 아니라는 점을 기억하십시오. C에 대해 침묵을 지키거나 교수에게 가능한 모든 지식의 흐름을 퍼부어 교수가 혼란스러워하고 "우수"를 주도록 시도하지 마십시오.

기술 인터뷰에서 무엇을 이해하고 싶습니까? 간단한 것 - 후보자가 어떻게 생각하는지. 만약 그가 선발의 첫 단계를 통과했다면 그는 아마도 어느 정도 어려운 기술을 가지고 있을 것입니다. 그가 그것을 어떻게 사용할 수 있는지는 아직 지켜봐야 할 것입니다. 우리는 3가지 과제에 동의했습니다.

첫 번째는 알고리즘과 데이터 구조에 관한 것입니다. 펜, 종이, 의사 언어 및 그림의 도움으로 우리는 트리를 복사하는 방법이나 단일 연결 목록에서 요소를 제거하는 방법을 알아냈습니다. 불쾌한 발견은 모든 사람이 재귀와 참조 ​​작동 방식을 이해하는 것은 아니라는 것입니다.

두 번째는 라이브 코딩입니다. 우리는 갔다 codewars.com, 단어 배열을 마지막 문자로 정렬하는 것과 같은 간단한 것을 선택하고 30-40분 동안 후보자와 함께 모든 테스트를 통과하도록 노력했습니다. tic-tac-toe를 마스터한 사람들은 놀랄 일이 없을 것 같았습니다. 그러나 실제로 모든 사람이 값이 변수에 저장되어야 하고 함수가 return을 통해 무언가를 반환해야 한다는 것을 깨닫지 못했습니다. 나는 그것이 불안했기를 진심으로 희망하지만 사람들은 더 가벼운 조건에서 이러한 작업을 처리할 수 있었습니다.

마지막으로 세 번째는 건축에 관한 것입니다. 검색창을 만드는 방법, 디바운스가 작동하는 방법, 검색 팁에서 다양한 위젯을 렌더링하는 방법, 프런트 엔드가 백엔드와 상호 작용하는 방법에 대해 논의했습니다. 서버 측 렌더링 및 웹 소켓을 포함하여 흥미로운 솔루션이 많이 있었습니다.

우리는 이 디자인을 사용하여 21개의 인터뷰를 수행했습니다. 청중은 매우 다양했습니다. 만화를 살펴 보겠습니다.

1. "로켓". 그는 결코 진정하지 않고 모든 일에 참여하며 인터뷰 중에 질문과 직접적인 관련이 없는 생각의 흐름으로 당신을 압도할 것입니다. 대학이었다면 이것은 당신의 모든 지식을 입증하려는 익숙한 시도일 것입니다. 당신이 발견한 티켓에 대해 당신이 기억하는 것은 어젯밤에 티켓을 공부하지 않기로 결정했다는 것뿐입니다. 여전히 얻을 수 없습니다. 밖으로.
2. "그루트". 그루트이기 때문에 연락하기가 상당히 어렵습니다. 인터뷰 중에는 한 마디 한 마디 답을 얻으려고 오랜 시간을 보내야 합니다. 단지 무감각하다면 좋습니다. 그렇지 않으면 일상 업무에서 매우 어려울 것입니다.
3. "드랙스". 저는 화물운송 관련 일을 했고, 프로그래밍은 Stackoverflow에서 JS만 배웠기 때문에 인터뷰에서 어떤 내용이 논의되는지 잘 이해가 되지 않을 때가 있습니다. 동시에 그는 좋은 사람이고 최선의 의도를 갖고 있으며 훌륭한 프런트 엔드 개발자가 되고 싶어합니다.
4. 글쎄, 아마 "스타로드". 전반적으로 협상하고 대화를 나눌 수 있는 좋은 후보자입니다.

우리 연구 끝에 후보자 7명 훌륭한 테스트 과제와 좋은 인터뷰 답변으로 그들의 하드한 실력을 확인하며 결승에 진출했습니다.

문화적 적합성

회사를 위해: 그 사람이랑 같이 일해요! 후보자는 자신의 발전을 위해 열심히 노력할 의향이 있습니까? 그가 정말 팀에 적응할 수 있을까요?

주니어용: 당신은 그들과 함께 일합니다! 회사는 정말로 후배들의 성장을 위해 투자할 준비가 되어 있습니까? 아니면 단순히 낮은 급여를 위해 모든 더러운 일을 당신에게 쏟아부을 것입니까?

각 후배는 제품 팀 외에 자신을 맡는 데 동의해야 하는 리드가 멘토를 얻습니다. 멘토의 임무는 그를 3개월간 온보딩하고 하드 스킬을 업그레이드하는 과정을 통해 안내하는 것입니다. 그래서 우리는 각각의 문화에 맞는 멘토로 와서 “우리 계획대로 XNUMX개월 안에 후보자를 개발할 책임을 맡게 될까요?”라는 질문에 답했습니다.

이 단계는 특별한 특징 없이 지나갔고 결국 우리를 데려왔습니다. 4가지 제안, 그 중 3개가 승인되었고 그 사람들은 팀에 합류했습니다.

제안 이후의 삶

회사를 위해: 후배들을 잘 돌봐주세요. 그렇지 않으면 다른 사람들이 그럴 것입니다!

주니어용:아아아아아아아아!!!

새로운 직원이 나오면 그는 합류해야 합니다. 프로세스에 대한 최신 정보를 얻고, 회사와 팀에서 모든 것이 어떻게 작동하는지, 일반적으로 어떻게 일해야 하는지 알려주어야 합니다. 후배가 나오면 어떻게 발전시켜야 하는지 이해해야 한다.

이에 대해 생각해 본 결과, 우리는 후배가 26개월의 온보딩 기간이 끝날 때까지 갖춰야 할 3가지 기술 목록을 생각해 냈습니다. 여기에는 하드 스킬(스택에 따른), 프로세스에 대한 지식, 스크럼, 인프라 및 프로젝트 아키텍처가 포함되었습니다. 우리는 이를 로드맵으로 결합하여 XNUMX개월에 걸쳐 배포했습니다.

예를 들어, 내 후배의 로드맵은 다음과 같습니다.

우리는 그와 개별적으로 함께 일하는 각 후배에게 멘토를 지정합니다. 멘토와 지원자의 현재 레벨에 따라 주 1~5회, 1시간 동안 미팅이 진행될 수 있습니다. 멘토는 단순히 코드를 작성하는 것 이상의 일을 원하는 자원 봉사 프런트엔드 개발자입니다.

멘토의 부담 중 일부는 Dart, Angular 스택의 과정을 통해 해소됩니다. 수업은 4~6명의 소규모 그룹을 위해 정기적으로 진행되며, 학생들은 직장에서 방해받지 않고 공부할 수 있습니다.

3개월에 걸쳐 정기적으로 후배와 멘토, 리더로부터 피드백을 수집하고 개별적으로 프로세스를 조정합니다. 펌핑 된 기술은 전체 기간에 걸쳐 1-2 번 확인되고 마지막에는 동일한 확인이 수행됩니다. 이를 기반으로 정확히 개선해야 할 사항에 대한 권장 사항이 형성됩니다.

결론

회사를 위해: 후배들에게 투자할 가치가 있나요? 예!

주니어용: 후보자를 엄선하고 육성할 줄 아는 기업을 찾아라

3개월에 걸쳐 우리는 122개의 설문지, 54개의 테스트 작업을 검토하고 21개의 기술 인터뷰를 실시했습니다. 이로 인해 이제 온보딩 및 가속화 로드맵의 절반을 완료한 3명의 훌륭한 후배가 탄생했습니다. 그들은 이미 프런트 엔드에만 2줄 이상의 코드와 000개 이상의 저장소가 있는 우리 프로젝트에서 실제 제품 작업을 완료하고 있습니다.

우리는 후배들을 위한 퍼널이 상당히 복잡할 수 있고 또 그래야 한다는 것을 알았습니다. 그러나 결국에는 정말 열심히 일하고 발전에 투자할 준비가 되어 있는 사람들만이 이 퍼널을 통과하게 됩니다.

이제 우리의 주요 임무는 멘토 및 일반 과정과 함께 개별 작업 모드에서 각 후배를 위한 XNUMX개월 개발 로드맵을 완료하고 리드, 멘토 및 직원들로부터 지표, 피드백을 수집하는 것입니다. 이 시점에서 첫 번째 실험이 완료된 것으로 간주하고 결론을 도출할 수 있으며 프로세스를 개선하고 새로운 후보를 선택하기 위해 다시 시작할 수 있습니다.

출처 : habr.com