12 думок про успішну співбесіду. Поради для інтерв’юерів

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Вітаю, товариство! Ми з Павлом Сафоновим вирішили продовжити тему пошуку роботи з попереднього подкасту на каналі QБ Podcast.

Цього разу ми запросили людину, яка особисто провела більше 1000 співбесід, засновника QA Club Lviv, організатора конференцій QA Party Hard — Романа Марінського. На трьох у нас в досвіді більше 1,5К проведених співбесід, отже нам є чим поділитися. Як тут уже можна здогадатися, акцент у розмові буде на тестувальників, але більшість питань не залежать від спеціалізації. Нижче буде коротка текстова версія цього питання моїми очима, якщо ж вам більше заходить відео- / аудіоформат, то вам сюдой :) 👇

Стаття буде корисна й інтерв’юерам, і кандидатам. Ідеї нижче є винятково моїм баченням і необов’язкові до виконання!

Дуже цікаво почути досвід і думки інших інтерв’юерів з цієї теми. А також цікаві історії зі співбесід.

Отже, далі ми розглянемо:

  1. Чому наразі вимоги до кандидатів більші, ніж будь-коли, і чому це продовжуватиметься.
  2. Найважливіша частина співбесіди.
  3. Як зрозуміти, чи кандидат знає, про що говорить, чи у нього / неї просто гарна пам’ять.
  4. Що робити, коли кандидат починає «плавати» на запитанні.
  5. Тривалість інтерв’ю, коли кандидат фактично не пройшов його за перші десять хвилин.
  6. Як давати негативний фідбек за результатами співбесіди.
  7. Скільки інтерв’юерів має бути на співбесіді.
  8. Чи треба давати тестове завдання перед співбесідою.
  9. Класична помилка на співбесіді автоматизатора.
  10. Порада менеджерам проєктів (де тільки планується автоматизація), яка збереже багацько грошей.
  11. Практичні задачі на співбесіді.
  12. Менеджерські співбесіди: цілі, навіщо існують.

Чому наразі вимоги до кандидатів більші, ніж будь-коли, і чому це буде продовжуватиметься

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

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

Найважливіша частина співбесіди

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

Рома використовує дуже крутий і, на мою думку, правильний підхід: починати зі small talk. Показати кота, насварити собаку, можна обговорити останні новини, будь-що, крім запитань про досвід. Зазвичай часу до пʼяти хвилин достатньо, щоб перейти в режим дружньої розмови, бо співбесіда — це не допит, а спілкування двох і більше спеціалістів з метою визначення зацікавленості у співпраці.

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

Як зрозуміти, чи кандидат знає, про що говорить, чи у нього / неї просто гарна пам’ять

Відповісти на суху теорію досить просто, хоч її і не мало. Достатньо кілька разів перечитати теорію і почувати себе більш-менш впевнено, але що це дає інтерв’юеру? Не так багато. Куди краще ставити відкриті питання, на які немає однозначної відповіді.

Наприклад, «А що би ти робив/ла в такій-то ситуації?», «Що найскладніше доводилося тестувати / автоматизовувати?». Відповідь на таке запитання може показати, як кандидат мислить: чи розуміє в деталях про що говорить, чи підкріплені його / її дії теорією, чи там навпаки більше інтуїції.

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

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

Що робити, коли кандидат починає «плавати» на запитанні

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

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

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

Тривалість інтерв’ю, коли кандидат фактично не пройшов його за перші десять хвилин

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

То скільки ж часу витрачати на кандидата, якщо за перші пʼять хвилин ти вже знаєш, що «нє»? На жаль, однозначної відповіді на це питання в мене нема. Маючи досвід рекрутера, я був навчений тому, що не можна швидко відмовляти кандидатам, бо це вважається некультурним. Тому я можу скоротити співбесіду, але 40–60 хвилин кандидату я приділю.

