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

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Всім привіт! Мене звати Микола, я FE (Angular) Team Lead у Customertimes Ukraine. Загалом працюю в IT більше шести років. До того працював майже шість років як інженер-менеджер (комбінована посада технічного спеціаліста та менеджера з продажів).

Сьогодні я б хотів поділитися зі спільнотою власним досвідом проведення технічних інтерв’ю. Хочу наголосити, що це мій персональний досвід, націлений на допомогу технічним спеціалістам (розробникам, QA, DevOps, Team/Tech Lead, архітекторам) та всім, хто проводить технічні співбесіди.

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

Що ж, почнімо!


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

Етапи:

  1. Підготовка технічних вимог до кандидата.
  2. Розгляд кандидата та озвучення умов співбесіди. Побажання до співбесіди.
  3. Із чого почати? Перші питання. Зміст співбесіди.
  4. Співбесіда.
  5. Відповіді на запитання.
  6. Поділіться враженнями (за вашим бажанням чи бажанням кандидата).
  7. Фідбек про кандидата

Підготовка технічних вимог до кандидата


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

Раджу обов’язково зазначити всі технічні вимоги та технології, знання яких знадобляться на проєкті. Також не забудьте про секцію Will be a plus. Оскільки я FE Developer, то опишу з боку фронтенду приклад того, як може виглядати вакансія Angular Developer.

Requirements (вимоги):

  • 2+ years of commercial experience with Angular (2+) — Тут ми зазначаємо, який саме досвід роботи з Angular ми б хотіли бачити у кандидата.
  • 3+ years of commercial experience with Javascript/Typescript — Який саме досвід роботи з JS ми б хотіли бачити.
  • Knowledge of SASS/CSS — Необхідні знання препроцесорів/технології.
  • Comfortable usage of npm — Гарний досвід роботи з npm.
  • Experience working in SCRUM teams — Досвід роботи у SCRUM-командах.
  • Experience with git based code versioning platforms (Gitlab, Github, Bitbucket тощо) — Досвід роботи з Git (так, окрім Git є й інші технології, наприклад, SVN).
  • Ability to communicate in English (B1/B2 тощо) — Певний рівень володіння англійською за необхідності.

Technologies (технології, які необхідні для роботи на проєкті):

  • Angular 2+;
  • TypeScript;
  • RxJS;
  • CSS3, SASS (SCSS), HTML5.

Will be a plus (які знання стануть плюсом для компанії під час вибору кандидата; ці технології зазначені опціонально).

  • Experience with PWA;
  • Experience with IndexedDB;
  • Angular Material;
  • Experience with Ionic.

Нумо розбиратися, що і навіщо ми тут описали.

  1. Requirements — вимоги до кандидата. Це, можна сказати, лінія відсіву. Утім це не означає, що вам потрібно відкидати кандидатів, у котрих, наприклад, є 2,5 роки досвіду з JS (коли нам потрібно 3 роки). Багато розробників самокритичні та за вимогами відчувають, наскільки можуть підійти до цієї вакансії. Бо спеціаліст може бути впевненим у своїх знаннях і хотіти спробувати себе на цю вакансію.
  2. Technologies — технології, які використовуються на проєкті
  3. Will be a plus — секція, у якій ви хочете зазначити, що було б плюсом для кандидата на цю вакансію для вашої компанії. Наприклад, у вас на проєкті використовується Angular Material, але ви вважаєте, що з ним можна досить швидко розібратися за необхідності.
    Або ж, припустимо, у вас налаштований PWA-застосунок, і єдине, що потрібно зробити зі сторони PWA новому спеціалісту — тільки продовжувати вже закладений підхід.
    Чи, наприклад, у вашій компанії, окрім цього проєкту, є декілька проєктів на Ionic. І потенційно ви хочете застрахуватися: якщо проєкт закриють або спеціаліст захоче змінити його, або ж спеціаліста дропнуть з проєкту (у мене був досвід, коли замовник дропав FE-розробника з проєкту через те, що той не міг пофіксити DevOps баг), то завжди можна знайти альтернативу.

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

Важливо! Не ставте занадто вибагливі вимоги до вакансії, якщо немає такої потреби! Якщо ви шукаєте, наприклад, Middle FE розробника, не треба писати «Десять років досвіду, знання всіх можливих фреймворків та/або DevOps, BE тощо».

Вимоги повинні бути обґрунтовані та змістовні. Завищеними вимогами можна просто відсіяти велику частину потенційних кандидатів.

Розгляд кандидата та озвучення умов співбесіди. Побажання до співбесіди


Цей етап я розбив на два підетапи, де перший — це розгляд кандидата, а другий — побажання до співбесіди.

Розгляд резюме кандидата

Це дуже важливий і цікавий пункт. На що, перш за все, треба звернути увагу?

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

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

Буває в людини два роки досвіду, а список технологій такий, що може позаздрити Senior з десятирічним досвідом, який побував на багатьох проєктах (тут мене можуть зацькувати трохи, але я не вважаю, що спеціаліст з Angular, що подивився двотижневі відеоуроки з React, має додавати React у резюме).

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

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

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

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

  1. Чи вчиться спеціаліст? Як комбінує навчання і роботу? Останнім часом люди досить рано поєднують повноцінну роботу з денним/вечірнім навчанням (заочно не враховуємо) і вказують у резюме робочий досвід.
    Наприклад, спеціаліст вчиться на третьому курсі денної форми навчання у виші, працює з першого курсу, комбінуючи навчання, роботу та розваги, водночас зазначає у резюме: «три роки досвіду роботи» та кидає резюме на вакансію Middle+ to Senior.
    Я в жодному разі не хочу образити студентів, а також не чіпаю останні курси навчання, де в рази більше вільного часу. Але з мого досвіду скажу: у багатьох випадках студент денної/вечірньої форми навчання поступатиметься людині, яка ці три роки була зосереджена саме на роботі, через те, що в останньої просто більше вільного часу. Тож вона могла спокійно концентруватися на восьмигодинному робочому дні та навіть більше.
  2. Де вчиться спеціаліст? Наприклад, я навчався у КПІ і зазвичай з майже всіма випускниками КПІ дуже легко знаходжу спільну мову. Це не означає, що треба шукати саме кпішника чи випускника будь-якого іншого ВНЗ. Але якщо людина закінчила факультет TikTok у певному виші або ж закінчила ІПСА у КПІ, повірте, ви відчуєте різницю.
  3. Профільна освіта. На кого вчиться чи вчився спеціаліст, чи є в нього профільна освіта чи немає (у мене самого, до речі, освіта не профільна для IT).

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

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

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

Побажання до співбесіди

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

Мої стандартні запити:

  • Кандидат та всі інтерв’юери повинні бути з увімкненими камерами (далі поясню чому).
  • Тривалість інтерв’ю — дві години (далі зрозумієте чому).
  • Певний проміжок часу, коли мені зручно, наприклад, на 9:00 або з 12:00 до 18:00. Це не означає, що якщо кандидат може лише після 18:00, то ви повинні відмовитись від проведення інтерв’ю. Індивідуальний підхід ніхто не скасовував.

Навіщо це потрібно? Усе просто: кандидат повинен знати, чого очікувати.

А тепер пройдімось кожним пунктом.

Кандидат та всі інтерв’юери повинні бути з увімкненими камерами.

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

Це — важливий аспект з багатьох причин:

  1. Невербальне спілкування. Усі ми більш-менш легко зчитуємо такі емоції, як-от злість, гнів, радість, здивування і так далі. Це потрібно, перш за все, аби зрозуміти, у якому емоційному стані перебуває людина під час інтерв’ю.
  2. Зоровий контакт. Він дає можливість тримати увагу людини, показати свою зацікавленість у відповіді та може підказати, коли людина каже неправду. Тут важливо самостійно підібрати тривалість і регулярність цього контакту.
  3. Можливість відносного контролю. Під час співбесіди бувають випадки, коли вам потрібно перебити людину та поставити уточнювальне запитання. Чи, наприклад, сказати, що цієї відповіді більш ніж достатньо. На жаль, трапляються і випадки, коли під час співбесіди люди починаються гуглити, читати відповіді з попередньо заготовлених матеріалів або ж використовують ChatGPT.

Певний проміжок часу, коли вам зручно провести співбесіду.

Під час розмови з кандидатом вам має бути комфортно.

  1. Не ставте собі інтервʼю у завантажений день або впритул до важливої події, адже це змусить вас поспішати чи/та хвилюватися. Те, що ви проведете співбесіду не сьогодні, а, наприклад, завтра, переважно ніяк не вплине на результат.
  2. Перенесення інтервʼю. Якщо з якоїсь важливої причини ви не зможете бути зосередженим на раніше запланованому інтервʼю чи у вас не буде вільного часу в цей день, попросіть рекрутера перенести співбесіду на інший зручний для вас і кандидата день. Краще перенести співбесіду, ніж отримати неповноцінний результат.
  3. Не ставте собі по п’ять співбесід на день. Ви не T-1000, і з кожною наступною співбесідою потроху втомлюватиметесь. Можливо, ви не так сильно виснажитесь фізично, але емоційно — точно. Звертати увагу на важливі деталі буде все складніше і складніше.
    Знайдіть свою максимальну кількість співбесід на день без втрати якості й не погоджуйтесь на більше. Мій особистий максимум зі співбесід на день — дві зустрічі. А пауза між співбесідами надасть необхідний час емоційно відпочити та сформулювати своє враження про кандидата в письмовій формі.

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

Намагайтесь підібрати час співбесіди максимально комфортний для вас і для кандидата. Якщо кандидат може зустрітись лише о 20:00 щодня, це не означає, що ви повинні відмовити. Підберіть собі день, коли ви зможете провести співбесіду о 20:00. Якщо ж такого часу немає, попросіть рекрутера, щоб інший спеціаліст з вашої компанії провів співбесіду.

Із чого почати? Перші питання. Зміст співбесіди


Нарешті ми дійшли до процесу інтервʼю. Початковий етап, який у мене зазвичай займає 20 хвилин, складається з таких кроків:

  1. Про пунктуальність.
  2. Етап привітання та самопрезентації.
  3. Питання про попередній досвід.
  4. Спілкування щодо відповідей кандидата або пунктів у резюме.
  5. Зміст співбесіди.
  6. Про табу. Що заборонено на співбесіді.

Про пунктуальність.

Перше, що ви повинні зробити — це не запізнюватись на інтервʼю.

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

Якщо кандидат не попередив і запізнився на 15-20 хвилин без пояснень, тоді це може стати червоним прапорцем для вас.


Етап привітання та самопрезентації. Десь до п’яти хвилин.

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

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

  1. Як мене звати та чим займаюсь у компанії та на проєкті.
  2. Скільки в мене років досвіду та з якими технологіями та фреймворками я працював.
  3. Із чим працював найбільше і з чим подобається працювати.

Умовно це виглядає так: «Привіт! Мене звати Микола, я FE Team Lead у компанії та на проєкті. Загалом працюю в IT вже майже сім років. За цей час працював на різних проєктах з різними технологіями та фреймворками: Angular, Vue.js, трохи React, Ionic, був досвід з PWA-застосунком. Саме з Angular працюю вже шість років. Трохи працював з BE, а саме — з Node.js на Express. Дуже люблю TypesScript та RxJS».

