Як ефективно проводити технічні співбесіди

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

Привіт! Мене звати Андрій, я iOS Team Lead у стартап-студії Kiss My Apps, що спеціалізується на розробці mobile first продуктів. За понад 12 років досвіду в ІТ, працював на різних позиціях від Trainee до Tech/Team Lead у продуктових стартапах. Провів понад 50 технічних співбесід та навчаю цього інших.

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

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

Етапи співбесіди в IT-сфері

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

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

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

Технічні завдання. Насправді описані вище пункти — це здебільшого заміна технічним завданням. Іноді технічні завдання можуть бути must have, але я вважаю, що без нагальної необхідності їх краще не додавати. Це займає зайвий час як у кандидата, так і у компанії. До того ж якщо завдання надто великі, це може лише відвернути від вакансії, а маленькі будуть не більш інформативними, ніж звичайна розмова. Live coding, своєю чергою, лише додає напруги до і без того стресового процесу співбесіди. Далеко не кожен може адекватно й швидко мислити в таких умовах. У кандидатів займе менше часу детально описати рекрутеру свої знання певних технологій та досвід, і це дасть гарне розуміння їхніх навичок.

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

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

Як я оцінюю кандидатів на технічній співбесіді

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

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

Теоретичні знання

По перше — банальні теоретичні питання, які зустрічаються на багатьох співбесідах: SOLID, architecture та design-патерни тощо. По друге — питання про різні технології, фреймворки, сервіси та інструменти. Що воно є та для чого, які потреби закриває і які вимоги додає.

Практичні навички

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

Soft skills та hard skills

Я надаю перевагу більшій персоналізованості процесу, тому завжди маю особистий підхід до кожного кандидата, базуючись на отриманій інформації. Окрім перевірки hard skills, я також роблю великий акцент на soft skills, які має людина. Найважливіші для мене — бізнес-орієнтованість, комунікативність, самостійність, жага до самовдосконалення, ставлення до процесів. Саме ці якості допомагають мені зрозуміти, які цінності кандидат принесе в компанію та як увіллється в наш колектив.

Про що я запитую на технічних співбесідах

Зазвичай я поділяю питання на три блоки:

Досвід

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

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

Практика

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

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

Теорія

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

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

Висновки після співбесіди

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

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

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

  1. Теоретичні знання.
  2. Практичні навички.
  3. Soft Skills.
  4. Розвиток та перспектива.
  5. Висновок.

Підсумок

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

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

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

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

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

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

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

Спасибо, что хоть не спрашиваешь кем вы видите себя через 5 лет и продайте мне этот карандаш.

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

Если ты уже разменял N-нный стек, тебе по барабану как очередная перделка называется, оно все примерно одно и тоже везде. Главное понимать память, IO, сеть, безопасность и многопоточность.

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

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

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

банально скриптовані

Це зворотня сторона формалізації процессів, тобто бюрократії. Так по суті ті співбесіди і спарвді роботи проходять значно краще за людей вже. Тим не менше алгоритми та структури даних, як і загалом дискретна математика дуже потрібна шткуа в програмуванні. Мені сподобалось пояснення процессів найму в Джоела Спольскі www.joelonsoftware.com/...​-interviewing-version-30
Особливо з провалом, який з ним прогорнули індуси — він мав перелік запитань, а індуси їх зазубарили елементарно (хоча з радянької школи пам’ятаємо що це теж дуже корисно, тренує пам’ять).
2. Часто люди які проводять співбесіди або не усвідомлюють що наймають, або насправді не є наймаючими менеджерами їх припахали боси це робити, щоби потім по фідбекам прийняти рішення. Тому воно перетворюється на токсику (пасивно-агресивна поведінка), тобто часто і взагалі негативний відбір — щоби твойому місцю в компанії та карьєрним перспективам, яке приносе грощі, загрози не було. У FAANG давно таке, там навіть хтось з HR-ів з тим почав боротись, бо усвдомили, що велику купу питань задають лише з ціллю самоствердження. Тобто люди і не збирались винаймати співробітників, вони збирались затягувати найм, щоб підвищити свою значемість для роботодавця.

і не розуміють реальні потреби конкретної компанії.

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

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

