Робота архітектором та розвиток власних проєктів у США

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

Усім привіт!

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

На DOU публікуватиму найважливіше з розмов.

Говорила з Дмитром Сподарцем. Дмитро більше ніж 15 років у IT. Інженер із фокусом на Cloud, HPC та AI/ML технології. Працював науковцем та викладачем в університеті.

Підприємець: був засновником ряду продуктових компаній, а зараз розвиває власне media та глобальне AI&Data ком’юніті у США Data Phoenix.

Останні декілька років працює DevOps Architect у компанії Grid Dynamics та живе у США. До цього працював Director of Product Engineering в американському стартапі.

Його телеграм-канал

Благодійний воркшоп Діми на підтримку Охматдиту: Майстерня з MLOps: AI від досліджень до деплою у продакшн



  • Який вигляд має роль DevOps-архітекта в американській компанії? Скажи, ти бачиш якісь особливості?

Я не працював ніколи архітектором в Україні, тож досить важко порівнювати. Можу поділитися, що таке DevOps-архітектор у нас в Grid Dynamics і що я роблю.

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

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

  • А знаєш про якісь особливості в роботі DevOps-ів саме в американських компаніях?

З погляду ролі я не бачу різниці між DevOps в Україні та тут.

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

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

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

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

  • Вони не сприймають звільнення як щось особисте, на відміну від нас. І я знаю, що американські компанії дають пакет 4 місяці зарплати після звільнення. Американські компанії, які працюють у нас в Україні, також. Я знаю такі компанії, які звільнили людей, дали 4 місяці зарплати, а потім знову найняли цих же людей, і ці люди просто 4 місяці сиділи відпочивали, а тоді повернулися. Коротше, дуже цікаво і далеко не завжди нам зрозуміло. Особливо те, як можна так зранку прийти, а ти не працюєш.

У великих компаніях тобі дають цей пакет підтримки, у маленьких стартапах таке дуже рідко буває.

  • Багато людей мені в особисті писали: «Віка, а чому Діма після директора в Product Engineering та власного бізнесу пішов у DevOps-архітектуру?». Ти сказав, що був COVID, і зараз anyway ти свій проєкт розвиваєш, так?

Ну так, в принципі, коли я потрапив під lay-off, було дуже тяжко знайти щось саме в Product, пов’язане з Product. І через те, що в мене досить великий технічний Сloud DevOps background, і я, в принципі, колись починав як системний адміністратор, то роль такого DevOps-архітектора здалася дуже цікавою. Я б сказав, що дуже швидко, за американськими мірками, пройшов усі інтерв’ю та потрапив до нової компанії. І тут ще один цікавий момент, чого в мене не було: я ніколи не працював із дуже великими компаніями, і якраз ця роль мені дала можливість почати працювати з топовими компаніями Штатів. Тож тепер я знаю, що таке розвивати маленький стартап, і як влаштований великий-великий enterprise, і чим це все відрізняється.

  • Знаєш, є такий bias досить поширений, що працювати в аутсорсинговій компанії це таке собі, а в продуктовій завжди круто. Скажи, що ти думаєш про це?

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

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

  • До речі, зараз досі багато аутсорсингових компаній розробляють продукти для клієнта просто end-to-end. Це не зовсім такий аутсорс, як він був раніше. Скажи, будь ласка, коли тебе наймали, які питання ставив саме клієнт до тебе? Чи побачив ти якусь різницю в співбесіді саме американською компанією?

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

  • Ну, тобто, не було спеціальних таких якихось питань, нічого такого не було, так?

Такого, ні, не було.

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

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

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

Тому на інтервʼю варто звертати увагу, чи зможе інженер сам знайти відповідь. Різні бувають ситуації, але так, це теж має сенс перевірити.

  • До речі, ще таке питання. У тебе періодично була робота на себе, потім ти там був кофаундером, потім працював в інституті. Тобто, в тебе досить багато такого фаундерського досвіду. Скажи, будь ласка, чи були в тебе якісь питання від роботодавців на кшталт: «У тебе є підприємницький досвід, чи будеш ти працювати з нами довго?». Тому що це такий страх більшості компаній: якщо у кандидата був досвід підприємця, то він піде. Чи були в тебе такі запитання від роботодавців?

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

  • Передавали таке питання: які AI тулзи ти використовуєш для написання скриптів та наскільки це реально економить час?

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

У мене для себе є розгорнута Llama 3, і я там інколи з нею граюся, якщо мені потрібно щось таке зробити. І це повністю приватне, тобто нікуди ніякі дані не будуть відправлені, я це знаю.

Інколи я використовую той самий ChatGPT, але теж фактично не для робочих питань.

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

  • Тут, до речі, є запитання, яке продовжує попереднє запитання. А як ти бачиш розвиток штучного інтелекту в архітектурі додатків? Чи DevOps замінить ШІ, чи буде відкат від клаудів? Що ти думаєш?

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

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

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

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

Але це потрібно дивитися на короткострокову/довгострокову перспективу, а ще на те, яке завантаження в тебе є, чи має це сенс, чи ні. Healthcare, наприклад, ти не завжди можеш у клауді все розвернути, це має бути десь локально.

  • У нас зараз така буде низка питань більше про Штати. Ти працював віддалено в американському стартапі, а зараз — onsite. У чому для тебе принципова різниця? Чи реально отримати роботу віддалено, і як саме це можна зробити? Які тенденції ти зараз бачиш щодо Remote Work? Як ти це бачиш?

