Нояб. 26

Senior у пошуках роботи. Як я пройшов 15 технічних співбесід і що про це думаю

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

На мій подив, попередня стаття про співбесіди з рекрутерами та HR викликала неочікуваний інтерес: усього більш, ніж 100 000 переглядів по всіх джерелах. Я отримав купу позитивних відгуків у приватні повідомлення: мені написали колишні колеги, котрих я останній раз бачив 5 років тому; героїні деяких історій зі статті; хлопець, якому я кілька тижнів тому продавав системник через OLX; барабанщик, з яким ми минулого року грали метал у гаражі, та, як це не дивно, дуже багато рекрутерів, які поцікавилися моєю думкою щодо того чи іншого. 250 людей додалися до мене у LinkedIn — не знаю, правда, навіщо :)

Перед тим як перейти до справи, відповім на найпопулярніші запитання з приватних повідомлень та коментарів.

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

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

Рекомендую прочитати перед пошуками роботи.

Кілька думок щодо рекрутингу

Я в жодному разі не даю порад рекрутерам, як їм робити їхню роботу. Я не професійний рекрутер і не знаю, як працює їхня внутрішня кухня. Коли мені доводилося шукати собі персонал (не проводити технічні співбесіди, а саме шукати і наймати — повний цикл), то це були junior-позиції, відповідно, в мене не було особливих проблем.

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

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

Також рекрутинг — це продаж вакансії кандидату. Чим швидше ви це зрозумієте та почнете прокачувати свої навички продажів — тим краще. Ой, я ж казав, що не буду давати порад :)

Мені подобаються думки та підхід наймаря Романа Кушнарьова. Якщо ви його ще не читали — рекомендую, файно пише.

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

Винайматися у компанію чи на проект

На мою думку, у наших реаліях — однозначно на проект. Трішки детальніше про це написав у себе в Telegram-каналі.

Як обирати собі тайтл

Я позиціював себе як кандидат рівня Senior Software Engineer та вище — Team/Tech Lead, Principal Engineer, Software Architect, Project Manager, People/Group Manager і так далі. Саме це «вище» малось на увазі під «+» у Senior+.

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

Отож, пані та панове, перейдемо до технічних співбесід.

Етап другий. Технічні співбесіди

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

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

Усього я пройшов 15 технічних співбесід, що, як на мене, насправді, не так вже й багато. Я міг би пройти значно більше, але в середньому чекав тиждень від першого контакту з рекрутером до розмови з технічним спеціалістом. При тому, що в мене не було практично ніяких обмежень по часу. Лише одного разу мені призначили співбесіду на час, в який в мене вже була запланована інша співбесіда). Також зауважу, що всі компанії або рекрутери виходили на мене самі, а не я на них. Я не надсилав резюме до жодної компанії першим. Це до питання, що не сеньор шукає роботу, а робота — сеньора.

Тестові завдання

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

«Виконайте проект з нуля (можливо, використовуючи конкретну технологію), та викладіть його на GitHub» — як на мене, найгірший варіант. Ви можете багато часу витратити на бойлерплейт, на інфраструктуру навколо рішення, а інтерв’юера будуть цікавити, як правило, декілька дрібних деталей, які закладені в умовах задачі. Добре, коли у вас є під рукою, припустимо, шаблони проектів і ви можете за 5 хвилин підняти сервер і швидко закодити, що там потрібно. Інакше доведеться якось те все згадувати і вручну піднімати. Також погано, коли в завданні є вимога використати зовнішні залежності, наприклад, не-embedded базу даних.

