Співбесіди, тестове і нестача QA. Як ми покращували процес найму в компанії

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт! Я Артем Григоренко, IT-консультант та Mentor. Також, автор блогу «Нотатки суворого QA».

У цій статті я хочу поділитися своїм досвідом про наш шлях покращення процесу найму в швидко зростаючій компанії. Вірогідно, мій досвід може стане в пригоді людям, які активно займаються наймом і хочуть його покращити. Щоб не читати повну історію, то можна перейти до розділу TL;DR.

Невеличкий дисклеймер: все, що я пишу — це мій досвід в конкретній компанії, та висновки до яких я прийшов після. Всі події відбувалися приблизно 1.5 роки тому під час 2021 року до початку лейофів

Контекст

Компанія у 700 осіб. У неї період активного зростання і план протягом року збільшити кількість працівників вдвічі, що й було зроблено в результаті. Таке зростання неможливе при неоптимізованих процесах найму. Плюс, будь-які уповільнення в процесі найму впливають на швидкість постачання нових продуктів на ринок.

До того ж потрібно зробити процес таким, щоб нова людина при виході в команду та в компанію вже могла активно допомагати та вибудовувати процес забезпечення якості, без сильного розгойдування.

Я не розповідатиму про значущість оптимізації процесу найму, але розповім, як ми з точки А прийшли в точку Б, і що це були за точки.

Аналіз проблематики старого процесу найму

Тут хочеться описати саме первісну точку, точку А, в якій знаходився найм.

Наша воронка складалася з 5 етапів:

1. Сорсинг відповідних кандидатів.
2. Спілкування з рекрутером + невеликий квіз.
3. Технічна співбесіда з лайв-кодингом.
4. Поведінкове інтерв’ю.
5. Офер.

Загалом, не надто великий список етапів. Однак було над чим розкинути мізками. За попередньою оцінкою, пошук одного QA у нас займав до трьох місяців. При цьому вважалося, що ми шукаємо виключно Senior+ кандидатів (майстри, які вміють і в бек, і в фронт, і в мобайл, і все це автоматизовувати), що в принципі додавало певних складнощів.

Ще в цій точці ми мали хаос із розподілом QA. Початкова ідея була в тому, щоб наймати людей в компанію, а потім розподіляти їх, використовуючи поточні пріоритети (загалом це було виправдано, оскільки за 3 місяці пріоритети змінювалися).

Через такий тривалий процес найму у нас утворилася черга із запитів, куди нам потрібні люди і в які команди. Ну, і додаткові палиці в колеса додавало те, що запити на пошук тестувальників у нас були наступні:

• трайб 1: чотири QA у першому кварталі;
• трайб 2: два QA у другому кварталі;
• і т.д.

Трайбів у нас було декілька, і на квартал треба було нормально так пошукати. Як можна помітити, то про конкретні команди, навички тощо не йшлося.

І це лише поверховий опис процесу найму, що відбувався. Були ще нюанси з онбордингом та самим розподілом. Тому довелося все рухати потихеньку.

Вивчення практик у галузі найму та впровадження змін

При визначенні стратегій з оптимізації ми не намагалися відразу змінювати весь процес і брати щось від топових компаній. Навпаки, такі речі нас би сповільнювали, і ми не могли б найняти потрібну нам кількість відповідних QA.

Всі оптимізаційні роботи ми робили поступово, не намагаючись виправляти все одразу. Тобто ми робили зміни в критичних нам місцях, дивилися на вплив, і якщо все було гуд, то рухались далі.

Це дозволяло нам робити покращення, не втрачаючи якість кандидатів.

Оптимізація процесу відбору кандидатів

З точки зору оптимізації процесу треба було розібратися в тому, чи справді всі наші етапи покращені з позиції витраченого часу, та чого ми можемо позбутися, не втративши якість кандидатів, які потрапляють в нашу воронку найму.

Ми почали з процесів, на які маємо безпосередній вплив — це технічна співбесіда. У нас вона відбувалась протягом 1 год 30 хв, причому з лайв-кодингом. Потім ми писали розширений фідбек менеджерам та кандидатам. Після чого вже приймалося рішення, рухаємося далі з людиною чи ні.

Для оптимізації ми обрали таку стратегію:

