Хороші та погані практики найму. Поради для роботодавців і кандидатів
Привіт, я Олег, і я люблю співбесіди. За свою кар’єру в тестуванні відвідав десятки співбесід. Певно, їхня кількість перевалила за сотню. Я сидів по обидва боки столу: і як інтерв’юер, і як кандидат. Я пробувався в аутсорс, аутстаф, продукт і стартап; в українські, європейські, азійські компанії. У FAANG не мав ще інтерв’ю, але як буде, то напишу й про це.
Певний період я часто ходив на співбесіди. Не тому, що шукав роботу, а тому, що процес був цікавий. Це допомогло мені прокачати навички, адже я отримував фідбек про свій рівень і чув нові «незнайомі слова», тобто про нові технології, які пізніше вивчав. Наприклад, так я ознайомився з Docker’om, коли про нього ще ніхто не чув (це був приблизно
Крім цього, я побачив багато недоліків у проведенні співбесід. Пізніше я і сам інтерв’ював кандидатів.
У статті я виділив погані та хороші практики. Докладніше про це розповідав на конференції QA DAY 2020.
Матеріал буде корисний інженерам, які шукають роботу, і тим, хто проводить інтерв’ю. Оскільки більшу частину своєї кар’єри я працював у тестуванні, мої співбесіди були у цій сфері. Але якщо прибрати специфічні для тестування моменти, то стаття підійде всім інженерам. А ще — рекрутерам.
Ілюстрація Аліни Самолюк
Що не треба робити
Отже, погнали. Уявіть, що ви техексперт на співбесіді.
Ніколи не читайте резюме перед співбесідою. Здавалося б, банально, але інтерв’юерів, котрі перечитують резюме до співбесіди, мало. Переважно я стикався з тими, хто його читає безпосередньо під час розмови. Мене неодноразово запитували про ту чи іншу сертифікацію чи мою освіту, хоча це все було зазначено в резюме. І дивно, що інтерв’юер, від якого ти очікуєш професіоналізму, не зміг навіть переглянути написане. Одразу ставлення до компанії погіршується, бо якщо тут несерйозно ставляться до найму, то так само можуть ставитися і до працівників.
Запитайте про різницю між лоад- і стрес-тестами. Ставити питання з першого-ліпшого списку Top-100 QA interview questions — тупо. Ці питання настільки заїжджені, що достатньо вивчити перші 15 — і вдасться пройти співбесіду в багато компаній. Часто ті самі питання ставлять як на Junior-рівень, так і на Senior. І відповіді очікують ті самі.
Ставте питання, на яке правильна відповідь лише ваша. Нерідко можна почути питання на кшталт «Як ви тестуєте такий-от сервіс?». І після кількох ваших відповідей вам скажуть «правильну». Навіть якщо ви озвучили правильне твердження, але іншими словами або врахували моменти, які не зауважив інтерв’юер, ваша відповідь все одно буде неправильною. Бо правильною є лише у його формулюванні. Така поведінка інтерв’юера схожа на спробу самоствердження.
На одній зі співбесід кандидата запитали: «На вебсторінці після натиснення на кнопку нічого не відбувається. Що може бути причиною такого?». Звісно, варіантів безліч:
- помилка на фронтенді;
- помилка на бекенді;
- кнопка закрита іншим елементом, відповідно клік не відбувається;
- інші варіанти, про які напишуть у коментарях.
Інтерв’юер проігнорував ці відповіді та сказав: «Там, напевно, event handler на клік не додали». І ось що виходить: з-поміж усіх можливих варіантів він очікував лише відповідь про event handler. І тільки її вважав правильною.
Курити вейп під час співбесіди. Навіть якщо співбесіда онлайн, не варто курити вейп та інші штуки. Курйозний випадок трапився зі мною на онлайн-інтерв’ю на початку пандемії. Під час нашої розмови, коли я пояснював своє бачення тестування, інтерв’юер просто дістав вейп і почав курити. Звісно, я не чув запаху, але це було непрофесійно. Наша співбесіда завершилась через 10 хвилин після того, тому що інтерв’юеру зателефонував кур’єр і він пішов по свою піцу. І я не хотів чекати того моменту, як він почне її їсти. Хтось скаже, що це не страшно і нікому не заважає. Але взагалі це вияв неповаги до співрозмовника.
Що треба робити
Інтерв’ю — не іспит, не варто проводити його як совковий викладач місцевого політеху. Мені нерідко траплялись співбесіди у стилі обміну визначеннями: «Що таке HTTP?» — «HTTP — це hypertext transfer protocol, протокол передачі гіпертексту!» — «О, молодець. Шариш».
Якщо ви не перекладачі, то для вас важливо не те, як розшифровують термін HTTP, а те, як людина використовувала протокол і як зможе ці знання застосувати на вашому проєкті. Те саме і щодо пошуків підводних каменів у чиїйсь роботі. Колись на мій псевдокод, написаний на листочку, заявили, що він не буде працювати, бо я пропустив дужку чи крапку з комою. Це причіпка і дуже схоже на самоствердження через інших.
Запам’ятайте: інтерв’юер — обличчя компанії. Це стосується і рекрутера. Перше враження будете справляти ви. І яким би не був результат співбесіди, кандидат запам’ятає цю компанію через вас.
Окремо я хотів би виділити те, що варто робити інтерв’юеру та рекрутеру.
Готуйтеся до кожного інтерв’ю. Ознайомтеся з наявною інформацією про кандидата: резюме, сторінка у LinkedIn, GitHub. Повірте, там можна знайти багато даних за короткий час
Однак важливо розуміти, що резюме — це ще не вердикт. Багато хороших інженерів забивають на резюме і погано його оформлюють. Не знаю, чи це лінь, чи ефект Даннінга — Крюґера спрацьовує. А буває і навпаки: спеціаліст перегинає палицю і пише резюме на 5 сторінок. Робіть висновок за результатами спілкування, а не з перегляду резюме.
Досвід у роках — неважливий. Мені доводилося шукати автомейшн зі знаннями Python. І на одну й ту саму вакансію були два кандидати з двома роками досвіду. Перший вирішував багато задач на проєкті, і його знання Python були достатніми для цієї позиції. Другий два роки займався Ctrl+C та Ctrl+V і взагалі не знав Python. Але формально двоє відповідали цим критеріям. Також досвідченому інженеру нескладно змінити мову програмування, особливо в автоматизації тестування. Тож висновок з цього такий: краще напишіть, які саме фічі мови програмування ви використовуєте, так можна краще зрозуміти, чи кандидат підходить.
Запитуйте лише те, що потрібно для вакансії. Я неодноразово бачив, як людей ганяють на співбесіді по тому, що на проєкті не використовують й не будуть використовувати. Моє улюблене — про Performance Testing. Сенс розпитувати людину про те, чого вона не буде робити? Дехто скаже «на перспективу», але поки ви будете чекати ту «перспективу», то кандидат зможе здобути нові знання або ж, навпаки, їх забути. Я не бачу сенсу обговорювати технології та підходи, котрі не стосуються конкретного проєкту. Винятком може бути ситуація, коли кандидата співбесідують не на конкретний проєкт і він може потрапити у різні команди.
Якщо кандидат не розуміє питання, спробуйте пояснити, що ви очікуєте почути у відповідь. Наприклад, я чув такі питання: «Що відбувається після того, як користувач введе назву сайту у браузері?». Інтерв’юер очікує почути про модель TCP/IP, які протоколи використовуються, як вони взаємодіють тощо. Не завжди кандидату вдається зрозуміти, що саме ви хочете почути. Це нормально, коли люди з різних компаній та оточень іноді трактують одне й те саме по-різному. Оскільки у кожного власний попередній досвід і сприйняття.
Якщо ви — кандидат
А тепер — ви кандидат у пошуках. Або не в пошуках, але вам написав рекрутер і підкинув пропозицію. Що варто знати й робити?
До того, як ви скажете перше слово на співбесіді, вас оцінять за резюме.
Не пишіть у резюме про школу, у якій ви вчились. Навіть якщо ви закінчили її із золотою медаллю. Тим більше якщо ви закінчили її із золотою медаллю. Бо це поставить під сумнів вашу відзнаку, адже в шкільному курсі української мови є урок про резюме. І там кажуть, що про школу не потрібно писати.
Я ніколи не працював у SoftServe, але знаю, якими є їхні внутрішні резюме. Бо десятки людей надсилають їх. Ні, не переробляють і надсилають, а надсилають без змін. І як після такого вірити у серйозні наміри людини змінити роботу, якщо вона не готова підготувати резюме? Крім того, внутрішнє резюме, можливо, є власністю компанії, і надсилання його комусь іншому може порушувати ваш контракт.
Пишіть про технології та підходи, з якими ви безпосередньо працювали. «Ну, Jenkins був у нас на проєкті. Я там іноді натискав на велику зелену кнопку», — каже кандидат, який нібито займався Jenkins. Хоча не має жодного поняття, як він працює чи як налаштувати простеньку Job’у. І це поширений приклад.
Погрупуйте назви інструментів за відповідними категоріями. А всяки утиліти типу WinSCP та TotalCommander взагалі би не додав до резюме.
Будьте готові отримати питання з будь-якої технології з вашого резюме, тому зазначайте лише ті, з якими справді працювали. Нерідко зустрічаю людей з Java у резюме, а по факту «я курс прослухав». Пам’ятаєте, коли викладач на іспиті ставив питання типу «Ви знаєте другий закон термодинаміки?» І щоб не сказати правду, що не знаєте, відповідали: «Ну, я читав...» Я часто таке чую від кандидатів. І ще «можна своїми словами» та «точного визначення не пам’ятаю».
Інтерв’ю — не іспит, і це нормально чогось не знати чи не мати досвіду роботи з чимось. Для мене видається безглуздим, коли людина намагається вгадати відповідь. Якщо не впевнені у своїх знаннях, то просто так і скажіть.
Озвучте свої цілі та очікування від проєкту. Щоб бути задоволеним новим місцем роботи, потрібно, щоб ваші персональні цілі та цілі проєкту збігалися. Ви хочете почати займатися автоматизацією? Запитайте, чи вона планується. Можливо, ви вбережете себе від проєкту, на якому швидко вигорите.
Яку ціну ставити за тестове завдання
Колись я побачив дискусію на форумі DOU про платне тестове завдання. За такою логікою можна вимагати гроші за відвідування співбесіди. Можна було б заробляти лише походами на інтерв’ю. Якщо вам не подобаються тестові завдання, одразу кажіть, що не будете їх виконувати.
Тестове завдання не повинно бути великим. Написати два невеликих UI-тести для людини, котра працює автоматизатором, не має займати більше як один вечір. Але великі тестові завдання, на які потрібно витрачати більше одного дня, це перебір.
Я дуже підтримую тестові завдання. У них можна побачити, як кандидат думає та пише код. Що вищий рівень спеціаліста, то більше ви очікуєте побачити у коді (обробка помилок, логування, структурування коду, навички користування Git: чи є бінарники у репо, чи використовує .gitignore, робить один коміт чи є якась історія, а може, ZIP-архів).
І знов-таки можна збагнути мотивацію людини. Зацікавлений кандидат буде старатися зробити свій код якісним і робочим. А дехто скаже, що буде робити, і навіть не почне. Це теж показник: якщо кандидат декілька днів твердить, що працює над тестовим, а в кінці каже, що не зробив — я не певен, що хочу працювати з людиною, яка обманює.
А тепер невелика статистика, за моїми спостереженнями. З десяти кандидатів, тестове:
- п’ятеро не виконує;
- у двох код не білдиться;
- у двох код падає або не робить те, що потрібно;
- в одного код працює, як очікується.
Коротенький підсумок
Усе, що тут описано, справді траплялося зі мною. І неодноразово. Хотілось би бачити більш професійних інтерв’юерів і кандидатів, адже знайти хорошого інженера навіть вдень зі свічкою важко.
Інтерв’ю не повинно бути іспитом, це має бути розмова, під час якої обмінюються досвідом і проблемами, які потрібно розв’язати. Насправді навіть маленькі кроки дадуть змогу поліпшити найм, та й кандидати будуть легше знаходити цікаві для себе проєкти.
Успіхів у пошуках.
А ще я стараюся вести блог про тестування (і не тільки), тож буду радий, якщо ознайомитесь з ним. Я відкритий до співпраці та зворотного зв’язку, тому пишіть у телеграм.
Дякую, що дочитали!