Якщо для вас час — критична складова, то варто закінчити раніше, але тут дуже важлива форма відмови. Це треба зробити таким способом, щоб не знайти про себе і компанію допис на «відомому.it».

Як давати негативний фідбек за результатами співбесіди

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

Зазвичай у кінці інтерв’юер ввічливо каже кандидату, ще HR повернеться до нього / неї з фідбеком впродовж Х днів (важливо, щоб так це і відбулося), і передає відгук HR. А далі то вже їхня задача. Але!

Кандидат може запитати про фідбек наприкінці співбесіди, і тоді можна одразу сказати, що пішло не так, якщо кандидат не підходить. Або інтерв’юер розуміє, що сенсу продовжувати нема, тому закінчує раніше — це рішення потрібно обґрунтувати.

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

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

Скільки інтерв’юерів має бути на співбесіді

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

Чому не більше? Тому що це створює додатковий тиск на кандидата.

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

Чи треба давати тестове завдання перед співбесідою

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

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

По-друге, якщо мова про Senior і вище, то зазвичай такі люди не шукають роботу. І викликом може бути навіть спроба затягти його на HR-співбесіду, не кажучи вже про тестове.

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

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

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

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

Класична помилка на співбесіді автоматизатора

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

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

Тому важливо говорити на співбесіді автоматизатора саме про релевантні теми: як обрати тести для автоматизації, що треба і що не треба автоматизувати, як автоматизувати певний функціонал, які техніки тест-дизайну використати для певного кейсу, яка архітектура автоматизації була на минулому проєкті, які патерни використовув/ла, як проводили код-рев’ю, які ознаки смердючого коду (code smells).

Ну і точно не треба питати про роботу garbage collector, якщо проєкт не пов’язаний з його розробкою.

Порада менеджерам проєктів (де тільки планується автоматизація), яка збереже багацько грошей

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

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

Ціна помилки на початковому етапі занадто висока.

Практичні задачі на співбесіді

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

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

Якщо це мануальний тестувальник, можна задати умовний функціонал і запитати, як і в якому порядку він / вона буде тестувати і що саме перевіряти. Я якось давав саме для мануальників практичну задачу: є скрипт, який пропонує ввести пару inputs, і він видасть якийсь результат.

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

Але тут важливо зауважити, що в 99,99% випадків кандидат буде значно краще писати код і тестувати, коли ви на нього не дивитеся 🙂.

Менеджерські співбесіди: цілі, навіщо існують

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

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

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

Висновки

І на останок: кандидати, не бійтеся співбесід — це теж досвід, і що більше ви їх пройшли, то впевненіше будете почуватися наступного разу. Співбесіда — це гарна нагода знайти ерії для розвитку.

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

Дякую, що дочитали аж сюди, це дуже круто, я аж не очікував! 🙂

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Автоматизатор — це інженер, який повинен вміти писати код і тестувати. Тож тут має бути мікс скілів. Але дуже часто на співбесіді перевіряють тільки одну складову — або тестування, або програмування.

І це типу окей. Коли на умовну позицію SDET пропонують розповісти про умовні класи еквівалентності, але не задають жодного питання про ci/cd, докери, роботу з пайплайнами, то це дуже чудово описує рівень цієї вакансії. На мій погляд, сучасний автоматизатор/SDET має бути ближче до коду, ніж до тестування

Це не окей, якшо задача писати автотести, а не суто фреймфорки. Знову ж таки від задачі. Якшо на проєкті є девопс, який відповідає за всі пайплайни, то важливість цього на співбесіді зменшується. Та і в принципі сіайка — то не така складна історія, з якою не можна розібратися потім, якшо на цій людині не буде задача створити той пайплайн якого ще не існує. А ось фігачити 100500 умовних e2e тестів, які геть не енд ту ендні, а більше компонентні і робити ті пайплайни по декілька годин — ось це проблема. Коли тести є, але вони по суті не тестують функціонал — це проблема. Коли автоматизатор підходить до девелопера, питає шо він зробив і потім зверху цього робить автотест який успішно перевіряє шо бага там є і тест зелений тому шо девелопер не правильно поняв вимогу, а автоматизатор навіть не намагався дізнатися про вимоги — ось це проблема. Так, я код ставлю на перше місце, але якшо людина не розуміє в тестування — це неприємний флажочок.

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

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

