Як сподобатись програмісту
Привіт, я senior (помідор) програміст. І я влаштовувався (або, принаймні, намагався) в багато різних компаній. Грунтуючись на цьому досвіді, я хотів би розказати про те, як з моєї точки зору виглядає ідеальний процес найму (ідеального) програміста.
Це розповідь про те, що особисто мені сподобалось, а що не сподобалось, в процесах найму різних компаній, і я адресую її всім, хто так чи інакше задіяний в цих процесах.
Я розумію, що враховуючи ситуацію на ринку, можливо, зараз доречніше було б написати про те як програмісту виділитись на фоні десятків претендентів на одну вакансію. Але про це я не напишу, бо сам не знаю як : )
Втім, я переконаний, що найняти дійсно крутого спеціаліста завжди не просто, в будь-який час і в будь-якій сфері. Тож уявлю що я і є цей самий крутий спеціаліст і дам пару суб’єктивних порад про те як мене наймати : )
Як писати вакансію.
Відверто кажучи, мені не так важливо знати яка версія якого фреймворку використовується в компанії і чи є “легасі”. Не найбільше цікавлять мене і різноманітні “бенефіти”. Набагато більше мене хвилюють дві речі: 1) гроші (очевидно) і 2) відчуття значущості своєї праці (неочевидно). На першому пункті зупинятись не будемо - жоден з нас не хотів би раптом знизити свій рівень доходів у 1,5-2 рази, тому вакансії без вказання “вилки” - це велика вірогідність згаяного часу з обох сторін. Щодо другого пункту - поясню: для того щоб зберегти ментальне благополуччя і працювати з максимальною віддачею потрібно вірити в те що робиш. І це набагато важливіше для мотивації, аніж оплачувані страховка і спортзал (які при гідній оплаті праці люди можуть собі дозволити оплатити самостійно). Іноді це може бути навіть важливішим за перший пункт, тому якщо ви дійсно змінюєте світ, то “вилку” можете не вказувати : ). Отже, найважливіше у вакансії - це розповісти які круті речі ви робите, і скільки платите. Все інше - другорядне.
Як комунікувати.
Приємно коли наймаюча сторона піклується щоб комунікація була для мене зручною. Наприклад, коли вказують назву компанії в заголовку листа-запрошення на співбесіду (бо ж таких листів в мене може бути не один і не два). Або коли не пишуть в месенджери в неробочий час. Або коли піклуються про те щоб по організаційним питанням я комунікував з однією особою**,** а не передають мене “з рук в руки” між різними людьми, які не синхронізуються між собою. Словом, коли про мою зручність думають з самого початку і в таких дрібницях - це дійсно круто.
Як проводити прескрінінг і співбесіду.
Безсумнівно, дуже важливо пересвідчитися що кандидат відповідає заданим вимогам. Але важливо робити це без буквоїдства. Автоматично відсіюючи всіх з 1.5 роки досвіду роботи з фреймворком N замість затребуваних 2-х, ви ризикуєте втратити цінного кандидата, який за потреби надолужить це відставання за тиждень. Важливо розуміти: чим вищий рівень спеціаліста, тим менше значення мають конкретні технології чи фреймворки. З певного етапу всі вони - просто інструменти для вирішення бізнес-задач, які опановуються, коли виникає потреба і забуваються, коли потреба зникає. Тож краще зосередьтесь на фундаментальних речах - архітектурі, паттернах, тестах, інформаційній безпеці тощо. Я розумію, що рекрутеру, як не-технічному спеціалісту, може бути непросто оцінити фундаментальні технічні знання на прескрінінгу, тоді як кількість років досвіду - величина конкретна і зрозуміла всім. В такому випадку раджу попросити ваших програмістів підготувати декілька контрольних питань, і задати їх кандидату. Для прикладу: чи зможете розказати про принцип інверсії залежностей? чи поясните різницю між асинхронністю і паралельністю? в чому, по-вашому, ключова особливість фреймворку X? тести якого типу переважали на вашому останньому проекті? Такі питання покажуть реальний рівень підготовки кандидата, і по тому, наскільки легко і розгорнуто він на них відповість, навіть не-технічний спеціаліст зможе зробити попередні висновки.
Як лайв-кодити.
Лайв-кодинг - це завжди стрес для мене. Але і його можна зробити приємнішим, і іноді навіть цікавим. Не вимагайте закодити щось що потребує якихось специфічних і конкретних знань, наприклад, як працювати з чергами в фреймворку X версії Y. Такі речі не запам’ятовуються, а “гугляться” за потреби. Натомість, вигадайте задачу, яка б показала як людина мислить, як перевіряє гіпотези, як уточнює вимоги. Не робіть лайв-кодинг дуже довгим, але і не ставте жорстких часових рамок. Приклад поганого завдання - зробити з нуля веб-додаток типу TODO-листа, час 3 години. Приклади хороших завдань - якась алгоритмічна задачка, або рефакторинг вже написаного шматка коду, час 1-1.5 години.
Яке давати тестове.
Тестове завдання (як і лайв-кодинг) може справити на мене як дуже погане, так і дуже хороше враження. Ідеальне тестове вимагає не більше ніж 2-3 години часу. Воно містить мінімум рутинної роботи, типу розгортання проекту, налаштування бази даних або контейнеризації додатка. Натомість містить концентрат із цікавих задач - рефакторинг, написання тестів, моделювання нетривіальної бізнес-логіки, проектування архітектури, тощо. Не вимагайте робочий додаток з інтерфейсом на виході, нехай це буде скрипт для запуску в терміналі, або навіть просто псевдо-код чи UML-діаграма. Знову ж таки, зосередьтесь не на конкретних енциклопедичних знаннях, а на більш фундаментальних речах: на вмінні розуміти вимоги і абстрагувати, писати підтримуваний код і перевіряти результати його роботи, тощо.
Післямова.
Рекрутинг і процес найму - обличчя компанії : ). І по тому, наскільки приємне враження він справляє, можна зробити серйозні висновки про те, чи комфортно буде працювати в цій компанії. Професіоналізм і здоровий глузд - найкраще чим можна зацікавити хорошого спеціаліста. Крім зарплати, звісно : )