Далі слово передається іншим інтерв’юерам, якщо вони присутні на мітингу.

Навіщо це? По-перше, ми хочемо налагодити звʼязок і починаємо перші, щоб кандидат трохи адаптувався і зрозумів, що процес співбесіди пішов і що він не на допиті. По-друге, ми показуємо приклад, у якому форматі ми хочемо почути від кандидата його самопрезентацію.


Питання про попередній досвід. Орієнтовний час: десять хвилин.

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

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


Спілкування щодо відповідей кандидата або пунктів у резюме (п’ять — десять хвилин).

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

Зачепіть тему, віддалену від співбесіди, щоб остаточно перевести інтервʼю у формат бесіди.


Зміст співбесіди. Орієнтовний час: одна — дві хвилини.

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

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

Як це зазвичай виглядає? Наведу приклад озвучення змісту співбесіди на позицію Angular-розробника:

«Перед початком технічної частини я б хотів тобі розказати, про що ми поговоримо, а саме: HTML, CSS, основні поняття (SOLID, Patterns і так далі), Network, Git, JavaScript, Angular, RxJS. Будуть питання різного плану: як легкі, що викликають посмішку, так і складні, де доведеться подумати трохи довше.

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

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

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

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


Про табу. Що заборонено на співбесіді.

Заборонено:

  • Політика. У жодному разі не чіпайте тему політики. Шанс, що ваші погляди співпадуть, невеликі. А емоції можуть вплинути на результат. Єдине, на чому ви можете погодитись — це те, що «**бана усня — справді **бана».
  • Релігія. Те саме правило, що і з політикою.
  • Сміятися з відповідей кандидата. Я думаю, тут не потрібно щось пояснювати.
  • Принижувати чи дорікати кандидату через незнання чогось.
  • Ставити себе вище іншої людини чи відповідати зверхньо.

Висновок: не запізнюйтесь. Запитайте, чи не проти кандидат спілкуватися на «ти», якщо вам так зручніше. Розкажіть про себе першим. Поставте декілька запитань про попередній досвід кандидата. Поспілкуйтесь на віддалену тему. Розкажіть кандидату про зміст співбесіди.

Середній час на вступну частину перед початком технічної співбесіди: 15-20 хвилин. Цього часу достатньо, щоб кандидат звик до вас і почав трохи розкриватися.

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

Співбесіда


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

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

Це не значить, що ви повинні починати питання з «Що таке HTML/CSS/JS?». Ви повинні починати із запитань, які нададуть розуміння про його знання.

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

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


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

Тобто ми можемо говорити про CSS, а потім різко запитати: «А що таке SOLID?». У цей момент людина може замислитись і подумати, що це якийсь новий фреймворк у CSS. Або ж перепитати, що ви саме маєте на увазі під SOLID.

Та якщо ви поговорили про CSS, а потім сказали, що тепер переходимо до основних понять і ставите запитання з SOLID, кандидат набагато краще зрозуміє запитання.


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

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

Наприклад, я якось проводив інтервʼю з кандидатом, у якого було 12 років досвіду і на кожне моє запитання він відповідав: «Я точно не знаю, але...» — а після слова «але» я чув абсолютно правильну відповідь.


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

Краще замінити вирази на помʼякшену форму (уточнення): «Не зовсім так», «Трохи не туди», «Так, але я б трохи конкретизував» тощо. Навіщо це робити? Щоб не збивати людину з думок, не заганяти в стрес, підтримувати дружній та екологічний діалог.

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

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


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

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

Крім того, людині треба обовʼязково залишити щось для самостійного пропрацювання, бо яка тоді користь від співбесіди?


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

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

Приклад: RegExp. Низький уклін усім, хто може написати його самостійно (до речі, я ніколи таке і не питаю).

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

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


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

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

Були навіть випадки, коли люди приймали офер, приходили на проєкт і я їх просив реалізувати їхні думки, про які запитував до цього на інтервʼю 🙂


Чи треба продовжувати, якщо кандидат відповідає добре. Якщо ви бачите, що кандидат дуже добре почав і вже 20-30 хвилин основної частини співбесіди те і робить, що дуже добре відповідає на всі ваші запитання, постає питання: «А чи треба продовжувати?» Так, треба! І на це є багато причин.

  1. Кандидат може чудово знати якісь ази, але може не знати основної мови програмування чи/та фреймворку, який вас цікавить. Наприклад, якщо до вас на співбесіду прийде верстальник на позицію Angular Developer, він чудово відповідатиме на питання HTML, CSS, Git, Network. А на рівні JS може відповідати гірше. Коли ж ви перейдете до фреймворків, то, скоріше за все, вже майже нічого не почуєте у відповідь.
  2. Співбесіда — момент, до якого люди зазвичай готуються і справді очікують його. І якщо ваша співбесіда пройде досить швидко, людина може не відчути того ефекту, на який розраховувала. Це може вплинути на вибір кандидата, коли в нього буде декілька офферів на руках.
    Пройшовши через повноцінне інтервʼю, кандидат відчує, як усі його знаннях були задіяні та відчує приємну втому. Він розумітиме, де відповідав добре, а які знання треба підтягнути. І це той ефект, який переважно ми хочемо отримати.
  3. Співбесіда може стати памʼятною для людини. За весь свій досвід проведення інтервʼю, я багато разів чув слова вдячності від людей, котрих ми потім наймали і навіть не наймали! Ні, я не збираюсь тут хизуватися, я лише хочу підкреслити, що гарну співбесіду людина запамʼятає (у хорошому сенсі).
    Бували і випадки, коли люди переймали нашу практику проведення співбесід та імплементували її під час проведення інтерв’ю у своїх компаніях.

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

  1. Зазвичай ви є останньою брамою у компанію і від того, як ви проведете співбесіду, залежить фінальне рішення кандидата. Навіть якщо зараз кандидат не підходить через якісь критерії на конкретний проєкт чи у компанію, це не значить, що у компанії не з’явиться з часом проєкт для цієї людини. За рік кандидат може прокачати власні скіли та знову прийти до вас на співбесіду.
  2. Людський фактор та репутація компанії. Якщо ви домовились, що співбесіда може бути до двох годин, а через 30 хвилин плануєте її завершити, кандидат може образитись та почати всім розповідати, як безвідповідально ви та ваша компанія ставитеся до проведення співбесіди. І всюди, де зможе, залишить негативні відгуки. За правильного (людського) підходу таких ситуацій не має виникати.

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

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

Наприклад, під час інтервʼю, коли кандидат відповідає достатньо добре й ми перейшли до теми JS, після декількох питань я люблю спитати: «Вгадай, яке буде наступне запитання?». Зазвичай подальший діалог виглядає наступним чином: «Event loop? — Event loop!» (відсилка на серіал Family Guy та Butt Scratcher!).

Інколи, коли кандидат дуже добре відповідає на питання і ми переходимо до нової теми, я можу сказати: «Я навіть не знаю, що тебе тут краще запитати. Можливо, сам щось розкажеш за Angular?».

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


Що робити, якщо кандидат відповідає не за досвідом. У мене неодноразово були випадки, коли кандидати з 1,5-2,5 роками досвіду відповідали як Senior і навіть краще.

У таких ситуаціях не соромтесь спитати: «Підкажи, будь ласка, у тебе X років досвіду, а ти відповідаєш як Senior-розробник. У чому твій секрет?». Це нормальне запитання. Бо у майже всіх випадках, котрі у мене були, це були не вундеркінди, і я думаю, у вас буде те саме.


Зазвичай відповіді досить прості:

  • Я зараз шукаю роботу, і це вже 5-10 інтервʼю для мене.
  • Я провожу співбесіди в себе в компанії.
  • Я дуже люблю теорію і багато читаю статей/книжок.
  • Ніякого секрету, це просто те, що я знаю.

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

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

Якщо ж людина не може пояснити, у чому її секрет знань, я бракую кандидата після співбесіди. Можливо, ви спитаєте: чому? Що тут поганого, якщо людина не може пояснити, чому знає такі деталі, які знають далеко не всі люди з досвідом 5+ років?

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

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

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


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

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

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

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


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

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

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


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

На цьому етапі ви мене запитаєте: а де тут дві години? А вони заховані у всьому, що описано вище. Вступ у середньому займає 20 хвилин, десь до півтори години піде на основну частину, останні десять хвилин — відповіді на запитання.


Стосовно моїх запитань: зазвичай так виглядає інтервʼю, яке я провожу для Angular-розробників (звісно, є різниця між підходом до Junior та Senior, але основна концепція зберігається):

  • HTML — не більше п’яти хвилин.
  • CSS — десь 10-15 хвилин.
  • Основні поняття (функціональне та об’єктно-орієнтоване програмування, SOLID, Patterns і так далі) — до десяти хвилин.
  • Network — п’ять хвилин.
  • Git — п’ять — десять хвилин.
  • JavaScript — 15 хвилин.
  • Angular — 25-30 хвилин (ще, за бажання, десь тут може бути захований TypeScript).
  • RxJS — 10 хвилин.

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

Забігаючи наперед, відповім: а чи потрібно питати у Senior-розробника про HTML або типи даних у JS? Потрібно! З роками досвіду певна інформація забувається, а особливо та, яка нечасто використовується. Тож навіть досвідчені люди починають ускладнювати відповіді (а потім і свій код).

У мене був кейс, коли людина забула/не знала про наявність певного функціонала і написала 100 рядків коду для вирішення задачі. На етапі код-рев’ю я звернув на це увагу, й ми замінили 100 рядків на один RxJS-оператор (один рядок).

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

Рекомендації тим, хто проводить технічні співбесіди

  1. Не нервуйте. Навіть якщо маєте два роки досвіду, а вас просять провести співбесіду людині, у якої більше десяти. Це був мій кейс, і я дуже сильно хвилювався. Якщо чесно, я думав, мене розірвуть за перші декілька хвилин, але так склалося, що людина не могла відповісти на багато моїх запитань.
    І я дуже сильно хвилювався через те, що це з моїми запитаннями щось не так. Але наступного дня в мене був інший кандидат, у якого було трохи більше двох років досвіду, і він спокійно відповів на всі мої запитання. Через рік я зустрівся з першим кандидатом.
    За цей рік я провів десятки співбесід, уже був більш досвідчени, і мої питання були перевірені часом. І ви не повірите, але результат був той самий. Тому не нервуйте, у вас все чудово вийде, просто поводьте себе впевнено.
  2. Контролюйте свої емоції. Не дозволяйте емоціям брати верх, якщо кандидат веде себе зверхньо стосовно вас. Можливо, це просто така людина, а можливо, це його самозахист, щоб не дати себе зачепити. Якщо кандидат чогось не знає, це абсолютно нормально, і також не повинно викликати у вас негативні емоції, навіть якщо всі інші відповідають.
  3. Будьте відкритими до чогось нового. Не треба сперечатися з кандидатом, якщо він розповів вам те, чого ви не знали. Або якщо у відповіді виправив вас. Це абсолютно нормально, жодна людина не знає все на світі.
  4. Кандидат може бути сильніший за вас. Це нормальна практика. Дуже вас прошу не думати, що цей кандидат може вас замінити, тому що він скіловіший за вас, і через це ви вирішите його реджекнути. У мене неодноразово були випадки, коли такі люди були в мене в підпорядкуванні на проєкті. Навіть коли у мене було три — чотири роки досвіду, а у хлопців — по шість — сім.
  5. Доводьте співбесіду до логічного кінця. Навіть якщо кандидат не дотягує до вакансії, проведіть повноцінну співбесіду. Хай у кандидата залишаться позитивні враження про вас і компанію. І коли він прокачає свої навички, він може знову прийти до вас на співбесіду.
  6. Вчіть колег, які можуть замінити вас на наступних інтерв’ю. Якщо ви єдиний спеціаліст, який вміє проводити співбесіди, беріть із собою когось з колег (це цікава тема, і я мабуть опишу її в окремій статті). Бажано — не більше одного (мається на увазі на співбесіду). Навіщо? Ви захочете піти у відпустку, захворієте чи не зможете провести співбесіду, а у вас буде заміна.
  7. Будьте людиною! Це, мабуть, найважливіший пункт серед всього, що написано:
  • не поводьте себе як робот;
  • не відповідайте заїждженими фразами типу «політика компанії»;
  • не влаштовуйте допит кандидату питання за питаннями.

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

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