— Щось дивне сталось з лінками в листах , комент більше не релевантний

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

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

Варто також зазначити такий момент. Загалом найняти треба спеціаліста, найкращого з наявних за умов, що він відповідає мінімальним, ні, не так, МІНІМАЛЬНИМ вимогам на проекті. Інший підхід можливий лише, якщо ви готові платити максимальну ціну на ринку (а здебільшого її платити не готові).

Стаття гарна, але в чому користь для кандидатів?

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

Точно, Геннадію!
Ви абсолютно праві і це інший аргумент, чому за 5 інтерв’ю найм можна заврешувати. Якщо вам на інтерв’ю рекрутери «постачають» не тих кандидатів, то тим паче нема сенсу витрачати ваш та їх час і перебирати людей з непідходящої когорти. Скоріше за все треба передивитись свій підхід (яку людину шукаємо, яку вакансію даємо, де даємо, як даємо, скільки платимо і т.д.). 5 інтерв’ю, то ще доволі консервативно. Зачасту наймаючий менеджер може зекономити собі час, глянувши на профілі кандидатів в пайплайні і визначитись чи воронка найму буде видавати йому потрібних кандидатів.
При цьому дуже розповсюджений інший кейс: «а от в минулій компанії я працював з людиною яка за зарплатню $1000 стільки всього вміла робити, а ці кандидати якісь нетямущі» або ще більш ймовірне «в нашій команді всі вміють робити і от це і от так, а ці кандидати не вміють, ну як ми їх можемо взяти», тобто порівнюють існуючих співробітників, пройшовших онбординг і адаптацію в компанії і проекті з кандидатами з ринку, які не мають контексту, або бракують певних знань, що можна опанувати за тижні, максимум місяці.

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

Як каже неповторний Сергій Немчинський «якщо ви знаєте 30% від того, що ви робиться на проекті, ви знаєте забагато і вам потрібно міняти роботу»

До айтішки я був рекрутером, в айтішці я був і в ролі технічного інтерв’юера і в ролі наймаючого менеджера. Якшо треба найняти джуна — то одна задача. Трейні я взяв з першої співбесіди. А от якшо треба синіор, то 5 співбесід звучить нереалістично. Принаймні з мого досвіду. І проблема не у вимогах чи рекрутерах. Звичайно не можна порівнювати вже існуючих інженерів з кандидатами і тим паче їх зарплати. Бо зп в більшій мірі залежить не від скілів, а від поточної ситуації на ринку. Я брав людину з меншим досвідом, з гіршими скілами на більшу зп ніж в мене вже була людина в команді і це нормально. Може не справедливо, але ми і так знаємо, шо живемо в несправедливому світі ) Проблема в тому, шо рекрутери не в змозі визначити де кандидат прибрехує. В резюме може бути все ну прям дуже айс, а на ділі там нічого нема і рекрутер не зможе цього визначити в більшості випадків. З досвіду спілкування з іншими менеджерами я в цьому не єдиноріг ) Резюмуючи — чим простіше задачі — тим легше знайти людину.

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

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

За завищені очікування згоден. В 99.9% випадків кандидат не буде відповідати всім очікуванням, тому треба визначити головне і плясати звідти і дивитися на скільки кандидат буде в змозі освоїти решту. Про зп не зовсім згоден. Та, воно погано, якшо так склалося, але часто бюджет на рейзи і найми — то 2 різних бюджети. Якшо відштовхуватися від цілей проєкту, а не від того як хочеться, то досить часто складається саме так.

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

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

