Senior у пошуках роботи. Про питання на системний дизайн та фінальні співбесіди
Після перерви знову продовжуємо говорити про співбесіди. Цього разу більше про практичні запитання, питання з дизайну та фінальні. Якщо ви ще не читали попередніх трьох частин (перша, друга, третя) — спершу зверніться до них.
Отож, почнімо. Коли ви успішно пройшли етапи тестових завдань, теоретичних запитань, перевірку на знання якихось конкретних штук, то у вас, найімовірніше, будуть цікавитися вже більш складними речами. А саме — вашим попереднім досвідом, підходами до вирішення задач, вашими роздумами щодо платформ та фреймворків.
Попередній досвід
Перше запитання, яке вам майже гарантовано поставлять, буде: «Опишіть найскладнішу задачу, яку вам довелося робити».
Як на мене, питання досить нерелевантне, тому що, як правило, інтерв’юер буде очікувати саме технічних проблем, тоді як у нашій роботі більшість складнощів пов’язані якраз із людьми. Навряд його задовільнить відповідь: «Ми вперлися в обмеження системи. Щоб порефакторити, треба було 3 місяці проводити купу мітингів з іншими відділами, щоб переконати їх, що ця робота повинна бути виконана саме зараз» (це, напевне, більше про менеджерський досвід). Або «у нас хаотичний замовник, і ми 4 рази переписували якусь частину системи. Вже на третій раз мені було дуже складно себе мотивувати».
Натомість усі чомусь будуть очікувати прохолодних історій про те, як ви перемелювали петабайти даних на кластерах, які коштують тисячу баксів за годину роботи. Як ви ковбасили 300kk req/sec на чистому Netty. Як ви застосовували consistent hash ring для шардування терабайтів даних і подібні байки.
Я вже писав у себе на каналі, що найскладніші задачі, для виконання яких мені треба було думати і напружувати сіру речовину, залишилися в університеті. Реальна робота з технічної точки зору виявилася прогулянкою Центральним парком у сонячний день. Тому, якщо вам не пощастило працювати в highload/adtech/fintech/gambling проектах, де є реально великі навантаження, то вашою найскладнішою проблемою, напевне, було розслідування якогось хитрого бага, який не давав нормально рендерити формочки або конвертувати один XML в інший.
Утім, раджу заздалегідь бути готовим до цього запитання, а ще краще мати декілька варіантів залежно від того, як буде йти розмова. Добре мати в арсеналі один перформенс-баг, один хитрий баг в underlying системі або бібліотеці, один баг в незнайомій системі (коли треба було розібратися самому), один цікавий баг і ще щось на кшталт цього. Добре, якщо ви дасте зрозуміти, що не боїтеся складнощів і можете докласти усіх зусиль, щоб вирішити проблему.
Щоразу я по-різному відповідав на це питання. Бувало, прямо казав, що в інституті мені треба було малювати граф зі стрілочками і там була складна тригонометрія. Іноді казав, що фіксив меморі ліки, а іноді — що мав терки з іншими відділами. Якось викручувався.
Далі, найімовірніше, будуть запитання щодо релевантних для вашої вакансії технологій, які перелічені у вас в CV.
Мав співбесіду в український аутсорсинг. Я працював раніше із Spring Cloud Netflix. У вакансії є така вимога, і інтерв’юери давай мене питати: а перелічіть, що ви використовували? А які є аналоги цих штук? А чому ви обрали саме цей стек? А які у вас були проблеми? А якби другий раз робили проект, то що б узяли? А навіщо ось це або ось це? І так далі. У результаті ми десь годину розмовляли тільки про Spring Cloud Netflix, і хлопці все ніяк не могли до мене підкопатися. Так і сказали: «Ми шукаємо таке питання, на яке б ти не відповів». А так вийшло, що я зміг на все відповісти.
Добре, коли у вас в CV перелічені тільки ті технології, які ви добре знаєте. Я дотримуюся думки, що «менше — краще», тому не пишу у CV, припустімо, WebLogic, з яким я востаннє мав справу 4 роки тому. Залишайте тільки те, що ви добре знаєте, бо інакше вас можуть запитати щодо якоїсь древньої штуки, а ви не відповісте. У цілому, напевне, нічого страшного, але краще все-таки залишати по собі лише позитивні враження.
Ще мав співбесіду в лідера ринку на техліда. У них на проекті є AWS. І в мене у CV теж написано, що я щось тямлю в тому. Ну і вони давай мене питати: а перелічіть усі сервіси, які ви використовували, а чому оце не взяли, а чому оце взяли, а які проблеми були, а що таке ось ця штука і так далі. Наостанок програм-менеджер(!) у мене запитав: «Чим відрізняються лямбди, написані на Java та інших мовах?» :)
Потім запитують щодо проектів. Щось у стилі: «Розкажіть про ваш останній проект, як там все було, що ви там зробили корисного, які були складнощі».
Тут теж добре пам’ятати, що точно ви робили, які були нюанси. Намагайтеся давати тільки релевантні факти, максимально стисло і без заглиблення у непотрібні деталі. Добре, коли ваш проект зроблений на технологіях, які якраз вимагають на вакансію. Потрібно також розуміти, що інтерв’юери дають це запитання, щоб через нього за ниточку розмотати потрібний та цікавий їм клубок. Запитання про проект — просто стартове, для того, щоб окреслити рамки розмови, цікаві моменти.
Щодо проектів під NDA, я особисто таких не мав. Але мені здається, що можна розказати деталі технічної реалізації, не вдаючись у значущі деталі бізнесу. У будь-якому випадку я би не відмахувався NDA-лейблом від таких запитань. Це навряд чи додасть вам плюсиків.
Я мав підготовлену промову про свій останній проект: що там були за технології, яка моя роль, скільки людей у команді, які складнощі. Раджу вам мати таку саму. Бажано також продумати, що можна сказати про кілька попередніх проектів, якщо вони були нещодавно.
Задачі на проектування і системний дизайн
Незважаючи на те, що у більшості випадків на роботі вас не допустять власне до таких задач або ваш внесок буде мінімальним, запитання такі люблять ставити. Тож необхідно знати, що відповідати, і мати у голові типовий алгоритм для вирішення задач.
Для підготовки до цього етапу я скористався таким списком матеріалів. Його буде достатньо майже для всіх випадків. Якщо навіть ви не претендуєте на роль архітектора або техліда, я все одно наполегливо рекомендую вам проштудіювати всі приклади, які там є, просто щоб знати, як будувати системи, типові підходи та інструменти.
Співбесіда на Java-помідора у дрібну аутстаф-контору. Їхній інженер розповідає, що в них мікросервіси на Spring Boot та Go, щось там якось крутиться, задає мені кілька дефолтних питань. Далі ми переходимо до фронтенд-частини, потім повертаємося знову до бекенд. І тут інженер у мене питає: «А от як би ти вирішив задачу, яка у нас стоїть? Мікросервіси і все це». Я не довго думав і відповів: «Взяв би Spring Boot і не парився», тобто віддзеркалив їхнє рішення :) Смішно було.
У ту контору мене не взяли, бо знань з фронтенду було мало.
Співбесіда на Java-техліда у лідера ринку. РМ-ом проекту виявився мій колега з попередньої роботи, який мене добре знав та був готовий брати мене фактично без співбесіди, але треба ж було дотриматися усіх формальностей. Отож, розмовляло зі мною аж троє людей (чомусь лідери ринку дуже люблять побільше людей напхати у переговорку). Одразу перейшли до запитань щодо розподілених систем, Spring Cloud Netflix, тестування АРІ.
Основним запитанням, як і на багатьох інших співбесідах, була організація RPC, як забезпечити уникнення проблем з версіонуванням API, як це тестувати, документувати та перевіряти дотримання контрактів. Тут я трішки дав маху, тому що був не в курсі трендового зараз gRPC, який, наскільки мені зрозуміло, всі ці задачі з успіхом вирішує. Довелося відбріхуватися рестом та JSON-Schema. Далі були запитання про побудову стійких систем і ще чогось такого. Трішки зачепили AWS, але я не знав потрібного їм сервісу.
У цілому співбесіда пройшла непогано. Видно, що люди, з якими я мав справу, розуміються на тому, що говорять, і знають, кого шукають. У мене залишилися приємні враження.
Тут мені очікувано дали офер, але менше грошей, ніж я хотів, тому відмовився.
Ще я мав реально хардкорну співбесіду на позицію SRE в аутстаф-контору. По скайпу зі мною розмовляли двоє людей — технар та менеджер. Продукт у них досить складний, хайлоадний та супер-секурний — його не можна в клауди, все бер-метал і т. д. Судячи з усього, найбільші вимоги у них були до мережевих файлових систем та сховищ даних, от по ним мене і почали питати. Шкода, що я практично ні в зуб ногою ні про такі системи (типу Ceph), ні про внутрішні деталі їхньої реалізації, ні про складнощі, які виникають при експлуатації таких систем. Завжди мав S3 і не парився, а тут виявилося, що ще є люди, які самі те все менеджать.
Отже, мене почали питати про те, як шардувати дані. Які є варіанти, які є протоколи для того, щоб це все правильно робити (щоб не було brain split наприклад), які є варіанти генерації ключів для шардів. Тут я мав би розповісти про consistent ring hash, про який я щось колись читав, але майже не пам’ятав, що воно таке. Хлопці все намагалися мене наштовхнути на це рішення, але я занадто далеко від цих штук (веб-макака ж!), щоб на ходу придумати рішення. Майже 40 хвилин ми вирішували задачу, яким чином побудувати надійне сховище даних, і крутилися навколо схем хешування. Ще трішки торкнулися баз даних і базових команд юнікса, на тому й розійшлися. Вердикт мені дали очевидний: «Далі не пускати».
Не знаю, чи справді їм треба було таких жорстких інженерів, які добре шарять ту всю розподілену фігню, але я б в таких умовах і не хотів працювати, тому не шкодую що не пройшов далі :)
У минулій частині я писав про співбесіду, де мені дали алгоритмічну задачу, хоча інтерв’юер сам визнав, що їм такі знання не потрібні, бо вони пишуть круди, і попередив про наступний етап дизайну, який теж немає змісту. Ось продовження.
Зв’язуємося по Zoom. Інтерв’юер довго вивчає моє CV (очевидно, що мітинги-мітинги, і не було часу підготуватися), і в нас відбувається такий діалог:
— Скільки у вас років досвіду з Java?
— 11 + ще з інституту пару років.
...
— Скільки у вас років досвіду роботи тімлідом?
— Подивіться в CV, там є абсолютно точні терміни.
— Скільки у вас років досвіду роботи тімлідом?
— ??? Я ж кажу — в CV все є.
— Скільки у вас років досвіду роботи тімлідом?
— Вам що, формочку якусь треба заповнювати, що ви такі питання задаєте?
— Ні, я просто хочу для себе розібратися, який у вас був досвід.
— Окей, якщо не хочете в CV дивитися, то 2 роки.Починаю відчувати, що розмова якось туго йде, бо на тому кінці дроту сидить нереальний інтроверт, з якого треба слова кліщами діставати, щоб зрозуміти, чого він від мене хоче. У мене таке вперше, до цього я зі всіма легко налагоджував контакт.
Продовжуємо:
— Розкажіть мені щось про Spring.
— Що конкретно розказати?
— Ну, щось.
— ???
— Розкажіть, навіщо потрібен Spring Boot.
...
— Розкажіть мені щось про JVM.
— Що?
— Щось.
— Ви знаєте, я не Шипильов, щоб вам тут про JVM розповідати. Давайте, може, якесь конкретне питання?
...
— А тепер, м-м-м, у нас буде питання про дизайн. Треба задизайнити систему. Ось є фейсбук, гугл, ютуб, твіттер, ще щось високонавантажене. Виберіть собі щось та задизайніть.
— Що саме?
— Ну, щось зі списку, що вам подобається.Тут у мене здали нерви. Більш дурнуватого питання про дизайн у мене не було, просто якийсь театр абсурду.
Відповідаю:
— Окей, я вибираю Hacker News. Це високонавантажений проект, він крутиться на одному сервері та зроблений на LAMP. От його і будемо робити )))Додаю:
— Ви знаєте, я бачу, що з якоїсь причини у нас розмова дуже складно йде. Чи то я не можу вас зрозуміти, але мені якось складно без конкретних питань давати відповіді, тому що мені незрозуміло, що ви хочете з’ясувати. Сформулюйте задачу нормально, і будемо вирішувати те, що вам потрібно, а не те, що я собі придумаю. Давайте задачу з вашої роботи.Інтерв’юер погодився та запропонував мені вирішити задачу про multi-tenancy рішення, в якому є багато багато ізольованих баз даних та один набір мікросервісів, який повинен якимось чином доступатися до тих даних. При чому самі мікросервіси не можна ізолювати один від одного, тому що тоді виростуть витрати на інфраструктуру. Я у відповідь щось там більш-менш адекватне запропонував, чим задовільнив інтерв’юера.
Під кінець діалогу спілкування стало вже ніби більш продуктивним, і питань «розкажіть мені щось» більше не було.
Мене були готові пускати далі, але несподівано виявилося, що в материнській компанії відбулися якісь ротації серед керівництва і весь найм заморозили.
Ще була співбесіда у аутсорс-контору на Java-помідора. Там хлопців теж сильно цікавило, яким чином побудувати RPC, тестувати контракти і оце все. Відповідь я вже мав — gRPC :) Зараз усюди мікросервіс через мікросервіс, тому ці речі точно необхідно знати.
У цій конторі мені готові були робити офер, але я сам відморозився від їхнього рекрутера, тому що мене якось завалило справами і не було часу з нею поговорити по скайпу, а текстом писати мені пропозицію рекрутер не захотіла. Досі трішки соромно, бо зазвичай я всім відповідаю.
Інтерв’ю в highload стартап на Java-техліда. Там, де мені треба було на співбесіді за півтори години написати робоче рішення. Отож, я мав розмову з головним архітектором, і він почав мене питати по задачі. Як зробити, щоб тут було більше даних? А от якщо в нас буде даних забагато і буде ООМ, то що робити? А як можна попередити таку ситуацію? У цілому всі питання були спрямовані на те, щоб розібратися, як кандидат буде вирішувати більш складні задачі, які виникають при значному збільшенні обсягу даних.
Цю співбесіду я успішно пройшов і отримав офер.
Здається, це всі питання про дизайн, які в мене були. Загалом мені сподобалися всі задачі-питання, хіба що крім жорстких хлопців з розподіленими системами. Я би рекомендував запитувати не про абстрактні фейсбуки з гуглами, а про реальні проблеми, які були чи є на проекті. А кандидату просто треба бути в курсі нових технологій і знати вирішення типових задач на побудову горизонтально масштабованих систем.
Менеджерські та фінальні співбесіди
Якщо ви успішно пройшли всі етапи, то, напевно, вам будуть готові робити офер. Перед цим традиційно проводиться співбесіда з менеджером проекту, власником компанії чи ще якоюсь іншою відповідальною особою. Тут, можливо, ще раз будуть з’ясовувати вашу мотивацію, наскільки ви підходите на цю позицію, а також дадуть можливість задати запитання. Ось тут я дуже раджу вам питати про все, що тільки можна питати. Типовий набір запитань, який я мав під рукою:
- Кому я буду репортити?
- Хто відповідальний за мій розвиток (якщо він є)?
- Яка використовується методологія розробки?
- Як організована комунікація? Які є канали, як вони використовуються? Що більше, що менше (пошта, Slack, Skype)?
- Скільки часу витрачається на мітинги та іншу комунікацію?
- Яким чином організовується документація на проекті?
- Чи мають інженери доступ до продакшн-систем?
- Як часто система деплоїться?
- Як робиться DevOps?
- Як організований контроль якості?
- Скільки людей у команді? Хто є на боці замовника?
- Які плани по проекту? Коли продакшн, коли саппорт? Які взагалі перспективи?
- Які найбільші складнощі на проекті прямо зараз?
- Чи бувають овертайми?
- Яким чином ухвалюють ключові технічні рішення?
- Які є можливості зростання на проекті?
- Хто стейкхолдери, яка структура власності (якщо це стартап або продукт)?
Мене цікавили такі питання, тому що насправді я прихильник async/remote підходу, але, на жаль, у жодній компанії нічого схожого не було. Всюди слаки та мітинги, що поробиш.
Якихось цікавих співбесід на цьому етапі в мене не було. Лише зачеплю тему переговорів.
Мав співбесіду на Ruby-інженера у аутстаф-контору. Пройшов її та наступну із замовниками. Мені запропонували на $500 менше, ніж я просив, тому що в мене, цитую: «Недостатньо фундаментальних знань у Ruby». Сказали, що можуть повернутися до цього питання через півроку.
«Шукайте дурних», — подумав я. «Краще я вивчу книжку, прийду більш підготовленим і не буду чекати півроку, поки мені скажуть, що бюджет не дозволяє піднімати зп або що в мене знову недостатньо знань». У голос сказав: «Я звичайно все розумію, але це економія на сірниках». І відмовився.
Ще мав офер на позицію Java-техліда. Там мені запропонували на $300 менше, мотивуючи це тим, що в них по грейду більше не можна. Але якщо ось я пройду внутрішні курси на архітекта і стану архітектом, то дадуть більше. Я теж відмовився — ще чого. Невідомо, чи буде та позиція через півроку, невідомо, чи дадуть більше грошей і т. д.
Не раджу вам погоджуватися на такі обіцянки, хіба би вони були зафіксовані на папері. І то, папір може нічого не значитиме. Гроші на бочку одразу і все — це мій підхід.
Бонусні співбесіди
Ще я мав співбесіди у три різні компанії на позиції відповідно Solution Architect, Group Manager та VP of Engineering. Тут вже питання та підхід трішки інші, ніж на девелоперів та тімлідів. Розповім і про це, щоб розбавити нашу одноманітність технічних співбесід.
На Solution Architect співбесіда була, напевне, найфейловішою, тому що в людей ентерпрайз, а в мене були всілякі дрібні стартапи. Якщо ви не в курсі, хто такий Solution Architect — це така людина, яка суміщає обов’язки продавця, дуже-дуже високорівневого технаря та бізнес-аналітика. Потрібно вміти малювати діаграми (чим складніше, тим краще) та робити презентації, вміти презентувати та захистити цю всю справу перед замовником, бути готовим до каверзних запитань від його архітектів, знати, які є «архітектурні» документи, розуміти всілякі методології і т. Д.
У більшості випадків на таких позиціях архітектор сам не займається розробкою. Для мене цінність роботи такого архітектора дуже сумнівна з технічної точки зору: як ти можеш щось там малювати, якщо сам не кодиш хоча б прототипи? Звісно, що в аутсорсі без таких людей нікуди: до кастомера ж не випустиш голих технарів-снобів. А ще додам, що в ентерпрайзі, де я працював, такі люди, як правило, виходили з бізнес-аналітиків. Їхньою роботою було скласти з квадратиків-модулів красиву картинку «рішення», яку продавали замовнику і навіть подекуди друкували на А3 та вішали десь у кабінетах. Зрозуміло, що до реального стану справ та картинка мала дуже віддалене відношення.
Щодо того, хто такий архітект, є крута стаття від Єгора Бугаєнко Are You an Architect?. Я з його концепціями повністю погоджуюсь.
В принципі я це все знав, але вирішив спробувати.
Отож, прийшов на співбесіду, і першим сюрпризом було те, що зі мною мав розмовляти в тому числі й мій одногрупник :) Яка в нього посада, я не знаю, але вона була однозначно високою — вище архітекта за їхніми внутрішніми грейдами. Крім нього, були РМ та програм-менеджер.
І ось ці всі люди мене по черзі починають питати, який у мене досвід в архітектурі, які документи я готував, як працювати з функціональними-нефункціональними вимогами, як робив планування навантаження та ресурсів (capacity planning), чи я це все якось захищав. Власне технічних питань не було: наприклад, як організувати read-heavy рішення, коли можна, а коли не можна NoSQL різних сортів та видів і т. д. Лише запитали про AWS, які сервіси я знаю.
Також значна частка питань була про розрулювання ситуацій із замовником, коли на його боці неадекватні люди, неадекватні вимоги, в контракті записали, а не зробили та інші політичні питання.
Ще поцікавилися, чи знайомий я з Best Practices індустрії. Пізніше виявилося, що є якісь стандартні методології та підходи.
Після перших 10 хв співбесіди я зрозумів, що мені тут ловити нічого, бо потрібного їм досвіду в мене не було. Але хлопці вирішили продовжити. Я думаю з тих міркувань, щоб передати мене іншій команді на іншу позицію. Власне так і відбулося.
У вердикті, крім того, що я нічого не знаю, написали: «He has very Technology Centric thinking». Думаю, що можна з натяжкою вважати це таким собі компліментом :)
До речі, щодо вердикту — я запросив у HR фідбек і рекомендації, і, на диво, мені їх надали досить розгорнуто. Щоправда, я зрозумів, що точно не хочу працювати Solution Architect :)
Друга співбесіда в мене була вже в іншу компанію на позицію Group Manager пари-трійки команд (загалом
Спочатку був досить довгий (більше години) скрінинг по скайпу з рекрутером, де у мене з’ясовували минулий досвід. Потім почали задавати питання на конфлікт-менеджмент, типу «Є співробітник, який працює в команді, де роботи не так багато. Потрібно його перевести в інші, але він не хоче. Що будеш робити?»
Також мені дали можливість задати питання, але рекрутер була трішки не в курсі, як у них що працює, тому не змогла конкретно відповісти, чим же у них займаються груп менеджери. Лише обмежилась загальними фразами з опису вакансії. Врешті-решт я той скринінг якось пройшов, і мене запросили вже на очну співбесіду.
Я прийшов до офісу, де мене вже чекали HR директор компанії та один з тих самих груп менеджерів. І почалося: розкажіть про ваш минулий досвід, а чому змінили роботу, чому розглядаєте менеджерську позицію, як ви себе оцінюєте, як ви надавали фідбек (позитивний або негативний), чому ви думаєте, що нам підходите, а які у вас були складні кейси, як оцінювати людей, як взаємодіяти з іншими менеджерами, як ви будували CI/CD ланцюжок (???) і ще якісь такі питання.
Далі мені дали можливість з’ясувати, що таке в них груп менеджер. Виявилося, що це щось середнє між проектним координатором, ресурсним менеджером та тімлідом. Протягом усієї співбесіди мені не задали жодного технічного питання, хоча суть позиції була в тому, що це обов’язково мав бути виходець з девелоперів. Тому я сам запропонував хоч щось мене попитати — на що отримав досить просте запитання з організації черг.
Час закінчувався, тому HR директор, який увесь цей час бачив мене наскрізь (маю на увазі те, що я не хотів працювати у них), сказав, цитую: «Подумайте про свої недоліки, а ми з вами зв’яжемося наступного тижня». Я швидко відповів, що дуже багато працюю та буваю настільки лояльним до компанії, що нехтую власними інтересами. Відповідь не проканала :)
Через кілька днів ми з HR директором знову зв’язалися уже в скайпі. Я намагався щось мукати та бекати про власні недоліки, але вийшло не дуже. У результаті мені винесли вердикт: «Сам не знає, чого хоче» та «незрілість», — що не дивно, тому що я дійсно не дуже хотів у них працювати. Крім того, мої справжні цілі точно йшли в розріз з очікуваними відповідями на позицію, тому я й склав враження типа, який сам не знає чого хоче :) А HR директор не дарма свій хліб їсть та бачить одразу лівих кандидатів. Йому респект, що мене не пропустив :)
В цю ж контору я ще хотів спробувати пройти просто на девелопера, але мені м’яко відмовили через відсутність мотивації. А я не захотів їх далі переконувати, що дійсно хочу працювати.
Третя співбесіда у мене була в компанію на 50 людей на позицію VP of Engineering. На мене вийшли через лінкедін, і я погодився піти поговорити. Хто знає, що там. Може, дійсно цікаво.
Отож, спочатку мене чекав скрінинг по скайпу с HR. Були дефолтні питання про те, про се. Потім домовилися про ще один скрінинг вже з їхнім техдиром. Знову поговорили про те, про се. Їх дуже цікавив CI/CD ланцюжок чомусь — тут я трішки щось розумію, тому мене покликали поговорити вже очно.
Техдир почав з питання «яке твоє найбільше досягнення?», з чим у мене виникли невеликі труднощі, тому що таких аж досягнень у мене не дуже-то й було. Я щось відповів про те, як я Spring інтегрував у легасі систему і як це потім стало мейнстрімом у компанії, де я працював. Але звісно, що це його не дуже цікавило.
Далі трохи поговорили про процеси, чого вони очікують від VP. І мені здалося, що це насправді не VP, а якийсь мікс з девопса та архітекта. Обов’язково з технічним бекграундом. Тут техдир, сказав що він не бачить у мене релевантного досвіду, тому я їм не підходжу. Думаю, що він мав на увазі побудову процесу розробки у компанії з великою кількістю різнорідних команд. Такого досвіду у мене дійсно не було. Але він сказав: те, що я говорю, йому подобається, тому якщо він колись зробить стартап, то покличе мене СТОшнічати там :) На тому й розійшлися.
Очевидно, що якщо вже вас кличуть на таку позицію, то ви більш-менш розумієте, що до чого, і поради якісь давати тут немає сенсу. Я думаю, що потрібно добряче готуватися, мати в голові список досягнень, проектів, продуктів, які зробили під вашим керівництвом, мати готові рішення для типових проблем взаємодії між командами і стейкхолдерами і т. д. Сподіваюся, в майбутньому в мене будуть шанси пройти на такі вакансії.
Fin
На цьому все! За результатами проходження співбесід у 16 різних компаній за два місяці (жовтень та листопад) я провів 35 сесій, не враховуючи деяких співбесід з рекрутерами, які нічим не закінчились. Я витратив приблизно 40 годин чистого часу + 10 годин на вирішення тестових завдань. Отримав 3,5 офери (менше ніж 25% конверсії, що, як на мене, малувато). Від усіх відмовився з тих чи інших причин та залишився там, звідки й почав. Але вже краще розумію, що є на ринку, як скоротити час на проходження усіх кіл співбесід, як себе ефективніше поводити та як готуватися. Також мені залишилася купа своїх думок щодо цього всього, якими я з вами і поділився.
Чесно кажучи, стільки співбесід трохи виснажують, тому, напевне, з середини листопада я вже почав відмовлятися від нових позицій.
Як основний висновок цієї подорожі співбесідами я би хотів зазначити таке: хорошому інженеру з солідним досвідом немає ніякого сенсу працювати в українських аутсорс/аутстаф/offshore devcentre посередниках. Ви будете далі від кастомера, отримуватимете менше грошей, витрачатимете більше часу на комунікацію та політику, матимете менше перспектив. Шукайте віддалену роботу у стартапах та продуктових компаніях — там і гроші будуть серйозніші, і можливостей може бути більше. В ідеалі знайти віддалену роботу напряму від замовника із зарплатою інженера з Silicon Valley :)
Якщо вам сподобалась моя писанина, то не забувайте долучитися до мого Telegram-каналу.
Всім хорошої роботи та продуктивних співбесід у новому році!
Попередні частини:
Senior у пошуках роботи. Як я пройшов 20 співбесід з HR і що про це думаю
Senior у пошуках роботи. Як я пройшов 15 технічних співбесід і що про це думаю
Senior у пошуках роботи. Про задачі на технічних співбесідах і теоретичні питання