З яких етапів має складатися співбесіда. Поради з власного досвіду

Я — Senior Software Developer та Team Lead в компанії Edvantis. За 6 років кар’єри розробника я побував по обидва боки «барикад»: і був кандидатом, і проводив співбесіди на продукти, де працював. Також я брав участь у розробці внутрішнього інструменту для рекрутингу, де ми оптимізовували процес найму нових працівників Edvantis.

У кожної компанії чи продукту різна кількість кіл пекла етапів співбесіди, які потрібно пройти для отримання оферу. Спробую поділитися своїм досвідом на дуже популярну зараз тему співбесід. Зосереджуся на технічній частині і, сподіваюсь, допоможу як молодим спеціалістам-кандидатам, так і експертам, які тільки починають інтерв’ювати кандидатів.

Переважно на кандидата чекає наступний шлях: контакт з рекрутером -> скринінг -> HR-інтерв’ю -> технічне інтерв’ю -> спілкування з представником замовника чи PM-ом -> Feedback (як останній етап співбесіди або ж відповідь листом/дзвінком). На всіх цих етапах вас супроводжуватиме рекрутер та інформуватиме про статус кожного з них.

Щоб мінімізувати витрати і час на сам процес, співбесіду часто розбивають на етапи по ~30 хвилин. На кожному етапі присутня людина, яка відповідає за свою частину співбесіди і допускає кандидата до наступного кроку. Навіть довгу технічну співбесіду можна розбити на 2-3 кроки по 30 хвилин: перевірка тестового завдання, усне спілкування, Live Coding тощо.

Можна ж навпаки — провести все одразу. Я дуже люблю Hiring Days, де всі етапи співбесіди втиснуто в короткий проміжок часу, зазвичай від 3 до 5 годин. Під час перерв між етапами можна випити кави зі своїми майбутніми колегами, поспілкуватися про продукт, досвід.

Вперше я спробував себе в такому форматі, коли проходив співбесіду на продукт однієї з великих українських ІТ-компаній. І на кандидата, і на наймачів тисне час, і це максимально наближає до робочих буднів (де треба встигнути все «на зараз»). Крім того, такі співбесіди чудово структуровані, від кандидата вимагають тільки тих знань, які дійсно потрібні для конкретної посади. Рішення ухвалюється максимум того ж дня, якщо ж сторони не підійшли одна одній — то одразу. За ваш витрачений час часто дають винагороду, сертифікат на якусь атракцію, курси на Udemy чи похід в ресторан :)

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

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

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

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

Коли всім все підходить, запрошують на перше очне інтерв’ю (або ж призначають відеоконференцію). Це поглиблене знайомство двох сторін, яке триває до 30 хвилин часу. Обидві сторони повинні підготуватися і ознайомитися з усією наявною інформацією (Google, CV, LinkedIn вам в допомогу), скласти список питань, які цікавлять, і відповіді на які дозволили б рухатись далі. Тут HR-спеціаліст (чи рекрутер) розповідає про компанію і продукт, на який наймають, а кандидат ділиться всією інформацією, яка відсутня в резюме.

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

Для відсіювання, не варто починати ставити кандидату технічні питання або проводити «бліц-опитування» на тему ООП чи примітивів в TypeScript. Для цього є наступні етапи або окреме спілкування з технічним керівником.

Технічне інтерв’ю

Знайомство перед технічним інтерв’ю

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

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

Короткий опис продукту

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

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

Технічна частина

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

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

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

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

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

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

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

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

Live coding

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

Під час Live coding ви просто і швидко дізнаєтесь про стиль написання коду, навички володіння IDE, знання синтаксису мови програмування, алгоритмів, структур даних та методів/методик, які використовує розробник під час написання коду.

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

Спілкуйтеся з кандидатом, відповідайте на запитання, коментуйте кожну дію. Нехай це буде той самий pair-programming, де ви разом вирішуєте конкретну робочу задачу.

Про тестові завдання

Досить часто, аби відсіювати кандидатів, перед технічним інтерв’ю ще дають тестове завдання. Це поширена практика, передусім у великих західних компаніях, де без успішного проходження Leetcode-задачок кандидат не переходить до наступного етапу — живого спілкування. Я ставлюся до тестових завдань скоріше позитивно, ніж негативно. Особливо, якщо воно схоже на типову таску з беклогу проєкту.

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

Де б я не використовував тестове — то це під час найму на Lead або Senior позицію. Щоб перевірити досвід такого розробника, треба більш складне та обширне завдання, на яке звісно потрібно більше часу/сил і тут (коли в Linkedin можна вибирати з-поміж кількох пропозицій) не всі готові погоджуватися на тестове завдання.

Найчастіше роботу над тестовим завданням (як і повсякденну роботу) потрібно винагороджувати. Якщо результат незадовільний — зробіть короткий code review і поділіться своїм відгуком/порадами з кандидатом.

Про PET-проєкти

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

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

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

Спілкування з замовником

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

Цей етап часто містить елементи «Culture fit», тут дізнаються цінності кандидата, і те, чи збігаються вони з цінностями компанії.

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

