Senior у пошуках роботи. Про питання на системний дизайн та фінальні співбесіди

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

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

Попередній досвід

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

Як на мене, питання досить нерелевантне, тому що, як правило, інтерв'ю юер буде очікувати саме технічних проблем, тоді як у нашій роботі більшість складнощів пов'язані якраз із людьми. Навряд його задовільнить відповідь: «Ми вперлися в обмеження системи. Щоб порефакторити, треба було 3 місяці проводити купу мітингів з іншими відділами, щоб переконати їх, що ця робота повинна бути виконана саме зараз» (це, напевне, більше про менеджерський досвід). Або «у нас хаотичний замовник, і ми 4 рази переписували якусь частину системи. Вже на третій раз мені було дуже складно собі мотивувати».

Натомість усі чомусь будуть очікувати прохолодних історій про ті, як ви перемелювали петабайти даних на кластери, які коштують тисячу баксів за годину роботи. Як ви ковбасили 300kk req/sec на чистому Netty. Як ви застосовували consistent hash ring для шардування терабайтів даних і подібні байки.

Я вже писав у себе на каналі, що найскладніші задачі, для виконання яких мені треба було думати і напружувати сіру речовину, залишилися в університеті. Реальна робота з технічної точки зору не прогулянкою Центральним парком у сонячний день. Тому, якщо вам не пощастило працювати в highload/adtech/fintech/gambling проектах, де є реально великі навантаження, то вашою найскладнішою проблемою, напевне, було розслідування якогось хитрого бага, який не давав нормально рендерити формочки або конвертувати один XML в інший.

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

Щоразу я по-різному відповідав на це питання. Бувало, прямо казав, що в інституті мені треба було малювати граф зі стрілочками і там була складна тригонометрія. Іноді казав, що фіксив меморі ліки, а іноді — що мав терки з іншими відділами. Якось викручувався.

Далі, найімовірніше, будуть запитання щодо релевантних для вашої вакансії технологій, які перелічені у вас 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-техліда. Там, де мені треба було на співбесіді за півтори години написати робоче рішення. Отож, я мав розмову з головним архітектором, і він почав мене питати по задачі. Як зробити, щоб тут було більше даних? А від якщо в нас буде даних забагато і буде ВОМ, то що робити? А як можна попередити таку ситуацію? У цілому всі питання були спрямовані на те, щоб розібратися, як кандидат буде вирішувати більш складні задачі, які виникають при значному збільшенні обсягу даних.

Цю співбесіду я успішно пройшов і отримав офер.

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

Менеджерські та фінальні співбесіди

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

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

Якихось цікавих співбесід на цьому етапі у мене не було. Лише зачеплю тему переговорів.

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

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

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

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

Бонусні співбесіди

Ще я мав співбесіди у три різні компанії на позиції відповідно System 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 пари-трійки команд (загалом 20-25 голів). Їм потрібен більше менеджер, ніж технар. Враховуючи, що на аналогічній позиції з такою самою кількістю людей я вже відбатрачив у минулому кілька років, то мене розглянули. Сам я вирішив піти туди зі спортивного інтересу: дадуть офер — буду думати. Але великого бажання працювати менеджером у мене не було.

Спочатку був досить довгий (більше години) скрінинг по скайпу з рекрутером, де у мене з'єднання ясовували минулий досвід. Потім почали задавати питання на конфлікт-менеджмент, типу «Є співробітник, який працює у команді, де роботи не так багато. Потрібно його перевести в інші, але він не хоче. Що будеш робити?»

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

Я прийшов до офісу, де мене вже чекали 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 у пошуках роботи. Про задачі на технічних співбесідах і теоретичні питання

Опубліковано: 26/12/18 @ 11:00
Розділ web дизайн

Рекомендуємо:

Junior дайджест: курси, стажування, вакансії. Січень'19
Product Management дайджест #6: A/B тестування в Twitter, пріоритизація фіч за моделлю Кано
Python дайджест #18: new Python governance model
Огляд AR-очок Magic Leap: крок вперед чи проривний стрибок?
Вибір засобів для забезпечення життєвого циклу рішень