Відповіді на запитання


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

Не потрібно фантазувати там, де ви цього не знаєте, попросіть рекрутера допомогти із цим питанням.

Зазвичай найтиповіші запитання такі:

  • Яка команда на проєкті?
  • Що знаєте про проєкт?
  • Чи є пряме спілкування з замовником?
  • Як давно працюєте у компанії і чи подобається?
  • На що потрібно звернути увагу?

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

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

Поділіться враженнями

Якщо у вас одразу склалася картинка про кандидата, ви можете поділитися зворотним зв’язком з ним/нею. Я, наприклад, люблю ділитися позитивним фідбеком. Якщо кандидат мені дуже сподобався, я можу одразу поділитися своїми враженнями.

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

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

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

Фідбек про кандидата


Що у цьому розділі мається на увазі під висловлюванням «фідбек про кандидата»? Це фідбек, котрий ви надаєте компанії про ваші враження та вашу оцінку знань кандидата.

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

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

Фідбек сильно відрізняється від компанії і залежить від багатьох змінних, як-от: наявність певних інструментів у компанії, опитувальники, форми зворотного звʼязку і так далі.

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

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

Кілька прикладів:

Приклад 1. «Загальне враження доволі хороше. Відповідав швидко та чітко, без зайвого затягування часу. Є деякі прогалини в знаннях, але не критичні. Також перевіряли знання, пов’язані з Angular та RxJS, загалом — все добре. Рекомендую до розгляду».

Приклад 2. «Загалом хлопець сподобався, спочатку відповідав не дуже, але це може бути пов’язано з тим, що в нього це було сьоме інтерв’ю за день, потім трохи розігрівся і діло пішло 🙂 З фронту витягує на рівень Senior. Стосовно беку: з Node.js майже не працював, але працював с Perl та PHP. Знання БД на хорошому рівні. Рекомендуємо до розгляду.
P. S.: Хлопець дуже приємний у спілкуванні».

Замість висновків

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

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

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

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

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

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

👍ПодобаєтьсяСподобалось48
До обраногоВ обраному25
LinkedIn

Найкращі коментарі пропустити

Чому я проводжу співбесіду дві години

Тому що у тебе багато вільного часу.

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

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

1)

моя задача — не доколупатися чи самоствердитись за його рахунок

Це треба великими буквами тупо на стіні у деяких рекрутерів вибивати. Або на лобі.
2) Перша стаття з останніх на багато букв, котра написана адекватно, сприймається нормально і не виглядає наче у автора просто словесна срачка. Читав без бажання пропустити кожен другий абзац.
3) А тепер до теми :-) Загалом дуже корисний текст, який можна з доробками під власну специфіку використовувати.
Ну і не зовсім зрозумілі претензії коментаторів, котрі кажуть: ви можете взяти людину, котра не буде працювати, треба було замість вашої мури зробити так чи отак. Покажіть мені хоча б 1 спосіб, котрий дасть 100% результат. Теоретики, трясця

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

До чого це все: оцінити рівень людини можна за 10-15 хвилин, а от дізнатись чи буде людина добре працювати то лише випробувальний термін.

Так і не зрозумів, навіщо дві години.

Все вищеописане можна охопити за 45-60 хв.
Дроч по теорії для кандидатів мідл+ не має сенсу, якщо є релевантний досвід і/або людина знає/розуміє як вирішувати необхідні вам задачі.

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

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

що супер круто насправді, бо ви такім чином уникаєте
resource starvation в економіці.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Відкрила статтю, бо стало дуже цікаво, що це за мазохізм опитування 2 години. Не знаю, як у кого, але я вже після 1 години починаю втомлюватися та мені банально вже не цікаво проходити співбесіду. Таке враження, що автор намагається докопатися до всього, навіть до того, що сам кандидат думає, що не знає.
А ще прі такій розмові відразу виникають питання: 1.Що за процеси такі у компаніі, якщо тільки співбесіда 2 години... 2.Як важко буде працювати з такою людіною, що проводить таку співбесіду... Тобто, жодного профіту
Навіть не пішла б на таку співбесіду, бо і часу немає, і бажання.

Якщо у спеца по 2 години співбесіди і 3 кандидатат за день, ось і весь робочий день)) Тобто співпесіда-інженер виходить)

Якщо у спеца по 2 години співбесіди і 3 кандидатат за день, ось і весь робочий день)) Тобто співпесіда-інженер виходить)

3 кандидати на день — це фактичний 0 інженерної роботи в цей день, навіть якщо співбесіди по годині. Ще треба відгуки написати, переключення контексту і тд.
Тут ще цікава тема — кількість співбесід на тиждень.

Тут декілька моментів. Сама співбесіда це ще не все, треба надати відгук, зазвичай сформулювати правильно думки та відписатися «потрібним» людям, це десь ще хвилин 30. Тому якщо підсумувати все, то виходить одна співбесіда з відгуком це десь 2-2.5 години. Зазвичай, я прошу ставити не більше 2 співбесід на день, щоб емоційно не перевантажуватись. Але якщо повернутися до вашого запитання, то так і є, якщо по 3 співбесіди на день, це рахуйте вже повний робочий день. З іншої сторони, якщо у вас 1 людина хто проводить співбесіди у компанію і у вас постійний потік кандидатів, то тут вже питання до менеджменту, самого інтервʼюера, а також до компанії, чим таким займаються у компанії, що постійно потрібні люди :) Зазвичай, в інтересах компанії та самого інтервʼюера — це вчити інших спеціалістів проводити співбесіду. Це допоможе зняти навантаження якщо потік кандидатів великий + буде заміна інтервʼюеру під час хвороби чи відпустки, чи якщо інтервʼюер захоче звільнитися. Але в любому випадку, це набагато дешевше ніж найняти спеціаліста котрий з певних причини не підійде на проєкт.

2 часа гонять человека контрпродуктивно. От стресса у него уже через час думалка ухудшится и отвечать он будет чисто из-за длительности интервью, не очень.
По моему опыту для понимания, подходит ли кандидат, в среднем нужно не более 15 минут.

Цікаво чи двогодинну співбесіду відповідно призначають в календарі. Останній раз припинив по-суті співбесіду, після того як її призначили в календарі тривалістю 1 годину, а на 1:40 навіть не думали зупинятись і далі навалювали нові завдання.

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

Краще замінити вирази на помʼякшену форму (уточнення): «Не зовсім так», «Трохи не туди», «Так, але я б трохи конкретизував» тощо. Навіщо це робити? Щоб не збивати людину з думок, не заганяти в стрес, підтримувати дружній та екологічний діалог.

Треба ще більш софт скілів. Оце:
> «Не зовсім так», «Трохи не туди», «Так, але я б трохи конкретизував»
треба замінити на оце
> «Можеш розказати детальніше чому ти так вважаєш?», «Можеш розказати детальніше чому ти вважаєш, що А = Б?».

Таким чином ми робимо наступне:
1) прибираємо "я«кання: «я би зробив так або сяк». Може кандидат взагалі сидить і думає «яка мені різниця як би зробив ти. Поки що єдина відмінність між тобою та мною є те, що ми сидимо по різні сторони столу. Але з досить великою вирогідністю я знаю краще відповідь на твоє питання і я з тобою ще не працював, тому твій авторитет як спеціаліста ще під питанням.»
2) прибираємо оціночні судження типу «Трохи не туди/ не так». Бо це звучить так, ніби кандидат щось робить не так. Типу відповідальність за не туди на його боці. Але з великою вирогідністю це інтервьюєр запитав трохи по дебільному. Так це не так, краще просто уточнювати те, що хочеш уточнити без оціночних фраз

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

На шоу типу America’s Got Talent навчилися за п’ять хвилин з’ясовувати чи підходить їм людина чи ні. І мені здається що це не їх вада.
Маю думку, що ідеальне інтерв’ю це онлайн парний кодинг впродовж 30-45 хв. Щось схоже на таску. Бажано щоб завдання враховувало всі потрібні вам технології. Якщо потрібно то англійською. Непогано було б вигадати стоп-слово, щоб не витрачати час, якщо за 10 хв все вже зрозуміло стало. З особистого досвіду, мене така штука робить оголеним і чесним як ніколи. А звичайну співбесіду можна натренувати за потребу.
Інший варіант, на 2-12 годин, це автоматизовані тести онлайн.
Просто, якщо ви знайдете людей, які зможуть адекватно битися дві плюс години в ці ваші зоопарки, то існує імовірність форматування команди виключно на хард задротен скілс, а софт скіли, які як кажуть грають роль на 80% у розробці, залишаться за бортом.

Чому я проводжу співбесіду дві години

Бо в мене дуже багато вільного часу, непевно.

Якщо б мені поставили співбесіду на 2 години, я би просто відмовився. За годину голова кипить, які там дві години?

Зі свого досвіду, 10 хвилин на побалакати про себе \ кандидата, розбити співбесіду на блоки типу html / css / js / networking / algorithms + DS / UI library || framework / state management / bundlers.
Дати кілька задач на розуміння того ж JS / TS, логіки в принципі. Якщо задача зроблена, попросити написати по-іншому, підштовхнути до правильної відповіді.
Не памʼятаю, щоб проводив співбесіду більше 45 хвилин. Бувало і 15-20, бо все зрозуміло одразу.

Почитавши певну кількість коментарів, я вже зрозумів, що:
— У мене багато вільного часу
— Що за 15 хвилин вже все зрозуміло
— Співбесіда нічого не гарантує і так далі.

Але якщо повернутися до суті, то з урахування того, що ви написали, то виходить наступне — співбесіда до 45 хвилин, з них 10 хвилин на вступ (з ваших слів) і залишимо 10 хвилин на відповіді на запитання кандидата (так як я це зазначав у себе в статті, тому у вас також порахую 10 хвилин, але якщо хочете, можу порахувати 5), загалом залишається 25-30 хвилин.

