З сапорту в Back-end-інженери. Як я потрапив у ІТ без досвіду
Привіт! Мене звати Максим Ващенко, я Back-end Engineer у продуктовій ІТ-компанії OBRIO з екосистеми Genesis. Влітку 2022 року мені вдалося потрапити в ІТ без комерційного досвіду та поєднувати цю роботу з профільним навчанням. А за рік — перейти з сапорту в технічну команду. За цей час я пройшов цікавий шлях розвитку, яким хотів би поділитися.
Розповім, які навички прокачує робота у сапорті (спойлер: не тільки стресостійкість), як можна застосувати технічні знання у цій ролі, а також про свій перехід в Back-end-інженери. Ця стаття буде корисною всім, хто шукає першу роботу, але переймається відсутністю досвіду та боїться HR-фільтрів.
Чому сапорт
Ще зі школи я знав, що хочу бути програмістом. Після дев’ятого класу потрапив до коледжу при КНУ. Там отримав відмінну базу, яка допомогла успішно скласти іспити та вступити в КПІ імені Ігоря Сікорського на спеціальність «Інженерія програмного забезпечення». Планував протягом двох років зосередитися виключно на навчанні, а далі починати шукати першу роботу в ІТ. Але коли я вчився на другому курсі, почалася війна.
Влітку 2022 року ситуація була такою: більшість компаній поставили найм на паузу. А тих, кого наймали, навряд були студентами другого курсу без комерційного досвіду. Впевненості у своїх силах було ще менше. До того ж мій батько приєднався до Сил Оборони Україні, і я дуже потребував чогось, що допомогло б відволіктися від складної реальності.
Так вийшло, що мій знайомий, який вже працював у сапорті української ІТ-компанії OBRIO, запропонував мені приєднатися до їхньої команди. Потрапити туди було значно простіше, адже основними вимогами були знання англійської мови та софт-скіли. Я подався, пройшов всі етапи інтерв’ю і почав працювати.
Автоматизація рутинних задач і перші технічні виклики
Спершу моя робота складалася з рутинних завдань, типових для сапорту: білінг, відповіді на технічні питання користувачів, допомога з контентом тощо. Навчання в університеті проходило дистанційно, тож я міг поєднувати його з роботою. Поступово набирав темп, завдання ставали складнішими та цікавішими. Я відчував, що мої технічні знання можуть приносити користь, тому почав застосовувати їх.
Розробив автоматизовану систему збору даних для скасування підписок користувачів на основі ключових слів. Це суттєво зменшило ручну роботу та прискорило обробку запитів. На той момент я не мав доступу до Back-end чи тісної співпраці з технічною командою. Самостійно створив невелику інтеграцію з нашим ESP-провайдером та налаштував систему так, щоби вона автоматично збирала необхідні дані з Back-end різних вертикалей (Web і Mobile) і зберігала їх у нашій CRM-платформі.
Ініціював процес оскарження чарджбеків, що допомогло виявити та протидіяти випадкам дружнього шахрайства з боку користувачів. Розробив початкову документацію, на основі якої зараз працює білінг-команда.
Започаткував створення внутрішнього технічного сапорту для оптимізації роботи supply-команди. Раніше один інженер отримував багато запитів, що було неефективно. Ми знайшли рішення — спеціаліст акумулює запити, категоризує їх, частину вирішує самостійно, а інші направляє до технічної команди.
Загалом усі мої ініціативи отримували зелене світло і я з радістю реалізовував їх.
На мою думку, роль сапорт-менеджера в ІТ-компанії є досить недооціненою. Студенти часто уникають таких вакансій, обираючи з найгірших пропозицій за спеціальністю, бо важається, що тут немає карʼєрного розвитку та корисного досвіду. Насправді ж робота в сапорті дала мені можливість розвинути навички кроскомандної комунікації, вміння швидко реагувати на проблеми, а також отримати розуміння загальної картини продукту.
Ця роль також часто асоціюється з високим рівнем стресу, оскільки доводиться мати справу з негативними відгуками та скаргами користувачів. Проте більшість комунікацій відбувалася через текстові повідомлення, що значно знижувало рівень стресу. Крім того, я завжди намагався бачити не лише проблеми, але й можливості для покращення сервісу.
Як я потрапив у Back-end
Моя менеджерка звернула увагу на те, що я активно займаюся технічними завданнями у команді підтримки. Зрозумівши, що мій вектор розвитку лежить за межами сапорту, вона організувала знайомство з моїм майбутнім лідом — Олексієм Румянцевим. За кавою ми поспілкувалися про роль Back-end-інженера та можливий перехід у технічну команду. На той момент Back-end вебсервісів був побудований на Node.js / NestJS, з якими я майже не був знайомим. Back-end мобільних сервісів був написаний на PHP, який я знав, проте команда переводила його також на Node.js, тож він міг знадобитися скоріше для роботи з легасі.
Олексій порадив мені дорожню карту, за якою я міг би розвиватися. Більша її частина стосувалась вивчення Node.js. Я користувався ресурсом roadmap.sh: він показує, які навички та знання потрібно опанувати на кожному етапі розвитку та допомагає структурувати знання.
Back-end розробка на різних технологіях має багато спільного. Тож я сфокусувався на дослідженні принципів, притаманних Node.js, зокрема асинхронності та Event Loop. З цим дуже допомогли лекції Тимура Шемседінова, викладача ФІОТ, КПІ. Технології, які використовуються в OBRIO (NestJS, Prisma ORM, TypeORM) вивчав за документацією, відкритим репозиторіям в GitHub. Паралельно створював мініпроєкти для кращого розуміння інструментів на практиці.
Разом з цим улітку відкрилася Genesis Software Engineering School, і я подав заявку та пройшов відбір. Навчання поряд з іншими Junior та Middle-розробниками, які вже мали комерційний досвід, допомогло мені стати впевненішим та відчути себе частиною технічної спільноти.
Тоді ж я зрозумів цінність академічної освіти: університет надавав базові інженерні концепції та загалом вміння «навчатися». Коли ти звикаєш постійно поглинати інформацію у великих обсягах, навчання на курсах дається простіше. З іншого боку, курси були побудовані на сучасних вимогах ринку і практичних навичках, що теж було дуже корисно.
У нас з Олексієм не було чіткої домовленості, що після навчання я обов’язково приєднаюся до технічної команди. Адже це в першу чергу залежало від потреб бізнесу. Найм без реальної потреби недоцільний як для компанії, так і для самої людини, яка не матиме можливості розвиватися. Проте для мене зірки зійшлися — щойно я пройшов курси, в технічній команді з’явилася потреба у фахівці.
Своєрідним тестом стало завдання від CTO: розробити автоматизоване рішення для нашої внутрішньої системи винагород OBRIO Rewards з інтеграцією під Slack. Потрібно було забезпечити синхронізацію нагород, запитів на отримання, а також механіку шерингу «валюти» між колегами. Цією задачею я займався у вільний від роботи час, консультувався з HR-командою щодо оформлення, механік, а також проходив ревʼю в Олексія.
У результаті вийшов застосунок, написаний на Node.js. Він містив Back-end-логіку, повʼязану з операціями, балансами, користувачами, айтемами, синхронізацією даних з Notion. А також Front-End, а саме формування шаблонів, які будуть відмальовуватися в межах Slack. Результат усім сподобався.
Мій перехід із сапорту до технічної команди відбувався за активної підтримки мого менеджера, яка допомогла зробити його плавним та структурованим. Я передавав свої обов’язки новим членам сапорт-команди, займався онбордингом колег, ділився знаннями та підходами до вирішення нестандартних та складних кейсів, а також навчав колег обробляти та категоризувати запити, вирішувати проблеми, що повторюються, без залучення технічної команди.
Робота в технічній команді
Після переходу до команди Олексія почалася справжня хардкорна робота. Перші дні були ознайомленням з робочими процесами та технічною інфраструктурою. Багато чого було для мене новим. Наприклад, система таск-трекінгу в Jira та робота зі спринтами.
Під час інтенсивної адаптації до нових інструментів я продовжував вивчати Node.js, використовуючи різні ресурси для самонавчання. Також багато читав код проєкту, з яким планував працювати, та приходив до тимліда з питаннями. Він надавав мені значну підтримку, пояснюючи логіку тих чи інших рішень.
Майже одразу мене залучили до відповідальних задач з відокремлення та рефакторингу бізнес-логіки певних сервісів. Для мене це був виклик, і я багато комунікував з іншими інженерами, допитуючись, як краще все зробити.
Зараз я працюю в напрямі Chat Stream, який відповідає за функціональність чатів. Основні обов’язки такі:
- Робота з платежами. Розробка та оптимізація платіжних механізмів, впровадження нових бонусів та оферів для користувачів на різних платформах.
- Відповідальність за Back-end-сервіси — ChatStream та AskNebula, а саме за їхню стабільність, продуктивність та відповідність бізнес-вимогам. Сюди також входить моніторинг, налаштування метрик та забезпечення безперебійної роботи.
- Технічні покращення. Співпрацюю з командою над виносом бізнес-логіки в окремі сервіси, що підвищує масштабованість та підтримку коду. Також беремо участь у процесі об’єднання технологій в межах ініціативи Nebula United, яка спрямована на уніфікацію процесів та інструментів всередині компанії.
Замість висновків
Мій приклад — не єдиний. У нашій компанії є декілька карʼєрних історій про перехід із сапорту до інших ролей: Product Analyst, Product Manager тощо. Якщо у людини є хист та бажання рости в іншому напрямі, їй обовʼязково допоможуть.
Зараз я продовжую активно розвиватися у сфері Back-end-розробки, працюючи з більш складними та відповідальними завданнями. Планую поглиблювати знання в області масштабованих систем та хмарних технологій, а також брати участь у стратегічних проєктах компанії.
Разом із цим продовжую навчатися вже в магістратурі. Коли отримаю більше досвіду, хотів би спробувати себе як ментора або викладача, долучатись до освітніх проєктів.
Студентам, які тільки починають шукати роботу, я б порадив не боятися HR-фільтру, а спробувати шукати можливості для розвитку через інші професії. Якщо ви знайшли «свою компанію», нехай навіть в іншій ролі, вам допоможуть знайти правильний вектор розвитку. Крім того, завжди можна знайти способи застосувати свої технічні знання, пробуючи автоматизувати різні процеси.
Бажаю усім успіхів у пошуку першої роботи.
1 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів