Чому технічні навички необхідні у сучасному рекрутингу

Усім привіт, мене звати Віталій Максимюк, я Head of Recruiting венчур-білдера CLUST. У цій статті поговоримо про необхідні технічні навички під час найму, але не у кандидатів, а у рекрутерів — чи справді без них не обійтися.

«Коли на першому ж колі з рекрутером мене спитали про технічні моменти розробки, я був вражений підготовкою рекрутера у нюансах роботи, процесів і розробки, ― так у мене зʼявився жвавий інтерес до того, чи реально у компанії вся така „підкована“ команда», ― відгук про найм від Захарія, дуже крутого PHP-розробника (кому потрібні контакти, звертайтесь:)

Питання у тому, як отримувати такі фідбеки від технічних спеціалістів і наскільки це важливо? Спойлер ― дуже важливо, оскільки це показник якісно виконаної роботи і вашої технічної обізнаності.

Пошук, оцінка та хантинг найкращих IT-талантів

Швидкий розвиток технологій змушує регулярно переглядати й оновлювати вимоги до спеціалістів, яких потребує той чи інший проєкт. Сьогодні я хочу поговорити про важливість технічного бекграунду в рекрутерів, методи пошуку релевантних кандидатів і способи заохочувати цінні кадри в ІТ-компанії.

Overhiring часів коронавірусу сильно вплинув не тільки на техногігантів, багато компаній почали скорочуватись, фонди почали керувати грошима набагато економніше і вдумливіше. Компанії вже не можуть дозволити собі довге і дороге тестування, переписання коду з 0, тому продукти намагаються писати «як треба» вже з початку.

Сучасні технічні запити від технічних команд на IT-фахівців

Софт-скіли ― це те, що ми вже на першому колі виявляємо найкраще. Однак кандидату важко зрозуміти, наскільки круто ви перевіряєте софти. Тому, щоб вразити і зацікавити його, треба показати, що у нас навіть команда рекрутерів розбирається в технічних моментах — що вже казати про технічних співробітників.

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

1. Дизайну коду

Це може бути SOLID і/або GRASP. По SOLID-у, наприклад, я перевіряю розуміння кожного принципу, прошу навести приклади його застосування або порушення.

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

2. Патерни проєктування

Кандидат, який знайомий з патернами, розуміється на особливостях їх використання, має значно більші шанси на проходження технічної співбесіди, бо йому, як мінімум, простіше спілкуватися з розробниками на рівні Middle і вище.

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

Я бачу три основні причини, чому так часто запитують про патерни:

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

3. Клауди

Актуально, скоріше, тільки бекенду. Зараз всі переходять на хмарні сервіси. В Україні найпопулярнішим клаудом залишається AWS, йому в спину дихають GCP і Azure.

Але знання бодай одного клауду і його специфіки додасть вам «балів» на співбесіді, оскільки нові продукти намагаються запускатись вже у Cloud-середовищі, використовувати оркестрацію, а стартапи на bare-metal запускаються у специфічних ситуаціях, і не дуже часто.

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

4. Безпека

На співбесідах все більше уваги приділяється розумінню принципів безпеки коду, можливості виникнення певних помилок, втрати даних тощо. Сучасний ІТ-фахівець має знати, як гарантувати безпеку даних, з якими він працює.

Добре, якщо кандидат може навести простий приклад з роботи або уявної ситуації, де безпека найважливіша (запис у базу даних ― sql-ін’єкції, наприклад).

Оцінка технічних навичок кандидатів під час найму

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

У моїй зоні компетенцій знаходиться перевірка фундаментальних знань, наприклад, ООР, який вивчають ще в університеті, патернів проєктування, принципів SOLID-у тощо. Я запитую, як працюють базові речі, наприклад: як працюють cookies у фронтенді або чим звичайні функції відрізняються від стрілкових.

У певних випадках я можу перевірити щось трошки глибше, наприклад, мови, в яких я орієнтуюсь — РНР і JS, тому зі мною можна трохи поговорити з приводу SOLID-у, onion-архітектури, мікросервісів, інтерфейсів, web-worker-ів тощо.

Але така розмова не є аналогом технічної співбесіди. Це лише перевірка наявності маркерів того, що в людини можуть бути необхідні базові знання і перспектива для переходу на технічну співбесіду, якщо немає «прогалин» в основних речах.

Окрім очевидного самостійного навчання, перегляду профільних YouTube-каналів і книжок, рекомендую більше спілкуватись з розробниками про їх «сьогодення» і актуальні тренди. Живе спілкування завжди краще за сухі туторіали.

Виклики, які пов’язані з хантингом IT-спеціалістів

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

Найбільший виклик нашої реальності — стрес. А зміна роботи — це завжди стрес для кандидата, навіть якщо в нього за плечима 7 компаній і 15 років досвіду. Адже це новий бізнес, новий проєкт, нове оточення, задачі і рутина, до якої треба звикати і адаптуватись.

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

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

У такому випадку важливо вказувати на соціальну відповідальність компанії, гарантії безпеки, піклування про mental health, давати впевненість у завтрашньому дні, розповідати про успіхи компанії і її стабільність, візуалізувати майбутнє людини.

Спробуйте взяти аркуш А4 (або відкрийте блокнот на ноуті), напишіть кожен описаний пункт «страхів» і подумайте, що ваша компанія може зробити, щоб «закрити» їх. Так ви зможете підготуватись до можливих відмов, знаходити під кандидатів win-win пропозиції будете краще підготовлені до будь-якого сценарію.