Позиція DevOps Engineer. Мені надіслали завдання зробити Vagrant конфігурацію з декількома інстансами, серед яких мали бути веб-сервери зі статикою, балансер для них і Jenkins. Усе це треба було встановлювати за допомогою Chef. А тепер уявімо: я ніколи не користувався Vagrant, Chef та не налаштовував ті веб-сервери, яких вимагали у тестовому завданні. Я приблизно розбираюся в тому, як воно все працює, мав справу зі схожими інструментами, але ніколи не використовував саме ці конкретні.
Мені довелося за одну ніч сісти, встановити це все, наступити на купу грабель, але врешті-решт виконати завдання. Основна складність полягала в тому, що в мене старий MacBook Pro 15-го року, який фізично не встигав рестартувати ті контейнери, і в тому, що я не мав досвіду з Vagrant.
На суть задачі — розібратися, як там що встановлювати, — у мене пішло може з півгодини. Решту часу (7 з гаком годин) я витратив на встановлення всього інструментарію, рестарти-ребути, тикання по конфігах в намаганнях зрозуміти, чому воно не працює, і так далі. Те саме на Docker Compose я би зробив, напевне, за годину, може, навіть менше. Чи можна було б у задачі не обмежувати кандидата інструментами? На мою думку, можна.
Чи було це завдання корисним для мене? Однозначно так! Я тепер буду знати, що від Vagrant та Chef треба триматися якомога далі :)
Витрачено часу — 8 годин.

На жаль, більше історій про цей тип завдань у мене немає, тому що тестових давали в цілому не так багато :(

«Ось посилання на сайт з тестами, пройдіть їх» — дуже класний варіант. У чому суть? Є SaaS, які дозволяють сконфігурувати набір практичних та теоретичних питань та для вирішення надають REPL та редактор коду прямо там в них і можливість запустити верифікаційні тести. Далі ви просто йдете по завданнях, фіксите або пишете код, запускаєте його і дивитися результати. Самі тести від вас приховані, ви бачите тільки результат (passed/failed) та короткий опис тесту, який одночасно є підказкою. Чому це варіант мені подобається найбільше? Тому що є однозначний критерій якості виконання завдання і кандидат точно знає, скільки балів він набрав, чи його рішення працюють і так далі. Мені особисто навіть цікаво було проходити ті завдання. Єдине, що я не бачу змісту в теоретичних питаннях типу «що буде, якщо виконати цей код» — вони легко гугляться.

Позиція Ruby Software Engineer (пам’ятаєте історію про місяць очікування? Це звідти). Мені присилають лінку на сайт TestDome, звісно, кастомний тест. Я клікаю, потрапляю до власне тестів. Мені дається 2,5 години на проходження всього набору, по 5-20 хвилин на кожне питання. Насправді мені дуже сподобалося, я вже давно не проходив такі штуки. Особливо мені сподобався TDD-підхід: закодив, запустив, подивився, що в тебе впало, кодиш далі. Пройшов із великим задоволенням.
Самі задачі були відносно прості: виправити код (Ruby/JS/CSS/HTML), написати якісь валідатори (Ruby), реалізувати структури даних (Ruby), нічого особливого. Але той факт, що ти одразу можеш перевірити, чи рішення працює, дуже допомагає у вирішенні.
Я впорався із завданням на 93/100 балів усього за годинку з гачком. Шкода, що це мені зовсім не знадобилося на подальших етапах. TDD допомагає у вирішенні, не потрібно витрачати час на підйом інфраструктури, репл прямо у браузері — коротше кажучи, дуже круто. Заради такого можна було і місяць почекати — адже я отримав свою порцію допаміну (я круто все зробив!) та адреналіну (таймер працює, часу все менше!).
Витрачено часу — 1 година.

Також великою перевагою цього типу завдань є те, що їх перевірка автоматизована. Усі ми знаємо, як інтерв’юери «люблять» перевіряти завдання (про це вже писали кілька тижнів тому). А тут за на все робить машина — дуже зручно як мінімум, що тобі не треба викачувати цей код та компілювати його. Можливо, буду використовувати цей метод при наймі у майбутньому.

«Ось репозиторій, там завдання, надішліть Pull Request з рішенням» — такий варіант мені не траплявся, але його використовували мої колеги. Мені він не дуже подобається, тому що можна подивитися, як виконували те саме завдання інші люди (якщо вони були).

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

«Ось репозиторій, там код, відрефакторіть, наскільки зможете» — варіація попереднього. Це вже краще, бо тут з самого початку створюються якісь рамки, у яких можна працювати. Недоліки ті самі: незрозуміло, коли потрібно зупинятися. Як казав Єгор Бугаєнко, будь-яка програма містить нескінченну кількість помилок, і фіксити їх можна теж до нескінченності. Автори завдання мали щось у голові, коли робили його, але швидше за все ми так і не дізнаємося, що саме було б для них основним. Якби завдання мало чіткий критерій, тоді це було б круто. Наприклад, є код, він на такому залізі видає ось такий результат по швидкодії. Порефакторіть, щоб працювало в два рази швидше. Без критерію працювати складно. У реальному житті в реальній роботі ми завжди маємо рамки і шукаємо оптимальне рішення, керуючись цими рамками та здоровим глуздом. І основна робота розробника — якраз відчути цей баланс і підібрати відповідне рішення.

На мій превеликий жаль, ніхто більше не давав тестових завдань, тому статистика у мене зовсім невелика. Хіба що можу згадати ті тестові, які я робив багато років тому. Вони всі були першого типу — потрібно було написати проект. Цікаво, що я їх робив у ті часи, коли GitHub не був таким популярним і треба було пересилати вирішення у zip-архіві поштою :)