Feedback обох сторін

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

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

Висновок і поради

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

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

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

Насамкінець підсумую і залишу декілька порад для кандидатів:

  • Оновіть своє резюме, опишіть свій досвід, приберіть все зайве і пункти, на які б ви не могли відповісти під час інтерв’ю.
  • Дізнайтеся деталі про компанію і продукт до того, як почнете спілкування. Це можe бути Linkedin, сам сайт компанії, сторінка в соцмережах, статті про компанію в онлайн-виданнях, відгуки (навіть на «всім відомому ресурсі»). Інформацію про міжнародні компанії, стартапи чи робочі продукти можна знайти на ресурсах на кшталт Glassdoor.com. Якщо серед ваших друзів є ті, хто працював чи працює в компанії, запитайте про їхній досвід, що їм подобається і не подобається в компанії, як вони туди потрапили.
  • Через хвилювання ви можете забути поставити якесь запитання, тому підготуйте їх окремо і поверніться до них наприкінці співбесіди.
  • Попрактикуйтеся відповідати на прості питання щодо мов та інструментів, які ви знаєте (в мережі є багато платформ для перевірки знань).
  • Попрактикуйтеся в навичках з програмування, розвʼязуйте алгоритмічні задачки на codewars.com чи leetcode.com. Якщо ви помітили, що вам тяжко даються деякі алгоритми чи структури даних — саме час підтягнути ці знання.
  • Запитуйте і уточнюйте всі незрозумілі моменти. Ви виглядатимете не як студент, якому щось незрозуміло, а як спеціаліст, який збирає інформацію і поглиблено цікавиться темою.
  • Завжди давайте ґрунтовну відповідь, покликаючись на те, як це працює, і як краще використовувати на практиці.
  • Будьте чесними. Обманюючи на співбесіді, ви витрачаєте не тільки свій час, а й час інших людей. Якщо таким чином ви і пройдете співбесіду, то ймовірно не пройдете випробувальний період.
  • Якщо чогось не знаєте, не соромтесь це визнавати. Ви можете знайти відповідь разом з інтервʼюером.
  • Уявляйте, що ви вже працюєте у цій компанії. Спілкуйтеся з працівниками компанії, як зі своїми колегами.

Також з власного досвіду можу дати кілька порад інтервʼюерам:

  • Підготуйте кандидата до співбесіди. Поділіться з ним інформацією про всі етапи, які знання перевірятимуть, і хто буде присутнім.
  • Ознайомтесь з резюме кандидата заздалегідь і виокреміть ті моменти, які вам, як майбутньому керівнику, було б цікаво дізнатися. Спілкуйтеся тільки про той досвід, який буде корисним на вакантній посаді.
  • Починайте з легших питань і піднімайте складність по ситуації.
  • Не питайте в Junior-розробників, що зашифровано в абревіатурі SOLID, і що це означає.
  • Якщо кандидату складно відповідати, підштовхуйте його до правильної відповіді уточнюючими запитаннями, або разом розмірковуйте про можливі рішення.
  • Підготуйте кілька завдань для Live Coding, щоб дати конкретне вже за результатом усної частини технічної співбесіди. Завдання мають бути близькими до тих, що зустрічаються у вас на проєкті, і часу на їх виконання має бути не більше 20-30 хвилин.
  • Під час співбесіди звертайте увагу на неточні відповіді кандидата. В кінці ви зможете дати feedback та поділитися своїми порадами для поглиблення знань.
👍ПодобаєтьсяСподобалось5
До обраногоВ обраному4
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
Наприклад, якщо кандидат приїхав до вашого офісу на електросамокаті (або ж на відео в Гугл-мітс на фоні видно крутий велосипед), можна разом обговорити велоінфраструктуру міста

Это тот смолл ток на котором горит жопа?)
Так как вело инфра город(а/ов) Украины только такие эмоции вызывает)

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

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

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

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

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

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

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

під час стендапу
згадується
блокер

Та то такой себе «блокер» если о нем «вспоминают» только на стендапе ))

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

№ 1 як уже доречно зауважили «блокер» не має «згадуватися» лише на стендапі а рівно у момент коли він узагалі виникає

№ 2 вирішенням «блокерів» займаються 3 людини № 1 той кого це «блокує» № 2 той хто на цьому знається № 3 той хто поставлений на цей спринт «рішать блокери»

пыщЪ і на справді немає там ні яких таких «принципивих питань ініціативності команди» )) просто бізнес

— Ще колись вже на моїй співбесіді мене запитали, як саме я б звільняв свого колегу у разі поганого перформансу.

youtu.be/VcSEjG7hq10

знову же ж таки питання просте і вирішується просто наявністю спеціально навчених людей які саме цим і займаються «як саме звільнити колегу»

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

знову же ж таки хто я ванчє такий шоп такою єрундою займатися? у вас (тут узагальненя) є спеціально навчені люди єйчар відділу треновані в університеті на психіатрів чи шо вони там як з людями розбиратися я лише маю зарепортити «тута чойта чувак погано перформить хотя так вапчє годний чувак може у нього проблеми порішайте то є мені дякую за співпрацю»

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