Коли я працював у стартапі віддалено, а потім приїхав, і ми працювали вже локально, я можу сказати, що віддалено було лайт-версією. А ось коли я приїхав, почався такий хард-кор. Тому різниця фактично буде в тому, що якщо ви приїжджаєте в Штати, то, скоріш за все, вам доведеться, скажемо так, фігачити і фігачити. Роботи буде досить багато. Про те, чи реально знайти віддалену роботу, мені здається так. Якщо подивитися на ринок Каліфорнії, Сан-Франциско, то тут він досить перегрітий, і компанії так чи інакше починають дивитися на те, кого де можна захантити віддалено. І в принципі, мені здається, досить багато вже з’являється вакансій, де є опція ремоут.

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

Тому тут потрібно просто моніторити, з якими компаніями хотілося б працювати, і дивитися, які в них є вакансії.

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

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

  • Скажи, будь ласка, чим, на твій погляд, відрізняється інженер у США від інженера в Україні з точки зору спілкування з командою та софт-скілів? Чи правда, що продаж та менеджмент краще в Штатах, а R&D — в Україні й Польщі?

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

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

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

Коли я працював у місцевому стартапі ми фактично наймали тільки PhD-шників з ТОПових вишів, таких як Берклі чи Стенфорду, тому там левел був досить непоганий.

  • Що ти в цілому порадив би інженерам, які хочуть співпрацювати з американськими компаніями? Що вчити, як готуватися до інтерв’ю?

По-перше, треба визначитись, у яку компанію є бажання подаватись, який стек технологій там є, і вже від цього відштовхуватися. Якщо глобально, то це вивчити Клауди, вивчити Kubernetes, якщо не знаєте, вивчити різні тулзи для CI/CD, і це буде залежати від того, що саме використовується в цих компаніях.

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

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

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

  • Які плюси та мінуси для власного продуктового бізнесу на ринку США? Твій бізнес зараз працює на ринку США, я маю на увазі, ти маєш теж свій проєкт. Що пішло, що ні?

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

У мене це першочергово був проєкт-хобі, який потроху почав переростати в медіапроєкт. Ми починали з невеличкого дайджеста, який я сам писав. Зараз ми вже пишемо в день по кілька новин, випускаємо дайджест, проводимо вебінари. Кількість наших користувачів, вже перейшов відмітку 10 тисяч. Фактично ми більше були сфокусовані на тому, щоб зростати у кількості якісної аудиторії. Зараз у нас буде інше завдання: «а тепер спробуймо знайти робочу бізнес-модель для цього всього».

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

В цілому зараз у Долині в середньому на день проводять десь 3-5± мітапів тільки з теми АІ.

  • Коли, на твою думку, ринок IT підніметься знову? Чи ти вважаєш, що цифри інвестицій повернуться після кризи?

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

Українське ком’юніті тут постійно збирає і відправляє донати. Я сам робив курс попереднього року та збирав на КОЛО. Але ми зрозуміли, що краще спробувати допомагати саме конектити українські компанії з місцевими компаніями. Це може якраз більше дати користі індустрії та в цілому розвитку всього, що в нас є в Україні. Тому, мені здається, це все залежить від тих, хто створює та розвиває зараз індустрію в Україні.

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

  • Які дорогі фейли, дорогі у всіх сенсах, були в тебе, і чому вони тебе навчили?

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

А потім, коли дивишся, що ця компанія вже підняла понад 150 мільйонів, то ти такий: «Так, це був цікавий момент».

  • Ти вважаєш, якщо б вони купили, це було б плюсом для тебе, для твого бізнесу?

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

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

Що ще такого цікавого було? Декілька разів, не маючи досить гарного досвіду побудови віддаленої команди, я провтикував комунікацію між усіма ключовими співробітниками. І для мене потім стало таке правило, що якщо будується якась команда, то дуже добре, якщо основна команда перебуває в одному місці. Тобто, зібрати кор-команду в одному місці, а не будувати її повністю розподіленою. Хоча в деяких компаніях це досить гарно виходить. То може, я ще не навчився так робити.

  • А скажи, будь ласка, про work-life balance. Що ти думаєш про це? Як у тебе з work-life balance зараз?

Ну, я стараюся його так дотримуватись, і в принципі у мене виходить, що я працюю десь із сьомої ранку до третьої-четвертої. Тому що я якраз по East Coast тайм-зон працюю, і в мене такий зсув є. І далі я займаюся спортом, з малим гуляємо. Тому такий ось якийсь баланс є. Але за рахунок того, що є ще свій проєкт, інколи цей баланс вилітає в нуль.

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

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному1
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

Велике дякую за транскрипт.
Це справді тут рідкість

От бачите, слово девопс приклюється до всього
Навіть до архітектора
Навіть до продукт овнера чи тестувальника

Всі практикують девопс

Тема корисна, але оформлювати для ДОУ ви все ж полінувались

Почекаю наступних тем з кращим оформленням

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