Мої рекомендації щодо тестових завдань:

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

Що ж, тестове, ви, сподіваюсь, успішно виконали, передали цю інформацію рекрутеру, і через невизначений час вас запросять поговорити in person.

Технічна співбесіда. Інтро

Почнімо з того, що зараз уже досить рідко запрошують до офісу на технічні співбесіди. В офіс мене запросили тільки декілька разів — для інтерв’ю на позиції Solution Architect, Tech Lead та одного разу — на менеджерську позицію. Усі інші співбесіди проходили по Skype, Zoom, Hangouts. Як і на попередній співбесіді з рекрутером, поради ті самі — хороша камера, хороша гарнітура. До цього обов’язково додамо умову шарити екран. Тому переконайтеся, що ви не маєте відкритих робочих проектів (якщо це важливо) та інших персональних речей, які не потрібно показувати людям з того боку. Майте під рукою чистий браузер без табів та REPL для кодингу про всяк випадок (IDE або відкритий сайт).

З усіх засобів зв’язку мені найбільше подобається Zoom. Власне його найчастіше і використовували.

Важлива порада щодо правильного спілкування у телеконференціях: майте звичку не говорити, не друкувати на клавіатурі, коли говорить інша людина, і вести розмову в гарнітурі, а не, наприклад, через вбудований мікрофон ноутбука та зовнішні колонки.
Чому це важливо? Найчастіше з вами будуть розмовляти двоє людей, відповідно, вони не будуть користуватися гарнітурами. Коли ви говорите, то на їхньому боці софт вмикає шумодав, який не дає з’явитися ефекту зворотнього зв’язку (фон, свист, ехо). Коли вмикається шумодав, то їхній мікрофон практично нічого не буде ловити, тому ви не будете чути, що вам говорять.
Коли ви друкуєте на клавіатурі, то це створює шум, який передається на той бік та теж вмикає шумодав. У результаті цього фрази обриваються і складається враження поганого зв’язку. Тому завжди потрібно чекати, поки люди не закінчать говорити. Інакше ви просто не почуєте, що вони хотіли сказати (окрім випадків, коли вони теж використовують гарнітуру). Як це не дивно, але багато людей не знають про ці механізми. Також корисно відключати мікрофон у той час, коли ви не говорите, щоб до людей не проривалися шуми з вашої кімнати. Я вихований роками роботи в ентерпрайзі, де ці правила знає кожен, тому в мене це звичка.

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