За 25-30 хвилин з ваших же слів ви питаєте:
— HTML
— CSS
— JS
— Networking
— Algorithms + DS
— UI library || framework
— State Management
— Bundlers

+ До цього

Дати кілька задач на розуміння того ж JS / TS, логіки в принципі. Якщо задача зроблена, попросити написати по-іншому, підштовхнути до правильної відповіді.

Якщо мене не підводить математика, то це виходить 8 тем + кілька задач (візьмемо 2), за 25-30 хвилин. Прикиньмо, наприклад задачка проста і людині треба прочитати умови та щось там відповісти(чи зробити), це умовно 3 хвилини — 1 задача, загалом це 6 хвилин за 2 задачі. Тобто у нас залишається 19-24 хвилини на 8 тем, це умовно до 3 хвилин на кожну тему, орієнтовно це 1-2 запитань по 1 темі. Якщо чесно, я не впевнений, що за 1-2 запитання у вас складеться повне розуміння знань кандидата по цій темі, яка б це тема не була (можливо окрім HTML). Наприклад на тему CSS, треба розуміти чи знає кандидат щось за препроцесори, CSS фреймворки, чи знає якісь CSS методології/архітектури, чи підходи написання CSS і так далі. І там не повинні бути запитання типу — «Працював? Працював. Ну, ок». А вам при всьому цьому ще потрібно зрозуміти як добре людина знає цю тему.

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

Я знаю випадки, коли наймали технічних спеціалістів без жодного технічного запитання і це дійсно були круті спеціалісти. Я якось сам приходив на співбесіду, де у мене запитали 2 запитання — «Як створити обʼєкт?» та «Як оптимізувати Angular?». Я не вважаю себе крутим спеціалістом, але б на ту вакансію я б точно підійшов і так далі, прикладів може бути багато. Але в якийсь момент, як, наприклад зараз, коли на одну вакансію десятки людей, до вас рано чи пізно прийдуть певні спеціалісти котрі не будуть вам підходити, але з дуже гарним вмінням «продати себе» чи, наприклад котрі пройшли 5 співбесід до цього і знають правильні відповіді на певні запитання і саме тоді, 25-30 хвилин може бути ой як недостатньо. Але втрати для компанії при цьому, будуть оцінюватися тисячами чи десятками тисяч.

з них 10 хвилин на вступ

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

Давайте з кінця.
Задача — залежно від рівня, літкод ізі чи мед. Че ж лайвкодинг. Слухаєш, як людина розмірковує, як працює логіка і знання алгоритмів. Які є варіанти по-іншому розвʼязати задачу. Це не більше 10 хвилин, бо інашке це виглядає як побиття. Якщо після спільного розмірковування людина не здатна вирішити задачу, то й рекомендувати ніхто не буде. Мені не цікаво слухати лекції про івент лупи чи як архітектурно працює ВД, які там алгоритми, які паттерни і тд. Людина розуміє, що відбувається — добро. Є кандидати, які починають сперечатися і доводити свою думку — тоді це вже більше 45 хвилин, але це залежить, чи вдала дискусія. Чи якщо це джун і йому цікава відповідь на моє питання — я розказую, теж буває більше :)

треба розуміти чи знає кандидат щось за препроцесори, CSS фреймворки

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

Також включіть сюди враження кандидата та стрес

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

Тому всі мої співбесіди супер френдлі і ноу стресс. Швидкий ритм (без напрягу) показує, як швидко людина думає. + завжди фідбек після кожної відповіді.

Тобто у нас залишається 19-24 хвилини на 8 тем, це умовно до 3 хвилин на кожну тему, орієнтовно це 1-2 запитань по 1 темі

Та нє, побалакати я можу вдома з дружиною. А чи знає людина, для чого реф в Реакті чи якісь хитрі хуки і як з ними працювати — треба секунд 15.
Так само і з нетворкінгом. Я не на сісадміна муштрую бідолагу, тому http(s), авторизація, методи і протоколи — теж не то щоб півгодини питати.

і знають правильні відповіді на певні запитання

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

Че ж лайвкодинг

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

Це ж не дав задачу і є-сь воно конем. Це обговорення. Не знає, як підступитись — розкажи, як думаєш, алгоритм дій. Допомогти і підштовхнути. Порефакторити разом і тд
Я ж прекрасно знаю, як воно може бути з теорією. Після 3 інтервʼю на ФЕ дева ти вже знаєш майже все, що тебе можуть запитати. Сам «вчив» колись давно. Тому я не бачу сенсу дві години жувати теорію. Краще спитати, як той сокет працює і накидати 3 рядки на ноді чи дати 3 рядки на ноді і попросити сказати, що не так чи як буде працювати.

Не памʼятаю, щоб проводив співбесіду більше 45 хвилин
10 хвилин на побалакати про себе
блоки типу html / css / js / networking / algorithms + DS / UI library || framework / state management / bundlers

Тобто маємо 8 блоків за 45-10=35 хв — 4-5 хв на блок.
Кодінг задачі не озвучено, бо вона це 10-30 хв.

Можете поділитись досвідом, як ви оцінюєте кандидита по розумінню networking та по algorithms + DS? Скільки питань задаєте на кожен блок (буду вдячний за приклади)? Яка шкала оцінювання?

Без проблем. Трохи вище описав.

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

algorithms + DS

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

Яка шкала оцінювання?

Це ж все субʼєктивно. Якщо все відповів — екселент, якщо не все, але після розмірковування разом — вері гуд і тд

Надалі використовую шкалу: початківець-середній-просунутий-експерт

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

Так, залежить від рівня. Але мені не ясно як щось окрім базового-середнього можна перевірити за 4-5 хв?
Задачка «опишіть загальне РЕСТ АПІ для книжкового видавництва» (дається опис основних сутностей, операцій що з ними будуть робити) займає у кандидатів 5-10 хв. Поверх цього можна заглиблюватись в структуру ХТТП, згадати про кешування (це вже просинутий-експерт). Ще є базові питання про ДНС/сокети/модель ТСП/ІП. А ще є лонгполінг, веб-сокети, ССЕ, про кожен з яких треба хоча б по питанню, це 2-5 хв помножити на 3.
Маємо:
Джуна ми будемо перевіряти десь 10+ хв (а ліміт 5)
Сеньйора — 20+ хв (а ліміт все ще 5)

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

Це тільки задачі, теорія не дуже цікавить.

Проста задачка — це 10-30 хв (залежить від навичок проходження інтерв’ю, а не знання алгоритмів) і це перевірка до рівня середній (базові задачі з літкод). Тут ваш приклад спрацює, але наведені задачі за 5 хв людина, що постійно їх не розв’язує, не розв’яже.
Щоб оцінити чи є рівень вище треба задачка на 30 хв (за умови, що людина її вирішує, а не завчив типові задачі з літкоду)

Це ж все субʼєктивно.

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

Я можу помилятися, але фронт енд джуну не треба ні тсп іп, ні днс. Та й з вебсокетами, якщо чесно, 1 джун тільки працював за всі інтервʼю.

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

const keys = [’prop1′, ’prop2′, ’prop3′] as const;
return keys.some(key => simulation.whateverProp[key] !== undefined);

Таке не завчиш, зате покаже, як людина вміє читати код.

але наведені задачі за 5 хв людина, що постійно їх не розв’язує, не розв’яже

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

Оцінка завжди суб’єктивна

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

Я можу помилятися, але фронт енд джуну не треба ні тсп іп, ні днс.

О, то ми в контексті співбесіди джунів (фактично перевірка базового та іноді середнього рівня).
Але джуну потрібне саме «розуміння», якщо людина не має розуміння хоча інтернет стеку або краще ОСІ, то виникають питання в її теоретичній підготовці і ризики, що людина просто не розуміє, чому на 9000 порту не можуть бути запущені 2 локальні сервери. Але можете поміняти питання про стек на детальніші про порти, УРЛ і тд. Чи займе це менше часу?

Чому? Це діалог. Від алгоритму до реалізації.

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

Але сумарно, ви праві, що ФЕ джуна (той який шукає першу роботу) можна проспівбесіудвати за десь 45 хв. Алгоритмічні задачки тут теж можуть зайти, якщо людина тільки-но з універу і там їх «задрачувала».
З кандидатами, як в статті, 2+ роки ОР складності будуть саме у виявленні сильних сторін, а не в перевірці базових навичок.

Без образ, але якщо у Вас «за годину голова кипить», то як Ви будете працювати 8-годинний робочий день 5 днів на тиждень? Для мене особисто це яскравий маркер, і співбесіда дійсно б не затягнулась надовго.

Два питання:
1. Скільки у Вас триває співбесіда?
2. Як би Ви побачили, що у співбесідника за годину голова кипить? Вона в нього, може, й кипить, але він це може й не сказати.

1. Зазвичай 4-5 годин, разом з тестовим завданням. Рекорд був 2.5 години, серед тих кого потім взяли. Витрачений час цілком залежить від навичок кандидата.

2. То я би дав співбесіднику час заспокоїтись, прийти до тями, попити кави, переключитись. У самого часто бувало, коли на співбесіді «клинить», і потрібен час, щоб вийти з цього стану. Нормальні люди все розуміють.

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

UPD. Стрес-тести не практикуємо, на співбесіді специфічною теорією не валимо. Лише те, що дійсно потрібно для поточної роботи.

Кандидат не буде

8-годинний робочий день 5 днів на тиждень

проходити інтервʼю із різними незнайомими людьми. Ні, це не те саме

Ні, це не те саме

Ну, наприклад є ще така неприємна річ як баги у продакшні, які часто вимагають декілька годин на вирішення у нервовій атмосфері, у тому числі

із різними незнайомими людьми

. Якщо у когось вже

за годину лапки голова кипить

на співбесіді, то це великий мінус йому у графу «стресостійкість»

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

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

Не плутайте стресову ситуацію з морально-комфортною, навіть з жортскими багами під дедлайн

навіть з жортскими багами під дедлайн

Якщо для вас ситуація типу «заблоковані важливі бізнес-флоу тому що лягла система за яку відповідає ваша команда», з обов’язковим репортом про прогрес кожні півгодини на С-level є морально-комфортною та менш стресовою ніж більш-ніж-годинна співбесіда, я щиро заздрю стійкості вашої нервової системи

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

Кандидат не буде

8-годинний робочий день 5 днів на тиждень
проходити інтервʼю із різними незнайомими людьми. Ні, це не те саме

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

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

Це питання без сарказму було? Тобто, Ви порівнюєте інтервʼю, де треба мапити купу знань під стресом з незнайомою людиною і + мільйон факторів, і «звичайний» робочий день?

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

де треба мапити купу знань під стресом з незнайомою людиною

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

2) Зараз обережно, можливі флешбеки і панічні атаки:

Варрум (+ постмортем).

