UNIT.City — місце, де люди працюють... КРАЩЕ! Обирай свій простір просто зараз 👉
Марія БровінськаІсторії
11 жовтня 2025, 09:00
2025-10-11
«Робота з IoT — це як гра в Бога, але з кодом». Хімік із Харкова «не залишив науку, просто змінив формулу», самостійно вивчившись на розробника. Нині він оптимізує сервіси американської Mercury Intermedia й має власну апку
42-річний Android-developer Олександр Плєхов уже 12 років працює в IT. До нинішньої роботи в американській Mercury Intermedia, де українець займається оптимізацією наявних рішень та інтеграцією сторонніх сервісів, його привели не тільки роки досвіду в галузі. Річ у тому, що Олександр свічнувся в IT, маючи освіту хіміка, і він вважає, що саме природничий бекграунд допоміг йому вдало вибудувати кар’єру в IT.
Його шлях у сферу IT розпочався після здобуття ступеня магістра хімії в Харківському національному університеті імені В. Н. Каразіна, де Олександр отримав ґрунтовні знання з ресьорчу й пошуку рішень для складних завдань. Після практичного досвіду за фахом у 2012 році він самостійно перевчився на IT-розробника й розпочав кар'єру Mobile Developer. Упродовж своєї кар’єри Олександр працював над проєктами в різноманітних доменах, включно з IoT, Healthcare, e-commerce та медіа, і відомий своїм лідерством та ефективним управлінням командами. А ще Олександр — Senior Member IEEE.
dev.ua поспілкувався з розробником, який нині проживає в США, про світчинг, ідеальні мобільні застосунки, користь менторства й інтернет речей. Далі — пряма мова айтівця.
42-річний Android-developer Олександр Плєхов уже 12 років працює в IT. До нинішньої роботи в американській Mercury Intermedia, де українець займається оптимізацією наявних рішень та інтеграцією сторонніх сервісів, його привели не тільки роки досвіду в галузі. Річ у тому, що Олександр свічнувся в IT, маючи освіту хіміка, і він вважає, що саме природничий бекграунд допоміг йому вдало вибудувати кар’єру в IT.
Його шлях у сферу IT розпочався після здобуття ступеня магістра хімії в Харківському національному університеті імені В. Н. Каразіна, де Олександр отримав ґрунтовні знання з ресьорчу й пошуку рішень для складних завдань. Після практичного досвіду за фахом у 2012 році він самостійно перевчився на IT-розробника й розпочав кар'єру Mobile Developer. Упродовж своєї кар’єри Олександр працював над проєктами в різноманітних доменах, включно з IoT, Healthcare, e-commerce та медіа, і відомий своїм лідерством та ефективним управлінням командами. А ще Олександр — Senior Member IEEE.
dev.ua поспілкувався з розробником, який нині проживає в США, про світчинг, ідеальні мобільні застосунки, користь менторства й інтернет речей. Далі — пряма мова айтівця.
Зміст
Про «хімію» без хімії, або світчинг в IT
Я ніколи не шкодував, що пішов із науки. Це запитання, мабуть, одне з найважливіших, бо воно дає змогу показати, що мій шлях не був помилкою, а усвідомленим вибором. Я завжди бачив у цьому переході не відмову від науки, а її логічне продовження. Це був крок уперед, що дав мені новий інструмент для реалізації моїх творчих та аналітичних здібностей.
На перший погляд, хімія та Android-розробка — це абсолютно різні світи, але насправді між ними є дивовижна паралель. Моя магістерка з хімії навчила мене не просто запам’ятовувати формули, а мислити як творець. У лабораторії ти береш дві сполуки, змішуєш їх, і в результаті отримуєш абсолютно нову речовину з новими властивостями. У програмуванні все відбувається аналогічно: ти береш певні компоненти (функції, класи, дані), комбінуєш їх за правилами мови програмування, і на виході отримуєш готовий додаток. Обидві сфери вимагають творчого підходу, уваги до деталей і вміння розв’язувати проблеми, тому мій хімічний бекграунд виявився ідеальною основою для кар'єри в IT. Це був не перехід, а радше еволюція мого підходу до творення.
Моя наукова освіта — це не просто диплом, це потужний набір навичок, які виявилися критично важливими в програмуванні. Серед них я б виділив:
Системне мислення: у науці, особливо в дослідженні, ти вчишся розкладати складні проблеми на менші, керовані частини. Це ідеально відповідає роботі над кодом, де потрібно розбивати велике завдання на модулі та функції.
Логічний та аналітичний підхід: будь-яка наукова робота вимагає аналізу даних, висунення гіпотез і перевірки їх на практиці. Це абсолютно те саме, що я роблю під час написання коду: аналізую вимоги, пишу алгоритми та тестую їх, щоб переконатися, що вони працюють правильно.
Увага до деталей: в експериментальній хімії одна маленька помилка може зіпсувати весь результат. Ця педантичність дуже допомагає в програмуванні, де навіть пропущена кома чи неправильний символ можуть призвести до збою всієї програми.
Наполегливість і вміння експериментувати: іноді наукові експерименти не вдаються з першого разу. Те ж саме і в програмуванні — код не завжди працює, як очікувалося. Я навчився не здаватися після невдач, а продовжувати експериментувати, шукати нові шляхи та рішення.
«Я не залишив науку, я просто змінив формулу»
В університеті я створював нові речовини, а тепер створюю нові продукти та рішення у цифровому світі. Уся база, яку дала мені хімія — логіка, системність, уміння експериментувати — це те, на чому тримається моя кар'єра в IT. Ця зміна була не просто новим етапом, а справжнім професійним та особистісним розвитком.
Перехід в IT дав мені більше свободи. Це можливість працювати над різноманітними проєктами, обирати цікаві мені напрями та бачити результат своєї роботи значно швидше. У науці дослідження можуть тривати роками, перш ніж дадуть плоди. У розробці додатків я можу створити щось нове й побачити, як це допомагає людям, практично за лічені тижні. Ця динаміка та прямий зв’язок із кінцевим користувачем і є тим, що дає мені найбільше задоволення. Це свобода творити й бачити, як твої ідеї втілюються в життя.
Коли запитують, чи планую я повернутися в науку, це змушує мене замислитися. Я часто про це думаю, і, чесно кажучи, що більше часу минає, то більше я усвідомлюю, що моя експертиза в хімії як науці поступово втрачається.
Я не планую повертатися в науку в її традиційному розумінні — до лабораторії та пробірок. Це було б нереалістично. Проте я абсолютно не виключаю можливості об’єднати ці дві сфери в майбутньому, якщо випаде така нагода.
Сьогодні хімія та програмування перетинаються в багатьох захопливих напрямах — це й обчислювальна хімія, і розробка нових ліків за допомогою алгоритмів машинного навчання, і біоінформатика. Мої навички в програмуванні, особливо в роботі з даними та AI, могли б стати ідеальним інструментом для вирішення складних наукових завдань.
Для мене це не питання «або-або», а питання «і-і». Моя кар'єра — це не відхід від одного до іншого, а постійна еволюція навичок. Тому якщо з’явиться проєкт на стику цих двох світів, я буду готовий. Це був би ідеальний спосіб об'єднати мою першу пристрасть із моєю теперішньою професією.
IoT як особлива любов
З усіх доменів, у яких мені довелося працювати, а це IoT, e-commerce, healthcare та медіа, я можу з упевненістю сказати, що саме IoT (Інтернет речей) був і найскладнішим, і найбільш драйвовим. Це був досвід, який не можна порівняти з іншими.
Робота з IoT — це як гра в Бога, але з кодом. Найбільший драйв для мене був у тому, що я міг бачити фізичний результат своєї роботи. Якщо у звичайному додатку ти бачиш зміни на екрані, то в IoT ти пишеш код, і через мить загоряється лампочка, запускається робот чи відкриваються двері. Це магія, яка перетворює абстрактні рядки коду на відчутну взаємодію з реальним світом. Ця сфера вимагає нестандартного мислення, і це постійний потік нових ідей і можливостей.
Це особливо яскраво проявилося під час моєї роботи в компанії Ezlo, де я керував Android-розробкою. Я не просто писав код, а постійно шукав нові, оптимальні підходи для покращення продукту. Ці зусилля не пройшли дарма, адже наш продукт, Atom, був визнаний «Продуктом року у сфері споживчих інновацій IoT» (IoT Innovation Award Consumer Product of the Year) за версією IoT Breakthrough. Це стало яскравим підтвердженням того, що ми досягли поставлених цілей, і це, безперечно, було неймовірним драйвом.
Водночас IoT — це вершина складності. Ти не просто пишеш код для додатка; ти працюєш в екосистемі, де багато рухомих частин. Додаються апаратні обмеження, проблеми з мережею, питання безпеки та нестабільність підключень. Іноді код ідеальний, але пристрій не працює через втрату сигналу Wi-Fi, розряджену батарею або іншу фізичну перешкоду. Це вимагає від розробника не лише глибоких знань у програмуванні, а й розуміння апаратної частини, архітектури мереж і вміння розв’язувати проблеми, які не завжди можна відтворити на екрані комп’ютера.
Моя зацікавленість у складних технічних рішеннях і бажання ділитися напрацюваннями виходять за межі комерційної розробки. Нещодавно я опублікував наукову статтю на цю тему, демонструючи прагнення перетворювати практичний досвід на знання, доступні науковій спільноті. Зокрема, у статті «Wi-Fi Direct в Android: Створення безшовного зв’язку між пристроями» я дослідив ключові аспекти комунікації пристроїв, що є фундаментальним для екосистем Інтернету речей. Ця публікація стала підтвердженням того, що мої глибокі знання й інноваційні підходи активно використовуються не лише в комерційних продуктах, а й сприяють розвитку галузі через наукові видання.
Я маю нагороду «Innovation in E-Commerce Software Development». І вона стала підтвердженням того, що ми рухаємося у правильному напрямку. Я вважаю, що сфера e-commerce переживає зараз революцію, і найбільший прорив тут може забезпечити саме IoT (Інтернет речей).
IoT перетворює онлайн-комерцію з віртуальної на фізичну. Уявіть, що ваш холодильник сам замовляє продукти, коли вони закінчуються. Це не фантастика — це реальність, у якій IoT-пристрої стають новими точками продажу, а шопінг стає не вибором, а автоматизованим процесом.
Найважливіша перевага IoT — це можливість збирати дані про поведінку користувачів у реальному світі. Ці дані дають змогу створювати гіперперсоналізовані пропозиції й оптимізувати ланцюжки постачань, забезпечуючи повну прозорість. Так, IoT є не просто технологією, а ключовим чинником, що перетворює e-commerce на інтегровану, розумну та по-справжньому клієнтоорієнтовану екосистему.
Один з останніх проєктів, над яким я зараз працюю в Mercury Intermedia, — це потоковий сервіс для перегляду спортивних ігор. На перший погляд, він може здатися простим — звичайний плеєр для відтворення відео. Однак «під капотом» приховано багато цікавих і складних викликів.
Найбільше мене захоплює саме ця комплексна логіка та постійна робота з оптимізацією плеєра. Щоб забезпечити ідеальний перегляд без затримок і буферизації, потрібно враховувати безліч чинників: від якості мережевого з’єднання до потужності пристрою користувача. Це як гра, де ти борешся за кожну мілісекунду, щоб досвід користувача був бездоганним.
Також багато часу займає інтеграція та налагодження сторонніх бібліотек. Потрібно зробити так, щоб вони працювали ефективно та стабільно в нашій екосистемі. Це робота, яка вимагає глибокого розуміння системи й дає мені змогу постійно вчитися. Тож, як ви можете здогадатися, сумувати точно не доводиться.
Про застосунки й непопулярні рішення
Світ Android-розробки змінюється блискавично, і те, що було «must-have» вчора, сьогодні вже є стандартом або навіть застаріло. Для сучасної та якісної мобільної розробки я б виділив кілька ключових трендів, які стосуються як технологій, так і підходів.
Головний тренд останніх років, що перетворює підхід до UI-розробки, — це Jetpack Compose. Це сучасний декларативний UI-фреймворк, який замінює застарілу XML-верстку.
Він значно прискорює процес розробки, робить код чистішим та інтуїтивно зрозумілим. Іншим важливим кроком є Kotlin Multiplatform, який дає змогу використовувати одну кодову базу для бізнес-логіки як для Android, так і для iOS, що економить час і ресурси.
Зрозуміло, що сучасний додаток повинен бути швидким, надійним і працювати навіть без інтернету. Тому «must-have» є використання офлайн-персистенції (наприклад, за допомогою Room) і зв’язок із бекендом через корутини та flows, що спрощує роботу з асинхронними операціями. Використання Unidirectional Data Flow (UDF) і чистої архітектури є ключовим для створення масштабованих і легко підтримуваних додатків.
Окрім цього, сучасні додатки повинні бути не лише функціональними, а й інтуїтивно зрозумілими. Особлива увага приділяється:
Адаптивному UI: додатки повинні ідеально працювати на всіх пристроях — від смартфонів до планшетів, і навіть складаних пристроїв.
Інтеграції з AI/ML: використання штучного інтелекту для персоналізації, прогнозування та автоматизації завдань (наприклад, чатботи або рекомендаційні системи) стає стандартом.
Оптимізації продуктивності: додатки повинні бути легкими, швидко завантажуватися та мінімально споживати ресурси батареї.
Зростання кількості атак на мобільні пристрої робить також безпеку одним із найважливіших аспектів. Шифрування даних, двофакторна аутентифікація та регулярні оновлення є обов’язковими. Також слідкувати за інноваціями, такими як доповнена реальність (AR) або інтеграція з 5G-мережами та IoT, дає змогу створювати додатки, що відповідають вимогам майбутнього.
Олександр має власний проєкт «Клієнти&Візити», який народився, щоб розв’язати реальну проблему, з якою дружина-фахівчиня зі сфери краси стикається щодня: скільки часу й незручностей забирає запис клієнтів у звичайний паперовий блокнот. Тому додаток допомагає фрілансерам і малим підприємцям автоматизувати найважливіші аспекти їхньої роботи: облік клієнтів, планування візитів та їхня історія. Це рішення, яке дає змогу перейти від ручного запису до ефективної цифрової системи.
Зараз він стратегічно переглядає проєкт: відключив монетизацію, щоб набрати ширшу аудиторію та зібрати більше відгуків, що допоможуть йому зробити додаток ще кращим. Крім того, розробник активно інтегрує нові AI-інструменти та працює над повним оновленням дизайну. Хоча вільного часу не так багато, Олександр наполегливо рухається вперед, тому що вірить у потенціал цього проєкту.
Сатисфакція розробника додатків
Найбільше задоволення для розробника, коли його особистий проєкт знаходить свою нішу, — це відчуття самореалізації та підтвердження. Це не просто робота «на замовлення», а оживлення власної ідеї. Коли ти бачиш, що твій додаток дійсно розв’язує чиюсь проблему, це відчуття неможливо порівняти ні з чим.
Це унікальний вид мотивації. Ти пишеш код не заради зарплати, а тому, що ти глибоко вболіваєш за свій продукт. Кожен відгук від користувача, навіть критичний, сприймається як цінна інформація, що допомагає зробити проєкт кращим. Ця робота над додатком є справжнім відображенням моєї пристрасті до створення чогось нового, корисного й унікального.
Рефакторинг замість «латання дір»
Оптимізація та рефакторинг — завжди болюча тема.
Зрозуміти, що проєкт потребує повного перегляду архітектури, а не просто «латання дір» — задача із зірочкою. Це справді одне з найболючіших, але й найважливіших рішень.
Я сам зіткнувся з подібною ситуацією, коли вперше працював із великим застарілим проєктом у компанії Ezlo Innovation. Необхідність рефакторингу була очевидною, але я не знав, із чого почати. Водночас мені дуже допомогла книга «Рефакторинг. Покращення наявного коду» Мартіна Фаулера. Вона стала справжнім порятунком, оскільки дала чітке розуміння, як підходити до цього складного процесу, не ламаючи все наявне. Ця книга є чудовим ресурсом для тих, хто стоїть перед схожим викликом.
«Латання дір» стає неможливим за кількох умов.
Швидкість розробки катастрофічно падає. Якщо додавання нової, навіть невеликої функції займає аномально багато часу через заплутаний код, це перший і найголовніший дзвінок. Це сигнал, що технічний борг досяг критичної точки.
Виправлення однієї помилки створює нові. Коли код настільки заплутаний, що зміна в одній частині ламає іншу, це ознака сильної пов’язаності компонентів. У такому стані боротьба з багами стає боротьбою з «гідрою».
Проєкт не може масштабуватися. Якщо система не справляється зі зростанням кількості користувачів або даних, а будь-яка спроба її розширити вимагає колосальних зусиль, значить, її архітектура є фундаментально хибною.
Нові розробники не можуть швидко почати роботу. Якщо досвідченому фахівцю потрібні місяці, щоб розібратися в кодовій базі, це вказує на її повну неструктурованість.
Якщо ви помітили у своєму проєкті два або більше з цих симптомів, це означає, що час зупинитися й повністю переглянути архітектуру, а не витрачати ресурси на безрезультатне «латання дір».
Про лідерство й менторство
Керування командою — це зовсім інша гра, ніж індивідуальна розробка. Це зміна мислення з «що я роблю» на «як ми досягаємо успіху». Я б виділив три ключові речі, що відрізняють сильного Android-лідера від звичайного розробника.
Стратегічне бачення, а не просто виконання завдань. Звичайний розробник отримує завдання і виконує його. Сильний лідер бачить, як ця задача вписується в загальну картину продукту та бізнесу. Він не просто пише код, а будує архітектуру на перспективу, передбачаючи майбутні потреби та потенційні проблеми. Його мета — не просто закрити задачу, а забезпечити, щоб рішення було масштабованим, підтримуваним і відповідало довгостроковим цілям проєкту.
Менторство та розвиток команди. Розробник фокусується на власному зростанні. Лідер — на зростанні всієї команди. Він інвестує свій час у менторство, допомагає молодшим колегам вирішувати складні проблеми, ділиться знаннями та створює середовище, де кожен відчуває себе впевнено. Для сильного лідера успіх команди є пріоритетом. Він розуміє, що його роль — не бути найрозумнішим, а зробити так, щоб кожен член команди став кращим за нього самого.
Ефективна комунікація та пріоритизація. Звичайний девелопер спілкується здебільшого про технічні деталі. Лідер є містком між розробкою, менеджментом, дизайнерами й іншими відділами. Він перекладає бізнес-вимоги на технічну мову для команди і, навпаки, пояснює технічні обмеження та прогрес для бізнесу. Він майстер пріоритизації, здатний відсікти зайве і сфокусувати команду на найважливіших завданнях, які приносять найбільшу цінність.
Я часто виступаю в ролі ментора для стартапів. Участь у хакатоні — це не просто змагання на швидкість, а інтенсивний курс із розв’язання проблем.
Моя роль як ментора й судді — не в тому, щоб дати команді готову відповідь, яка приведе її до першого місця. Це було б нечесно і безглуздо. Натомість я намагаюся навчити їх самостійно знаходити шлях до перемоги.
Я фокусуюся на таких аспектах, як чітке визначення проблеми та пріортизація. Чи справді команда розв’язує ту проблему, яка є найважливішою? Що є «must-have», а що можна відкласти на потім? Також важливий аспект — створення цінності: як показати, що їхній проєкт не просто працює, а приносить реальну користь?
Швидко генерувати інноваційні технічні рішення яскраво проявилися під час нещодавньої участі у великому хакатоні «Shipaton 2025». Я очолив розробку проєкту Snovyda — додатка, який інтерпретує сни за допомогою штучного інтелекту. Цей проєкт став чудовою можливістю поєднати мій технічний досвід, зокрема у сфері мобільних платформ та AI-інтеграцій, із керівними навичками. Сподіваюся, наша команда буде переможцем.
Нагорода на хакатоні — це тимчасова радість. А от навички стратегічного мислення, уміння працювати в команді, ефективно керувати часом та ухвалювати складні рішення — це інструменти, які залишаться з ними на все життя. Вони зможуть застосувати їх у будь-якому майбутньому проєкті, стартапі чи на своїй основній роботі.
Тому коли я менторю, моя основна мета — дати команді не «рибу», а «вудку», щоб вони могли будувати успішні проєкти й після завершення хакатону. Для мене це набагато більша перемога, ніж будь-який приз.
Про помилки джунів
З мого досвіду менторства, я бачу одну і ту ж помилку у джуніорів знову та знову. Вона не технічна, а скоріше ментальна. Найбільша помилка — це фокус на «щасливому шляху» (happy path).
Коли джуніор отримує завдання, він насамперед думає: «Як зробити так, щоб цей код виконав свою функцію?» І він чудово справляється — пише функцію, яка виконує завдання, коли все йде ідеально.
Але реальний світ далекий від ідеалу. Користувач може втратити інтернет, забути ввести дані, натиснути не ту кнопку або спробувати використовувати додаток на пристрої з поганою батареєю. І саме тут додаток, написаний із фокусом лише на «щасливому шляху», почне падати або поводитися непередбачувано.
Досвідчений розробник завжди ставить собі запитання: «А що, якщо користувач не матиме підключення до мережі?», «Що станеться, якщо дані із сервера надійдуть не в тому форматі?», «Як додаток поведеться на маленькому екрані або при зміні орієнтації?»
Ця різниця в мисленні і є ключовою. Вона полягає в тому, щоб думати не тільки про те, як код виконує завдання, а й про те, як він поводиться в реальних, часто неідеальних умовах. Цей скіл приходить із досвідом і є одним із найважливіших для росту в професії.
Чи є життя після Senior тайтла?
Я Senior Member IEEE (Інститутe інженерів з електротехніки та електроніки). Я став Member IEEE у 2024 році, а у 2025-му, зібравши всі необхідні підтвердження досвіду та досягнень, подав заявку на статус Senior Member. Після ретельного рев’ю мою кандидатуру узгодили. Це ще раз доводить, що професійне зростання — це не випадковість, а результат цілеспрямованої роботи та визнання спільнотою.
Членство надає доступ до величезної бази знань. Це можливість бути в курсі найновіших досліджень, публікацій і технічних стандартів ще до того, як вони стають загальнодоступними. Для мене це постійне джерело інновацій та ідей, які я можу впроваджувати у свої проєкти. Насправді я зараз сам пишу технічну статтю в IEEE, що дає мені унікальну можливість не лише споживати знання, а й активно брати участь у їхньому створенні. Це своєрідний інструмент, який дає змогу залишатися на вістрі технологій.
На мій погляд, «скляна стеля» для Android-розробника існує лише в тому сенсі, що змінюється характер зростання. Це вже не про вивчення нових фреймворків чи мов програмування, а про перехід на абсолютно новий рівень мислення. Коли ви досягли рівня Senior, шлях розвитку розгалужується на кілька напрямків, і кожен із них вимагає нового набору навичок.
Технічне лідерство: стати інженером-архітектором. Цей шлях для тих, хто прагне залишатися ближче до коду, але на іншому рівні. Ви переходите від питання «як написати цю фічу?» до «як побудувати всю платформу?» Ви стаєте Principal або Staff Engineer. Ваша роль — розробляти архітектуру, яка буде стабільною й масштабованою на роки вперед, вирішувати найскладніші технічні проблеми та менторити інші команди. Це про вміння впливати на технічну стратегію компанії.
Лідерство над людьми: стати менеджером. Якщо вам більше до душі розвивати не код, а людей, то наступний крок — Team Lead або Engineering Manager. Тут ви переходите від індивідуальної роботи до управління командою. Ваші завдання — не писати код, а допомагати команді бути продуктивною, вирішувати конфлікти, наймати нових людей і розвивати їхні кар'єри. Це перехід від суто технічних навичок до Soft Skills: комунікації, емпатії та стратегічного планування.
Підприємництво: створення власного продукту. Це найсміливіший шлях. Він про те, щоб узяти на себе повну відповідальність за продукт, від ідеї до монетизації. Тут ви не лише пишете код, а й стаєте дизайнером, маркетологом, фінансистом і лідером проекту в одній особі. Мій додаток «Клієнти&Візити» є ідеальним прикладом такого розвитку. Це не лише можливість перевірити всі свої навички, а й шанс створити щось, що має реальну цінність на ринку.
«Скляна стеля» зникає, коли ви розумієте, що кінцева мета — це не статус, а вплив. Ви можете впливати на архітектуру, на людей, на ринок. Головне — знайти той напрям, де ви зможете принести найбільшу користь і продовжувати вчитися вже там.
Куди розвиватися Manual QA, коли впираєшся у професійну стелю? Велика розмова з тестувальником зі Львова, який підкорив ринок США й рухається в бік позицій Staff, Principal і Technology Leader
«Я вчився Data Science із 4 років. Кожен урок математики був важливим». Історія математичного генія з невеличкого села на Волині, що нині створює LLM для Lyft, Reface та AppFlame
«Я звільнився з американської компанії заради українського miltech-проєкту». Історія випускника КПІ, що врятував американський healthtech-стартап від краху, створив мініконкурента Netflix, а нині готує ШІ-систему захисту від російських FPV
«Замовники й PM жартували, щоб я не поспішала та трохи розслабилася». Як розробниця зі Львова будує AI-Healthcare систему в США: інтерв’ю з українкою, яка підкорила глобальне IT
«Я не шукав роботу, мене звабили. Team Lead мене змусили стати». Історія Senior AQA, який увійшов в IT у 39 років, і вже 10 років про це не жалкує
Діма Наумов — Senior AQA в Capgemini Engineering. 10 років він працює тестувальником, і готовий ламати всі можливі стереотипи про вхід в IT. Діма став айтішником у 39 років, залишивши успішну кар'єру в фінансовому світі та продажах.
Свою історію чоловік розповів dev.ua.
«Треба вірити в себе та йти (чи хоча би лежати) в бік своєї мети». Історія бухгалтерки, яка стала розробницею та виросла до Team Lead і ментора
Немає більш слушного часу для змін, аніж сьогодні. Шлях до професії мрії може бути ретельно спланованим зі шкільної парти або тернистим і сповненим пригод. Своїм досвідом переходу з позиції бухгалтера в ІТ-компанії до frontend-розробниці на проєкті в ній же ділиться Наталія Сингаєвська, Frontend Engineer у Levi9. Вона знайшла своє призначення та за чотири роки зросла зі стажистки до Team Lead на проєкті в Лондоні.
«Розіслала 200+ резюме, фідбек поки негативний». Як вінницька лікарка тимчасово застрягла на порозі входу в IT
Софія Тимошенко — сімейна лікарка в одній із приватних лікарень Вінниці. Зі своїх 25-ти років 8 вона присвятила навчанню медичній справі та подальшій роботі у сфері. Проте сьогодні в дівчини є нова ціль — стати айтішницею. Наскільки можливо новачку безболісно «ввійти в IT» — читайте в нашому матеріалі.
