Перша робота в Samsung, потім — Meta та Instagram: український розробник — про те, кому не сподобається бігтех

У студентські роки Вадим Пінчук випадково захопився мовою програмування Java. Потім він влаштувався у Samsung, де так само випадково став мобільним розробником. Після цього Вадим змінив не одну компанію, поки не поставив собі за мету потрапити у бігтех. Останні два роки він працює над застосунком Instagram у Meta.

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

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

Досьє:

Вадим Пінчук — Mobile Software Developer у FAANG, з 2021 року розробляє застосунок Instagram. Живе та працює в Лондоні.

Лектор курсу-професії Flutter Mobile Developer у robot_dreams. Має 8 років досвіду Android-розробки та 3 роки кросплатформної мобільної розробки Flutter. Веде технічні блоги на HackerNoon і Medium, менторить програмістів-початківців на ADPlist.org.

Вадим Пінчук — лектор курсу Flutter Mobile Developer

«Реферальні програми — найефективніший шлях у FAANG»

— Одразу після випуску з університету ви потрапили у Samsung. Чи свідомо ще зі старту хотіли працювати саме у великих міжнародних компаніях?

Ні, насправді й мій вибір стати програмістом не був дуже свідомим. У виші я навчався за спеціальністю «Захист інформації в комп'ютерних системах і мережах» — це скоріше про криптографію та алгоритми. А програмування мені здавалося нудною роботою: писати код, який ніхто не бачить, але він якось працює (сміється).

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

У київський R&D-офіс Samsung я прийшов у 2012 році, це була моя перша робота. Компанія тоді активно розширювалася, і я вдячний за те, що вони брали вчорашніх студентів. На інтерв’ю перевіряли здебільшого теорію та дали кілька легких алгоритмічних і математичних задач.

Оскільки я не мав жодного досвіду, компанія могла призначити мене на будь-яку Junior-роль — залежно від своїх потреб. Вже у команді мені сказали, що я буду Android-програмістом. Я здивувався, адже майже нічого не знав про мобільну розробку. Але поступово навчився і зараз радий, що все склалося саме так.

— Що було далі? Як розвивалася ваша кар’єра?

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

У 2015 році я пішов із компанії та протягом наступних років змінив ще кілька місць роботи як Android-розробник. З середини 2018 року перейшов на кросплатформну розробку — мене захопив цей шлях після того, як на конференції Google I/O презентували фреймворк Flutter.

Зрештою у 2021 році влаштувався у Meta (тоді ще Facebook) — для цього знову повернувся до нативної розробки під Android.

— Як потрапили до Meta? Чому обрали саме цю компанію?

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

До інтерв’ю я інтенсивно готувався близько 4 місяців, а загалом весь процес зайняв десь 9 місяців до отримання офера. Зазвичай інтерв’ю у FAANG складаються з кількох етапів:

• Coding — перевіряють підхід до нечітко поставлених задач, вміння уточнювати потрібні деталі, озвучувати думки та власне писати читабельний та робочий код;
• System Design — визначають ваш масштаб мислення, чи ви вмієте думати поза рамками та проєктувати великі системи, маючи обмежені вхідні дані;
• Behavioral — дивляться, як ви працює в команді, чи можете комунікувати зі стейкхолдерами, як розв’язуєте конфлікти й працюєте над фейлами.

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

Підготувавшись, я попросив друзів з Amazon, Google та Meta надіслати моє CV рекрутерам через внутрішні реферальні програми. Це найефективніший шлях у FAANG, адже він збільшує шанс відбору кандидата на співбесіду — як спеціаліста, за якого готові поручитися поточні працівники компанії.

В Amazon я не дуже хотів працювати: з огляду на те, що чув від працівників компанії, а також власне з їхніх принципів лідерства я зрозумів, що це не моє. Тож у цю компанію я подавався заради того, щоб здобути досвід інтерв'ю та зрозуміти, де саме потрібно підтягнути знання, аби бути готовим до конкурсу в Google та Meta.

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

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

«У вас з’являється можливість впливати на життя мільйонів користувачів. Але це не завжди перевага»

— Як ви стали частиною команди, яка створює Instagram? Що саме розробляєте?

Моя робота в Meta почалася з буткемпу, де я міг познайомитися з різними проєктами та обрати свій. У мене одразу було два фаворити — WhatsApp та Instagram. Спочатку я більше схилявся до WhatsApp, там була класна команда і крутий менеджер.

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

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

Щодо продукту і про щоденні завдання розповісти не можу через NDA, але зазвичай вони залежать від етапу проєкту:

• на початкових фазах завжди багато мітингів, узгоджень, побудови роадмапів;
• потім — розробка, репортування про прогрес, доставка нової фічі користувачам, а також аналіз того, наскільки успішним виявився проєкт.

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

