Привіт, мене звати Костянтин Колесниченко. Я Desktop Lead у компанії ENESTECH Software, що входить до холдингу TECHIIA. Поділюся напрацюваннями, як у пошуку досвідчених розробників знаходити «своїх» людей і відсіювати недостатньо підготовлених. Стаття розрахована на лідів-початківців і тих, хто планує стати керівником. Кандидати ж можуть підглянути, чого чекати на співбесідах. А досвідченим колегам-менеджерам буду вдячний за відгуки та кейси у коментарях.
В IT я працюю з 2004 року. За плечима — КІбцентр (Інститут проблем математичних машин та систем Національної академії наук України), геймдев і розробка софту для мобільних телефонів. Останні роки працюю в ENESTECH Software, де збирав команду, будував робочий процес і очолював різні департаменти. Наш головний продукт — SENET — SaaS-сервіс для комп’ютерних клубів і кіберарен, який використовують у 60+ країнах світу. У команді розробки зараз понад 20 людей.
Поговоримо про те:
- яка ціна помилки найму;
- що та навіщо вказувати у вакансії;
- на що дивитися в резюме, пет-проектах, на зустрічі;
- чи примушувати писати шматки коду на аркушику та як взагалі побудувати співбесіду;
- що робити в разі неспівпадіння.
Навіщо заморочуватися правильним наймом
За моїми спостереженнями, досвідчених розробників шукають насамперед продуктові компанії та такі, що не мають часу на довгу розкачку та навчання. «Досвідчений» — той, хто зустрічався з реальними практичними завданнями та знаходив рішення. В ідеалі — знає, де шукати та як. Або як мінімум має на те бажання.
Для інших досвід не завжди важливий. На розігрітому ринку компанії готові брати людей ледь не зі школи, щоб навчити їх під свої завдання. Про це поговоримо пізніше.
Є два етапи, на яких можна виявити недосвідченого розробника. Перший і найважливіший — власне пошук і співбесіда. Другий і малоймовірний — під час роботи, якщо раптом ви проґавили «симулянта».
Люди з недостатнім досвідом приходять практично на будь-яку посаду. Деякі, пропрацювавши півроку, йдуть у сусідню компанію, бо там можуть запропонувати трохи більше. Багато аутсорсингових компаній до такого вже звикли, але через це необхідно особливо ретельно вибирати людей.
Кожен неефективний найм має свою ціну. Ми з колегами з інших компаній TECHIIA підрахували, що збитки від помилки становлять 6-9 місячних рейтів спеціаліста. Іноді менше, іноді більше. Якщо вам ця цифра здається космічною, ось кілька аргументів.
1. Менеджер витрачає час на пошуки та узгодження. Замість виконання прямих поточних обов’язків, він чи вона готує вимоги, читає вхідний потік резюме від рекрутерів, бере участь в інтерв’ю, дає фідбеки, перевіряє тестові. Таких циклів може бути декілька.
2. Нова людина проходить адаптацію. Наприклад, ми працюємо над продуктом, тому шанси взяти з вулиці людину, яка за тиждень почне видавати результат, майже нульові. У кращому разі вистачає місяця, в реальності треба два-три. Весь цей час компанія платить за те, щоб розробник:
- прочитав документацію;
- розібрався в нюансах продукту/проекту;
- поговорив з технічними та іншими менеджерами;
- налаштував процеси;
- влився в команду.
3. Менеджер, який має свої завдання, витрачає час на навчання новачка. Через це продуктивність команди протягом онбордингу може навіть зменшитися. У середньому лише з третього-шостого місяця спеціаліст і команда виходять на той рівень продуктивності, заради якого і брали новачка. І це нормально.
Якщо ж узяли не ту людину, ресурси витрачені даремно. Для продуктової компанії вкрай важливі як гроші, так і час. Зробити свою частину роботи, щоб продукт або оновлення вийшли на ринок у запланований термін, – це найважливіше. Якщо це не відбудеться, то втрата грошей на найм стане найменшим злом. Адже компанія може проґавити влучну мить і вже ніколи не вийти на бажаний ринок.
Як готувати вакансію
Перш ніж дати завдання рекрутеру, визначаємо, чим саме людина займатиметься. Це збереже нерви і компанії, і кандидатам.
Приклад. Коли ми набирали команду для SENET, на бекенд нам була потрібна людина з трирічним досвідом на Python Django, яка одразу включиться в роботу. На мою думку, за три роки людина якраз встигає пройти купу різних завдань і навчитися їх самостійно виконувати.
Але недостатньо сказати рекрутеру: «потрібен пітоніст з трирічним досвідом Django». Бо такий кандидат може і веб-сторінки для магазину робити, і складний бекенд. У кожного – своя спеціалізація. Комусь подобається працювати з базами даних, а хтось пиляє сек’юріті або пише мегаоптимальний код для роботи з мережею. Тому ми вказуємо рекрутеру предметну сферу і частини проекту, для яких шукаємо кандидата.
Далі йдуть додаткові побажання:
- Освіта. Бажано вища профільна. Такі спеціалісти, згідно з моїм досвідом, зазвичай мислять більш системно. Винятки також є: у нас є розробник без базової IT-освіти, але це компенсується талантом та величезною зацікавленістю.
- Мова. Англійська хоча б на рівні швидкого читання та розуміння.
- Технічні нюанси. Умовно, якщо шукаємо людину на Django, треба розуміти SQL, бази даних. Для C++ — вміти працювати з WinAPI, застосовувати сучасні технології та патерни.
Ну і, звичайно, описуємо формат роботи та бонуси. Не знаю, наскільки пункти про дружній колектив, каву та печиво потрібні, але це вже на кшталт традиції. Тим паче, коли це правда.
Ось . Перед фіналізацією ми проглядаємо текст ще раз, щоб прибрати зайве та зафіксувати нюанси, без яких кандидат не потрапить на співбесіду, наприклад, досвід певного домену.
Перші фільтри: базові питання, резюме та пет-проекти
Перед першою розмовою HR-менеджер узгоджує з замовником вакансії вхідний опитувальник. Зазвичай він стосується досвіду, але останні три роки я видаю також і «фільтраційні» питання.
Простий приклад вхідного питання: «Що таке масив, що таке список, і чим вони відрізняються?». Ми допомогли рекрутерам самим зрозуміти різницю, щоб вони одразу розпізнали, коли кандидат видає нісенітницю.
Під час опитування базової теорії відпадає до 90% безперспективних кандидатів, особливо «senior’и з річним досвідом».
Коли резюме потрапляє до мене, насамперед я дивлюся на відповіді щодо бази. Потім — на освіту. Потім — на досвід. Скажімо, кандидат працював у банку, потім півроку займався QA, після чого став програмістом. Тут буде багато питань. Або, наприклад, написано «10 років С++, 15 років Python», але при цьому людина була сисадміном. Обов’язково перепитаю рекрутера про професійний шлях кандидата та зроблю собі помітку.
Також прошу приклади робіт та пети. Якщо є лінк на GitHub, навіть просто з тестовими чи університетськими лабами, — супер. Буває, що людина не хоче світитися у пошуковиках або працює під жорсткими NDA. Тоді можна надіслати приклади напряму.
Незалежно від типу коду, мені цікаво, як людина пише. Звертаю увагу на структуру, акуратність, назви. Типовий маркер новачка — відсутність свого стандарту: тут з великої букви, там з маленької, тут починається з підкреслювання, там з двох. Копіпасти зі Stack Overflow теж видно одразу. Найімовірніше, під час живої зустрічі людині буде важко пояснити, для чого вона використала саме цей шматок.
На GitHub за історією комітів можна побачити, як код розвивався. Іноді у проекті пара комітів: перший — Initial, другий — решта коду, зваленого в купу. Тобто людина щось накидала та більше не поверталася. Навряд чи це пет-проект, говорити про нього буде складно.
Людей з найцікавішими комбінаціями «освіта-досвід-приклади» та відповідною спеціалізацію кличемо на зустріч.
Блоки питань на співбесіді: від базового до глибокого (але теж базового)
Технічна співбесіда в середньому триває годину. Вона поділяється на такі умовні блоки.
1. Питання про досвід. Знайомимося, встановлюємо контакт. Коли людина розповідає про минуле та щось їй знайоме, вона заспокоюється. А я читаю резюме, трохи занурююся в конкретику.
Тут доречно запитати про захоплення та вподобання. Можна взяти спеціаліста, який рівно о шостій іде з роботи, а у вільний час перемикається на зовсім інші проекти. Не завжди, але часто це ознака того, що людина за деякий час піде. Не тому що я ціную порожні овертайми, просто зацікавленість іншою роботою рано чи пізно переможе.
Це стосується і напрямів. Наприклад, якщо я візьму програміста на C#, який поза роботою любить пиляти фронтенди, є ризик, що одного дня він туди й піде. Я так свого часу залишив наукову діяльність і пішов у геймдев, де пропрацював 10 років.
2. Загальні питання. Їх можна застосувати до будь-якої мови програмування. Найелементарніше — про масиви та списки: що це, відмінності, швидкість роботи, що таке алгоритмічна складність. Далі переходимо до дерев, хешів, таблиць. Можна поговорити про алгоритми сортування.
Досвідчена людина насамперед має розуміти базові речі. Де використовуються списки, а де — масиви. Чому в одному разі сортувати краще «бульбашкою», а в іншому — «пірамідою». Необов’язково, щоб спеціаліст умів це все робити руками, але повинен знати та розуміти, коли та як застосувати.
3. Більш специфічні питання залежно від позиції. Це досі не про бібліотеки, а про базові принципи, властиві конкретній мові програмування.
У випадку С++ та C# мені цікаві знання з ООП. Людина може на автоматі видати три принципи: поліморфізм, інкапсуляція, наслідування. А поліморфізм — це віртуальні функції. Тут я можу спитати: «А як взагалі працюють віртуальні функції?». Якщо людина знає і розповідає про таблиці віртуальних функцій, це вже великий плюс. Це означає, що спеціаліст розбирається в механізмі, а не просто його використовує. Такий підхід показує розробника більш високого рівня, ніж початківець.
Іноді С++ розробникам можу ставити начебто дурні питання на кшталт «як мінус один буде представлений у двійковій або шістнадцятковій формі?» або «скільки буде 2 у 8-й ступені?», «а чому саме так?», «що там про прямі та додаткові коди?». Це дасть змогу побачити, наскільки людина орієнтується у «бітовій магії», яка для C++ актуальна і сьогодні.
Також на цьому етапі, коли ми вже розговорилися, можуть добре спрацювати діагностичні питання. Вони показують, наскільки людина занурилася в тему.
Наприклад, кандидата-джуна на C# можна спитати про витоки пам’яті. Є збирач сміття, який автоматично очищає пам’ять, і нібито остання нікуди витекти не може. Але насправді є багато кейсів, у яких це може статися. Якщо людина пояснює кілька варіантів, це свідчить одразу про кілька речей. Перше — вона взагалі знає, що таке витік пам’яті. Друге — знає, як його отримати. Третє — знає, як з ним боротися.
Досвідченого спеціаліста питаю за тим самим принципом, тільки глибше за кожним параметром. Щодо Python-Django можна поцікавитись, як людина працює з Object Relations Model. Після кількох питань видно, чи людина знає, в якому разі генерується мегазапит до бази, а в якому все швидко пропрацюється з кешуванням даних.
Мій колега практикує ще один підхід. Після кількох стандартних запитань він ставить таке, на яке людина, найімовірніше, не знає відповіді. Але сама відповідь — другорядна. Важливо, як спеціаліст буде мислити та рухатись до рішення, що буде згадувати, на що спиратися. І чи взагалі візьметься. Наприклад, як Python-програміст зорієнтується в завданні про управління пам’яттю, яке більше властиве для С++?
Технології та мови змінюються, а от спосіб вирішення проблем — річ універсальна. І якщо брати у відсотках, то знання технічних тонкощів — це максимум 40% оцінки кандидата. 60% — спосіб мислення та вирішення завдань.
Завдяки тому, як людина поводиться під час інтерв’ю, формується розуміння, хто переді мною: досвідчена людина чи випадковий кандидат. Одні думають та відповідають. Інші намагаються змінити тему розмови або переходять до атаки: «Не знаю, ніколи не думав, хто цим взагалі зараз користується?». Для мене це погана реакція.
Якщо ж людина може пояснити чи хоча б розуміє, куди копати, це вже добре. Навіть якщо каже, що піде в Google або на Stack Overflow, це вже активність. Є в мене приятель, який на співбесідах так і відповідав, не пам’ятаючи про деталі «бульбашок» чи дерев. І його наймача це влаштувало. Людина встигла попрацювати в Lukas Arts, а нині — на senior-позиції в Microsoft.
Тут можна спитати — а де ж межа занурення в нюанси?
Це залежить від специфіки продукту та майбутніх завдань людини. На співбесіді в геймдев мене питали про віртуальні функції, ортонормований базис, векторне та скалярне множення. Якщо ви шукаєте людину робити форми, необов’язково її мучити бітами та тонкощами пам’яті. Але тоді варто запитати про масиви і таблиці, зрозуміти, наскільки спеціаліст може щось скласти та порахувати.
Що зайве на співбесіді
Є кілька неписаних «НЕ», якими я користуюся під час розмови з кандидатом.
1. Не влаштовую додатковий стрес. Співбесіда — і так неспокійна процедура для всіх. Я не сиджу з видом інквізитора, вбиваючи в кандидата питання, наче цвяхи. Важливо, щоб вийшла розмова двох спеціалістів. Нервовість ускладнює дискусію для обох сторін.
Часто виглядає так. Рекрутер дає вступне слово і просить кандидата розповісти про професійний або особистий досвід. Поки людина говорить і звикає до нас і простору, я шукаю, де зачепитися за потрібну мені тему, щоб акуратно вступити в діалог.
Ви робили ігри? А як працювали з персонажами? Як використовували моделі? Ага, тобто у вас була загальна модель, а з неї ви наслідували людей, коней, котів?
Використовували список? А чому? Якби замість списку взяли дерево, що було б?
Запит із бази? Як організовували саму базу? Які критерії за часом обробки у вас були?
Ніби між іншим можна багато чого з’ясувати про практичний досвід кандидата та глибину його знань. Це найкращий варіант — щоправда, складнуватий у реалізації.
Буває, відповідаючи, людина губиться. Якщо це нерви, то після пари моїх підказок вона підхоплює та розвиває думку. Якщо ж не допомагають і підказки, найімовірніше, кандидат відповіді не знає.
2. Не прошу написати код на аркушику. Співбесіду і так багато хто сприймає як екзамен, і я не хочу це підсилювати.
Обговорюємо ми, скажімо, принципи ООП, і я можу спитати: «Уявіть, що в нас є геометрична фігура — квадрат або трикутник. Як буде виглядати поліморфізм, наслідування, інкапсуляція?». Намагаюся все розбирати усно, буквально на пальцях. Хіба що людині простіше намалювати. Мені важливо не виловлювати бліх у вигляді забутої дужки чи зайвої коми, а зрозуміти глибину знань. Синтаксисом хай займається машина.
Якщо для позиції важливо глянути, як людина пише, можу попросити зробити невеликий тест за межами співбесіди. Час для нього кандидат обирає сам — і тоді отримує завдання.
3. Не занурююся в знання дуже специфічної технології. Мені не цікаво, чи користувався кандидат якоюсь дрібницею з оновлення PHP. Особливо, якщо хитається база.
Кажуть, є три ступені пізнання: не вмію користуватися; вмію користуватися; вмію не користуватися. Нас цікавить друга категорія, а також те, наскільки людина швидко та самостійно вчиться новому.
Якщо вам здається, що я дуже багато пишу про базові знання, вам не здається :) Можливо, це суб’єктивізм. Але він зовсім не заважає.
Кілька разів я експериментував: брав людей, які на верхньому рівні могли щось розповісти, але фундаментальних знань не мали. Згодом команда від цього тільки страждала. Людині доводилося постійно щось глибше пояснювати, доробляти за неї або взагалі переробляти.
Мій досвід свідчить, що без бази людина не зможе розв’язати навіть трохи складне завдання — просто не знатиме, куди копати.
База, зокрема, допомагає проводити співбесіди за різними спеціалізаціями. Наприклад, на старті SENET ми шукали бекенд-програміста на Python Django, а фронтенд — на Angular. Я не маю досвіду ні в тому, ні в тому. Але перевіряючи базові знання, можу зробити висновок: людина розуміє основи, які можна застосувати абсолютно до всього, отже, далі вона розбереться.
4. Не звертаю уваги на особливості особистості, якщо вони не нашкодять команді. На співбесіді ми зокрема узгоджуємо цінності, аналізуємо софтскіли людини, подумки приміряємо, чи впишеться вона в команду.
Але жодних оцінок за типом активності. У мене в команді працював інтровертний інтроверт. Він тихо приходив на роботу, тихо йшов додому. Не любив корпоративи, ні з ким не обговорював своє особисте життя. Лише іноді вдавалося на кілька хвилин його розговорити. Йому було комфортно, оточуючим також — чого ще бажати?
Проте це не стосується співбесіди. На неї обидві сторони приходять не мірятися характерами.
Навіть найглибші інтроверти або найрозумніші розумники зацікавлені відповідати на питання. Якщо мені відповідають крізь зуби або кажуть «усім і так відомо, як ця штука працює, нащо ви це питаєте?», можливо, цієї миті мені забивають баки. Намагаюся максимально вивести на конкретику: і все ж таки, як це працює, чому, для чого використовується?
Для мене діє маркер — «як на співбесіді, так і в роботі».
Людина не може знати все, але діалог є, я бачу опору на попередній досвід та бажання розібратися. Найімовірніше, в роботі буде комфортно.
А буває, що починається торгівля з собою. Наче все добре, але... щось не те. Тут я намагаюся довіряти собі. Досвід показує, що поверховість і відчуття роботи на галай-балай переповзе у щоденну взаємодію.
Колеги іноді питають: «Що робити з тими, хто зумів справити враження, а в роботі виявився майже нульовим?»
У моїй практиці таких не було. Співбесіда — прекрасний лакмус. Звісно, можна замість знань зубрити відповіді на підступні питання та тренувати мегаскіли із забивання баків. Але такі хитруни мені не траплялися. А якщо вони раптом і пролізуть на посаду, може, не так усе й погано? Зрештою, вони щось уміють, просто спрямовують свої зусилля не туди.
Що робити в разі неспівпадіння
Часто кажу, що мені щастило, бо багатьох спеціалістів я брав із першого разу. Але трапляється, що позицію не вдається закрити ні після другої, ні після шостої співбесіди. Тоді дивлюся на поточну ситуацію.
Наприклад, кандидат не тягне на нашу посаду, але на джуна — цілком. Років п’ять тому можна було б внести його в шортліст і шукати далі. Зараз людей скрізь не вистачає. Якщо ми знаємо, що все одно будемо шукати далі та набирати команду, чому б не взяти талановитого спеціаліста, який за деякий час виросте до потрібного рівня? Але це питання необхідно узгодити з відповідальними за фінанси та розвиток компанії.
Зрозуміло, що в такому разі під час оцінки кандидата пріоритетними є його бажання вчитися та цікавість до продукту. Тоді й ми будемо мотивувати та допомагати. Якщо ж людина шукає тимчасовий «запасний аеродром», немає сенсу домовлятися — на спеціаліста не можна буде покластися в роботі.
Відмовляючи, я стараюся пройтися компетенціями та пригадати «сліпі зони» зі співбесіди. Чітко сказати, яких знань у якій сфері не вистачає. Наприклад, що треба освіжити розуміння роботи з пам’яттю чи бітову логіку. Моя відповідальність тут — дати корисний фідбек, який допоможе спеціалісту.
Таким є мій досвід пошуку досвідчених :) Він точно не є аксіомою — скоріше можливістю обговорити підходи. А шукачам роботи хочу побажати зосередитися на базі — вона допоможе вам зібрати до купи розрізнені знання та збудувати нормальну компетенцію, з якою ви станете бажаним кандидатом.
Оригінал статті на
