Відтінки співбесід і як до них готуватись

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

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

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

  • Спочатку кілька важливих дисклеймерів:
  • Я не найкраща людина, щоби давати поради новачкам.Першу серйозну роботу в ІТ я отримав багато років тому. Тоді для отримання позиції «DevOps» достатньо було орієнтуватись в Linux і мережах, і вміти розпарсити JSON на Python. Якщо ви знали ще щось на кшталт Chef чи Ansible, можна було одразу пробувати стрибати на middle-позиції. Зараз все змінилося: вимоги значно виросли, особливо для входу в професію. Тож якщо ви дійсно хочете дізнатись, як розпочати, запитайте тих, хто отримав першу таку роботу тиждень / місяць / рік тому.
  • Моя позиція — Site Reliability Engineer. Отже, співбесідою я людей на ці позиції і сам я теж співбесідуюсь на подібні посади. У статті я буду розглядати процес інтервʼю саме на такі позиції.
  • Протягом своєї карʼєри я працював тільки у продуктових компаніях, хоча кілька разів співбесідувався і в аутсорси. Аутсорси можуть мати свою специфіку, яка мені невідома, тож буду вдячний, якщо ви розкажете про неї в коментарях.
  • Я живу в Німеччині, тож мій досвід здебільшого стосується співбесід в компанії Західної Європи. Тож, як кажуть, your mileage may vary.
  • Мета цієї статті — описати загальний фреймворк співбесід, із яким я стикався. Зрозуміло, що існують крайні випадки і буває так, що ви отримуєте посаду в стартапі свого сусіда після однієї розмови на кухні.
  • Я не хочу чіпати тему резюме. Про це можна написати окрему статтю. Ось є гарне відео від Google із порадами щодо написання резюме. Приклад того, як я зіставив резюме, ви можете переглянути тут.

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

Типи співбесід

Для себе я виділяю пʼять основних типів співбесід: Introduction, Technical Skills Evaluation, Big Picture Interview, Behavioural (Cultural) Interview і Closure.

Важливо зазначити, що тип співбесіди — це не те саме, що й етап. В процесі найму може бути декілька етапів, що відповідають одному із типів інтервʼю. Якийсь тип може випадати, мінятись місцями чи навіть зливатись з іншим. Наприклад, big picture інтервʼю може не використовуватись для молодших позицій, а розмова з менеджером може містити елементи як big picture, так і behavioural інтервʼю. Проте в цій статті я буду вживати іноді слово «етап» в значенні «тип».

На скріні вище зазначено девʼять (!) етапів співбесіди, але, як ви можете бачити, всі вони вкладаються в зазначені типи.

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

Introduction

Також відомий як screening. Цей тип інтервʼю завжди йде першим і включає в себе як холодні повідомлення від рекрутерів в LinkedIn, так і перші дзвінки з рекрутером в компанії чи наймаючим менеджером. Також із мого досвіду багато нідерландських компаній та великі консалтинги дають на цьому етапі IQ та інші personality tests (1). Я не дуже розумію навіщо, але якщо ви дуже хочете працювати в Нідерландах чи конторах на кшталт PWC або Deloitte, мабуть, це потрібно просто прийняти.

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

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

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

Technical Skills Evaluation

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

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

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

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

І ще кілька слів про домашнє завдання. Якщо компанія дала вам задачу і ви вирішили її зробити, будь ласка, читайте уважно ТЗ і не відправляйте назад код, що не працює. Моя компанія дає домашні завдання і ви будете здивовані, як часто нам надсилаюсь код, який не працює, або ж роботу, де проігнорували якусь із вимог. Очевидно, що далі такі кандидати не проходять. Як я вже зазначав, цінність домашніх завдань не в тому, щоби отримати черговий спосіб розпарсити JSON, отриманий із публічного API, і скласти якісь дані в Redis. Цінність його в тому, щоби побачити, як людина ставиться до ТЗ і фінальної документації.

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

Big Picture Interview

Спочатку я хотів назвати цей тип System Design, бо саме такі співбесіди проводжу я у своїй компанії, але Big Picture інтервʼю охоплюють не лише його. Цей тип включає і case studies, при чому кейс може запропонувати як інтервʼюер, так і ви — з власного досвіду. Якщо цінність домашніх завдань в ході найму падає з прогресом у карʼєрі, цінність Big Picture інтервʼю тільки зростає.

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

Як підготуватись. Існує дуже гарна книжка з system design. Також можете подивитись ресурси, представлені в списку Awesome System Design. Приділяйте увагу нефункціональним вимогам! Нефункціональні вимоги — це сік system design інтерв’ю, адже зазвичай перед вами ставлять задачу: давайте побудуємо систему, де юзер зможе завантажувати і переглядати картинки котиків. Скільки планується тих юзерів? Де вони розташовані географічно? Чи є якісь SLO зі швидкості завантаження картинок? Знову ж таки, основна задача цієї співбесіди — зрозуміти, чи знаєте ви, як системи взаємодіють одна з одною і які є трейдофи того чи іншого рішення.

Для case studies підготуйте два-три кейси складного чи нестандартного технічного завдання, що вам доводилося вирішувати. Кейс готуйте за принципом STAR — Situation, Task, Action, Result. Побачили, що деякі сторінки сайту довго відкриваються (situation). Почали розбиратись, які і чому (task). Знайшли, що забагато даних, що не часто оновлюються, витягуються з бази, і додали кеш (action). Стало краще на X мілісекунд в 95-му перцентилі (result). До речі, нові situations можуть виникати прямо під час поточної action, згадувати про них чи ні — вирішувати вам. У будь-якому випадку, кейси — це сторітелінг. Можете подивитись відео про трьохактну структуру оповідання, але це якщо вам дійсно цікаво.