Для тих хто не стикався з таким. Це мітинг, часто в аудіорежимі, де частина людей може бути в 1 кімнаті і треба зроміти хто говорить, довжиною 2-20 годин (більше 20 я лише чув, але не приймав участь) для вирішення серйозних інфраструктурних проблем, наприклад ддос атака і тд. 20 годин на дзвінку ви навряд чи будете, але 6-8 годин і потім 2-6 годин наступного ранку — таке легко може бути. Там можуть бути десь 40+ людей, більшість з яких має свою спеціалізацію і не має чіткої загальної картини. І в таких умовах вам треба ще й рішення примати.

Трохи більш приємна активність, але все ще дуже напружена — Quality Attribute Workshop. Тут людей менше, але це 1-2 дня мітингів довжиною 6-8 годин.

Ну серьезно, 2 години співбесіди — це лайтова активність.

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

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

цікава стаття, подєкував 👍

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

тому що честь працювати в нашій компанії

Не можу нічого сказати стосовно співбесіди на 5-6.5 годин, але можу прокоментувати стосовно 2. Тут дуже багато залежить від інтерв’юера. Хороший інтерв’юер зможе побудувати співбесіду таким чином, що 1.5-2 години пройдуть достатньо легко та швидко. З іншої сторони, ви скоріше за все вибираєте собі компанію не на декілька тижнів, а на певний проміжок часу (рік, два, пʼять, десять і так далі), з хорошими умовами, як мінімум компетентною командою та гідною оплатою вашої праці. У такому випадку це як і в ваших інтересах, так і в інтересах компанії більш детально ознайомитись один з одним. Співбесіда повинна дати не тільки розуміння для інтервʼюера, а і вам розуміння з ким вам доведеться працювати.

Навантаження велике, але це не 2 години запитань, це також і етап знайомства та відповіді на запитання. До того ж ще багато чого залежить від кандидата, якщо людина швидко відповідає та швидко думає, зазвичай така співбесіда займає 1 годину та 30-40 хвилин, якщо ж навпаки, може зайняти навіть більше часу.

цікаво звідки йде традиція переходити на «ти» на інтерв’ю і якій в ній сенс? з ймовірністю 95% я перший і останній раз бачуся з цими людьми, нахіба це штучне зближення — завжди було загадкою.
ps інтерв’ю на мідла проводжу десь година 20-25 з двома невеличкими задачами, якщо мені відомий проект який набирає.

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

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

я сприймаю, «на ти» якщо ми не добре знайомі як фамільярність та неповагу

Цікава у вас статистика) Дозвольте поцікавитись джерелом?

Якщо коротко — бо так працює психологія. А тепер трохи розгорну відповідь. Це «штучне» зближення вирівнює інтервʼюера та кандидата, та переносить вас на один рівень спілкування. Не миттєво звісно, але достатньо швидко. Знайомство з новою людиною — це завжди стрес, котрий може або мінімізуватися/зникнути або підсилитись упродовж співбесіди. Спілкування на «Ви», особливо не допомагає мінімізувати вплив стресу, бо у більшості випадках, людина буде відчувати напруження від формальності такої бесіди, це непогано для отримання хороших відповідей, але не дуже добре для нас з вами. Бо якщо навіть людина відповідала добре, у більшості випадках, у неї не складеться відчуття комфорту на співбесіді. І якщо навіть вам підходить кандидат, то кандидат коли буде вибирати між декількома компаніями, то ваша компанія (співбесіда), особливо не буде нічим виділятися. Якщо ж вам вдалося побудувати комфортну атмосферу на співбесіді, при цьому ви спілкувалися на одному рівні, людина відчує той ефект «не чужої людини», котрий підсилить приємне враження про співбесіду і тим самим підвищить шанси саме вашої компанії, на позитивний відгук від кандидата. Це не значить, що це панацея, але конкретно у моєму випадку, я завжди питаю дозволу про перехід на «ти» і зазвичай люди погоджуються. Такого плану питання підкреслює вплив кандидата на співбесіду, так як рішення про такий перехід вже належить самому кандидату, а не вам. Це зрозуміло, що спочатку це трохи може підсилити стрес, але цей ефект доволі швидко пройде, при правильних діях інтервʼюера. Я не кажу, що це обовʼязково чи правильно, але це те, як я зазвичай роблю. + Як зазначив Valeriy Shvets, комусь дійсно зручніше спілкуватися на «ти».

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

Враховуючи що середній attention span у людини значно менше 2 годин, хіба не було ситуацій коли у кандидатів після енного проміжку часу просто голова відключається, хоча до цього моменту все було ок? Для порівняння, BRAC(Basic rest—activity cycle) людини складає 90 хвилин, з яких тільки 50 ідуть на активну фазу, а в тому ж помодоро інтервал роботи складає взагалі 25 хвилин.
Тут хоча б перекур посередині робити для людяності.

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

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

Для порівняння, BRAC(Basic rest—activity cycle) людини складає 90 хвилин, з яких тільки 50 ідуть на активну фазу

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

Аргумент:
З мого досвіду (кілька сотень співбесід, в різних ролях), 1.5-2 години — це дуже лайтова співбесіда, різниці по навантаженню з 40-60 хв не відчувається. Власне тому мене здивував заголовок, я очікував аргументації проти 3-4-годинних співбесід, які у нас не розповсюджені.
Знову ж тут важливо не тиснути на кандидата і не допускати інших помилок, бо можна і за 1 годину заіпати людину і при цьому не отримати ніякої корисної інформації.

З мого досвіду (кілька сотень співбесід, в різних ролях), 1.5-2 години — це дуже лайтова співбесіда

це для шашечок чи їхати?

це для шашечок чи їхати?

Що саме? Якщо про співбесіди, то вони «щоб їхати» — аргументовано обрати оптимального кандидата.

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

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

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

Читайте уважно:

коли обом сторонам стає зрозуміло, що людина не підходить.

Проблема коротких співбесід в тому, що вони зводяться до «відчуттів», відповіді тут не мають значення.
Відповіді мають значення, коли треба аргументовано приймати рішення.
Щодо 1 години — то це не правда. Бачив купу кандидатів, що нормально проходять 1-2 години, якщо не гратись в екзаменатора. ФАААГи-або-ті-хто-вважають-себе-такими нормально проводять співбесіди по 3-4 години. Є ще цікавий патерн «робочий день» — 3-4 сесії по 1.5-2.5 години з 15 хв перервами, і якось люди справляються.

Бачив купу кандидатів, що нормально проходять 1-2 години, якщо не гратись в екзаменатора

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

мабуть тому що платите набагато вище ринку і маєте купу вільного часу

кажу про себе, я десь в 2019 собесилась в Европу
на Go/Python (релок) з двумя чуваками
трі години, про все все все плюс потім ще тестове додали.

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

Мій особистий рекорд — шість годин співбесіди з різними людьми, включаючи два тести на комп’ютері з C++ й англійської мови. Пройшла.

У мене в цьому плані якось був антирекорд) Коли я прийшов на співбесіду, у мене на той момент було десь 3 роки досвіду, навпроти мене був хлопець, Lead Java, котрий трохи щось писав на Angular і як я розумію, він не знав, що мене можна запитати. Тож він запитав за мій попередній досвід і поставив лише 2 технічні запитання «Як створити обʼєкт в JS?», а потім одразу «Як оптимізувати Angular застосунок?». На цьому співбесіда була закінчена. По факту на це пішо десь хвилин 5, інші хвилин 30 просто жартували та говорили про життя.

Пам’ятаю схожий досвід з Microsoft — здається 5 єтапів, кожен десь по ~1 годині з перервами по 15хв і все за один день.

Дві години, а що так мало? Мене он звали на співбесіду на 3 години поспіль.
Ще й казали типу «у нас тут дуже ретельний відбір, 95%+ відмови».
Послав їх нахрін відпискою в стилі «Unfortunately, ...»

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

Але тут є певні моменти, це їх право висовувати умови, а ваше право погоджуватись на такі умови чи ні. З урахуванням того, що зараз відбувається з ринком, кількість спеціалістів на 1 вакансію велика і якщо стоїть задача знайти кращого з кращих, таке можливо. У нас був лише один кейс, коли ми шукали FE архітектора, на проєкт на базі Salesforce та Ionic + Angular (на разі я вже не згадаю скільки було людей), але часто приходили люди котрі взагалі не розуміли специфіку роботи (а вона там капець яка, якщо чесно) і конкретно для тієї вакансії, у нас був відсів на рівні десь 90%.Тобто з 10 чи більше кандидатів, ми вибрали одного.

а чим займаються рекрутери у цій компанії?

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

якщо стоїть задача знайти кращого з кращих, таке можливо

Гугл теж відбирає кращих з кращих, а потім на нафіг, 1000 людей зі шмотками на вихід

Та якби ж то, покопав — EasySend.
Я їм дав calendly щоб орієнтуватися по вільному часу, а вони на пофіг скинули мені в ранок інтерв’ю на 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.

гг) а по їхній задумці це мало б мотивувати тебе до проходження челенджу, як онлайн тести — 95% людей не можуть вирішити це рівняння 2+2 =...

Було якось проводив співбесіду FE SE, на всі питання співав як пташка, коли взяли його то він рік ходив з розумним видом та нічого не робив, тільки патякав, поки його не звільнили.
Було якось взяв хлопця з палаючими очима, котрий теорію не дуже тямив, так він весь проект сам витягнув.
Стаття звісно благородна, але навіть 60% не буде гарантій що ви візьмете гарного співробітника.

На роботу перш за все треба брати людину, а не ChatGPT.

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

Тут дуже багато моментів, котрі треба врахувати. За час проведення співбесід, я помилився лише з одним кандидатом, котрого, як правильно зауважив Nikola Utiuzhnikov, ми звільнили під час випробувального терміну. Але на той момент, я був не такий досвідчений у проведенні співбесід і мій список запитань не покривав все те, з чим би довелося працювати спеціалісту, загалом ми тоді вклалися десь у 45 хвилин. Я не глибоко копав тоді у знання Angular та особливо не питав HTML/CSS, так як думав, що це забагато, але як виявилось, я помилився. З того часу я сильно переглянув підхід до співбесід і поки або мені щастить, або кандидати круті, але жодного звільнення по некомпетентності у нас більше не було. Стосовно вашого коменту про палаючі очі, я на це завжди звертаю увагу і інколи це вирішальний фактор, правда не завжди. Так як якщо це джун з палаючими очима, але мені на проєкт потрібен прагматичний Senior, то при всьому бажанні, але я виберу останнього і так далі. Але якщо це непоганий спеціаліст, плаває в теорії, але я бачу, що в нього палають очі від нових челенджів, то звісно я виберу цього хлопця. Насправді, багато чого працює на рівні інтуїції та розуміння психології, але якщо викласти це все на папір, тут можна книжку написати. Тому у статті я робив відсилки, що скоріше за все, якщо людям сподобається, то я б описав ще багато аспектів проведення інтервʼю, але під іншим кутом, або трохи іншу тему і так далі.

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

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

що супер круто насправді, бо ви такім чином уникаєте
resource starvation в економіці.

Не можу не підтримати

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

1)

моя задача — не доколупатися чи самоствердитись за його рахунок