Та навіть гірше — просто не знають кого шукають. Так сталось починаючи з 22-го року, що мені довелось проходити суттєво співбесід. До цього я здебільшого проходив їх «на клієнта». Там 2/3 з них закінчувались на питанні з моєї сторони : «Кого ви шукаєте?». Усе як під копірку, спочатку — ступор, а потім і до такого доходило інколи, що стосунки між собою з’ясовуали. І це було ясно насправді ще по профілю вакансії, якщо той і взагалі був. Комусь треба — супер мека експерт на посаду джуніора, чи секретарки. Комусь людина оркестр — пргограмісто-devops-qa-кухар і щоб ще за пивом бігав. Комуст просто закрити вакансію хтось для массовки, бо бігом щоб акаунт менеджер не вставив штакет, що знадто довго на контракт треба певна кількість русерсів для массовки, навіть як їм насправді нема чого робити на проекті. У Кожаєва дуже цікава стаття з цього приводу є.

Відверто кажучи, дійшовши до «декілька видів

InAppPurchases

» виникає питання, а що це дає? На справді — ця інформація знаходиться у документації Apple. Тримати це в голові — на що. Про паттерни — це ок, тому що дає розуміння про досвід побудови архітектури. І взагалі — тримати в голові такі речі ви можете, тільки якщо недавно з цим працювали. З мого досвіду краще запитував, на приклад, такі речі чи варто/не варто застосовувати на View @NSFetchRequest плюс деякі контейнери і в якому випадку який краще (дає відразу всю інформацію), а далі як піде.
Ще один момент — дуже залежить від того, як інтервʼювер налаштован і як відповідає кандидат. Іноді просто відразу хочется все закінчити. Як показує практика, десь 10-15 хвилин технічних питань вже достатньо для розуміння.

InAppPurchases

Це є сенс питати тільки якщо кандидат сам вказав в резюме, що нещодавно розробляв покупки/підписки.
Цікаво, чи завершуєте ви співбесіду через 10-15 хвилин якщо очевидно, що рівень кандидата не достатній і як ви це робите? Зазвичай HR ставить у календар мінімум годину на інтервʼю, тож кандидат одразу зрозуміє що його злили)

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

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

Компанії, у яких були дуже приємні співбесіди, де реально питали по суті і те, що вони використовують у повсякденній роботі: Luxoft, SoftServe, Intellias
Компанії, де питали всіляку фігню, відірвану від життя і їхніх реальних задач: GlobalLogic, EPAM, Grid Dynamics, Lohika

У мене якось була співбесіда у велику і модну компанію м. Києва, не зі списку. Вимоги до кандидату були описані в діапазоні «системний адміністратор — дослідник передових технологій — програміст С++», але лише прямо на співбесіді я дізнався, чим же команда займається. Першим технічним питанням було «Чи можете ви написати нам формулу методу Рунге-Кутта ІІ порядку», на що я відповів, що я знаю, навіщо цей метод, але от формулу не напишу. І взагалі, який це має звʼязок з вашою заявленою діяльність? — «Ну так...еееее... для кругозору»

Насправді — як повезе :) На приклад, в SoftServe дійсно інтервʼювера підготовують, щоб у кандидата не склалось хибне враження, принаймі, з усіма, з ким там стикався — все було ок, незалежно від напряму технології. А ось з Luxoft зовсім протилежне враження.
Ще класно, коли приходять на інтервʼю і не вмикають камеру.
Також був цікавий випадок, коли приходять і інтервʼювери ведуть себе немов вони з Netflix.
Якось пара хлопців дали код у Google Doc перевернути певну структуру даних, розгорнув, прийшлось дещо пригадати, але все ж таки, один за все інтервʼю жодного слова не вимовив, інший, коли вже закінчували — сказав, що я мав би спілкуватись... Facepalm
Ще випадок, це коли в маленькому віконці пишуть код, а потім, щоб його додивитись — треба розгорнути те вікно, але воно не розгортається. Задають питання застосування деяких речей і наполягають, що так правильно, а ти відразу розумієш, що люди не користуються лінтерами і не читають best practices. Це було у одну крупну українську аутсорсінгову компанію.

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

Luxoft, SoftServe, Intellias
GlobalLogic, EPAM, Grid Dynamics, Lohika

Ескобар.жпг

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

Дуже розумно сказано, що співбесіда не має перетворитися в спробу завалити кандидата)

ставили купу питань з оптимізацій

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

Навіть відсутність репозиторію — це вже корисна інформація, яка надає додаткове розуміння про кандидата!

І які висновки і розуміння ви можете отримати з цієї інформації?

Він не такий як ми ©
PS не маю репозіторія

Типу нема портфоліо — фу на тебе. З миру enterprise цього не зрозуміти, в нас навпаки питання а. Коли був на то час б. Чи не станеться витоку інформації коли робочий код та ноухау потрапить в паблік

А ще маєш донатити і паяти дрони :-P

Було би з чого, а так діло не хитре, що те що інше.

Скільки часу триває така співбесіда у вас?

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