— У чому особливості роботи у бігтех? Які є переваги та недоліки?

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

Робота у вертикальній осі полягає у співпраці з XFN (cross-functional) членами команди, як-от дизайнерами, рисерчерами та власне директорами й усім менеджментом. Робота по горизонтальній осі — це робота з сусідніми командами, у цій же організації або навіть ширше.

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

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

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

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

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

Здебільшого я працюю зі стеком Android. Також, як і скрізь у бігтех, у Meta є багато внутрішніх мов програмування та фреймворків. Деякі фреймворки мають відкритий код і можуть використовуватися публічно, на мою думку, в чомусь навіть переважаючи такі технології, як Jetpack Compose. Однак адаптація декларативного UI, як-от Compose, відбувається поступово і всі інструменти тісно взаємодіють один з одним.

Конкретний стек залежить від проєкту й команди. Наразі є загальна тенденція оновлення коду з Java на Kotlin, і на сьогодні код майже повністю конвертований у Kotlin. Адже Java — вже доволі застаріла мова, яка тягне за собою багато непотрібних речей, що не використовуються в сучасному мобільному світі.

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

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

«Є тренд, що дедалі більше нативних розробників переходять на кросплатформу»

— У robot_dreams ви викладаєте Flutter і Dart. Чим цікаві ці технології?

• Flutter — це кросплатформний фреймворк, який створили в Google. Він дозволяє розробляти застосунки під Android, iOS, web, Windows, Linux і macOS. Для перших двох застосунок точно працюватиме чудово, для інших — доволі непогано. Для десктопів потрібно буде підлаштувати. Творці Flutter надихалися React Native, але у багатьох речах він досконаліший та суттєво швидший.
• Dart — мова програмування, яка використовується у Flutter. Її теж створили в Google ще у 2011 році — як внутрішню мову. Спочатку вона використовувалася на чистому бекенді, а згодом поширилась і на фронтенд. Dart не всім подобається, адже виглядає доволі дивно — як гібрид JavaScript, Kotlin і Java. Водночас вона не схожа на жодну зі старих зрозумілих мов.

Одна з особливостей мови Dart — у тому, що вона однопотокова. З одного боку, це мінус — неможливо виконувати обробку даних у паралельних потоках. З іншого — плюс, адже не потрібно керувати доступом до одного обʼєкта в памʼяті з різних потоків, а тому менше вимог до знань розробника. До того ж можливо запустити окремий Isolate (щось типу Worker або Service з Android-світу) для обробки даних в окремому процесі, і тим самим розвантажити головний процес, у якому працює додаток.

І Flutter, і Dart стрімко розвиваються. Наразі ці технології широко використовують у Google, Alibaba Group, BMW, eBay та інших менших, але не менш відомих компаніях.

— Мобільним розробникам-початківцям є сенс одразу вчити Flutter? Чи краще почати з нативних фреймворків?

Мобільний пристрій — це середовище з обмеженими ресурсами, тому застосунок має дуже чітко керувати ресурсами процесора: не витрачати зайву пам'ять, заряд акумулятора, інтернет-трафік. Крім того, особливість мобільної розробки — у необхідності отримувати дозволи на використання камери, контактів, Bluetooth тощо.

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

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

— А завдяки чому Flutter витісняє React Native?

React Native був першим фреймворком із декларативним UI. Наприклад, старий нативний Android вимагає використовувати мову XML для опису UI, а також Java або Kotlin для опису бізнес-логіки між UI-компонентами.

Певно, розробники Flutter надихалися React Native. Але у нього зовсім інші принципи роботи. А головна перевага — в тому, що він новіший. І спільнота не перестає його розвивати.

Flutter зʼявився в компанії Google та активно розвивається як опенсорс-проєкт — завдяки тому, що Google підтримує Flutter-спільноту.

Втім, згідно з останніми даними, працівники Google складають лише 1% від усіх розробників, які роблять активний внесок у покращення фреймворку. Решта 99% — це програмісти з різних компаній по всьому світу, які є частиною великої спільноти. Завдяки такій залученості більшість проблем розв’язується швидко. Однак є і зворотний бік медалі, властивий будь-якому опенсорсу, — не всі люди пишуть гарний код або розв'язують проблеми правильно.

— Яким ви бачите майбутнє мобільної розробки? Воно — за кросплатформними фреймворками?

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

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

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

Водночас є тренд, що на кросплатформу переходить дедалі більше нативних розробників з усіх платформ — iOS, Android, веб. До речі, нещодавно JetBrains випустив Compose Multiplatform і Kotlin Multiplatform. Тож Android-розробники, які знають Jetpack Compose та Kotlin, тепер можуть писати кросплатформні застосунки за допомогою цих фреймворків.