Це треба великими буквами тупо на стіні у деяких рекрутерів вибивати. Або на лобі.
2) Перша стаття з останніх на багато букв, котра написана адекватно, сприймається нормально і не виглядає наче у автора просто словесна срачка. Читав без бажання пропустити кожен другий абзац.
3) А тепер до теми :-) Загалом дуже корисний текст, який можна з доробками під власну специфіку використовувати.
Ну і не зовсім зрозумілі претензії коментаторів, котрі кажуть: ви можете взяти людину, котра не буде працювати, треба було замість вашої мури зробити так чи отак. Покажіть мені хоча б 1 спосіб, котрий дасть 100% результат. Теоретики, трясця

JavaScript — 15 хвилин.
Angular — 25-30 хвилин
RxJS — 10 хвилин.

Завжди цікавало навіщо так задрачувати кандидатів по тим over9000 лібам

Можливо, тому, що сучасний Angular побудований на реактивній парадигмі, тому знання RxJS теж треба? До того ж, якщо це співбесіда на senior’а, то, зазвичай, на цьому рівні потрібне добре розуміння, як певний фреймворк працює «під капотом»?

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

Я навіть більше додам, дуже часто так і є) Просто далеко не завжди компанія котра наймає спеціалістів, починала писати проєкт. Це може бути як легасі проєкт, так і підтримка і так далі. Але це не значить, що спеціаліст не повинен цього знати, я знаю випадки коли починали переписувати такі проєкти з нуля, а буває таке, що нічого і не міняється. Тут ніхто не знає, як воно повернеться і чим все закінчиться, якщо чесно. У мене неодноразово були випадки, коли я був на зідзвоні з замовником і шарив йому екран і показував результат роботи або ставив запитання, як на його думку, краще (не завжди є BA/PO на проєкті). У таких випадках, замовник інколи просить, щось переробити чи показати як буде виглядати щось, щоб він побачив результат і зазвичай це робиться швидко, у цей момент сказати дайте мені кілька хвилин «погуглити» досить недоречно, як на мене. Більше того, я якось працював на одному проєкті як аутстаф, де один технічний спеціаліст, зі сторони замовника, дуже сильно відстоював нас на проєкті, так як ми йому часто шарили екран і показували зміни в рантаймі і він всім розповідав, що ми дуже скілові, так як жодного разу не бачив, щоб ми під час цього процесу гуглили, чи щось шукали в інеті.

Вибачте за лонгрід) Але це цікава тема

Зато это означает другую вещь. Крайне вредную для того самого специалиста. На таком проекте он начинает деградировать. Что бы там не говорили, а знания, которые не используются, просто забываются. И как результат, после очень широкого диапазона вопросов, ты «входишь в двери» новой компании как прямо в НАСА, а там оказывается обычное формошлепство или ДТО-шлепство, или что-то еще такого же рода. А ты уже вымотался после кучи собеседований с вопросами, ответы на которые тебе понадобятся только на собеседовании. И ты сидишь, и думаешь «вот попал, надо валить»! Но валить особого желания нет, потому что опять эта вся канитель с ненужными вопросами... И ты думаешь «ладно, через месяц (или два)». Они проходят, а ты вроде пригрелся... И так и сидишь, деградируешь дальше...

У меня вообще есть ощущение, что «крутизна вопросов» на собесе обратно пропорциональна «крутизне работы на проекте» после собеса. Такое ощущение, что собеседователи хоят перед кем-то выпендриться (скорее перед самими собой) чтобы показать на сколько они круты. Ну и заодно подавить кандидата ,чтобы не думал, что он заслуживает много денег. )

«...

ми йому часто шарили екран

...» "

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

" Ну да, гуглят обычно до того, как что-то утвеждать. Странный, мягко говоря, критерий скиловости! ))

что бы там не говорили, а знания, которые не используются, просто забываются. И как результат, после очень широкого диапазона вопросов, ты «входишь в двери» новой компании как прямо в НАСА, а там оказывается обычное формошлепство или ДТО-шлепство, или что-то еще такого же рода.

ИМХО вынужденная альтернатива этому — внутреннее собеседование в компании при смене проекта. Т.к. если предположить обратный случай — наняли «формошлёпа», который вполне себе справляется на текущем проекте, потом этот проект заканчивается, а на новом нужно переписывать с нуля и сразу по-правильному — вот там этот «формошлёп» с большой вероятностью жёстко зафейлится.

Т.е., другими словами, это уже довольно классическая дилемма «нанимаем в компанию или на конкретный проект»

Не всегда это может помочь. Наверное сильно зависит от времени деградациии и личностных качеств «деграданта». Может он уже на столько обленился, что ему только и хочется отформошлепить день и на пиво с друганами.
Как мне кажется, оптимальным будет нанимать кандидата, который чуток не дотягивает по каким-то направлениям до реальных запросов проекта/команды. Подчеркиваю, реальных, а не всего, что нагуглить удалось. Тогда и ему будет и достаточно интересно развиваться и не сильно страшно. И проекту не нужно будет ждать пол года, пока он там вкурит что и как. Просто немного приглядывать, корректировать и пояснять тонкие моменты. И все будет нормально для обеих сторон.

Кстати, я, признаюсь честно, по диагонали читал. Там было что-то про наличие у «пациента» гит-хаба с кодом? А то я вот не понимаю, когда они должны успевать его делать? Все кандидаты, которые у нас были «с гит-хабом», показывали на нем, какие-то простейшие хеловорды, написаные за пару дней до собеса. Чтобы иметь что-то стоящее на гит-хабе, нужно стоящее количество времени/усилий в это вложить. Стоящее время означает не меньше чем на работе. А жить когда?
Я после работы не имею ни времени, ни желания, обычно, кодить что нибуд еще. Так как на работе чаще всего весь день что нибудь педалю. Времени и сил остается только на почитать что там нового в моих инструментах и технологиях, чтобы поставить себе отметочку на завтра/попозже поробовать найденное/прочитанное на работе, если конечно что-то стоящее/полезное нашлось.

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

«Підкажи, будь ласка, у тебе X років досвіду, а ти відповідаєш як Senior-розробник. У чому твій секрет?». Це нормальне запитання.

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

Дякую за коментар. Розумієте у чому справа, багато людей (я також так вважав), думають що конкретно їх питання унікальні, а також ті питання котрі ми вважаємо глибшими чи то більш детальними, на практиці ж, більша частина запитань повторюються у певних компаніях. До прикладу, я свого часу думав, що мій список унікальний, сходив на декілька співбесід і виявив, що 60 і більше % моїх унікальних питань взагалі не унікальні і їх багато хто питає (потім, звісно, я зробив висновки з цього, але кардинально це кардинально не змінило). Напевно ви тут подумаєте, до чого це він зараз веде? Я веду до того, що якщо людина пройшла 10 співбесід до вашої, без банального запитання в лоб, ви і не зможете зрозуміти як так. У мене був кандидат, у котрого було 1 рік і 9 місяців досвіду, а відповідав він прям дуже-дуже круто (не хочу тут писати краще за когось, щоб не склалося враження культу «лички»), просто спитавши його прямим запитанням замість десятка додаткових, він розповів, що це вже 10 інтерв’ю за тиждень і ось і секрет. Бували випадки, коли приходив кандидат, у котрого 2.5 роки досвіду, а відповів він на всі запитання навіть не замислюючись, прямим запитанням я дізнався, що він проводить інтервʼю у себе в компанії і загалом провів вже понад 100 співбесід і так далі. У той же самий час, знаю історію, коли інтерв’юер під впливом кандидата у котрого 2 роки, ставить йому личку типу Senior, так як він дуже круто відповідав, на практиці, людина не може пофіксити просту UI багу упродовж тижня. Таких прикладів я можу перелічити дуже багато.
Я не питаю таке запитання у кожного, хто приходить на інтервʼю, це більше вийняток, а ніж правило, а також не вважаю це образливим запитанням, якщо чесно, більше того, таке мало хто питає і зазвичай почувши такого плану пряме запитання, говорять правду (тобто у них немає заготовлених відповідей на нього). Я не кажу, що моє рішення правильне, чи ви повинні робити саме так, як я описав, але якщо у вас є свій підхід котрий дозволить виявити ситуації котрі я описав вище, то я б з радістю підкреслив для себе щось новеньке.

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

У мене був кандидат, у котрого було 1 рік і 9 місяців досвіду, а відповідав він прям дуже-дуже круто (не хочу тут писати краще за когось, щоб не склалося враження культу «лички»), просто спитавши його прямим запитанням замість десятка додаткових, він розповів, що це вже 10 інтерв’ю за тиждень
У той же самий час, знаю історію, коли інтерв’юер під впливом кандидата у котрого 2 роки, ставить йому личку типу Senior, так як він дуже круто відповідав, на практиці, людина не може пофіксити просту UI багу упродовж тижня.

Припустимо, що перший кандидат з цитати (1) відповів інакше: багато читаю, весь час вчуся бо мені це подобається бла-бла-бла. Це б змінило вашу оцінку? Виглядає що так. Але чи дало б гарантію, що з ним не може статись отієї другої проблеми з «фіксити баг тиждень»? Очевидно, що ні, жодної — бо «знати» ще не є «вміти». Як на мене, це означає що сам процес «тече» й генерує false positives, і фіксити це потрібно аж ніяк не питаннями «звідки ти це знаєш».

також не вважаю це образливим запитанням

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

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

Дуже непоганий підхід, але є моменти. Як на мене, він не дасть вам повного розуміння знань людини по тих технологіях, котрі вам можуть знадобитися на проєкті чи поза ним. Тобто, наприклад, якщо людині не зайде проєкт, або він не сподобається замовнику, або на проєкті будуть скорочення і так далі, прикладів може бути багато (це актуально для аутсорсу та аутстафу). І треба шукати людині інший проєкт. У такому випадку діє підхід окремої співбесіди на кожний проєкт (як тут описували у коментарях), правда тут свої моменти. Чи, наприклад вам потрібно потім робити людині Grade Evaluation або ж Grade Confirmation і так далі, без скринінгу необхідних знань, це складнувато зробити (правда це можна зробити пізніше). Тут ще є нюанси стосовно того, якого саме плану задачі. Якщо брати FE, то бажано зрозуміти чи вміє людина щось писати по HTML/CSS, по JS та Angular і так далі. З BE можливо це простіше, але я тут не експерт, якщо чесно. Я б сюди ще додав момент проведення інтервʼю іншими людьми, тобто у вас, наприклад свій підхід, а якщо ви будете у відпустці чи захворієте, як співбесіду буде проводити інші людина і у якій форматі давати фідбек? Тут непогане працює «шаблонний» підхід, не без індивідуальних моментів звісно. Але я згоден, що такого підходу до співбесіди як ви описали, часто достатньо для нормальної роботи на конкретному проєкті.

Тут просто виникає конфлікт інтересів певний: або ми шукаємо людину, яка підійде саме нам і жертвуємо майбутнім потенційним пошуком для неї проекту, або ми шукаємо людину яка потім підійде всі, але закриваємо очі на потрібні саме нам якості.
Ну або тратити на співбесіду 3 години

Чудова стаття, дякую. По стилю статті видно, що інтерв’юер дійсно користується останньою порадою, а саме

Будьте людиною!

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

Цікаво ще було б почути про тестові завдання — чи є практика чи ні (не про лайв кодінг, який згадували, а про завдання зробити офлайн якусь задачу).