правильна відповідь у тому що юрба якогось лівого народу займаються не своїми справами в той час як робити справу та роботу тупо нікому )) найпростіша відповідь і є «правильною» згідно тов. окама

Вы явно замечтались, такое бывает, ничего страшного.

В условиях перегретого рынка, можно вообще без собесов людей набирать, но вдруг не смогут перформить на заявленный уровень. Единственная функция собеса сейчас — проверить, не нап****ел ли кандидат в резюме.

Да все наё в резюме, норм компании сейчас офер присылают в течении 3 дней после 2 этапов
А потом смотрят на испыталке

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

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

Испыталку для того и придумали чтоб не краснеть

«испытательный срок» у фопа это высер украинских галер, чтоб на его время не платить бонусы, бОльшую зарплату, не пускать в отпуск до окончания срока, не давать страховку и плюшки

Сейчас испыталку это больше дата когда тебе проводят ревью и решают останешся в или нет

Ты себя хорошо чувствуешь? Когда я выкидываю резюме на джини то это 150 запросов. Обычно принимаю первые 10 и с них получаю 4-5 оферов. Остальным даже не отвечаю. Такие как ты сразу идут в баню.

Эх, вы давно нанимали? :) Сейчас за такой план работ вас рекрутер забьет насмерть подсвечником. Мы даже для QA упростили собесы, хотя раньше давали заградительные тестовые задания, чтоб половину кандидатов отсеить.

короткий челендж (на кшталт задачок з Codewars) на 5-10 хвилин

Можно тут конкретнее, что этот челендж проверит?
— Умение разбираться в легаси?
— Умение писать адаптивный код?
— Подход к покрытию тестами?
— Умение в анализ нагрузок?
— Правильное покрытие логами/метриками?
— Умение в no-BC?
— Умение в поиск багов?

— Подход к покрытию тестами?

this (only this :) )

Можно тут конкретнее, что этот челендж проверит?

Власне правильна задача — це якраз відправна точка для технічної співбесіди. Але тут важливо:
— вона має бути на початку
— вона не має вибивати кандидатів з колії (як це часто роблять «задачки з літкоду»)

Нууу... day2day activity включает в себя много всего, я слабо представляю себе задачку, которая влазя в адекватные временные рамки могла бы покрыть все или хотя бы 50%+. А узкая задачка может попасть в слабое место кандидата и мы будем оценивать рыбу по умению лазать по деревьям. Или наоборот.

С другой стороны — если у вас этот подход работает и кандидаты хороши — то почему бы и нет? :)

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

Без обид, но нафига этот цирк если можно за день пройти четыре собеседования и получить два оффера уже на следующий день?

Вы наверное платите x2 от рынка, иначе нет смысла тратить время

Володимире, дякую за коментар! Не сумніваюсь, що з таким досвідом як у вас можна пройти 4 співбесіди за день :) Я коли писав навіть неявно пригадав одну з ваших статей.

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

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

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

Ваша стаття — це набір фантазій (в принципі можете використовувати слово «допис»). Поради мають вирішувати якусь проблему. Ваші ж «поради» не лише не зрозуміло що вирішують, а й створюють купу проблем (див тестове чи поради по підбору задачок для лайфкодінга)

Власне ментальна проблема описана у висновку:

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

Це поради з позиції «кандидату потрібна робота, а компанія буде обирати». На розігрітому ринку реакція на такі співбесіди буде як вован описав вище.

Стратегічна порада:
Пробуйте вибудовувати партнерські стосунки з іншою стороною переговорів, розумійте в чому інтерес іншої сторони та пробуйте допомогти їй. Це порада як компаніям так і кандидатам.

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

И потом плачут: айяйяй, почему это мы не можем никого найти?

А потом западная компания с такими процессами идёт нанимать людей в аутсорс))) где за 3 дня чик чик и взяли человека

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

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

Є таке... Тестове у наших краях найкраще підходить для Junior-Middle, кількість відгуків на вакансію яких більша і є потреба у такому додатковому кроці.

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

Під час Live coding ви просто і швидко дізнаєтесь

Фейспалм. Далі можна не читати.

То есть «6 лет и оппа Тимлид» — Вас не смутило, и Вы продолжили читать дальше?

А по-твоему за 6 лет люди превращаются в чудесников-волшебников-телепатов? Сам-то понимаешь, что сравнивать будет человек с опытом В СВОЕЙ настроенной системе работу ДРУГОГО человека, с другими настройками.

Если бы в киберспорте были такие же правила, как в рекрутинге, мыла из судей наварили бы на годы вперёд.

Дякую, що дочитали аж до половини!

Не думав що саме ця частина викликала б в когось фейспалм, оскільки це працює майже завжди і для розробників будь-якого рівня. Я звісно ж можу частково помилятися, бо тільки «6 років і оппа Тімлід» (насправді лідити я почав ще на третій рік) :)

Тебя не лидить поставили, а быть цапом видбувайлом

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