Правило «Знай свій проєкт», або Наскільки важливо розбиратись в технологіях проєктів

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

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

Наприклад:
— Проєкт у нас на РНР.
— А якої версії? Чи вже завершили переїзд на (таку-то) версію?
— ...
Відповіді далі вже немає, а це важливо, бо з цим повʼязані нюанси роботи розробника.

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

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

Які компетенції допоможуть кандидату у пошуку роботи

Як не банально, але це компетенція «постійного розвитку», коли розробник постійно актуалізує свої знання і намагається бути у контексті своєї професії.

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

Я б рекомендував як рекрутерам, так і розробникам, не концентруватись на грейдах, оскільки грейд — не показник скілів. Middle по грейду іноді може дати фору Senior, а у Senior по факту може бути лише 3 роки досвіду і він буде слабше за мідла в технічних навичках.

Тож головне ― реальні технічні знання.

Ще важливо:

• якість кодового продукту ― писати код, керуючись best practices за якістю і readability, відповідати за його підтримку, писати автоматичні тести на свій код;
• мати продуктовий майндсет — думати про те, як моє рішення вплине на продукт, користувача, чи буде це зручно, чи вирішуватиме це проблему тощо;
• бути професійно впевненим — не боятися сказати «ні» на рішення, яке може нашкодити, аргументувати власні рішення.

Як оцінити технічну компетентність кандидата

Це може бути перевірка фундаментального досвіду, який він отримав на проєкті, з яким працював. Наприклад, такі запитання я ставлю бекендам:

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

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

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

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

Є приклади, коли продукт здається легким і не сильно завантаженим, проте якщо кандидат був єдиним розробником на продукті і створив усе з нуля, тоді це теж може бути маркером експертності.

Також це стосується команди. Кандидат міг працювати у дуже крутому, складному, інноваційному продукті, але якщо команда складається з 30 спеціалістів, великий шанс того, що він відповідав лише за дуже вузький функціонал чи невелику частину такого продукту.

Водночас інший проєкт міг бути значно меншим, проте людина відповідає за значну частину інфраструктури і фіч.

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

Будуємо довіру з найкращими IT-фахівцями у компанії

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

Проте я вірю, що якщо «на березі» дати повну інформацію і весь можливий контекст, тоді кандидат точно буде знати, куди він йде і на що розраховує, тому і його retention, і довготривале співробітництво у компанії буде імовірнішим.

Я взяв дуже просте правило за основу комунікації — бути відкритим і чесним.

• Це відмова через hard skills. Кажіть, як є, і детально опишіть ті технічні аспекти, які були заслабкі, щоб кандидат знав, що йому покращити і вивчити для майбутнього процесу.
• Вакансію закрили через якусь не дуже «красиву» причину, наприклад, команда зрозуміла що не знає, кого вони хочуть. То так і кажіть, бо це повага до часу людини, який вона приділяла на співбесіди і чесність, щоб кандидату не довелось шукати причину у собі.
• Завеликий бюджет. Аналогічно, кажемо, що бюджет завеликий, ми зараз не можемо покрити ваші очікування.
• Є якісь «підводні камені», legacy код чи якісь проблеми з функціоналом. Краще сказати це одразу, бо тоді людина буде розуміти, що їй очікувати і з чим працювати, бо проблеми магічним чином нікуди не зникнуть до виходу такого кандидата на роботу.
• У вас застарілі технології на проєкті. Не кажіть про інноваційність і молодий колектив. Знайдіть інші причини, чого кандидату варто до вас прийти, наприклад, безліміт на навчання як компенсація за застарілі задачі, або відчуття стабільності і впевненості у завтрашньому дні, елементарно грошова винагорода достатнього рівня, або серйозні виклики щодо переїзду на нові технології.

Співбесіда — це про діалог і повагу один до одного, тому чесність у процесі є фундаментальною і я не підтримую компанії, які намагаються приховувати такі речі в процесі.

Чим компанії можуть зацікавити сучасних IT-фахівців

4 речі, які безумовно мають бути в наявності, щоб конкурувати за кандидатів:

1. Розвиток, який дається не лише обіцянками, але і фактично: професійна література, компенсація сертифікацій, конференції і професійні заходи, можливість відвідувати хакатони або виділення часу на pet-projects і, звичайно, перегляди зарплати. Можна додати кандидату приклад розвитку, щось на кшталт: «Ми проводимо зустрічі, де разом розбираємо практики програмування і сінкаємося щодо їх реалізації у роботі, чим покращуємо ваші безпосередні навички розробника».
2. Стабільність, впевненість у завтрашньому дні, надання допомоги у важкі часи (одразу можна згадати періоди блекаутів), тобто, переконати кандидата в тому, що компанія забезпечить його усім необхідним, і що завтра нічого з його проєктом не станеться. Сюди ж можна віднести і соціальний пакет як частину відчуття стабільності і впевненості.
3. Здорова корпоративна культура, яка не заохочує «працю заради праці», яка поважає персональний час кандидата, його інтереси, його бажання бачити щось крім задач, де є повага до work/life балансу і ментального здоровʼя людини.
4. Чітка соціальна позиція, дати змогу кандидатам побачити і відчути, що компанія робить щось крім заробляння грошей: соціально-значущі проєкти, корисні ініціативи, волонтерська діяльність.