Вітя, ти ж був в одній великій галері тестувальником, чому зараз контент менеджер в ксерокс?

Привіт.
Дякую, що звернув увагу, я профіль не міняв дуже давно, я там раніше працював. Ще раз дякую, поправив (тільки не зрозумів, хто ти і звідки ми знайомі)

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

С задоволенням сходив би на таку співбесіду :)

Похизуватися? Чи познущатися? ;)

Тут ми зазначаємо, який саме досвід роботи з Angular ми б хотіли бачити у кандидата.
Який саме досвід роботи з JS ми б хотіли бачити.

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

У мене неодноразово були випадки, коли кандидати з 1,5-2,5 роками досвіду відповідали як Senior і навіть краще.

Це дуже хороше запитання. Відповідь на котре, залежить від багатьох факторів, наприклад складність проєкту, команда на проєкті, технології котрі використовуються і так далі. До прикладу, якщо я працюю на проєкті, я можу рівняти по собі або по інших членам команди, тобто я дивлюсь наскільки я справляюсь з задачею і наскільки мої колеги справляються на базі свого досвіду. Таким чином, вдається сформувати розуміння, який мінімальний досвід може знадобитися для роботи на проєкті. Якщо ж я не знаю за проєкт, то зазвичай таким самим займається людина котра відповідає за проєкт або буде відповідати. Але на практиці, дуже часто, є просто сформовані ринком вимоги до Junior, Middle та Senior позиції. І ± розуміючи обсяг робіт чи можливі задачі котрі потрібно буде робити на проєкті ± підбираєш команду, умовно 1 Middle — Middle+ розробник та один Senior і так далі. Але знову ж таки, з практики, команда комплектується просто хорошими спеціалістами певного рівня.

Хех. В США сейчас при найме
1час(скрининг) +1 час лайвкодинг(внешнее), потом в один день 2(техническое) + 1(поведение) + 1(дизайн).
В одной из компаний я прохожу вот эту цепочку — с сентября.

А потом вам могут назначить еще парочку, ибо кто-то еще на вас не посмотрел из 100500 индусов команды.
Ну и вишенкой на торте — а найм вообще не планировался, взяли внутреннего кандидата.

по поводу образования — там канадцы провели сравнение материалов по IQ и выяснили, что за 30 лет среднее бакалавра снизилося со 120 до 102(напоминаю, тесты сделаны так, что 100 — средниа популяции).

По поводу длительности интервью — большинство людей держат фокус от 30 до 40 минут. Соответсвенно два часа без перерыва — фейл практически без вариантов, выход скорее всего рандомный.

Цікаво про 40 хв
А вступний іспит в вуз 3 години

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

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

Напевно, саме тому і треба довге і змістовне інтерв’ю, щоб відсіяти кандидатів з IQ 100 і які не здатні зосередитись більше, ніж 40 хвилин.

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

«Що дозволено Юпітеру, не дозволено бику» ©

Не варто навіть порівнювати МААНГ+ з усіма їх плюшками, можливостями,бонусами, зарплатами, вихідними виплатами, гарантіями і галеру куди співбесідують формошльопером.

Денисе, але нічого поганого чи ганебного в тому немає. Різні варіанти роботи, кожен зі своїми плюсами і мінусами.

У мене за останній час трапилось так що на інтерв"ю з«ясувалось що у мене 4 роки досвіду з реактом а не 5...... і ми завершували тому що це було «КРИТИЧНО» для клієнта *pokerface*

І подібних історій вистачає.

Для клиента критично, что вы соврали в резюме. Выяснять, где еще — никому не интересно.

вы соврали в резюме.

Ти бачив в житті хоча б один проект, який би на 100% відповідав тому, що вони розповідають про себе під час інтерв’ю? Я ні — навіть класні компанії, яким не потрібно себе зайвий раз представляти, все одно вдаються до, скажімо так, «маркетингу». В процесі пошуку роботу/робітників обидві сторони завджи намагаються представити одна одну в найкращому ракурсі (краще, ніж є в реальності), це нажаль невід’ємна частина процесу. Забракувати кандидата через 4 роки досвіду замість 5 — це як на мене або захмарний рівень самодурства/непрофесіоналізму, або невдала спроба приховати реальну причину відмови.

Ти бачив в житті хоча б один проект, який би на 100% відповідав тому, що вони розповідають про себе під час інтерв’ю?

Я — бачив, але лише один раз, й то був найкращий проєкт в моїй кар’єрі.

Так я не брехав в резюме, у мене і написано що 4 роки, але подавався я на вакансію де було вказано 5+ і рекрутер не додивився цього

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

на інтерв"ю з"ясувалось що у мене 4 роки досвіду з реактом а не 5..

www.youtube.com/watch?v=zvFWRuh4xj4

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

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

З ким працював:
1. Наймолодший 19-20 років
2. Середній десь 25-35 років. Правильно напевно тут написати 30, але це не зовсім так, бо 30 майже нікому не було, багатьом було або 25 або десь 35.
3. Найстарший 47 років (напевно тут у вас виникне запитання, чому я точно знаю скільки людині років, а тут дуже проста відповідь, у нас є внутрішня система, де я можу глянути рік народження)

По кому я приймав рішення про найм:
1. Наймолодший 21-22 роки
2. Середній десь 25-35 років
3. Найстаршому на той момент було 39 років (зараз вже 42).

Щоб у вас не склалося враження, що я когось відсікаю по віку, свого часу у статті був присутній параграф де я описував, що вік та стать не має значення. Але це могло сприйнятися як сексизм та/або ейджизм, тому його прибрали. На практиці ж, просто більше кандидатів молодшого віку і це не припущення, а статистика dou — dou.ua/...​a/articles/portrait-2022

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

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

Ці індуси в кожному коментарі, щось тут не те. Це особисте?

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

Вибачте, але це маячня. Ми прекрасно знаємо яке зараз навчання в університеті. І всі студенти зараз оформлюють індивідуальний графік і їх навчання ніяк не заважає роботі окрім 1-2 тижнів сесії

Дякую за відповідь, якщо чесно, я чекав цього коментаря) На жаль у мене немає інформації стосовно того, як роблять всі студенти і я не впевнений, що у вас також є така інформація. Якщо студент навчається у вищі, як я зазначав у статті, на денній/вечірній формі навчання, то комбінувати навчання (пари, домашка, екзамени, підготовка до них та доїхати, якщо не онлайн) та 8 годинний робочий день + до того не забуваємо про вік, коли киплять гормони, доволі таки складно і я б сказав, майже неможливо. Коли я вчився в вищі у нас було по 3-5 пар на день + перерви + дорога. Я звільнявся зазвичай десь після 14:00, 16:00 і так далі. Якщо ж, як я розумію, ви маєте на увазі, під індивідуальним графіком, нічого не робити, а просто здавати сесію в кінці семестру, то я б не назвав це навчанням і в статті вказано про денну/вечірню форму навчання і я не чіпаю останні курси, у тому числі заочно. Часткова зайнятість при денній формі більш ніж реальна і більше того, таке активно практикують, але порівнювати часткову зайнятість з повноцінною, це неправильно.

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

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

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

Просто хотів передати привіт))

Соррі, що не по темі, але хочу зробити комплімент вашому нікнейму

Староста і викладачі

Індуси теж це вміють
Але то ж не в універі

Інструкція як вибирати собі кума, а от співробітника — якось трохи сумнівно)

Підкажіть, будь ласка, чому у вас склалося таке враження?

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

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

вже декілька разів потрапляв на такі ’інтерв’ю’ одразу кодінг та ще такий що в нормальному стані треба подумати. Або задачи з рубрики ’що тут буде’ ?

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

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

Більше того, зазвичай під час такого лайв кодингу, я сам пишу код, а кандидата прошу ревʼюіти, робити зауваження та пропонувати покращення. Виходить таке парне програмування, де кандидат грає роль штурмана. Це майже повністю нівелює стрес з його боку, особливо якщо я роблю помилки чи забуваю сігнатуру метода ). Дуже ерекомендую такий підхід.

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

А хто у вас потім розгрібає наслідки «швидко вирішених задач»?

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

Чим гра в 100 технічних запитань краща ніж вирішення двох практичних задач, як це роблять в Америці?

Бо 100 питань за 2 години — це менше часу ніж 2 задачі по 4 години :)

Бо люди працюють не з компами, люди працюють з людьми

гра в 100 технічних запитань

Там не про 100 технічних запитань

двох практичних задач, як це роблять в Америці?

Wat? Не розписуйся за америку ;)

Чим гра в 100 технічних запитань краща ніж вирішення двох практичних задач, як це роблять в Америці?

А потім віддають проєкт на аутсорс в іншу країну)

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

Віддають писати бойлерплейт, цікаві проекти залишають собі

Якого плану задачі: такі, які будуть в роботі. Якщо треба систему управління польотів, то треба питати про те як розробити систему управління польотів, а не про паліндроми

А совок: застаріла система, яка не працює

У мене на жаль немає такого хорошого розуміння по проєктах, але я працював як мінімум на 4 (здається навіть 5, але за останній я не впевнений) американських проєктах, 2 з котрих стартапи, 1 сайт для внутрішнього використання та 1 ресурс на базі CMS. Тому, я не можу сказати який з них

бойлерплейт

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

все так і є, саме тому Боїнг найняв писати софт індусів замість американських фахівців, яких, очевидно, перевів на «цікаві проекти». )

Да, именно так оно и было!

«...Недостатки софта, возможно, оставят самолеты прикованными к земле еще на один месяц — на этой неделе американские регуляторы обнаружили дополнительные проблемы. Программное обеспечение для серии 737-Max было написано во времена, когда компания Боинг увольняла опытных инженеров и оказывала давление на поставщиков.

Более того, икона американского самолетостроения и ее субподрядчики, доверяли временным работникам, зарабатывающим всего лишь $9 в час, разрабатывать и тестировать свое программное обеспечение. Зачастую, это были работники из стран с неразвитым самолетостроением, а именно из Индии....»

Ну и там дальше интересная статья о том, что из этого вышло. )

По факту спрашивают про управление системой продажи мороженного, чтоб никого не обижать.

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

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

Задаешь типовую задачу, покажи чем будешь работать, расскажи как это будет работать, как развернуть
Как сделать быстрее
Как сделать безопасней
Как сделать доступней

Автор, в 45 мин уложишся

Зачем спрашивать то, что Copilot и так умеет решить

Я во времена жирных бюджетов мучил себя и людей по 4 часа лет 10 назад, каюсь

Зачем спрашивать то, что Copilot и так умеет решить

Для чого наймати людину, для того, що копайлот і так вміє вирішувати?

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

До чого це все: оцінити рівень людини можна за 10-15 хвилин, а от дізнатись чи буде людина добре працювати то лише випробувальний термін.

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

за 10-15 хв можна хіба лапши собі відгрузити. Всі ці інтерв’ю лише пайплайн і карти таро. Інтерв’ю це скоріше про те чому НЕ найняти людину.

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

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

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

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

Мені в принципі сподобалось.. на папері людське відношення.