• Намагаємося вкластися в 1 год.
• Забираємо лайв-кодинг.
• Перед технічною співбесідою даємо тестове завдання.

Тут ми йшли на свідомий ризик, що тестове робитимуть далеко не всі. Але щодо тих, хто робив і робив успішно, ми вже знали, що вони більше нам підходять. Краще так, ніж дізнаватися про це протягом лайв-кодинг сесії, наприклад.

Щодо тестових ми досліджували різні рішення і зупинилися на Test Gorilla.В якості тестового давали стандартне опитування з теорії тестування англійською (тут навіть деякі супер досвідчені кандидати не справлялися, скоріш за все, через недостатній рівень англійської). Друге — було невелике завдання з Python (потім додали ще на JS, через різний технологічний стек команд). Остання частина — це написати тест-кейси на попереднє завдання з Python.

Загалом на все тестове кандидату треба було витратити не більше ніж годину — 10 хвилин на тест, 30 хвилин на задачку і 10 хвилин на тест-кейси. Середня швидкість вирішення задачі на код була 10 хвилин ;) Думаю, досить справедливо.

Тут ми вже відчули перше полегшення і стало краще з точки зору нашого навантаження та якості кандидатів. Потік кандидатів трохи знизився, але вони були якіснішими.

На цьому ж етапі ми торкнулися поліпшення зворотного зв’язку. У нас особливо не було якихось шаблонів і ми давали зворотній зв’язок кожен у свій спосіб. Потім ми зробили документ по зворотному зв’язку, це була гугл-форма зі шкалою оцінки знань та відкритими полями для запису.

Один з інтерв’юерів заповнював цю доку прямо під час співбесіди. Після заповнення форми запускався скрипт, який робив з форми звичайний документ і надавав до нього доступ учасникам співбесіди. Ну, а далі, за необхідності, вносилися правки.

Зворотній зв’язок складався з трьох наступних частин:

• загальний висновок;
• рекомендації на майбутнє, якщо кандидат не підходить;
• відгук на структуру проведеної співбесіди, наприклад, хард-скіли, софт-скіли, логічні завдання тощо.

Процес, до якого ми прийшли, дозволив нам надавати кандидату повний хороший зворотній зв’язок протягом одного робочого дня. Вважаю це успіхом.

Зрештою, вдосконалення саме технічної частини процесу найму тут майже і завершилось. Ми поліпшили тестове і воно перетворилось з абстрактного завдання на наближене до реального, з якими працювали QA в компанії.

Поліпшення вибірки

Разом з покращенням технічної частини найму, ми паралельно думали над тим, як покращити вибірку кандидатів, які потрапляють до співбесіди з рекрутерами (зробили такий собі shift-left підхід у наймі!). Нам одразу спало на думку, що кандидатів нам шукають сорсери, які в більшості випадків передають нам не зовсім тих, хто підходить, а отже відсоток проходження у результаті менший. Тому продовжили думати у цей бік.

Якщо згадати описаний спочатку процес, можна зрозуміти, що конкретних вимог до кандидатів не було. Були бажання з розряду «нам потрібен сеньйор-помідор, мега-зірка» тощо. Ми почали ходити до тимлідів та хедів і дізнаватися, а що ж за такі помідори потрібні, що вони робитимуть, які завдання вирішуватимуть.

У деяких випадках виявлялося, що помідор не потрібен, а підійде міцний самостійний мідл. Ага, крига скресла, тож ми продовжили. Далі ми утворили документ QA Hiring Plan, відмінний від загального документу компанії. Та почали переносити туди з повного списку відкритих позицій запити конкретно щодо QA.

Робилось це, наприклад, так: замість одного запиту про чотирьох QA у трайб, ми формували 4 рядки під кожного QA, куди додавали деталі: в яку команду шукають, необхідний рівень фахівця, технічний стек. Плюс, ми вносили туди інформацію про те, без чого ми не готові розглядати кандидата, або що є блокером. Так з’ясувалось, що деякі команди все ж таки мали чіткі вимоги.

Цей підхід надав нам прозорості в тому, скільки, хто і коли нам потрібні. Адже іноді з цих чотирьох спеціалістів терміново потрібен був лише один. Решту ми можемо винайняти і протягом решти 3-6 місяців. Однак це не розв’язувало всі наші проблеми. Загалом ситуація була доволі сумною: нестача QA складала близько 20 осіб. Але ми не впадали у відчай 🙂.