Behavioural Interview

Також відомий як culture fit. Це зазвичай чистий case studies, найчастіше з наймаючим менеджером команди, у якій ви будете працювати. Буває, технічні спеціалісти нехтують цим етапом. Мовляв, я пройшов технічні співбесіди, менеджеру я точно щось розкажу. Але цей етап дуже важливий саме для вас!

  • Технічні інтерв’ю можуть проводити люди з інших команд або ж запрошені спеціалісти. Цей етап може бути першим, коли ви безпосередньо маєте можливість поспілкуватись із людиною, з якою будете безпосередньо працювати, а отже, запитати її про команду, культуру, процеси.
  • У компанії завжди є вилка зарплат для позиції. Дуже часто behavioral тип інтерв’ю існує для того, щоби зкалібрувати кандидата по вилці. Наприклад, якщо вилка €75k/Y — €85k/Y, ваш фінальний офер може відрізнятись на €10k/Y, а це неабиякі гроші.

Як підготуватись. Всі поради про кейс стадіз попереднього пункту актуальні й тут, проте слід пам’ятати, що цього разу акцент ставиться на взаємодії з людьми. Підготуйте два-три кейси, коли вам потрібно було брати на себе лідерство або ж організувати процес між декількома командами. Звичайно, всі принципи сторітелінгу працюють і тут. Ми побачили, що сторінки сайту довго завантажуються через неоптимальні запити в базу даних (situation). Ми пішли до відповідальної команди (task). У них були інші пріоритети, тому ми домовились, що в цьому кварталі ми вертикально масштабуємо базу, але в наступному вони із нашою допомогою переглянуть запити (action). Декілька місяців ми платили більше за БД (tradeoff), але потім разом із тією командою оптимізувала запити і ми змогли повернутись до попереднього скейлу (result). Ось є чудове відео від «A Life Engineered» про проходження саме таких типів інтерв’ю. Також у нього є загальне відео про проходження співбесід, в якому він теж ставить акцент на big picture та behavioral інтерв’ю. Дуже рекомендую переглянути обидва відео.

Closure

Це той момент, коли всі етапи вже позаду, і ви домовляєтесь щодо фінального офера. Може здатись, що це вже не має жодного стосунку до співбесід, але це все ще частина найму, при чому важлива. По-перше, тут ви можете помінятися місцями з компанією і зробити їм реверс-інтерв’ю. Що це таке і які питання є сенс задавати дуже добре розписав Gergely Orosz в своєму блозі. Також у нього є список із 12 питань, що слід задати компанії. Звичайно, на кожному із етапів вам, зазвичай, надаються час поставити свої запитання. Якщо ви вважаєте, що отримали відповіді на всі важливі запитання, можете пропустити цей пункт. Також деякі питання зі списку мають виражено регіональний характер. Наприклад, акції та опціони (equity) можуть складати велику частину загальної компенсації у США, але в Західній Європі вони — просто ще один бонус. В Україні ж це взагалі виняток із правил.

Оскільки ми вже почали говорити про компенсацію, як і обіцяв, повертаюсь до питання: «Коли називати цифру?». Дуже часто загальна порада полягає в тому, що хто першим назвав цифру, той програв. Наприклад, статті «Ten Rules for Negotiating a Job Offer» і її другій частині говорять саме про це. Та, на мою думку, не завжди ця стратегія є оптимальною.

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

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

Побачити ситуацію на ринку ви можете або на DOU, або на сайтах на кшталт Glassdoor чи Levels.fyi. Проте жодна статистика не буде обʼєктивною. Наприклад, на Glassdoor, на мою думку, цифри трохи занижені, а на Levels.fyi — навпаки, завищені. Звичайно, ви можете самі зробити дослідження, походивши по співбесідах, але це займе час, сили, та й вибірка буде обмеженою. Проте ви зможете зрозуміти, скільки компанії готові платити саме вам, а не абстрактному Senior Software Engineer.

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

-------------------------------------------------------------------------------------------

  1. Тут я використовую термін «IQ тест» як узагальнення всіх типів тестів на абстрактне мислення і ситуативну поведінку.
  2. Дуже хороша стаття про live coding — «Why Senior Engineers Hate Coding Interviews»
  3. Проблема локального максимуму описана в книзі Tanya Reilly «The Staff Engineer’s Path». Нехай є команда К, що вирішує якусь задачу. Для вирішення задачі підходить дві технології — А та Б. Технологія А простіше в підтримці, але за допомогою технології Б інші команди можуть вирішити також свої потреби. Якщо команда К не знає про потреби інших, то з більшою ймовірністю вона вибере технологію А для вирішення задачі, бо так краще їм, а не технологію Б, яка краще підходить для всієї компанії. Таким чином, технологія А буде локальним максимумом для команди К.
👍ПодобаєтьсяСподобалось24
До обраногоВ обраному31
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

В обране.
Після Перемоги треба буде ще раз перечитати, щоб знов «продавати» себе дорого)

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

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

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

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

Я маю на увазі не форму проведення технічного інтерв’ю, а набір проблем які обговорюються. Бо із тим самим резюме (переважно .NET backend) я стикався абсолютно з різним (приклади різних інтерв’ю нижче):

  • що таке збірка, reference vs value types і якісь нюанси за Ріхтером
  • SOLID, async/await та інше що до асинхронного та паралельного програмування
  • асинхронщина; САР-теорема та інші нюанси життя та дизайну розподілених систем
  • величезний ухил у бік MS SQL / T-SQL

Дуже рідко буває по іншому. 95% технічних інтерв’ю це екзамен/допит
Звісно інші 5% набагато приємніші та врешті більш вдалі

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