Дві години не так багато, якщо справді вони витрачають на комфортне відношення й описане

Якщо дві години витрачається на класичне мочалення втрьох з ЧСВ розміром з юпітер на одного, то всьо не так однозначно

Але варто тоді робити перерви... на попісять, і каву/печиво

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

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

Звичайно, тому треба людям довіряти і вони потягнуться до тебе, а не 2 години співбесіда.

Я б добавив питання за кого голосував в 2019, що б розуміти кого береш в команду. ))
Це жарт на злобу дня,якщо шо.

А взагалі думаю що такі великі співбесіди проводять уже на фінальному етапі коли сформував пул з максимум трьох претендентів і обираєш суперзвєзду ))

за кого голосував в 2019

от дивлюсь серед кандидатів був ківа прастигоспаді

І як далі вигладатиме інтерв’ю? :)

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

Та я в шоці, ківа, балашов ще, бойко, ото йбнп**ц був

в зе в першому турі 30% в пе 15%

У ківи 5к голосів, померти від раку думаю більша імовірність ніж отримати таку відповідь на інтерв’ю ))

Так і не зрозумів, навіщо дві години.

Все вищеописане можна охопити за 45-60 хв.
Дроч по теорії для кандидатів мідл+ не має сенсу, якщо є релевантний досвід і/або людина знає/розуміє як вирішувати необхідні вам задачі.

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

більшість фронтенд кандидатів мідл+ не знає JS толком, тому це мастхев. це не жарт.
Звісно запропоновані вами методи цікавіші — але шаблонне простіше для інтерв’вера який проводить сотні інтерв’ю(це автор і вказав)
І пам’ятайте що від сініора фронтенда в основному вимагається тільки слідувати бест практикам фреймворку. Звісно це актуально для гелер а не в ФААНГи
На співбесіду фулстека/ліда/архітекта — то тільки ваш варіант звісно

тому що, як каже автор, -

Інтервʼю — це мистецтво, і тут у кожного свій стиль.

коротше, автор — стіляга ще той )))

Дроч по теорії для кандидатів мідл+ не має сенсу

Тут от задача з’ясувати чи кандидат є мідл+. Для людини 10+років ОР, що була на проектах довжиною 3+ років, напевне це можна пропустити. Проблема з кандидатами 3-5 років, які можуть виявитись усім від джуна до адекватного ліда.

Куди цікавіше виділити 30 хв і задати людині задачу написати код чи зробити рев’ю чи змоделювати рішення проблеми чи створити систем дизайн.

І ось тут протиріччя з попереднім вашим твердженням. Давати кодінг задачу сеньйору має відносно мало сенсу, бо в нього буде вже багато суміжних задач (той же дизайн або інфраструктура). Тут розуміння (саме розуміння, а не знання АПІ) фреймворків чи не важливіше за кодінг.
Системний дизайн — це взагалі окрема тема, яку треба перевіряти, тому тут не «чи», а «і», тобто 30 хв перетворюються в 60. Також треба розуміти, що норм систем дизайн рішення не означає, що кандидат нормально програмує.

а не визначати сініорність по здатності переказати статтю з вікіпедії.

Треба фокусуватись на розмінні того, що написано в «статті на вікі». Якщо кандадат переказує без розуміння, це червоний прапорець.

Так і не зрозумів, навіщо дві години.

Та власне, щоб провести нормальну співбесіду і скласти аргументований фідбек, по якому потім можна порівнювати кандидатів.
Давайте накидаємо простий чекліст:
— основна мова (будемо використовувати джаву)
— ООП, СОЛІД/КІСС/ДРАй і тд; ще можна про патерни
— основні фремворки (умовно треба поговорити про Спрінг ІоЦ, МВЦ, Дата, Бут)
— тулінг (гіт, білд системи, ЦІ-сервери і тд)
— розуміння РЕСТ (хттп, АПІ в фремворках) + задача на дизайн
— черги повідомлень, асинхронний підхід
— БД (реляційні, задачка на СКЛ, НоСКЛ, АПІ з мови/фреймворків)
— клауди (хоча б кілька основних сервісів) + принципи дизайну для клаудів
— контейнеризація (докер, куб)
— щось ще про мікросервіси
— ФЕ, якщо воно треба, то тут ще кілька пунктів
— безпека, знову ж, залежить від специфіки проекту
— кодінг задача, про важливість якої ви згадали, і яка займе 15-30 хв

А ще добре б поговорити про специфічний досвід кандидата, це може зайняти багато часу.
Маємо 10+ пунктів по яким треба аргументовано оцінити людину хоча б по 4 рівневій шкалі (новачок-середній-просунутий-експерт). 45-60/10 == 4.5-6 хв на таку оцінку по кожному пункту, це без урахування часу на початок/завершення співбесіди і на кодінг задачу.

Але 45-60 — це норм час, якщо ми йдемо по схемі «прийняли рішення за перші 10-15хв»

UPD.
В принципі для чисто ФЕ — де треба верстка+основний фреймворк+базове розуміння ХТТП, то можна і за 45-60 хв

Дякую за розгорнуту відповідь.

Давати кодінг задачу сеньйору має відносно мало сенсу
Системний дизайн — це взагалі окрема тема

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

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

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

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

Куди цікавіше виділити 30 хв і задати людині задачу написати код

Враховуйте що будь-які варіанти live coding можуть бути вкрай некомфортними для кандидата.

Чому?
Саме написання коду лише одна з опцій. Можна запропонувати кандидату зробити код-рев’ю або не писати весь код спочатку, а пофіксити баг в існуючому шматку коду.

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

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

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

Корисно. Відчувається, що автору не все одно на людину по той бік екрану.

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

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

в такому випадку можна запросити розробника на офлайн інтервʼю

+50 до соціального рейтингу і додаткова миска рису

Чудовий посібник «Як проводити токсичні співбесіди».

Підкажіть, будь ласка, у чому полягає токсичність? Я завжди намагаюсь проводити інтервʼю у дуже ввічливій та комфортній атмосфері. У статті намагався описати саме такий підхід і поки не можу зрозуміти, де ви побачили токсичність.

Підкажіть, будь ласка, у чому полягає токсичність?

В двох годинах.
Для інтроверт 2 години розмови це 4 години відходити потім.

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

Десь приблизно так.

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

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

Ви описали тактики, як змусити кандидата відповідати на зручні для вас особисто питання і не плакати, коли він вас посадить сракою в калюжу.
Ви намагаєтесь вчити когось протягом інтервью...
Може просто запитаєте, що людина вміє/знає? Це не обов’язково будуть речі, в яких ви розбираєтесь. Поговорите про різні підходи до роботи.
Чому не можна задавати тупих питань? Щоб не впасти в очах кандидата? А як дізнатися, що він таке? Може він в NASA працював, розкаже вам про ракети...

Добрий спеціаліст з CV, LinkedIn вже знає підходить кандидат чи ні.

То ви просто не зтикалися з кандидатами, які дуже класно вміють в резюме та саморекламу, але потім, як виявляється, не дуже добре вміють в робити реальну роботу

Так в цьому і фішка виявити фейкове резюме по CV і LinkedIn. Якщо сеньйор працював 3 роки в компанії Х і 3 роки в компанії Y, то варто поцікавитися що ці компанії робили і чи треба вам такого спеціаліста.

варто поцікавитися що ці компанії робили

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

Набагато частіше компанії реальні і навіть проекти реальні, а от в описі того, що людина на тих проектах робила, і починається фантастика.

Як ви пропонуєте це перевірити, якщо ті компанії класу «галера», та, відповідно, проекти будуть під NDA — я не зовсім уявляю.

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

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

очень часто опыт с чем-то указанный в CV потом в итоге оказывается «люди на моем проекте этим занимались а я рядом был».

Вот нє надо тут разжігать

Ну да працював в команді з чуваками які роздуплились в технології Х.

Заімплементили там фсьо, а я був теж в команді і правив баги на проекті.
Тому з чистою (ну майже) совістю добавив технологію Х собі в резюмеху.

А шо такоє? ))

Тауе пишуть в розділ еніайронмент а нк скіли.
Різні секції резюме

Чому я проводжу співбесіду дві години

Тому що у тебе багато вільного часу.

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

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

з іншої сторони в 1 годину теж важко вкластися якщо вакансія на сініора...
і фокус повинен буди не тільки на знання фреймворків(це лише половина інтерв’ю)
а й на такі речі які ви описали в кінці.
Тому проводити інтерв’ю по шаблону для сініорів я перестав (html/css > JS > frameworks), для мідлів це все ще ок.
а більше фокусуюсь на досвіді кандидата, шо він робив і які проблеми вирішував.

а більше фокусуюсь на досвіді кандидата, шо він робив і які проблеми вирішував.

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

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

а для JS аналогічно — 50% кандидатів не знають як працює setTimeout...
я кажу що для сініора «шаблони» це тільки половина справи

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

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

Кстати, всегда было интересно, зачем людям setTimeout? То, что я видел, скажем так, вызывает желание отбить руки! Причем эти люди уж точно знали как его использовать! Но вот почему у них случилась необходимость его использовать, они не хотели понимать! ))

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

Основні моменти (нюанси) — рухаємось ми далі чи ні — видні в перші хвилини спілкування

Як? Рожа сподабалась чи нi?))0

Дуже важлива складова. Всі кто кажуть інакше — живуть в уявному світі

Рожа сподабалась чи нi?

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

Якщо відповідь схожа на «Ну ... ееее ... це був проект у сфері X та я, еее ... закривав таски що мені призначали» — це для мене 70% у скриньку no-go
Я очікую щось на кшталт «Моя команда в цілому відповідала за функціональність A, B, C, яка була реализована на техничному стеку X, Y, Z. Особисто я був сфокусований на D,E,F»

P.S. Я не дуже часто проводжу співбесіди, та звичайно на ролі middle+. Це може бути не дуже релеватно для джунів.

Основні моменти (нюанси) — рухаємось ми далі чи ні — видні в перші хвилини спілкування

«Внєшность обманчіва»

Тому що у тебе багато вільного часу.

А у кандидата вільного часу мало, саме тому він шукає роботу )))
Не подобається тривалість інтерв’ю — не проходь.
В даному випадку мова ж не йде про варіанти типу «у нас тестове завдання + п’ять етапів інтерв’ю». Бо зараз це знову стало популярним (плюс всякі «я зараз вам файлик на 100 питань пришлю, ви його заповніть» (бо ми вирішили свою HR базу заповнити, а з резюме виписувати влом), а вже потім ми може удостоїмо вас спілкування з живою людиною.
Є навіть варіанти автоматизованого проходження інтерв’ю в спеціалізованих системах (звичайно з увімкненою камерою і записом) яке потім хтось дуже важливий перегляне і можливо з вами звяжуться. ))

Теж завжди дивуюсь компаніям, які витрачають по 3-5 етапів на співбесіди, де загальна кількість проінвестованих мною годин може доходити до 6, у людей реально багато вільного часу, і за той час сплачує компанія, якийсь цирк на дроті.
Подібні співбесіди оминаю ще на етапі спілкування з рекрутером, чи підходить людина — вседно буде зрозуміло через 1-2 місяці

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