Як DevOps-інженеру підготуватися до співбесіди та пройти всі етапи успішно: поради від фахівця

Своїм досвідом проходження співбесід з нами поділися Сергій Сайфулін — Middle DevOps Engineer у компанії NETFORCE Ukraine. У сфері DevOps він працює понад 3 роки, а до цього більше 3 років був сисадміном.

У першій частині інтерв’ю Сергій розповів про свій старт кар’єри та поділився порадами для пошуку роботи у DevOps. Читайте матеріал тут.

У цій частині говоримо про:

• особливості співбесід для кандидатів у DevOps;
• які питання ставлять на технічному етапі;
• що допоможе краще підготуватись.

Як проходять співбесіди на DevOps-позиції?

Це завжди декілька етапів: інтерв’ю з рекрутером, далі — з тімлідами чи директорами на технічні питання.

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

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

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

На технічній співбесіді відбувається знайомство з технічним спеціалістом. Це може бути тімлід, а буває — техлід чи навіть IT-директор. Все залежить від компанії.

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

Які питання ставлять на технічному інтерв’ю?

Питання можуть бути дуже різними — залежно від стеку та рівня досвіду кандидата. 

Питання по теорії є завжди. З високою ймовірністю для DevOps-інженерів будуть такі теми:

• Linux
• Вебсервери
• Бази даних
• Git
• Автоматизація (скрипти)
• CI/CD-пайплайни
• Контейнеризація

На моєму досвіді не траплялося, щоб питання повторювалися. Тому варто бути готовим до різного.

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

Що стосується БД, можете почути питання: «як пришвидшити роботу?» або «як підвищити availability, коли база налаштовується для продакшену (кластери, реплікація, і т. ін.)?».

Або ж, наприклад, вам кажуть: «У нас є Git і Jenkins, потрібно задеплоїти код на Kubernetes. Як ви це зробите?».

Ваша відповідь може звучати приблизно так:

1. Надаємо Jenkins необхідні доступи до Git та Kubernetes.
2. На Jenkins ми пишемо пайплайн, який буде забирати код з Git. 
3. Білдимо це, наприклад, в Docker та заливаємо в Docker Registry. 
4. Робимо Helm Chart, яким це будемо деплоїти до Kubernetes. 
5. Запускаємо Helm, використовуємо секрети і параметри для деплойменту.

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

Як змінюється кількість і глибина питань для джунів та мідлів?

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

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

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

Наприклад, якщо на інтерв’ю питають про Kubernetes, то:

• у джуна можуть запитати про його основні елементи;
• у мідла — щось глибше. Скажімо, як писати Kubernetes-оператор.

Чи дають DevOps-інженерам тестові завдання?

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

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

Що може допомогти в підготовці до співбесіди?

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

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

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

Коли ви на співбесіді запитаєте, чому у вакансії зазначені інструменти Х та Y, але про них не згадують, то можете почути приблизно таку відповідь:

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

Як варто діяти кандидату, якщо він не знає відповіді на питання?

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

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

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

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

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

Яким для вас є ідеальне DevOps-інтерв’ю? 

• Для мене — це два, максимум три, етапи співбесіди: тобто скринінг та технічне інтерв’ю.

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

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

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

Які кроки ви робите, перш ніж погодитися на співбесіду?

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

Тому коли приходить запрошення, я запитую таку інформацію (якщо не надали): 

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

Які червоні прапорці можуть вплинути на ваше рішення не приймати офер від компанії?

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

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

Якщо порівняти співбесіди 3 роки тому, коли ви починали шлях у DevOps, і зараз — що змінилось?

Сильних змін немає. Звичайно, стек технологій, який я використовував на початку кар’єри в DevOps, та той, що є зараз, трохи змінився.

Головна відмінність — у вимогах компаній від кандидатів. Коли я починав кар’єру у DevOps, мене питали Linux, Terraform, AWS. Зараз від джунів очікують більше. Наприклад, не тільки AWS, а й GCP або Azure. Тобто шукають більш універсальних фахівців. Хоча це також залежить від запитів конкретних проєктів: іноді треба паралельно працювати з кількома клієнтами, і кожен має свої вимоги.

Якщо взяти до уваги ваш досвід сисадміна, які зміни відбулись?

Коли я проходив співбесіду на роль сисадміна на мою першу роботу, я приходив в офіс. Зі мною поспілкувався HR-менеджер і дав мені тестування десь на 80 питань. Тоді я від руки на листочку А4 відповідав на питання. Потім вже спілкувався з керівником відділу системного адміністрування. 

Чим далі розвивається IT-сфера, тим більше роботодавці очікують від кандидата на початку його шляху. Понад 7 років тому ви могли пройти на посаду сисадміна без досвіду роботи, з мінімальним розумінням, що таке комп’ютер. Через 1,5-2 роки від моменту, коли я отримав роботу, наша компанія не набирала людей без досвіду. Потрібно було мати базу знань та розуміння, що і як працює. Вже тоді я зрозумів, що якби зараз прийшов з тим набором знань на співбесіду, то взагалі б не пройшов її.

Які поради можете дати кандидатам на роль DevOps-інженера, які зараз готуються до співбесіди?

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

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

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

Чесно відповідайте на питання. Тут нікуди не дінешся. А це важливо, щоб у вас потім неприємностей не було.

Що порадите початківцям?

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

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

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

На завершення

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

А ідеальний DevOps-проєкт вже чекає на вас — на платформі NETFORCE Jobs.

Христина Донченко