Коменти для того і є ) Це очевидні ризики, на які дуже часто пофіг людям які дають гроші. Повірте, я все робив, щоб не втратити старих людей. Не одразу, але все вийшло. Але було не просто ) Тому та, ризики є, а життя не справедливе )

Сьогодні відмовив розумникам, які слали інвайт на 3-годинний лайв-кодинг:

Thank you for your interest in me for the Senior Frontend Developer position at EasySend.
Unfortunately, I will not be moving forward with your vacancy, but I appreciate your time and interest in me.

Кажуть у них там FE TL такий молодець, що відхиляє 90% кандидатів та за 5 місяців зміг наняти тільки двох х_х.

Не знаю шо там, але в теорії у них може бути шось занадто складне, тому такий ретельний відбір.

Та хай хоч 99,9% відхиляють там шукають по 5 років — не мої проблеми.
Добре що вавку в голові стало видно одразу і я на них витратив фактично тільки годину часу.

Може варто було поторгуватися?) Типу годинку — і досить

Я їм сказав що лайв-кодинг в Теслу був фактично 40 хвилин, бо перші 20 — це так, про все.
І натякнув що вони при цьому ні разу ні Тесла, щоб хотіти 3 години на один етап.

Три години із 10% вірогідністю отримати офер? Та вони по фулл рейту повинні за це платити.

Нафіга мені фулрейт. Фулрейт це коли найм на рік, на пару тисяч годин тотал.
А сидіти разово страждати 3 години я б білив десь х5, тобто щоб вийшло як 2 робочі дні, тобто десь 10% від місячної ЗП.

По-третє, якщо тестове велике та займає певний час, треба подумати над оплатою, щоб додати мотивації виконувати його

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

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

ну це теж не погано. Принаймні одразу зрозуміло, що йти до них не хочеться.

І на останок: кандидати, не бійтеся співбесід — це теж досвід,

Ось після цих слів я чомусь почав боятися співбесід

:)))

Коли мене питають про те, чого не знаю, я прямо легко кажу: «Цього не знаю». Потім спокійно сідаю, читаю, розбираюся. Взагалі спокійно.

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

Наприклад, нещодавно мене запитали про «фікстури». Я їх чудово знаю і вже багато-багато разів писала.
Але в останньому проекті ми не вживали слова «фікстури». Просто взагалі це слово не використовували. Ми говорили про precondition/postcondition.

Хвилин п’ять я згадувала, що таке фікстура.
Згадала. Але було соромно

Як давати негативний фідбек за результатами співбесіди

Найголовніше правило: фідбек треба давати завжди, і бажано із цим не затягувати

В Українському IT це скоріше виняток, ніж правило.

Мені незрозуміло, навіщо фідбек??? Відмова так, корисна — викреслюємо з листа. А що мені дасть фідбек???

Нормальний фідбек — це конструктивна критика відносно конкретного проєкту. Далі ви вирішуєте, чи хочете ви це покращити, чи воно вас влаштовує. Мені було б цікаво )

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

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

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

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

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

Фідбек корисний по тестовому завданню. Я такий отримував лише раз. При чому там був pdf на 3 сторінки із детальним розбором мого коду і списком літератури яку варто почитати. Аж захотілось запитати скільки я їм винен за таку роботу.
У інших випадках це скоріше — ну тут чувак із досвідом по більше і попросив по менше ... Тому не цікаво.

Чи треба давати тестове завдання перед співбесідою

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

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

От жеж, а як про мене, то мені краще fast fail, ніж оте ще 40 хвилин переливання.

Не вгадаєш, тут кожному своє. Рекрутерська практика — головне не образити)

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

Уікаво. Всі люди різні. На мою думку, смол ток принаймні не напружує ) Це ж розмова по душам, не про роботу. У американців то взагалі правило починати 1*1 зі смол токів.

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

Анекдот пригадався: ми повії, а не синоптики.