Перед співбесідою обов’язково ще раз пройдіться по вакансії, зауважте вимоги, які пред’являються до кандидата, та підготуйте промову. Я проходив співбесіди на Tech Lead, DevOps/SRE, Ruby/Java Software Engineer і у кожному випадку говорив різні речі, які б, на мою думку, зацікавили інтерв’юерів найбільше. Намагайтеся не заглиблюватися в деталі, а надати ту інформацію, яка створить вектор для подальшої дискусії. Не варто детально говорити про те, що ви робили 5 років тому (якщо це не було щось екстраординарне).

Я казав, наприклад, таке: «8 років працював у ентерпрайз-конторі, в основному з Java. Далі пішов у стартап, там займався інфраструктурою. Останні два роки пишу в основному на Rails». Все, у інтерв’юерів є досить інформації, і вони далі вже будуть розкручувати розмову в тому напрямку, який їх найбільше цікавить.

А тепер несподіваний факт.

Ваше резюме ніхто не читає

Чесно кажучи, це виявилося для мене великим відкриттям. Ну добре, рекрутери не читають профіль у LinkedIn, тому що він може бути не up-to-date, HR має навичку проглядати CV і просто виділяти для себе основне. Але от люди, які проводять співбесіду, вже точно не будуть читати ваше резюме. Жодного, підкреслю, жодного разу я не відчув, що люди хоча б одним оком глянули на те, що я там детально порозписував. Я підозрюю, що, як правило, вони дізнавалися про те, що потрібно проводити технічну співбесіду, попереднього дня, і вирішували почитати CV за 5 хвилин до дзвінка, а там вже буде як буде.

Зрозумійте мене правильно: я не є нарцисом або балериною «кружите меня, кружите». Я знаю, що в мене є багато слабких сторін (як з технічного, так і з менеджерського боку). Я не очікую, що інтерв’юери будуть на мене дивитися, як мавпи на Обеліск. Я не вимагаю, щоб мені виказували респекти з перших хвилин розмови. Я лише очікую від людей професійної підготовки, тим більше, що займає вона 10 хвилин. Перечитати CV, можливо, подвитися лінки, які там є, підготувати приблизний список питань та скоротити загальний час на розмову.
Особисто я завжди читав CV перед співбесідою та продумував, що мене буде цікавити. Шкода лише, що нормальне резюме в нас майже ніхто не вміє робити, там три рядки, як правило.

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

Ви нікому не потрібні

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

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

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

Ви не будете розмовляти зі своїм майбутнім босом чи тімлідом

Це є наслідком з попереднього. На моє глибоке переконання, ви повинні говорити з тим, кому ви потім будете підпорядковуватися, формально чи неформально. В усіх організаціях є якась ієрархія, хоч це Scrum-команда, хоч кривавий ентерпрайз. Усюди є людина, яка буде приглядати за вами (як мінімум на старті).

На жаль, ви нічого не можете з цим зробити. Єгор Бугаєнко у своєму дописі «Why I Don’t Talk to Google Recruiters» дуже добре описав цю ситуацію. Якщо ви будете вимагати розмови зі своїм майбутнім босом — ви просто не підете ні на яке інтерв’ю.

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

Трішки минулого досвіду. Коли я винаймався на поточну роботу, то розмовляв безпосередньо з CTO та CEO. Я повинен був бути першим інженером у стартапі, тому й ставлення до мене було дуже прискіпливе та серйозне. У результаті ми чудово спрацювалися, та й співбесіда була однією з найкращих, що в мене були. Ми обговорювали не тільки технічні деталі, а відразу й перші кроки і плани на декілька місяців наперед. Навіть якщо співбесіду не буде проводити ваш безпосередній керівник, обов’язково вимагайте ~~долива пива после отстоя~~ спілкування з ним перед тим, як приймати пропозицію (звісно, якщо вдасться пройти всі етапи).

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

Долучайтеся до мого каналу у Телеграмі, і до наступної статті!