Ми почали щільно працювати з рекрутерами та сорсерами. Розповідали їм про кожну позицію: хто нам потрібен, чому одні кандидати підходять компанії, а інші — ні і так далі. Поступово якість кандидатів зростала і ми це відчули: замість 10% успішних технічних співбесід отримали приблизно 30%.

Примітка: тут я можу збрехати, бо це було давно, тому наведені цифри приблизні, хоча й порядки дотримано.

У цій точці хочу сказати, що мета найму все ще була не під конкретну команду, а в компанію взагалі, оскільки загальних вимог було багато, а пріоритети постійно змінювалися. Хеди все ще особисто розподіляли, кого і куди відправляти. Але це не надовго 🙂

Постійно навчаючи рекрутмент та оптимізуючи вибірку, нам у перші 5 місяців вдалося значно підвищити якість кандидатів, до того ж моя команда, яка повністю займалася процесом найму, зросла до 6 осіб і в новий рік ми прийшли з новими силами.

Новий рік та плани з найму

Рік починався з планів на зростання кількості працівників. Зазвичай зростання компанії завжди супроводжується приблизним зростанням кількості позицій на відповідні ролі. Я прикидав, що ми маємо найняти приблизно x2 людей у новому році, на той момент ми мали близько 40 QA, тому додаткові 40 QA за рік — непоганий такий план. Ми були до цього готові, але за словами хедів у нас досі був велика нестача QA.

У той момент ми почали дивитися на найм інакше. Незважаючи на те, що у нас була велика кількість незакритих вакансій, ми прийняли рішення використовувати 2 наступні підходи паралельно: спиратись на пріоритети компанії та наймали конкретно у команду. Ми вже навчилися знаходити необхідних кандидатів у компанію, тому вирішили спробувати шукати одразу у конкретну команду з найвищим пріоритетом. У нашій табличці вже були прописані всі необхідні пріоритети, тож за ними і рухались.

Другий пункт, який ми зробили — почали додавати до наших співбесід QA і тимлідів з команд, куди відбувався найм, або того ж трайба. Всі ці кроки дозволили нам вдало розподілити наш час і навантаження, і в новому році ми змогли проводити в середньому одну технічну співбесіду на день.

Щоб довго не розписувати, скажу так: з поступовим підвищенням якості вибірки ми змогли закрити основний запит на людей за перший квартал. У підсумку залишалося не більше 10 конкретних відкритих вакансій, деякі з них мали бути закриті у 2-му й 3-му кварталах, а деякі були просто досить специфічними.

Проте були і фейли. Наприклад, був у нас хороший кандидат, але його не могли провести далі до поведінкової співбесіди, бо команда, до якої він підходить, ще не була створена. Тут уже точно ніхто не міг нам нічого сказати щодо нестачі QA. Були звичайно і проблеми з наймом на специфічні позиції, наприклад, AQA на C#. Але тут уже треба було пропрацьовувати найм глибше і знаходити необхідних кандидатів, використовуючи інші методи.

Оцінка нового процесу найму відбулася тоді, коли ми шукали до себе в команду ще одного тест-ліда. Вибірка була у сім кандидатів, дві технічні співбесіди, один офер. Від моменту відкриття вакансії (запиту на найм) до офера минуло 3 тижні. Я думаю, що і тут можна було б прискоритися, але не завжди є вільні дати календаря 🙂.

TL; DR

Ось кілька висновків з мого досвіду, які допоможуть вам значно покращити процес найму:

• Проводьте процес найму максимально прозоро і залучайте усіх стейкхолдерів.
• Запитуйте, хто саме необхідний команді, чому саме він, які завдання має виконувати.
• При оптимізації процесу спробуйте «shift-left» підхід.
• Наймати в команду простіше та краще, ніж наймати в компанію.
• Лайв-кодинг переоцінено.
• Не використовуйте процеси з топкомпаній, тому що вони можуть не підходити конкретно у вашій ситуації. Вирішуйте свої проблеми і закривайте запити поступово.
• Навчайтеся всією командою найму (менеджери, рекрутери, сорсери, QA тощо).
• Ідеальний процес найму — це коли ви можете взяти людину в компанію без проведення співбесід та великої кількості додаткових етапів.