Мій бос-швейцарець свого часу голосно сміявся з моєї розповіді про те як мене самого в 2016 році на співбесіді на Senior .NET валили питанням, у чому принципова різниця між Mercurial i Git (до речі, досі не знаю, та і нецікаво, про ртутну VCS вже всі забули), а потім сказав, що швейцарський підхід полягає у пошуку сильних, а не слабких сторін кандидата.
Особисто я дуже люблю відкриті практичні питання, вони розкривають фахівця найкраще.

Ну... Якщо у тебе немає досвіду з hg або git, то питання виглядає дивним, людина не може стикатися з усім. Якщо завалювати, то у мене є гробік з бітовими операціями (ніби-то база), який я ніколи не використовував.

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

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

Ок, тоді лови гробік: напиши без циклів та умов (швидкодія), як з даного числа більшого за нуль отримати наступне число, у якому така ж сама кількість одиниць, як і у даного. Тобто 1 -> 2 -> 4 -> 8 -> 16 ... (один біт встановлено) 3 -> 5 -> 6-> 9 -> 10 -> 12 -> 17 (два біта) 7 -> 11 -> 13 -> 14 -> .. (три біта).

Взагалі, часто люди, які вважають, що добре працюють з бітовими масками, валяться навіть на примітивному x & (x-1) не кажучи про x & (-x).

Містику, де б я тебе ще зустрів :-)
Іншого б послав ;-)
Я Marser ;-)

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

... а послав би тому що я тобі про «знайти, що знає, а не те, що не знає», а ти мені завідомо навколоолімпіадну задачу.
Очевидно, я б її розв’язав, навіть якщо тупо брутфорсом через зсуви (>>, <<, або в нашій рідній мові то було shr, shl), але принципово не став навіть братися, бо це офтопік до сказаного мною.

Зсуви там використовуються, але не головне. Наскільки це олімпіадна задача? Не знаю, щоб її треба вміти не тільки встановити біт у масці, прочитати або скинути його. Там треба базова операція x & (-x). Але в принципі, навіть якщо прибрати умову відсутності циклів та умов, треба як мінімум придумати алгоритм отримання такого наступного числа.
Ось типовий перехід: 01011100 -> 01100011, та він не дуже й елементарний. Тепер треба зрозуміти алгоритм, яким чином переходити до наступного числа, які біти куди мають йти, які біти змінюються. Ну а далі вже легко.

А от коли я чую "я б її розв’язав але не буду цього робити... То це для мене виглядає як (1) велике ЧВП; (2) явна недооцінка складності завдання.

Ну а прикладне значення досить просте, наприклад у нас є 52-бітове число, по біту на кожну карту в колоді. Ми хочемо перебрати усі п’ятикарточні комбінації (тобто усі числа, в яких встановлено рівно п’ять біт).

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

Wishful thinking (в сенсі вірити в якийсь особливий раціональний швейцарський метод). Все залежить від людей, й одне з самих всратих інтерв’ю яке можу пригадати у мене було саме зі швейцарцями.

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

доречі а якщо хочете прочитати які питання задавати до самих інтервʼюерів то у мене теж тут статейка є dou.ua/forums/topic/41470

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

Інколи це також може бути цікаво: можна подивитися з якого боку буде підхід, як це співпадає з твоїм, ...

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

Згоден, але шанс, що людина піде в себе на співбесіді більше, ніж на проєкті. Через стрес і обмеженість в часі

Наскільки вище? Знову ж таки, це зайві ризики, чому б не обрати іншого?

Дуже вище на мою думку. Ну але якщо кандадтів аже нема куди складати, то можна мабуть і спробувати. Але знову ж таки, всі різні. Комусь це більше важливо від людини, комусь менш.

Гена бубочка, дал бы почитать non-QA специалистам как крик души куа команды 😁🤏

Гарна стаття! Дякую

Підписатись на коментарі