Genesis — це українська компанія, 90% співробітників та керівників якої від початку повномасштабного вторгнення залишаються в Україні. Майбутнє компанії, як і майбутнє більшості українських бізнесів, залежить від якості освіти та рівня випускників університетів. Аби конкурувати з найбільшими світовими лідерами, потрібно мати освіту, рівень якої не поступається світовому. Співзасновник і СЕО Genesis виступив із лекцією на внутрішньому мітапі для генезійців в межах Internal Education Week. Володимир Многолєтній розповів, чому Genesis приділяє багато уваги освіті та скільки і в які освітні напрями інвестує. В цій колонці ми зібрали найважливіші тези з виступу Володимира. Навіщо ми інвестуємо в освіту? IT-компанія — це насамперед люди. Крута IT-компанія — це висока щільність талантів на один квадратний метр. Якщо вам вдалося зібрати в компанії багато талантів, то з певного моменту ця спільнота буде допускати до себе лише фахівців такого ж високого рівня. 80% успіху керівника — це вміння наймати й утримувати талановитих людей. Якщо СЕО зібрав і зміг утримати круту команду, то його життя стає досить простим, і вивільняється купа часу для інших задач: стратегії, фандрейзингу, IPO тощо. Тут вже кожен обирає сам. В мене є певний підхід до найму, який дозволив зробити Genesis успішною компанією. Передусім я шукаю людей, що здатні системно мислити та системно приймати рішення. За моїми спостереженнями, 80% таких людей — вихідці зі STEM, тобто зі студентів, що вивчали фундаментальні науки. Маю зазначити, що знаю багато талановитих людей, які закінчили гуманітарні університети, але більшість «системників» — це саме випускники технічних спеціальностей. Освіта навчила їх системно мислити або покращила природний талант. Вона навчила їх таких механізмів прийняття рішень, що вони можуть стати успішними у будь-чому: від науки до вирощування квітів. Я за першою освітою — ядерний фізик, за другою — економіст. Не займаюся нині ні тим, ні іншим, проте навички, що дала мені моя академічна освіта, дуже допомагають в бізнесі й зараз. Ми прагнемо побудувати системну компанію, яка буде значно більшою, ніж є нині, і тому нам важливо мати доступ до талантів із сильним освітнім бекграундом. Системна людина з якісною освітою та хорошим трек-рекордом роботи в інших компаніях, скоріше за все, швидко «приживеться» в Genesis. Саме тому ми вже не перший рік інвестуємо в освіту в індустрії та в Україні загалом на стратегічному рівні. Що саме ми робимо? Якщо розглянути економіку традиційних університетів в Україні, то найперша фундаментальна проблема, що впадає в очі — їхня збитковість. Ба більше, це ще й неможливість стати прибутковими у майбутньому. Саме тому я маю тверде переконання, що ми як компанія маємо працювати з університетами й допомагати їм. У Genesis є низка проєктів, які охоплюють пряму співпрацю з найкращими університетами в країні. Ми регулярно інвестуємо кошти у реновацію освітніх просторів, у спільні школи, проєкти, спільні лекції, допомагаємо безпосередньо викладачам. Щорічно ми інвестуємо у напрям роботи з університетами приблизно $1 млн. Ще один важливий напрям — Всеукраїнський курс «Створення та розвиток IT-продуктів». Його ідея виникла, коли ми зрозуміли, що можемо працювати не лише з топовими ЗВО, а й зі студентами регіональних університетів. Так, ми не можемо туди поїхати з лекціями, проте можемо створити диджитал-формат для них. Тож ми оцифрували лекції й створили курс про продуктове IT, який викладачі в регіонах можуть імплементувати у свою програму. Наразі цей курс пройшли вже понад 10 000 студентів по всій країні, а 1000 викладачів готові інтегрувати його в освітній процес. Наш план на майбутнє — 30 000–50 000 студентів на рік, які опановуватимуть курс. Для нас цей проєкт — інвестиція у майбутнє IT-індустрії в Україні. Непринципово, чи прийдуть потім ці студенти працювати в Genesis. Якщо вони доєднаються до української IT-спільноти та працюватимуть із цифровими продуктами у будь-якій українській компанії, це означатиме, що наші зусилля не були марними. Третій напрям інвестицій — це Genesis Academy, екосистема наших освітніх проєктів: профільні школи за різними напрямами, курси й інтенсиви. Основна мета — розповісти учасникам, які вже мають фундаментальну освіту, як працює продуктова компанія. Нині в нашій екосистемі й поза нею є багато талановитих фаундерів та СЕО, які свого часу закінчили ці школи. Унікальний проєкт в освітній екосистемі — Startup Academy together with Meta. Свого часу компанія Meta, з якою ми тісно співпрацюємо, запропонувала нам зробити спільний проєкт для стартапів, аби навчати майбутніх фаундерів тому, як будуються та масштабуються великі IT-компанії. Нині це єдиний приклад подібної освітньої колаборації в Україні. Інвестиції чи благодійність? Щороку ми виділяємо бюджет на освітні програми, враховуючи, що повернення інвестицій в тому чи іншому вигляді нам принесуть від 30% до 50% освітніх ініціатив. Що це може бути? По-перше, ми прагнемо генерувати талановитих фахівців, аби залучати їх до Genesis. По-друге, нам важливо, аби про компанію та її продукти знали на ринку. Відповідно, близько половини всього, що ми робимо у сфері освіти — це благодійність, від якої ми не очікуємо жодних повернень інвестицій. Це, наприклад, Всеукраїнський курс зі створення IT-продуктів, стартап-академія та інші. В Україні є 300 000 фахівців, які зараз працюють в ІТ. Чому вони працюють в цій індустрії? Тому що українці успадкували непогану базу технічної освіти. Ми маємо розвивати й підтримувати IT-освіту в Україні, аби наша індустрія продовжила існувати й рости. Якщо дивитися з цього боку, то наша благодійність — не зовсім благодійність, а віра в те, що якісна освіта неодмінно зростить майбутні покоління талантів.

Операційний директор Genesis Артем Копанєв став учасником нового рейтингу українського Forbes «30 до 30. Творці майбутнього». Він є одним із чотирьох представників IT-сфери в цьогорічному рейтингу молодих українців, які досягли успіхів у своїх сферах до 30 років. Артему Копанєву 27 років, він випускник Київського національного економічного університету за спеціальністю «Фінанси». Розпочав свою кар’єру на позиції фінансового аналітика в аудиторській компанії Ernst&Young у відділі супроводу угод. ​ У 2017 році долучився до команди Genesis як Operations Manager. У 2018–2020 роках Артем побудував роботу операційної команди Glovo під час виходу на український ринок і захоплення лідерської позиції на ньому. З 2020 року — знову в команді Genesis, пройшов шлях до СОО. Нині Артем керує бізнес-процесами екосистеми, бере активну участь у стратегічному розвитку та масштабуванні бізнесів, а також наймі топменеджменту. Артем Копанєв є лектором всеукраїнського курсу «Створення та розвиток ІТ-продуктів» та «Genesis StartUp Academy Together with Meta» — спільного з компанією Meta курсу для підприємців. Також викладає курс «Продуктове IT» у Київській школі економіки. Про рейтинг Forbes 30 до 30 30 до 30 від Forbes — набір списків із 30 людей віком до 30 років, які мають видатні здобутки у різних сферах. Списки щороку формує журнал Forbes та його регіональні версії. Український список виходить цього року вчетверте. До торішніх рейтингів «30 до 30» потрапляли СЕО Promova Андрій Скрипник, Олена Мажуга й Олексій Єрмоленко з інвестиційного фонду Flyer One Ventures.

Транзакція — це основна робоча одиниця при взаємодії з базою даних. Катерина Медведська, Data Еngineer в Boosters, на мітапі генезійського бекенд-ком’юніті розповіла HBJ про особливості транзакцій в базах даних, гарантії, які надають AСID-транзакції та про те, навіщо потрібні різні рівні ізольованості транзакцій. Катерина працює в Boosters більше року. Раніше вона понад десять років працювала в сфері автоматизації торгових підприємств. Відповідала за автоматизацію торгових і складських процесів, обліку залишків. Працювала з оптимізацією баз даних — як для збільшення пропускної здатності конкурентного доступу, так і для вирішення проблем з блокуваннями. Публікуємо конспект з найважливішими тезами з виступу спікерки. Проблема паралельного доступу Уявімо, що в нас є інтернет-магазин, назвемо його «Ruletka». В нього є сайт, через який здійснюються всі продажі. У магазина є також склад, і інформація про наявні товари на цьому складі зберігається в певній реляційній базі даних (БД). Склад додає інформацію про товари в БД, а сайт вичитує її з цієї бази, аби відобразити користувачам. Уявімо, що магазин отримує партію із тисячі штук відомих всім марок «воєнний корабль». Склад, відповідно, вносить ці дані в базу, і вони через певний час відображаються на сайті. Одразу набігає більше п'яти тисяч охочих купити марку. Що ж при цьому відбувається в базі даних інтернет-магазину? Для кожного користувача, який додає товар в корзину, сайт повинен запросити дані з БД про наявність товару, одразу заблокувати його під користувача, і лише після цього «сказати» сайту, що все успішно, можна показувати сформоване замовлення клієнту. На кожну одиницю товару у нас по п'ять користувачів, які одночасно намагаються забронювати собі цей товар. На рівні бази даних це виглядає наче вони всі намагаються змінити таблицю вільних залишків в БД складу. Тут важливо, щоби всі користувачі, які замовили раніше, отримали свій товар першими, при цьому магазин не продав нічого в мінус, а база даних витримала таке навантаження. В цьому процесі може бути безліч проблем і складних ситуацій. Програмне або апаратне забезпечення БД може відмовити, при чому це може статись в будь-який момент, наприклад, посередині операції запису. Інша ситуація: розриви мережі неочікувано відріжуть ваш додаток від БД. Кілька користувачів зможуть виконати записи операції одночасно, при чому перезаписати один одного, і хтось не отримає свою марку. Ще одна потенційна проблема: клієнт може прочитати дані, які не матимуть сенсу, тому що вони були оновлені лише частково. Навіщо потрібні транзакції? Протягом десятиліть транзакції вважались оптимальним механізмом вирішення всіх вищеописаних проблем. Транзакції – це спосіб групування додатком кількох операцій запису та читання в одну логічну одиницю. По суті, всі операції запису і читання в ній виконуються як одна, і вся транзакція або цілком виконується успішно з фіксацією змін, або завершується невдало з перериванням і відкатом. І якщо відбувся збій, додаток може спокійно спробувати виконати операцію ще раз, бо він знає, що ніяких часткових операцій запису не було виконано. Це значно спрощує обробку помилок, оскільки не потрібно пам'ятати, що там щось могло частково записатись або не записатись взагалі. Гарантії функціональної безпеки, які надаються транзакціями, часто описуються абревіатурою ACID, яка розшифровується як Atomicity, Consistency, Isolation and Durability. Це атомарність, узгодженість, ізоляція та довговічність відповідно. Атомарність — це неможливість розбиття на менші частини. В контексті ACID атомарність транзакції гарантує, що будуть або виконані всі операції, які беруть участь в транзакції, або не буде виконано жодної. Тобто, якщо операції запису згруповані в атомарну транзакцію і її не вдається завершити через збій, то вона переривається, і в базі даних необхідно відкатити всі вже ці виконані зміни перед тим, як відповісти юзеру, що транзакція бази даних була перервана. Узгодженість. Під цим поняттям мається на увазі, що БД перебуває з погляду додатка в хорошому стані, тобто система має перебувати в узгодженому, несуперечливому стані до початку дії транзакції і по її завершенню. Що саме вважаємо узгоджений станом? До прикладу, при переведенні коштів з рахунку на рахунок, кошти необхідно спочатку зняти з першого рахунку, після чого нараховувати на другий. Відповідно, після зняття коштів, але до їх нарахування система перебуває в неузгодженому стані: коштів немає на жодному з рахунків. Але після завершення транзакції бази даних повна сума перебуватиме на другому рахунку, або, якщо сталась якась помилка, на першому, що буде узгодженим станом. Ізоляція. До більшості баз даних звертається одночасно кілька клієнтів. І в цілому це не викликає проблем, поки вони читають і записують дані в різні частини бази, в різні таблиці, в різні рядки. Але якщо вони звертаються до одних і тих самих записів, то тут можуть виникати проблеми конкурентного доступу, які називаються race condition або стан гонитви. Ізоляція існує саме для уникнення таких проблем. БД повинна гарантувати, що результат фіксації кількох конкурентних транзакцій такий самий, як наче вони виконуються послідовно, одна за одною. Довговічність. Основна задача СУБД — це надати надійне місце для зберігання даних. Під довговічністю мається на увазі зобов'язання бази не втратити успішно зафіксовані дані транзакції, навіть в разі якогось апаратного збою чи фатального збою самої БД. Чотири рівні ізоляції B ідеальному світі ізоляція повинна була б полегшити життя розробників, які б могли зробити вигляд, що жодного конкурентного виконання взагалі не відбувається. На практиці витрати на серіалізовану ізоляцію досить високі, і багато баз даних не згодні платити таку ціну. Саме тому були створені слабші рівні ізоляції, які захищають лише від частини проблем конкурентного доступу, але при цьому мають значно кращу продуктивність при паралельному виконанні транзакцій. Стандарт SQL-92 визначає чотири рівні ізоляції. Це Read Uncommitted, Read Committed, Repeatable Read і Serializable. Всі ці рівні відрізняються певними мінімально допустимими гарантіями, які повинна надавати СУБД, і описуються в документації через присутність конкретних проблем паралельного доступу. Більш високий рівень ізольованості підвищує точність даних, зменшує кількість проблем, але при цьому знижує кількість паралельних транзакцій. Відповідно, чим нижчий рівень ізольованості, тим більше транзакцій може виконуватись паралельно, але при цьому може знизитись точність даних, якщо ви все не врахували. Read committed Базовий і найпоширеніший рівень ізоляції транзакцій — read committed. Він забезпечує дві основні гарантії. Перша — жодних брудних операцій читання (dirty read). Це означає, що при читанні з БД клієнт бачить лише зафіксовані дані. Тобто якісь середні, неузгоджені дані він не може прочитати. І друга гарантія — це жодних брудних операцій запису. Тобто при записі в БД можна перезаписувати лише зафіксовані дані. Для запобігання «брудним» операціям запису частіше за все бази використовують блокування рядків. Перш ніж модифікувати конкретний об'єкт, транзакція повинна спочатку встановити блокування на цей об'єкт. Дане блокування має утримуватись аж до фіксації або переривання транзакції. Утримувати блокування на конкретний об'єкт може тільки одна транзакція одночасно. Іншим транзакціям, які хочуть виконати операцію запису в цей об'єкт, доведеться дочекатися фіксації або переривання першої транзакції і лише потім отримати блокування і продовжити свою роботу. Подібні блокування виконуються базами автоматично в режимі читання зафіксованих даних (і на сильніших рівнях ізоляції). Більшість БД запобігають «брудним» операціям читання за допомогою підходу, коли база запам'ятовує для кожного об'єкта, що записується, як старе зафіксоване значення, так і нове, яке встановлюється поточною транзакцією. А в цей час всім іншим транзакціям, що читають об'єкт, просто повертається старе значення. І тільки після фіксації транзакції запису інші транзакції починають одержувати нове значення. Repeatable read Коли в нас є якісь аналітичні запити або перевірки цілісності, то зазвичай сканують велику частину БД і сканування виконується певний час. Якщо такі запити будуть бачити, частину старих даних, а потім додавати частину нових даних, то в результаті ми отримуємо неузгоджені дані, які не матимуть жодного сенсу і вважатимуться помилковими. В таких варіантах рівень read committed не підходить, а для запобігання цим проблемам існує рівень ізоляції знімків стану — snapshot isolation, який ще називають repeatable read. Основна ідея полягає в тому, що кожна транзакція читає дані з узгодженого знімка стану бази, тобто це повний зріз даних на певний момент часу. Навіть якщо дані потім були змінені іншими транзакціями в моменті читання, то наша транзакція не буде бачити цих змін. Механізм ізоляції знімків стану підтримується багатьма СУБД. Як і в read committed, в реалізації snapshot isolation зазвичай використовується блокування запису для запобігання брудним операціям запису. Але при цьому операції читання не вимагають жодних блокувань. Отже, основним принципом ізоляції знімків стану є «читання ніколи не блокує запис, а запис ніколи не блокує читання». Завдяки цьому БД здатна виконувати тривалі запити на читання і в цей же час виконувати операції запису. Цей рівень ізоляції використовується найчастіше. Для реалізації ізоляції знімків стану бази використовують такий механізм, який називається Multi-Version Concurrency Control (MVCC). В ньому кожен SQL-оператор бачить знімок даних — повну версію БД на певний момент часу, незалежно від поточного стану даних. При читанні застосовується окремий знімок стану для кожного запиту, а для транзакцій — один і той самий знімок для всієї транзакції. Розглянемо детальніше, як реалізується цей механізм на прикладі PostreSQL. На початку виконання транзакція отримує свій унікальний, монотонно зростаючий ідентифікатор, який називається txid. Будь-які дані, записані цією транзакцією, позначаються цим номером. В кожному рядку таблиці є поле created by, що містить ідентифікатор транзакції, в якій був доданий в цей рядок. І в кожному рядку також є поле deleted by, яке початково порожнє. Коли транзакція змінює дані, вона насправді залишає старі в своєму рядку, дописуючи в нього свій txid в поле deleted by. А також додає рядок з оновленими даними, зі своїм txid в полі created by. Пізніше, вже коли жодна транзакція точно не звернеться до цих даних, vacuum в PostgreSQL почистить ці видалені рядки. БД не збирає фізичний знімок бази, щоби надати його кожній транзакції. Читання узгоджених знімків стану реалізується завдяки ідентифікаторам та низці правил видимості. Нижче перерахую основні: На початку кожної транзакції БД створює список всіх інших транзакцій, які ще не завершились на поточний момент, і всі зміни, які виконуються цими транзакціями, просто ігноруються для поточної транзакції. Усі операції запису, які виконані перерваними транзакціями, також ігноруються. Усі операції запису виконані транзакціями з більш пізнім ідентифікатором, також ігноруються. Результати всіх інших операцій запису видимі для поточної транзакції.

Мова програмування Swift — це сучасне потужне рішення для будь-якого продукту чи обмежений інструмент в закритій екосистемі? Асинхронні оновлення iOS та Swift досі ламають проєкт? Чи вдалося IBM адаптувати цю мову під бекенд, а розробникам Apple — нарешті «допилити» SwiftUI? Та чи дозволить Kotlin Multiplatform Mobile оптимізувати розробку для двох команд? Найпоширеніші міфи про Swift спростовує Роман Кириленко, iOS Developer в Quarks , партнерській компанії Genesis. > Swift створили, щоби замінити Objective-C, але цієї мети так і не досягли > Swift — мова, на якій неможливо писати поганий код > Після кожного оновлення Swift, iOS чи Xcode все ламається > Swift повністю адаптований для проєктів за межами iOS > На Swift можна створювати ігри > SwiftUI — нове покоління UI-фреймворків > Єдиний код для Android та iOS неможливий МІФ №1 Swift створили, щоби замінити Objective-C, але цієї мети так і не досягли Поява Swift у 2014 році була органічною потребою, адже Objective-C вже тоді була доволі застарілою мовою програмування. Попри її мачурність та здатність вирішувати багато завдань, вона не відповідала поточним трендам розробки, була недостатньо гнучкою та сучасною. Мотивація Кріса Латнера, який розробляв Swift, не була націлена на витіснення Objective-C та подальше домінування в iOS-розробці. Але, побачивши результат, Apple почали інвестувати в комʼюніті, чия активність і зробила мову Swift такою, яка вона зараз. Було зрозуміло: якщо Swift «зайде» і проживе декілька версій, надалі ми рухатимемося в бік повної відмови від Objective-C. Це ми спостерігаємо зараз. Останнім часом нативні фреймворки поступово переписуються на Swift, все менше проєктів запускають на Objective-C, — а ринку вже чимало розробників, які ніколи не стикалися з цією мовою. Іде відмова навіть на рівні Apple, і це гарна тенденція на користь покращення перформансу. МІФ №2 Swift — мова, якою неможливо писати поганий код Взагалі iOS-розробка складається з трьох компонентів: власне Swift, iOS SDK та Xcode. На кожному рівні є певні правила, які не допускають помилок. Більшість проблем розробників повʼязані саме з Xcode. Порівняно з іншими програмними середовищами, Xcode має проблеми з перформансом, оновленнями та містить баги. Щодо Swift — це така ж мова як і всі інші, в яких якість коду цілком залежить від навичок розробників. В останніх версіях мови було розширено інструменти, які дозволяють відслідкувати баги, але водночас додано функціонал, який створює велике плато для нових помилок. Наприклад, раніше під час програмування вагомим джерелом помилок був менеджмент памʼяті, зараз — на рівному місці можна створити проблеми з перформансом в плані зайвих обчислень чи відмалювань UI, що призводить до інших складнощів. Щоби цього уникати, треба ретельно вивчати інструменти, з якими працюєш. МІФ №3 Після кожного оновлення Swift, iOS чи Xcode все ламається Xcode, iOS SDK та Swift справді часто оновлюються асинхронно. Раніше це було проблемою, оновлення часто ламали всю роботу. Зараз це не так. Проблеми з оновленнями Swift так само були найбільш відчутними на початку. Між першою, другою і третьою версіями різниця була настільки суттєвою, що при кожному оновленні треба було переписувати вагому частину проєкту. Починаючи з четвертої версії, зʼявляються скоріше мінорні зміни, та зберігається зворотна підтримка попередніх версій. Це свідчить про те, що Swift стає більш мачурною і стабільною мовою. Тепер, якщо девелопери хочуть згорнути певну функціональність, вони дають рік або навіть два для перехідного періоду — цього часу достатньо, щоби перейти на нову версію. Зазвичай розробники не поспішають імплементувати нові фічі в проєкти, адже більшість оновлень можна використовувати тільки на останніх версіях iOS. Наприклад, нативний фреймворк StoreKit. Комʼюніті дуже чекало його оновлення, щоби зробити міграцію з першої версії, яка на той момент була сильно застарілою та містила чимало «бородатих» багів. Анонс другої версії відбувся разом з анонсом iOS 15. На той час актуальною для користувачів була версія iOS 14. Оскільки поширеним правилом є підтримувати хоча б -1 актуальну версію, на той час більшість продуктів підтримували iOS 13 та iOS 14. Проте для повної міграції на нову версію StoreKit потрібно було відмовитись від всіх версій крім 15 або підтримувати обидві реалізації одночасно. Тому для більшості розробників вибір був очевидним — чекати анонсу та переходу користувачів на наступну версію операційної системи, iOS 16. МІФ №4 Swift повністю адаптований для проєктів за межами iOS Objective-C — мова, замкнена на операційній системі macOS. Раніше ніхто навіть не пробував використовувати її для іншої розробки. На відміну від неї Swift — open-source проєкт, який можна використовувати для завдань за межами iOS/macOS. Наприклад, на Swift пишуть короткі легкі скрипти для локальних завдань. Також IBM намагалась інвестувати в бекенд на Swift. Зрештою, з цього так нічого суттєвого не вийшло. Крім локальних невеликих проєктів, Swift залишився технологією, що не виходить за межі екосистеми Apple. Основна перешкода — потреба інвестувати в комʼюніті, яке саме собою зростати не буде. Крім того, з точку зору перформансу є значно цікавіші альтернативи для того ж бекенду. Наприклад, відносно новий Go, який показує гарні результати, в якого вже доволі хороше комʼюніті. МІФ №5 На Swift можна створювати ігри Swift — це компільована мова, написана на С++. Вона досить швидка, чудово перформить. При цьому Swift не може існувати в iOS-розробці без набору фреймворків SDK. Туди входять певні інструменти для рендеру графіки, але вони не підходять для розробки ігор, які зазвичай мають високий FPS і потребують рішень, ближчих до хардверу. Ніхто не створює ігри на тих самих фреймворках, що звичайні застосунки. Для цього є спеціальні рішення у вигляді SDK, такі як SceneKit, SpriteKit, Metal. Останній з них був вже написаний під час домінування Swift, і досі розвивається. Проте написані на цих технологіях ігри будуть обмежені платформами iOS та macOS, тому доцільність використання саме Swift для розробки ігор дуже залежить від контексту. В Unity є опція експортувати проєкт у Swift, щоби надалі мати можливість зарелізитись в App Store. Для рендеру графіки вони використовують кастомний двигун, написаний на С++, який забезпечує пряму комунікацію з хардвером. МІФ №6 SwiftUI — нове покоління UI-фреймворків SwiftUI випустили 2019 року дуже «сирим». Якщо перші версії Swift були проблемними, то на SwiftUI в принципі неможливо було створити застосунок, адже цей фреймворк не закривав базових завдань. Певною мірою SwiftUI досі залишається «недопиленим». Ряд питань, які вже відпрацьовані в iOS-розробці протягом років, не можна закрити на SwiftUI, а треба повертатися на рівень UIkit. Загалом SwiftUI може існувати в певній архітектурі. Але нормально цей функціонал працює лише у версіях, починаючи з iOS 15 (поточна — iOS 16). Тому про нове покоління, вочевидь, говорити ще зарано. МІФ №7 Єдиний код для Android та iOS неможливий Десять років тому поширеним упередженням серед розробників було те, що майбутнє — за кросплатформною розробкою. Мається на увазі поява єдиної мови програмування, на якій можна буде створювати продукт та експортувати для різних платформ. Це виглядало дуже логічним: навіщо створювати окремі продукти на двох платформах, якщо все можна зробити на одній? Проте ця ідея не «вистрілює» вже довгий час з багатьох причин. У кросплатформених рішеннях доволі багато недоліків. Сама розробка може бути складнішою — подекуди розробнику треба орієнтуватись одразу в трьох рішеннях — iOS, Android та тій тулзі, на який він пише. Також кросплатформені рішення з часом застарівають і замінюються новими, через що треба переписувати проєкт. Наприклад, застосунок Airbnb зрештою переписали з кросплатформеної розробки на нативну, вклавши в це чимало часу та грошей. Натомість зʼявилося інше рішення — кодова мультиплатформа Kotlin Multiplatform Mobile (KMM), яка дозволяє iOS-розробникам ділитися кодовою базою із Kotlin-розробниками. Теоретично у такий спосіб можна буде реалізовувати певні фічі на одній платформі і передавати іншій. Наприклад, одна команда створює якусь бізнес-логіку, ділиться з іншою, яка вже навішує свій нативний UI. Це дозволило б оптимізувати час на розробку і підтримку. В мобільному комʼюніті це одна з найгарячіших тем для обговорення.

У процесі масштабування продукт «обростає» великою кількістю даних. Бізнес має їх приборкати, аби працювати ще ефективніше. Тоді на роботу запрошують дата-аналітиків, вакансії для яких ми й хочемо запропонувати у першому літньому дайджесті. Гортайте до кінця та шукайте можливості для себе! Data Analyst (вакансія закрита) Аби обійняти цю посаду, потрібно мати мінімум рік досвіду в ролі Product Analyst, Web Analyst чи Data Analyst, працювати з SQL, а також вміти самоорганізовуватися. У кандидаті цінуватимуть вміння презентувати аналітичні результати за допомогою Tableau, Power BI та знання Python. Серед робочих завдань — A/B-тестування нових продуктових фіч, автоматизація процесів, визначення проблемних місць та точок росту, детальне дослідження поведінки користувачів. Data Engineer (вакансія закрита) Приєднуйтеся до команди OBRIO , чиїм флагманським продуктом є астрологічний застосунок Nebula — світовий лідер за кількістю завантажень у своїй ніші. Новий Data Engineer посилить мобільну команду, долучиться до побудови та підтримки нової структури. На цій позиції фахівець зможе самостійно формувати повну архітектуру та впливатиме на процес побудови ETL. Навички, які знадобляться — знання Python в контексті створення ETL data pipelines (Pandas, pyodbc), автономна робота зі сторонніми API, розуміння побудови архітектури баз даних, досвід роботи з хмарними сервісами, а також із середовищем зберігання та обробки «великих» даних. Технологічний стек: Vertica, PostgreSQL, MySQL, BigQuery, Python, Git, а ще — Firebase, Amplitude, AppsFlyer, Google Analytics. Data Analyst Від кандидата на цю позицію команда очікує володіння інструментами SQL, Python і Tableau. Серед особистих якостей оцінять вміння пояснювати складні речі простими словами, працювати в умовах невизначеності, проактивність та здатність брати на себе відповідальність. Хороша новина для світчерів: якщо маєте бекґраунд у маркетингу, фінансах чи інвестиціях, ця посада також для вас. У детальнішому описі вакансії за посиланням ви знайдете приклади завдань, склад команди маркетингової аналітики та інші умови роботи. Marketing Data Analyst (вакансія закрита) Команда Genesis Growth Accelerator будує унікальну модель роботи з перспективними продуктами — інвестує в проєкти на ранніх етапах, масштабує та допомагає створювати успішні компанії. Головне завдання на цій посаді — допомогти команді маркетингу ефективно працювати з рекламним трафіком завдяки інсайтам на основі даних. Також потрібно буде розвивати автоматизовану систему для аналітики та оптимізації трафіку, шукати точки зростання — у наявних продуктах й MVP на нових ринках. Знадобиться від року досвіду, знання Python (NumPy, Pandas) на середньому рівні, базове розуміння ключових маркетингових показників, а перевагою буде досвід роботи з SQL та API, інструментами для контролю ефективності трафіку, а також сервісами веб- і мобільної аналітики Similar Web, Sensor Tower, AppMagic. Вакансії партнерів Data Science Content Developer Продукт стартапу Codefinity — освітня платформа для навчання програмування. Окрім створення навчального контенту, аналітики найкращих на ринку навчальних програм та роботи з фідбеком користувачів, посада передбачає розробку інструментів та побудову процесів для оптимізації роботи та пошук способів гейміфікації курсів, вікторин і завдань. Серед вимог — знання Python чи R, навички управління проєктами, розуміння принципів та підходів Data Science. Analyst/Data scientist Ще один аналітик у команді Codefinity буде знаходити закономірності в поведінці користувачів на всіх етапах життєвого циклу, створить статистичні моделі для прогнозування конверсії, утримання та інших ключових показників, а також попрацює над системою рекомендацій, яка допоможе користувачам знайти найкращий контент. Для цього йому знадобляться знання Python, SQL та Excel, академічна освіта в галузі математики/статистики/комп'ютерних наук та англійська мова рівня Upper Intermediate та вище. Перевагою будуть знання економіки. Data Analyst (вакансія закрита) Solidgate — це B2B-платформа у сфері онлайн-платежів, команда якого будує фінтех-екосистему для швидких, безпечних та вигідних прийомів оплат в усьому світі. Шукають дата-аналітика, який покращить декілька внутрішніх сервісів, а саме: систему маршрутизації транзакцій між банками, скорингову модель оцінки підозрілих транзакцій та сервіс оптимізації регулярних списань для клієнтів, що працюють за моделлю підписок. Найкраще з завданням впорається фахівець з 2+ роками досвіду, технічною освітою, вмінням працювати з BI системами та знанням SQL. Технічний стек: Python (Keras, Pandas, Numpy, Matplotlib, Prophet), SQL, Tableau, AirFlow, Git, Elasticsearch, Grafana. Що почитати про роботу з даними: 7 міфів про SQL. Спростовує Data Engineer в Boosters Майже у всіх вакансіях з цієї підбірки є вимога — знання SQL. Це повноцінна мова розробки чи примітивний інструмент для вибірки даних? У чому різниця між SQL та NoSQL? Чому знати конструкції та селекти не дорівнює знати SQL? У матеріалі за посиланням відповідаємо на ці питання та спростовуємо найпоширеніші міфи індустрії. Об’єднуємо, фільтруємо, групуємо: SQL-скрипти для отримання вибірок Технічний матеріал, де послідовно та без води розповідають, як використовувати SQL для отримання вибірок з декількох джерел з потрібними обмеженнями, в потрібному вигляді й розрізах. Корисно для ознайомлення тим, хто вчиться працювати з SQL або володіє ним на початковому рівні.

У 2014 році Міжнародна спілка електрозв’язку (ITU) запровадила Міжнародний день дівчат в IT , який з тих пір щороку відзначається у квітні. Це свято створили, аби привернути увагу до того, що в технологічній галузі все ще є потреба у більшій кількості жінок. Сьюзан Войчицькі управляє YouTube, Гвін Шотвелл керує процесами в SpaceX, Мері Бет Вестморленд — технічний директор Amazon. Водночас індустрія все ще сприймає жінок технічних спеціальностей як виняток із правил. Ми розпитали трьох генезійок, які працюють на технічних позиціях, про їх кар’єрний шлях, освіту, дозвілля і стереотипи, з якими стикаються (або ні) жінки в IT. iOS замість хімії Своє навчання я починала в університеті Граца, що в Австрії. Після закінчення ліцею в Україні вступила спочатку до грацького коледжу, потім до вишу на спеціальність «Біомедична інженерія». Навчання в університеті було складним і насиченим. Дуже швидко я збагнула, що хімія мені не до душі. Водночас університетські лекції з інформатики та електротехніки мене дуже зацікавили. В цей час з'явилася думка перевестись в інший університет на технічну спеціальність. Після першого семестру я повернулася на літо в Україну, подала документи в КПІ на факультет інформатики та обчислювальної техніки, вступила туди, і залишилась в Києві. На другому курсі почала працювати бекенд-розробницею в сервісній компанії. В певний момент в ній просто закінчились проєкти для мене, і мені запропонували навчатися писати застосунки на Android або iOS. Мені завжди подобався дизайн iOS-апок, тому вибір був очевидним. Нові навички опанувати було не складно, маючи досвід програмування. Так я переключилася на iOS-розробку, якою займаюся і дотепер. У 2021 році мене запросили на співбесіду в PlantIn , і за місяць я вже отримала офер. Нині моя позиція — Engineering Lead iOS -команди із трьох фахівців. В нашій зоні відповідальності два застосунки для ідентифікації рослин — PlantIn та Carl . У мене як у ліда є додаткові управлінські таски: проведення рев’ю-зустрічей, one-on-one, консультування інженерів тощо. «Ніколи не знаєш, що тебе спіткає» Мені було цікаво випробувати себе в якості керівника, хай навіть невеличкої команди. Спочатку я була менеджером одного розробника, в мене був випробувальний термін на цій позиції. Тоді не було жодних чітких критеріїв і тасок саме в розрізі менеджменту для мене, тож я складала собі воркфлоу самостійно. Відштовхувалась від того, що помічала, коли була розробником — що можна додати або змінити в процесах для більшої ефективності. Окрім цього, в перші ж тижні мого випробувального терміну в ролі ліда у нас з'явилася позиція для нового iOS-інженера. Опановувала ще й проведення найму, онбордингу тощо. Найцікавіше в управлінні — ніколи не знаєш, що може тебе спіткати. Я стикнулася з великою кількістю питань, які раніше навіть не виникали у мене. Як правильно комунікувати різні рішення, розв’язувати конфлікти, або — навіть цікавіше — попереджати конфлікти, які гіпотетично можуть виникнути. Велику кількість уваги намагаюсь приділяти тому, чи всім членам команди комфортно, чи відверті вони в тому, чим вони діляться зі мною, чи вільні у вираженні своїх занепокоєнь або ідей. Для стратегічних питань в мене є менторські зустрічі із одним із СЕО PlantIn Дмитром Гринцем. Оскільки в нього більше досвіду, мені важливо отримати фідбек до моєї роботи, поставити питання щодо менеджерства або технічної складової роботи, які мене хвилюють. Я б хотіла й надалі розвиватися в компанії, і в напрямі розробки, і в напрямі управління. Мене дуже цікавить розвиток продуктового мислення та бізнес-підходи до створення IT-продуктів. Водночас мене цікавлять технології, я хочу продовжувати писати код і розвиватися в створенні застосунків. Хобі і дозвілля У вільний час я дуже люблю фотографувати — це захоплення зі мною з дитинства. Малою брала камеру в батька, потім вже мала власну. Беру її в кожну подорож. Окрім цього багато часу приділяю спорту: біг, велосипед, йога, силові тренування, бадмінтон. Коли ти весь робочий день проводиш сидячи за комп’ютером, спортивне навантаження обов’язкове. Вихідні обожнюю проводити в книгарнях із книжкою, кавою і моїм улюбленцем — джек-расселом Мортіком. Навіщо потрібна технічна освіта? Ще в останніх класах школи я вирішила, що хочу бути інженером, аби створювати щось дійсно суттєве і корисне для людей. Спочатку навіть хотіла вчитись будувати літаки, але все ж таки обрала програмування: мені завжди подобалась математика, мала високі результати з цього предмету. Для навчання обрала Могилянку, вона тоді була лідером рейтингів найкращих ЗВО для технічних спеціальностей. Технічна база в університеті була дуже якісна: профі-викладачі, корисні практичні заняття. Освіта в Україні не ідеальна, але нині я бачу, що багато чого я пам’ятаю ще з часів навчання, в той час, як деякі розробники-сеньйори лише зараз це починають вивчати — алгоритми, принципи роботи комп’ютера тощо. Окрім цього, академічна освіта значно розширила досвід, дала багато практики в різних напрямках програмування. Після другого курсу я почала працювати в маленькій компанії, а за рік потрапила у Genesis. П’ять тижнів тривав процес найму , і от — я в Boosters. Від воронок до платформ Спочатку я працювала на лендингах-воронках різних продуктів компанії. Там немає важкої логіки, переважно верстка, підключення оплати, відстеження аналітики. Водночас це дуже динамічна робота, щодня прилітали нові таски, були постійні зміни. Код, який писався до цього декілька тижнів, за секунду ставав нерелевантним. Час від часу я була там однією розробницею, тож з багатьма штуками доводилось розбиратися самостійно. Це був класний челендж, і все вдалося. Були різні складнощі, повʼязані і з підключенням внутрішніх продуктів Boosters, і з продуктами компаній Genesis, але з усім вдавалось справлятись. Не дивлячись на динаміку, задачі все ж були досить одноманітними, а мені хотілось чогось більш складного. Нині вже майже рік я працюю на іншому проєкті від Boosters. Там платформа вже більш навантажена: авторизація, декілька ролей у користувачів, адмінка, чати, більш цікава логіка, велика команда. Цей рік був дуже цікавим, тому що ми розбудовували продукт з нуля, покращували його, імплементували багато нових фіч. Мені цікаво розширювати досвід, але не хочется втрачати свій грейд. Щоби світчнутись, до прикладу, в iOS-розробку, маю наважитись почати з джунівської позиції, ще й в часи, коли і так дуже висока конкуренція. Можливо, в найближчий час спробую фулстек. Перейти одразу на мідла буде не так просто, проте челенджі мене не лякають. Дівчата і фронтенд В моїй групі в університеті близько 30% складали дівчата. Вони були розумними і талановитими програмістками, не поступалися хлопцям. Мені дивно, що люди й досі дивуються дівчатам-розробницям. По-перше, розробка абсолютно однаково дається і дівчатам, і хлопцям, це не питання гендеру. Навпаки, хлопцям може бути важче, тому що їм іноді не вистачає терпіння і наполегливості, на мою думку. Мені здається, справа в кордонах у сприйнятті себе і світу, нібито програмування справа чоловіча, і багато дівчат навіть не допускають можливості стати розробницями. Але це лише стереотипи, адже, маючи зацікавленість і наполегливість, можливо все. Я справді дивуюсь, чому в Genesis так мало дівчат-розробниць. Нещодавно натрапила на лекції тимліда Wix Олени Жукової на React fwdays. Мене надихає, коли я бачу дівчину на високій технічній позиції у великій продуктовій компанії. Мені здається, таких спікерок має бути більше в публічній спільноті фронтендерів, аби кожна з нас могла собі зайвий раз сказати: «Ти можеш бути тим, ким захочеш». «Будеш шукати жучків» Те, що я потрапила в IT, було абсолютною випадковістю, або долею, як подивитись. При вступі в мене був вибір між фінансами і кібербезпекою. Фінанси мене мало цікавили, а про кібербезпеку я нічого не знала. Коли ми з мамою прийшли подавати документи на вступ, випадково зустріли якогось викладача, який сказав — «А чого б тобі не вступити на кібербезпеку? Це цікаво, будеш там шукати всіляких «жучків». Так загалом і вийшло, тепер шукаю «жучків» у коді. В університеті у нас було дуже багато годин комп'ютерних наук, інформаційних технологій, вивчали різні мови програмування. Тому пізніше, коли я пішла на курси вивчати більш поглиблено QA, це не було щось зовсім нове для мене. Закінчила курси, працювала в різних компаніях на посадах від офіс-менеджера до QA-фахівця. Півтора роки тому я прийшла в Genesis, де основною моєю задачею стало полегшити роботу менеджерів, які займались тестуванням, взяти на себе всі етапи тестування фічей від розробників. Я стала відповідати за написання документації, побудову процесів в команді — не лише QA, а і взаємодію з розробниками. Нині я і Manual QA, і Automation QA. Автотести ми пишемо на Cypress разом із нашим фронтенд-розробником. До приходу в Genesis в мене був досить невеликий досвід написання автотестів, а тут були і можливість, і час цьому навчитися. Часто я стикаюсь із уявленням , що тестування, — це така monkey job. Типу сидиш і клацаєш кнопки. Звичайно, це не так. Чим більше людина заглиблюється в цю спеціалізацію, тим чіткіше розуміє, що й тут варто багато чого знати і вміти, аби бути класним QA-фахівцем. До того ж, нині дуже змінився ринок, тож людині без досвіду роботи досить важко знайти цікаву роботу в сфері QA. Як бути менеджером? Невдовзі після мого приходу в OBRIO наша команда почала розширюватись, водночас я залишалась єдиним QA-фахівцем. Аби не стати боттлнеком для задач, я мала найняти ще одного тестувальника. В мене не було жодного досвіду найму і управління, проведення співбесід тощо. Зазвичай я працювала як один QA, або один з двох QA, у яких різні зони відповідальності. Тут мені потрібно було розібратись, як проводити співбесіди, підготувати карту найму, скласти запитання до співбесіди, провести інтерв’ю з кандидатами, надати по ним фідбек, оцінити тестове завдання. В OBRIO є хайринг-інтенсив, де HR-фахівці допомагають майбутнім менеджерам опанувати цю навичку, розповідають, як проводити хайринг, на що звертати увагу, які існують red flags. Окрім цього, аби стати менеджером, я мала пройти Leadership Intensive . Це було дуже корисно: спікери з різних генезійських проєктів підсвічували найважливіші моменти, ділилися різноманітним досвідом, і це все можна було одразу застосувати на практиці. Також мені дуже допомогли колеги QA з інших проєктів, з якими ми спілкуємося в ком’юніті: розповіли, які питання ставити для кандидатів різних грейдів, як оцінювати софт скіли, на що звернути увагу, поділилися лайфхаками зі свого досвіду. Нашого другого QA-фахівця в команду ми взяли з першої співбесіди. Інтерв’ю проводили з різними кандидатами, але зупинились на першій кандидатурі, бо відразу було зрозуміло, що ми знайшли найкращого спеціаліста. Я дуже хвилювалась і підійшла до цього відповідально — читала книжки, складала план онбордингу тощо. Для мене було важливо, аби у людини, яка доєдналася до команди, склалось позитивне враження, щоби їй було комфортно. Подальше опанування менеджмент-скілів — один з пунктів мого PDP (плану особистого розвитку) на три наступні роки. Мій план має своєрідну T-shaped структуру. Горизонтально планую розвиватись у сферах, дотичних до моєї: вивчати продакт-менеджмент, дизайн, DevOps. Це не означає, що я через рік стану девопсом або дизайнером. Горизонтальне навчання — для ознайомлення із цими спеціальностями. А от вертикальне — це більш поглиблене опанування, власне, QA і менеджменту. Намагаюсь вкладати час і сили в самоосвіту. З цікавістю слідкую за виступами і статтями української QA Guild Master Євгенії Гловацької. Ще з корисного — подобаються книжки про Agile-тестування від тренерок Карен Грейвс і Саманти Лейонг, «Хто? Вирішуйте проблему №1» Джеффа Смарта та YouTube-канал про тестування «Попелюха» . Не тестуванням єдиним Моя мама займається шиттям, і я з дитинства багато спостерігала за цим процесом. Останніми роками стала бачити в Instagram багато невеличких магазинів, які не мають власного виробництва і перепродають не дуже якісний одяг. Подумала – чому ми не можемо зробити краще? Знайшла приклади виробів, які б хотіла створити, декількох кравчинь, технолога. Ми розробили лекала і відшили першу партію одягу. Так з’явився мій нетехнічний pet-проєкт, бренд домашнього одягу Mior. Нині я займаюсь його розвитком у вільний час самостійно, проте зараз відчуваю необхідність і бажання приділяти багато уваги своєму професійному розвитку як QA-фахівця. Для магазину залишається менше часу, але замовлення постійно надходять, тому можливо скоро доведеться пошукати собі помічника для розвитку бренду.

Роль фронтенд-розробника полягає не лише у тому, щоби спроєктувати робочий інтерфейс, а й у тому, щоб бути сполучною ланкою між іншими командами. За необхідності, він розумітиметься і на дизайні, і на бекенді, і на продакт-менеджменті. Однак на цьому шляху є багато речей, які заважають робочому процесу та ускладнюють завдання. Про найбільш розповсюджені болі фронтенд-розробника розповідає Олесь Марола, Front-end Developer у Genesis Growth Team. Олесь понад чотири роки працює розробником, а у Genesis уже рік розробляє продукт для маркетологів. БІЛЬ №1 Фронтендери вищих ґрейдів стають «містками» між командами й витрачають на комунікацію багато часу та зусиль. Аби виконати об’ємне завдання, фронтенд-розробнику потрібно спілкуватися з багатьма сторонами — дизайнерами, бекенд-розробниками, тестувальниками, продакт-менеджерами тощо. Спочатку фахівець дізнається про всі особливості проєкту та взаємодії сам, якщо потрібно — ставить до відома продакт-менеджера. Однак кожна сторона має власні цілі, пріоритети та вподобання. Орієнтуватися серед різноманітних поглядів та шукати спільне може бути важко, особливо, коли ідеї або вимоги суперечливі. Непорозуміння призводять до затримок, перепрацювань і навіть конфліктів між командами — що тільки заважає розробці продукту. БІЛЬ №2 Необхідність працювати під тиском, у стислі терміни або з вимогами, які швидко змінюються. Фронтенд-розробка передбачає багато варіантів того, як можна реалізувати ту чи іншу задачу. Починається робота — і розробник працює за технічним завданням , але потім одержує фідбек від тимліда: все потрібно робити інакше. У мене був подібний кейс. Я почав працювати над завданнями певним чином, а коли пізніше зідзвонився з продакт-менеджером — виявилося, що пріоритети змінилися, й задачу потрібно робити взагалі інакше. Пара-трійка змін — і таска уже зовсім не така, як спочатку. Інша ситуація: розробник не уточнив ТЗ, самостійно додумав, як зробити краще, але у результаті код має велику складність, чого можна було б уникнути. Такі шматки коду в майбутньому буде дуже важко підтримувати. Робота в умовах нестабільності характерна для бізнесів на ранній стадії, яким треба якомога швидше запустити MVP. Колись нам потрібно було спроєктувати першу версію продукту — тобто, клієнтську частину, адмінку й бекенд — за два тижні. Через подібні історії проходить більшість молодих проєктів, яким треба налаштувати процеси, цикл розробки, комунікацію і т.д. Однак у стійкому продукті, що вже пару років на ринку подібних проблем буде менше. БІЛЬ №3 Необхідність забезпечувати сумісність з браузерами. Фронтенд-розробники мають переконатися, що їхній код працює коректно й виглядає узгоджено і в Google Chrome, і в Mozilla Firefox, і в Safari, і в Microsoft Edge, і в інших браузерах. Кожен з них має власний механізм рендерингу й може інтерпретувати HTML, CSS та JavaScript дещо по-різному. Те, що ідеально вписується в Chrome, може зламатися або відображатися інакше в Safari. Добре, що уже не потрібно підтримувати хоча б Internet Explorer. Проблема полягає не лише у відмінностях браузерів, а у їхніх різних версіях. Наприклад, якщо продукт нормально функціонує в останній версії Google Chrome — не факт, що він працюватиме в старіших версіях браузера. Буває так, що ми підтримуємо новіші версії, а потім приходить тестувальник, який робив регресії та перевіряв старіший гаджет, і виявляється, що все поламалося. Певний відсоток людей досі користується більш ранніми версіями браузерів, тому ми робимо застосунки й для них також. БІЛЬ №4 Продукт має виглядати гармонійно на різних пристроях і розмірах екранів, однак дизайн для всіх брейкпойнтів не роблять. Цей біль актуальний лише для розробників, які займаються версткою. Коли робиться дизайн, ніхто не «морочиться» з брейкпойнтами на планшети та інші нестандартні екрани. У найгіршому випадку проєктують тільки версію на десктоп, у кращому — варіант для мобайлу. Так, дизайнери малюють найбільший і найменший варіант, а проміжних немає. Інша проблема виникає, коли дизайнери працюють із не зовсім стандартними параметрами екрана. Наприклад, обирають висоту фрейму в Figma 900 пікселів. Здебільшого юзери мають гаджети з меншою висотою екрана, як-от 700 пікселів. І в такому випадку, контент з оцих 200 пікселів, просто не вміщається, а тестувальники приходять з питаннями до фронтендера. Тоді розробник має самостійно робити адаптиви для різних екранів. На перший погляд, це простіше та швидше, ніж намалювати декілька різних екранів. Однак для фронтендера це додаткове завдання та час, який він міг би витратити на розробку іншого функціоналу. БІЛЬ №5 Підтримувати чистий код у проєктах зі зростаючою складністю не завжди виходить. Особливо, коли над ним працюють понад три людини. Коли коду бракує ясності, командна робота дуже ускладнюється. Якщо база обростає дублікатами, застарілими шматками або неактуальними коментарями, то у майбутньому це може спричиняти проблеми з масштабуванням. Наприклад, щоб розробити нову фічу, код потрібно буде не просто змінити, а переписати. Через це завдання, що мало зайняти годину, розтягується на всі чотири. Крім того, така база ускладнює залучення новачків до проєкту. І він, і тимлід витрачатимуть час і зусилля на занурення у процес — а продуктивність страждатиме. В ідеальному світі на проєкті має бути архітектурний підхід, а всі шорсткості виправляються рефакторингом коду. Однак тут є інша проблема: на це не завжди є час, тож завдання ризикує перекочувати до категорії «ми колись до цього повернемося». БІЛЬ №6 Кодова база проєкту застаріла, їй бракує належної документації або документації загалом. Проблема, яка пов’язана з попередньою. Якщо чистий код працює без збоїв, написаний у єдиному стилі, добре задокументований та відформатований, то застаріла кодова база призводить до труднощів у імплементації рішень, збільшення часу подальшої розробки, складнощів оновлення ПЗ тощо. Наслідки можуть відчуватися не одразу, а за кілька місяців чи навіть років, коли вже вийшла купа мажорних апдейтів, оновилися технологічні пакети й додалися нові бібліотеки. Відрефакторити великий проєкт майже неможливо. Ще більше ускладнює проблему неактуальна документація. Розробникам доводиться витрачати багато часу на розшифровку архітектури системи, структури коду тощо. Колись нашій команді дістався подібний проєкт «у спадок». Спочатку здається, що все зроблено добре, а потім настає час оновлювати код або додавати якийсь функціонал — а це довго й боляче. БІЛЬ №7 Дизайнери роблять макети, але деякі елементи не працюють так, як їм би хотілося. Під час проєктування клієнтської частини важливо пам’ятати: інтерфейс повинен не лише мати гарний вигляд, а й працювати певним чином. Однак деякі дизайнерські рішення дуже важко перенести та реалізувати так, щоби вони гармонійно виглядали в коді, у верстці, а ще — коректно відображалися на різних гаджетах. Як і дизайнер, розробник добре розуміється на UI, але завдяки знанням у програмуванні здатен помітити недоліки ідеї, які заважатимуть реалізації. Саме по собі рішення може бути вдалим, але воно не працюватиме так, як задумувалося. Або ж під нього доведеться писати тонну коду, який буде важко масштабувати та підтримувати в майбутньому. Якщо дизайнер не впевнений у можливості реалізувати якесь рішення, краще проконсультуватися з розробником заздалегідь. Інакше останньому доведеться самому переробляти макет та шукати рішення, що займатиме багато часу.

Genesis виступила партнером дослідження ринку iOS-розробки в Україні, яке провів портал AIN.UA. Редакція видання опитала більше сотні iOS-розробників та проаналізувала їх відповіді. Питання стосувалися мов програмування, рівня зарплат в індустрії та задоволеності роботодавцями й продуктами, над якими вони пропонують працювати. Ми зібрали найцікавіші інсайти з дослідження та запросили експертів генезійського Mobile Community прокоментувати результати: своїми думками поділилися Орина Панченко, Lead iOS Developer в PlantIn та Роман Кириленко, iOS Developer в Quarks, партнерській компанії Genesis. Опитування було анонімним і поширювалося через сайт AIN.UA, тематичні канали для iOS-розробників та через компанії з профільними спеціалістами у штаті. Національне дослідження стосувалося саме iOS-розробників, що працюють на українські компанії, і тривало півтора місяця. Це тенденційне дослідження, яке показує головні тренди ринку. Загалом його пройшло 113 респондентів, які відповіли на 21 запитання. Мови програмування та технології, якими користуються iOS-розробники Яку мову програмування використовуєте? Найпопулярнішою мовою програмування серед iOS-розробників, звісно, є Swift, який у своїй роботі використовують майже 95% спеціалістів. На другому місці знаходиться Objective-C, яким користується 31,86%. Інші мови програмування, наприклад C, C++, JS чи Ruby використовують менше ніж 2% розробників, решта не змогли набрати й 1%, хоча загалом були згадані респондентами. Що ви використовуєте для розробки UI? UIKit досі залишається найпопулярнішим інструментом для розробки UI. Ним користується 66,67% iOS-розробників. А представлений у 2019 році SwiftUI набрав лише 26,13%. При цьому 7,21% використовують обидва інструменти, зазначаючи, що на роботі використовують UIKit через старий код, а для Pet-проектів вже використовується SwiftUI. «SwiftUI існує вже четвертий рік, і все частіше використовується. Та й в Apple UIKit практично не згадують. Це говорить про те, що поступово вся iOS-розробка буде переходити на SwiftUI. При цьому все має відбуватися органічно. Якщо, до прикладу, певний проєкт існує і розвивається наступні п’ять років, то за ці пять років він вже стовідсотково буде на SwiftUI. Якщо ми за рік почнемо наймати команду iOS-розробників, їх буде більше цікавити саме SwiftUI. До того ж, він трохи легший у використанні, ніж UIKit, відповідно, поріг входу в цю мову і в iOS-розробку буде нижчий», — коментує Роман Кириленко, iOS Developer в Quarks. З якими технологіями ще не працювали, але хотіли б? Майже третина (28,57%) всіх українських iOS-розробників ще не працювали зі SwiftUI, хоча хотіли б. Серед інших технологій, від 6% до 9% набрали AR, Combine та CoreML. Дещо відстає від них загалом трендовий зараз штучний інтелект, з яким хотіли б попрацювати 4,4% розробників. «Ми використовуємо ШІ в PlantIn, і, власне, Apple нині цю сферу розвиває і стимулює розробників використовувати ці інструменти. Під час Apple Enterpreneur Camp , де я брала участь, фахівці Apple закликали використовувати усі можливості штучного інтелекту в застосунках. До прикладу, активно розвивається фреймворк Core ML, який допомагає імплементувати ШІ на девайс без жодних запитів на бекенд», — говорить Орина Панченко, Lead iOS Developer в PlantIn. Бачення ринку Де найцікавіші для iOS розробників задачі та стек технологій? На думку українських спеціалістів, найцікавіші для iOS-розробників задачі та стек технологій пропонують компанії, чия основна діяльність — це розробка додатків для iOS. Лідерами стали MacPaw (14,29%) та Readdle (10,71%). На третьому місці опинилась Genesis (8,93%). Крім цих компаній понад 5% зміг набрати лише EPAM з 6,25%. З того що ви чули, де найвищі зарплати для iOS розробників? 11,54% розробників вважають Genesis компанією з найвищими винагородами на ринку. Другою найпопулярнішою відповіддю після Genesis стала MacPaw, за яку проголосувало 10,26%. За ними з незначним відставанням розмістилися Grammarly та Readdle, які набрали по 7,69% Пошук роботи У який спосіб шукаєте роботу? Серед способів пошуку роботи лідерами є додавання профілю в сервіси для пошуку роботи (Djinni, Recruitika, Skyworker), який будуть використовувати 71,25% респондентів, та відгуки на розміщені вакансії — 65%. «Нині існують проблеми з ринком. Коли я починав, мені не важко було знайти роботу. Для джунів і світчерів зараз найкраще — шукати компанію, яка надає інтернатуру, школу абощо. Зараз iOS-розробка має багато прошарків, технологій та інструментів, початківцю в них важко розібратись. А компанія, що має школу або стажування, допоможе зорієнтуватись, навчить фахівця саме під свої запити і бачення. Якби шукав роботу зараз, як сеньор, то найголовніше джерело — колеги з ринку. Це можуть бути проджект-менеджери, з якими я працював раніше, колишні колеги-розробники. По-перше, вони знають, як ти працюєш, що вмієш, і одразу можуть дати рекомендацію. По-друге, все ж таки, реферали — це те, що працює надійніше за все» — коментує Роман Кириленко. Згідно з дослідженням, трохи більше за половину iOS-розробників оновлять свій LinkedIn-профіль, додавши в нього нову інформацію та поставлять статус Open for opportunities. Найменшою популярністю користується пошук роботи через знайомих рекрутерів, проте й цим варіантом скористається майже третина або 28,75% спеціалістів. 15% респондентів зазначили, що будуть використовувати всі доступні методи пошуку нової роботи. Про зарплатні очікування і реальність, кросплатформні рішення, найцікавіші українські iOS-продукти читайте у повній версії дослідження на AIN.UA.

Фронтенд-розробник — це спеціаліст, який створює видиму частину сайту чи застосунку для користувача. Вважається, що фронтенд — це легкий вхід в ІТ. Але може, насправді, фронтенд — це один з найскладніших напрямів розробки? Щоб розвиватися, потрібно вивчати якомога більше бібліотек, заглиблюватися в дизайн чи в патерни програмування? Чи завжди нативні застосунки кращі за веб? Мікрофронтенд вирішить усі проблеми вебзастосунку чи додасть нових? Найрозповсюдженіші міфи для HBJ спростовує Микола Носенко, Front-end Developer в OBRIO з екосистеми Genesis. > Фронтенд — це легкий старт в ІТ > Робота на фронтенді складається з однотипних задач > Для розвитку потрібно вивчати більше сучасних фреймворків та бібліотек > HTML, CSS та JavaScript — це технології, які не розвиваються та не змінюються > Нативні застосунки завжди будуть зручнішими за веб > Фронтенд-девелопер має обовʼязково добре розумітися в дизайні > Сторінки та вебзастосунки стають занадто складними > Мікрофронтенд — універсальне рішення, за яким майбутнє та яке підходить усім МІФ №1 Фронтенд — це легкий старт в ІТ. Історично склалося, що початківцям легше вивчати frontend development, аніж бекенд чи інші види розробки. Але це зовсім не означає, що цей напрям — простий. Раніше вивчення HTML та CSS було достатньо, щоби почати реалізовувати якісь проєкти. Загалом робота фронтенд-девелопера потребувала значно менше знань у програмуванні. Але щороку цей напрям ускладнюється: як інтерфейси, так і самі рішення. Джуніор уже навряд зможе знайти роботу та бути корисним на проєкті, якщо не знає JavaScript та як мінімум один із фреймворків. Бекенд — не легший і не складніший, а просто має свою специфіку. Робота з інтерфейсом командного рядка, терміналами, базами даних може здаватися занадто складною та незвичною для світчерів. Також тут неможливо отримати фідбек та побачити результат своїх зусиль так швидко, як їх покаже фронтенд-розробка, де більшість твоїх дій повʼязана зі взаємодією з користувачем. МІФ №2 Робота на фронтенді складається з однотипних задач. Насправді у фронтенд-розробника різноманітні задачі. Це не тільки створення інтерфейсів окремих компонентів або сторінок, а ще й робота з анімацією, написання автотестів, бізнес-логіки, налаштування аналітики, інтеграція нових технологій та багато чого іншого. Також це постійна комунікація з багатьма командами: дизайну, бекенду, QA, SEO, менеджерами, замовниками та іншими. МІФ №3 Для розвитку потрібно вивчати більше сучасних фреймворків та бібліотек. Часто розробники переконані, що шлях розвитку в цій сфері полягає у вивченні якомога більшої кількості бібліотек: чим більше їх знаєш, тим краще. При цьому в них залишаються прогалини у фундаментальних знаннях, без яких складно уявити подальший розвиток девелопера. Йдеться про основи та принципи програмування, парадигми, патерни — на будь-якому складному проєкті без цих основ буде дуже важко працювати ефективно. Принципи програмування допомагають краще організовувати код, робити його зрозумілим для інших розробників. Патерни — це підходи до вирішення абстрактних проблем. Більшість із них не пов'язані з конкретним доменом або сферою знань, але допомагають розуміти програмування загалом. Вміння їх використовувати допомагає позбавитися багатьох проблем, які можуть виникати в процесі розробки, та забезпечують якість коду. Frontend developer — це фахівець, який може швидше розвиватися вертикально або ж опановувати бекенд, фулстек чи інші сфери розробки. Крім того, такі навички допомагають розробнику обирати найефективніші інструменти та бібліотеки для його потреб. МІФ №4 HTML, CSS та JavaScript — це технології, які не розвиваються та не змінюються. Це твердження абсолютно невірне. Щороку в CSS, HTML та JavaScript виправляються недоліки та додаються нові можливості. Наприклад, з найцікавішого, що з'явилося в CSS за останній час, можна виділити: @layer — нарешті дозволяє вирішити одну з найскладніших проблем в CSS, а саме контроль над каскадом та конфліктами між селекторами. :has() — дає перевірити, чи містить батьківський елемент хоча б один із вказаних елементів. Цього дуже не вистачає в роботі. Умовні конструкції when/else — цікавий напрям розвитку, який ймовірно може стати стандартом. З останніх помітних нововведень у JavaScript — private fields та розширення синтаксису static, що наближають JS до класичних мов ООП, таких як Java, C# тощо. МІФ №5 Нативні застосунки завжди будуть зручнішими за веб. Дійсно, нативні застосунки можуть бути зручнішими для користувача ніж вебзастосунки, якщо дають доступ до певних функцій пристрою, яких не має браузер. Одна з їхніх переваг — швидкість. Однак це змінилося з появою прогресивних вебзастосунків (Progressive Web Apps) та зростанням їхньої популярності. Вони можуть працювати в режимі офлайн та мати багато функцій, які раніше були доступні лише в нативних застосунках. Після встановлення на головний екран, вони працюють швидше, ніж у браузері. Крім того, PWA значно дешевші та простіші у розробці та підтримці. Наразі їх можна публікувати в Google Play та Microsoft Store серед інших продуктів. Водночас існує багато інструментів, які дозволяють фронтенд-розробникам створювати гібридні застосунки на JavaScript для різних платформ. Наприклад, Electron можна використовувати для створення продуктів для десктопу, а React Native — для мобільних пристроїв. Цей напрям розробки також активно розвивається, постійно з'являються нові технології. Наприклад, фреймворк Tauri, що поєднує швидкість Go з легкістю розробки за допомогою HTML, CSS та JavaScript для створення десктопних застосунків. Але PWA та гібридні застосунки не є ідеальним рішенням, яке може повністю замінити нативні. Все як завжди залежить від складності застосунку та потреб бізнесу. МІФ №6 Фронтенд-девелопер має обовʼязково добре розумітися в дизайні. Фронтенд-розробник має вміти взаємодіяти з дизайном. Особливо на ранніх етапах проєкту, коли треба закласти дизайн-систему в коді для подальшого успішного розвитку продукту. Але з іншого боку, одна з цінностей фронтенд-девелопера полягає в тому, що він може поставити себе на місце користувача. Він — та людина, яка першою буде взаємодіяти з інтерфейсом. Дизайнерський досвід та фокус на правилах прийняття тих чи інших рішень можуть обмежувати його у судженнях. МІФ №7 Сторінки та вебзастосунки стають занадто складними. З одного боку, вебзастосунки з кожним роком стають все складнішими, що призводить до проблем з продуктивністю. З іншого боку, стандарти швидкості від Google надають жорсткі критерії, яким мають відповідати сайти для успішного SEO-просування. У відповідь на це зʼявляються технології, що вирішують проблеми оптимізації, які вже не можна ігнорувати в Single-page Application (SPA). З новими фреймворками можна не витрачати багато зусиль на самостійне вирішення проблем перформансу. Серед них, наприклад, Next.js, який вже став майже стандартом для створення нових продуктів на React, або новачки, такі як Astro, що пропонують поглянути на створення сайтів під новим (старим) кутом Multiple-page Application, розробляючи їх на улюблених SPA-фреймворках. МІФ №8 Мікрофронтенд — універсальне рішення, за яким майбутнє та яке підходить усім. Проблеми, для вирішення яких підходить мікрофронтенд, зʼявляються, коли вебзастосунок стрімко зростає разом з командою. Або ж йому вже стільки років, що його надто складно підтримувати та треба ітеративно покращувати. Мікрофронтенд — це підхід, що дозволяє працювати з певними частинами проєкту, незалежно від інших. Наприклад, одна команда може створювати логіку пошуку, а інша сфокусована на профілі користувача. Вони не перетинаються у виборі технологій і не залежать одна від одної. З одного боку цей підхід призводить до «зоопарку технологій», а з іншого — додає гнучкості у формуванні команд, наймі, підходах, які використовуються на проєктах. Чи ефективний такий підхід? Так, але підходить він не всім. Не варто використовувати його без потреби та конкретної проблеми, яку треба вирішити.

У квітні компанії з екосистеми Genesis шукають розробників, що працюватимуть з технологічними продуктами різного спрямування. Є пропозиції для фахівців з PHP, Unity, а також тих, хто розуміється на Android та iOS. Завдання — складні, але цікаві. Гортайте підбірку та знаходьте пропозиції саме для вас! А ще — декілька корисних матеріалів для співбесід. iOS Developer (вакансія закрита) У Holy Water , паблішера застосунків та рольових мобільних ігор, ви будете працювати у команді, яка розвиває гру в жанрі інтерактивних історій. Завдання — розробляти застосунки та покращувати користувальницький досвід: тестувати нові фічі, працювати над новим функціоналом та вдосконалювати наявні продукти. Для цього знадобиться досвід в iOS-розробці не менше 2 років, вміння працювати зі SwiftUI та знання архітектурних рішень (Swift, UIkit, core data/realm і т. д.). PHP Developer (вакансія закрита) Компанія Sendios працює з великими та малими підприємцями і допомагає їм досягати бізнес-цілей за допомогою email-маркетингу. Наразі команда шукає PHP-розробника з мінімум чотирма роками відповідного досвіду, що працював із фреймворками Laravel та Symfony, добре знає інженерні моделі та принципи SOLID, а також технології Memcached/Redis, RabbitMQ. Плюсом буде досвід декомпозиції завдань та розробки нових функцій, робота з високонавантаженими системами та будь-яким ESP. Серед завдань — покращенням архітектурних рішень продукту, аналіз та впровадження технічних рішень для потреб бізнесу, участь у декомпозиції завдань та виборі технологій. DevOps Engineer (вакансія закрита) Також Sendios шукає DevOps-інженера рівня сеньйор. На посаді він допоможе команді впоратися з основними службами сховища даних та оптимізує рішення щодо їхньої доступності, затримки та перформансу; «переселить» програми на інфраструктуру на основі Docker, автоматизує процеси розгортання інфраструктури та вдосконалить систему моніторингу. Що для цього потрібно? Хороша технологічна підкованість: сильні навички адміністрування Linux, розуміння систем Unix/Linux, розуміння систем віртуалізації KVM (Proxmox), VMware, досвід роботи з MySQL та системами моніторингу на кшталт Zabbix, Grafana, Prometheus. iOS Developer Lift — це компанія-розробник мобільного фоторедактора на основі штучного інтелекту, що допомагає створювати візуальний контент малим підприємцям і диджитал-фахівцям. Її технічну команду посилить iOS-розробник рівня сеньйор, що працюватиме з функцією обробки відео, створить новий функціонал та обере оптимальні технології для стабільної роботи застосунку. Команда очікує, що людина вже знає Swift, Xcode Profile, розуміє багатопотоковість, а ще має досвід роботи з AVFoundation та Metal. Останнє стане перевагою під час найму. Android Developer (вакансія закрита) Команда Impulse розвиває застосунок для тренування мозку. Його версія на платформі iOS уже стала лідером у ніші Health&Fitness. Шукають фахівця, що з нуля зробить аналогічний продукт на Android. Не самотужки — в команді будуть ще 1-2 фахівці. Щоби приєднатися, важливо мати хороші знання з Kotlin та Java Core, Multithreading, Android SDK, попрацювати з Android Architecture Components та технологіями Coroutines + Flow й Jetpack Compose. Також згодяться розуміння принципів ООП, патернів проєктування, SOLID-принципів, а ще — досвід роботи з кастомними View, анімацією та Canvas. Не зайвими стануть приклади реалізованих застосунків у Google Play Market. Unity Developer (вакансія закрита) SUITSME розробляє інтерактивну платформу, яка об’єднує ігри та моду в одному застосунку. Розробник, що приєднається до команди, буде займатися ігровим процесом та функціями інфраструктури, братиме участь у розробці та впровадженні бекенд API та тісно співпрацюватиме з командою дизайнерів. Йому знадобиться мінімум 4 роки досвіду з Unity 3D і C#, знання найкращих практик збірки та контролю версій. Крім того, потрібен досвід інтеграції різних SDK в Unity, зокрема, Firebase, аналітики, рекламних мереж та вміння працювати з UniRX, UniTask, Zenject. Перевагу нададуть кандидатам, що менторили інших розробників, знають F2P, а також вміють оптимізовувати пам'ять та простір. Не знайшли вакансії для свого технологічного стека? Можливо, вона є серед інших вакансій компанії. Перегляньте їх за посиланням наприкінці тексту, а перед цим ознайомтеся з можливими питаннями на співбесіду для різних ґрейдів — у нас є матеріали про Golang , QA та JavaScript . Що почитати? 6 міфів про мобільну розробку. Спростовує iOS Engineer в Universe Мобільна розробка часто здається простішою, ніж інші, «серйозніші» напрями програмування. Але це не так — там чимало цікавих завдань і складних технологій. А ще багато хто думає, що застосунок можна зробити без коду, наприклад, через готові рішення в конструкторах інтерфейсів. Утім, розробникам так чи інакше доведеться працювати з кодом, аби все налаштувати. У матеріалі за посиланням — ще декілька міфів та їхнє спростування. Читати всім, хто думає, що ринок мобільних застосунків перенасичений і там більше нічого робити. 30 подкастів для техногіків і техногікинь Добірні подкасти для тих, хто уже загубився в різноманітті пропозицій від Apple Podcasts, Spotify та інших стримінгових сервісів. Тут і про венчур, і про штучний інтелект (так, ми теж від нього втомилися), і про останні новини. Окремий блок — подкасти із жінками в головних ролях. Одним словом — ось контент для дороги на роботу або для відпочинку наприкінці тижня.

Що питають на співбесіді у Golang розробників? В цьому тексті зібрано великий перелік поширених питань з теорії та практики для спеціалістів різних ґрейдів — Junior, Middle, Senior. Він буде корисним для підготовки до технічного інтервʼю та допоможе виявити прогалини в знаннях. Зазвичай кандидатам ставлять лише невелику частину питань із цього списку. Євген Кострика, Golang Developer у Boosters та Володимир Корнієнко, Back-end Engineer у Headway , партнерській компанії Genesis, поділилися, чим відрізняються співбесіди на різні позиції, а також пояснили, чого очікують інтервʼюери від кандидатів та на що звертають увагу. > Питання для Junior > Питання для Middle > Питання для Senior > Що почитати, готуючись до інтервʼю Питання для Junior Співбесіда для ґрейду «джуніор» зазвичай починається з низки загальних теоретичних питань. «На мою думку, це гарний спосіб почати інтервʼю. Це дає змогу зрозуміти, що ви говорите однією мовою. Наприклад, якщо кандидат не знає, що таке взагалі ООП, то, можливо, навіть немає сенсу продовжувати співбесіду, — ділиться Євген Кострика, Golang Developer у Boosters. Далі інтервʼюеру варто переходити до більш практичних питань, або таких, що корелюють з фактичною роботою, з якою стикнеться розробник. «Якось на співбесіді на попередню роботу мене протягом години «ганяли» винятково по теорії, щоби визначити мій ґрейд. На мою думку, це не зовсім обʼєктивно. Вважаю, що іноді тестові завдання можуть значно більше сказати про бекграунд розробника, ніж теоретичний квіз», — пояснює Євген. Робота джуніорів — суцільні стресові ситуації, з якими вони стикаються майже щодня. Тому на співбесідах інтервʼюери часто перевіряють реакцію — це можуть бути завдання з лайфкодингу або доволі складні питання. «В такому випадку звертають увагу не на саму відповідь (правильна вона чи ні), а на те, як кандидат реагує на труднощі, хід його думок та мотивацію», — каже Євген Кострика. Загальні питання 1. Які бувають типи баз даних? 2. Що таке HTTP-протокол? Як він працює? 3. Що таке статус-код у HTTP? Назвіть статус-коди, які знаєте? 4. Що таке патерн програмування? Які патерни ви знаєте? 5. Що таке процеси та потоки в операційній системі? 6. Які основні принципи ООП? 7. Що таке SOLID? 8. Поясніть, що таке Docker? 9. Що таке контроль версій і чому він важливий у розробці програмного забезпечення? 10. Опишіть життєвий цикл розробки програмного забезпечення? 11. Що означають різні фази життєвого циклу та які дії виконуються на кожній з них? Go 12. Які переваги має Go перед іншими мовами програмування? 13. Чи можете ви пояснити концепцію каналів у Go? 14. Як в Go реалізовано ООП? 15. Що таке goroutine? Навіщо вона потрібна? 16. В чому різниця між goroutine та потоками? 17. Назвіть види лапок в Go? Чим вони відрізняються? 18. Що таке slice? Як він влаштований? 19. Чим slice відрізняється від масиву? 20. Чи потрібно передавати slice по ссилці у функцію? 21. Як передаються змінні в Go? 22. Який розмір масиву виділяється під slice при його розширенні? 23. Що таке runtime? 24. Що являють собою рядки в Go? 25. Як можна оперувати рядками? 26. Чи можна змінити певний символ у рядку? 27. Що відбувається при склеюванні рядків? 28. Як визначити кількість символів для рядка? 29. Як працює базова функція append? 30. Якщо у функції є return, чи обов'язково вона поверне те, що зазначено в return? 31. Що таке пакети в Go? Які пакети ви знаєте? 32. Як працює сортування? Які знаєте допоміжні функції для сортування? 33. Поясніть, як працює оператор defer? 34. Який порядок виконання для кількох операторів defer у Go? 35. Чим defer відрізняється від інших операторів потоку керування в Go, таких як return і panic? 36. Як ви розумієте процес garbage collector в Go? 37. Що таке асинхронність? 38. Що таке конкурентність? 39. Що таке паралельність? 40. З якими сторонніми пакетами та фреймворками працювали? Опишіть свій досвід. Чому обрали саме їх? 41. Який порядок виконання операцій case у select? 42. Що таке type switch? 43. Як повідомити компілятор, що наш тип реалізує інтерфейс? 44. Яке у slice zero value? Які операції з ним можливі? 45. Чим відрізняється int від uint? 46. Що таке типовий int і які є аспекти його реалізації?" 47. Як перетворити рядок на int і навпаки? Чи можна зробити int(string) та string(int) відповідно? 48. Що таке константи? Чи можна їх змінювати? 49. Де константи розташовані в памʼяті? Map 50. Що таке map в Go? Чим відрізняється від інших структур даних? 51. Які є особливості синтаксису отримання та запису значень у map? 52. Як відбувається пошук по ключу в map? 53. Як додавати та видаляти пари ключ-значення з map в Go? 54. Що станеться, якщо ви спробуєте отримати доступ до ключа, якого немає в map в Go? Як це можна вирішити? 55. Чи можна зробити map з ключами різних типів у Go? Якщо так, то як це зробити? 56. Як перевірити, чи існує ключ в map? Який найефективніший спосіб це зробити? Інтерфейси 57. Що таке інтерфейс у Go? Яке його призначення та чим він відрізняється від структури? 58. Наведіть приклад реалізації інтерфейсів в Go? 59. Як ви оголошуєте інтерфейс у Go? 60. Чи можете ви навести приклад інтерфейсу, який визначає метод? 61. Як визначити тип інтерфейсу? 62. Що таке порожній інтерфейс? Як його можна використовувати? 63. Як переконатися, що ваш інтерфейс сумісний із кодом, який його реалізує? 64. Що таке поліморфізм у Go? Як інтерфейси підтримують поліморфізм у Go? Практичні завдання 65. Що виведе цей код ? Чому? Які зміни треба внести, щоби програма вивела 42 и 13? 66. Що виведе цей код ? Чому? 67. Що виведе цей код ? Чому? Як його виправити? 68. Що виведе цей код ? Чому? Як його виправити? 69. За який час умовно виконається програма — за 3 секунди чи за 6? Що потрібно змінити, щоби код працював за 3 секунди? Питання для Middle Ґрейд Middle — перехідна ланка. Тому в кандидатів так само можуть запитати теорію, дати завдання на кодинг. Від них очікують знання різноманітних нюансів горутин, тестування, синхронізації, роботи з мікросервісами та garbage collector. Також інтервʼюери часто мають спільний список питань для Middle / Senior, просто не очікують від мідла такої глибини аналізу та досвіду. Тому радимо кандидатам цього ґрейду також переглянути наступний розділ. 70. Які технічні недоліки Golang можете назвати? 71. Як зробити з масиву slice? Чи відсортується масив у сортуванні slice? 72. Припустимо, ваша функція повинна повертати деталізовані Recoverable та Fatal помилки. Як це зробити? 73. Що таке пакет testify? 74. Що таке пакет Mock? Для чого він потрібен? 75. Який мінімальний і максимальний розмір горутин? 76. Що буде, якщо розмір горутини перевищив допустимий максимум? 77. Чи однаково горутини ділять між собою процесорний час?" 78. Які є способи зупинити горутини? 79. Як налагодити зв'язок між горутинами? 80. Чи можна використовувати один і той самий буфер []byte у кількох горутинах? 81. Яка різниця між монолітною архітектурою та архітектурою мікросервісів? Наведіть приклад, коли варто кому віддати перевагу? 82. Які існують загальні стратегії кешування? 83. Поясніть концепцію рефлексії в Go. Як її використовувати для реалізації загальної структури даних або алгоритму? 84. Поясніть концепцію інтерфейсів у Go? Наведіть приклад, як ви використовували інтерфейси в проєкті, та як вони допомогли досягти ваших цілей? 85. Чи є для Go хороший ORM? Аргументуйте свою відповідь. Канали 86. Як можна використовувати канали для реалізації паралельного програмування, і які найкращі практики для цього? 87. Яких поширених помилок слід уникати під час використання каналів у Go? 88. Як можна використовувати буферизовані канали в Go для підвищення продуктивності, і які компроміси слід враховувати при цьому? 89. Як можна використовувати оператори select для обробки кількох каналів і уникнути блокування? 90. Які є альтернативи каналам для паралельного програмування у Go? Коли можна вибрати один підхід замість іншого? 91. Що таке буферизований та небуферизований канал? 92. Назви чотири аксіоми каналу? 93. Що буде, якщо писати/читати в nil канал? 94. Що буде якщо писати/читати/з закритий канал? 95. Що буде якщо писати/читати в/з буферизованого каналу? 96. Що буде якщо писати/читати в/з небуферизованого каналу? 97. Як закрити канал? Що з ним відбувається? Контексти 98. Що таке контекст? Для чого застосується? 99. Чим він важливий для паралельного програмування? 100. Чим відрізняється context.Background от context.TODO? 101. В чому різниця між context.WithCancel, context.WithDeadline, context.WithTimeout?" 102. Як можна використовувати контекст у Go для керування термінами та тайм-аутами? 103. Яких поширених помилок слід уникати під час використання контексту в Go? Памʼять 104. Як реалізовано сховище пам'яті Go? 105. Що означає * і &? 106. Як передаються параметри у функцію? 107. Чи є особливості поведінки під час передачі map і slice у функцію? 108. Як функції діляться пам'яттю? Garbage collector 109. Що таке garbage collector і за яким алгоритмом він реалізований в Go? 110. Коли запускається garbage collector?" 111. Які ресурси споживає garbage collector?" 112. Які переваги та недоліки має garbage collector? 113. Як можна налаштувати garbage collector в Go, щоби оптимізувати продуктивність і мінімізувати використання пам’яті? 114. На які типові проблеми продуктивності слід звернути увагу під час використання garbage collector? 115. Які є альтернативи garbage collector в Go для керування пам’яттю? Коли можна вибрати один підхід замість іншого? Синхронізація 116. Що таке пакет Sync і що він надає? 117. В чому різниця між Mutex і WaitGroup у пакеті Sync? 118. Що таке змінна Once і як вона використовується в пакеті Sync? 119. Що таке пакет atomic? Як використовується в пакеті Sync? 120. Як можна використовувати WaitGroup у пакеті Sync для синхронізації виконання кількох готурин? 121. Що таке Mutex і для чого він використовується? 122. Які існують типи Mutex? 123. Яка різниця між Mutex і RWMutex у Go? 124. Чи можете ви пояснити, як Mutex допомагає синхронізувати доступ до спільних ресурсів у Go? 125. Як Mutex отримує та знімає блокування в Go? 126. Що таке взаємоблокування і як його можна уникнути, використовуючи Mutex у Go? 127. У яких сценаріях ви б використали Mutex над WaitGroup у Go? 128. Чи можна реалізувати sync.Mutex та sync.WaitGroup у каналах? У який спосіб? Мікросервіси 129. Що таке мікросервіси? Чим вони відрізняються від монолітних архітектур? 130. Які переваги та недоліки використання мікросервісів? 131. Чи працювали ви з будь-якими фреймворками мікросервісів у Go? Опишіть свій досвід? 132. Як би ви вирішували наскрізні проблеми, такі як authentication and logging, в архітектурі мікросервісу? Опишіть моделі та інструменти, які ви б використовували? 133. Як би ви підійшли до тестування та налагодження архітектури мікросервісу? Опишіть стратегії та інструменти для виявлення та усунення проблем? 134. Як би ви впоралися з узгодженістю даних і транзакціями в архітектурі мікросервісу? Чи можете ви описати деякі шаблони та інструменти? Тестування 135. Що таке модульне тестування? Чим воно відрізняється від інтеграційного тестування та наскрізного тестування? 136. Як написати модульний тест у Go? Наведіть приклад простого модульного тесту для функції? 137. Як ви використовуєте mocking у своїх тестах? Наведіть приклад ситуації. 138. Як ви вимірюєте покриття коду у своїх тестах? Який інструмент ви використовуєте та як інтерпретуєте результати? 139. Як ви обробляєте залежності у своїх тестах? 140. Як написати тест для паралельного коду в Go? Наведіть приклад тесту для паралельної функції? 141. Як ви автоматизуєте свої тести? Який інструмент використовуєте та як інтегруєте його з пайплайном CI/CD? Практичні завдання 142. ​​Дано масив n x n, поверніть елементи масиву, розташовані від крайніх елементів до середнього елемента, рухаючись за годинниковою стрілкою. array = [[1,2,3], [4,5,6], [7,8,9]] snail(array)#=>[1,2,3,6,9,8,7,4,5] 143. Дано додатне число n > 1. Знайдіть розклад n на прості множники. Результатом буде рядок такого вигляду: "(p1**n1)(p2**n2)...(pk**nk)" з p(i) у порядку зростання та n(i) порожнім, якщо n(i) дорівнює 1. Example: n = 86240 should return "(2**5)(5)(7**2)(11)" 144. Реалізуйте функцію, яка отримує дві адреси IPv4 і повертає кількість адрес між ними (включно з першою, за винятком останньої). Усі введені дані будуть дійсними адресами IPv4 у вигляді рядків. Остання адреса завжди буде більшою за першу. * With input "10.0.0.0", "10.0.0.50" => return 50 * With input "10.0.0.0", "10.0.1.0" => return 256 *Withinput"20.0.0.10","20.0.1.0"=>return246 Питання для Senior Питання для розробників рівня сеньйор зазвичай стосуються архітектурних рішень, оптимізації, безпеки та вирішення різноманітних проблем системи. Інтервʼюер звертає увагу, які технології обирає кандидат для запропонованих рішень, як аргументує свій вибір, які бачить плюси й мінуси. Загалом від нього очікують глибокого розуміння, як працюють сучасні сервіси, та як їх будувати. «Мова програмування Golang дизайнилася, як проста та мінімалістична. Це не С++, в якому сеньйор і мідл дуже відрізняються за рівнем знання мови. Можна сказати, що починаючи зі «strong junior» до «senior» в Golang вже немає великої різниці у якості коду. Просто сеньйор більш концептуально розуміє проблеми, має глибокі знання, як все працює під капотом, ширше бачить проблеми та може запропонувати рішення на рівні архітектури — це ми перевіряємо на System Design інтервʼю», — пояснює Володимир Корнієнко, Back-end Engineer у Headway. 145. Як можна оптимізувати роботу програми Go? Опишіть поширені «вузькі місця», з якими ви стикалися, і як ви їх вирішували? 146. Розкажіть про ваш підхід до дебагінгу в Go? Які інструменти та стратегії вважаєте найбільш ефективними? 147. Як би ви впоралися з concurrency в програмі Go? Наведіть приклад використання вбудованих функцій паралелізму? 148. Розкажіть про ваш підхід до тестування коду Go? Які фреймворки та інструменти використовуєте? 149. Чи можете описати складну проблему, яку ви вирішили за допомогою Go? 150. Чи працювали з розподіленими системами в Go? Опишіть свій підхід до вирішення проблем мережі та узгодженості між кількома вузлами? 151. Як би ви розробили стійку до збоїв розподілену систему за допомогою Go? Які архітектурні моделі та стратегії ви б використали для забезпечення надійності та масштабованості? 152. Як би ви оптимізували вебзастосунок з високим трафіком? Опишіть поширені вузькі місця продуктивності та як ви їх вирішували? 153. Чи можете ви описати складну проблему паралелізму, яку ви вирішили за допомогою Go? Розкажіть про своє рішення? 154. Як би ви підійшли до налагодження складної багатопоточної програми Go з численними залежностями та службами? Які інструменти та стратегії ви б використали? 155. Скільки часу у хвилинах у вас займе написання процедури звернення однозвʼязного списку? 156. Що таке thread pool, якого він розміру та для чого потрібен? 157. Який, на вашу думку, найкращий спосіб зробити dependency injection? 158. Яка функція використовується для хешування в map? 159. Чому інтенсивна конкурента модифікація atomic призводить до помітного зниження продуктивності? 160. Ваші критерії вибору між GRPC та OpenAPI? 161. Який у вас улюблений логер? Які переваги має zerolog? Кешування та БД 162. Як реалізувати кешування в Go за допомогою популярних систем кешування? 163. Як можна оптимізувати запити до бази даних у Go і яких поширених пасток слід уникати? 164. Які існують стратегії обробки збоїв бази даних і як можна забезпечити високу доступність і відмовостійкість у розподіленому середовищі? 165. Як реалізувати LRU cache? 166. Які типи баз даних ви знаєте? Для яких кейсів кожна з них підходить? 167. Як масштабувати базу даних? 168. Які є методи зберігання даних? 169. Що таке індекси для бази даних? 170. Як можна виправити ситуацію, коли в системі велике навантаження? 171. Як використовується CD? 172. Як використовується load balancer? 173. Назвіть способи організації бази даних для зберігання медіа? Архітектура 174. Які шаблони проєктування ви використовуєте у своїй кодовій базі? Наведіть приклад. 175. Як ви керуєте залежностями у своїй кодовій базі? 176. Поясніть концепцію шлюзів API в архітектурах мікросервісів і як їх можна використовувати для покращення масштабованості та надійності? 177. Чи працювали ви з будь-якими фреймворками шлюзу API в Go? 178. Як би ви підійшли до розробки архітектури мікросервісу для нового проєкту? Які фактори ви б врахували, і яких шаблонів проєктування ви б дотримувалися? 179. Як ви гарантуєте, що ваш код масштабований і підтримується? 180. Як би ви гарантували безпеку програми Go з точки зору запобігання зовнішнім атакам і захисту конфіденційних даних? Розкажіть про свій досвід впровадження автентифікації та авторизації в Go? 181. Як вимірюєте продуктивність вашої архітектури? Які інструменти використовуєте для моніторингу та оптимізації системи? 182. Як ви гарантуєте, що ваша архітектура є гнучкою та адаптованою? Наведіть приклад того, як ви змінили свою архітектуру у відповідь на нові вимоги? Що почитати, готуючись до інтервʼю Книги An Introduction to Programming in Go, Caleb Doxsey The Go programming language, Alan A. A. Donovan, Brian W. Kernighan Go Design patterns, Mario Castro Contreras Level Up Your Web Apps With Go, Mal Curtis Concurrency in Go, Katherine Cox-Buday Go in Action, William Kennedy, Brian Ketelsen, and Erik St. Martin Learning Go, Jon Bodner Блоги https://microservices.io/ https://blog.Go.org/ https://grpc.io/ ​​ https://tour.golang.org/ https://dave.cheney.net/

Аутсорс чи продукт — кожен із цих типів ІТ-бізнесів має свої обʼєктивні переваги та недоліки. А також — ряд упереджень щодо стеку технологій, можливостей для розвитку, овертаймів та бенефітів. Чи йдуть у продуктових компаніях на компроміс із якістю, чи є можливість експериментувати з технологіями, чи впливає розробник на продукт та чим мотивувати спеціалістів в Україні. Найрозповсюдженіші міфи спростовував Юрій Мокрушин, CTO Universe , компанії з екосистеми Genesis. Юрій починав карʼєру понад 10 років тому з позиції Java-розробника та встиг попрацювати в різних типах ІТ-компаній: стартапі, аутсорсі, аутстафі та великій продуктовій компанії. Має досвід у побудові складних архітектурних рішень, оптимізації процесів та створенні команди. > В гонитві за хайповими технологіями та фічами доводиться поступатися якістю. > С тек технологій відстає, тому розробники повільніше розвиваються. > Робота в розвинутому продукті — це переважно підтримка. > Р оль розробника менш важлива. Усі рішення диктують цифри в аналітиці (користувачі, маркетинг) тощо. > У продуктових компаніях багато овертаймів та нерівномірна завантаженість. > Н емає, з ким обмінюватися експертизою. > Працівники швидко втрачають мотивацію, тому проєктам бракує свіжих ідей. МІФ №1 Стартапи женуться за хайповими технологіями, а розвинуті продукти — за фічами. В обох випадках доводиться поступатися якістю. Найголовніше, за чим мають гнатися всі технічні команди — це певні бізнес-цілі. Від цього відштовхуються стейкхолдери, приймаючи будь-яке рішення. Якщо є потреба отримати раунд інвестицій завдяки хайповій технології або збільшити кількість користувачів завдяки новій фічі, — це і є бізнес-цілі, яких треба досягти. Від них залежить доля компанії: якщо не буде фінансування, бізнес не виживе. Якщо не «викатувати» нові фічі, ви будете відставати від конкурентів, та як наслідок, ваші продуктові метрики падатимуть, зменшуватимуться доходи, і в результаті — бізнес не виживе. Тому статистично цей міф можна підтвердити. Але щодо поступок у якості — можна сперечатися. Спочатку варто визначити: що таке якість? Технічні фахівці часто називають «якістю» чисто технічні показники — наприклад, Code Coverage, доцільність яких важко пояснити стейкхолдерам. Тому для них три години рефакторингу на тиждень — це і є компроміс у питаннях якості. Якщо «якістю» назвати рішення, без якого «відвалиться» 10% юзерів та 5% доходу, виникнуть проблеми з масштабуванням чи безпекою, то на такі компроміси не піде жодна продуктова команда. МІФ №2 У продукті стек технологій відстає, розробники не мають змоги експериментувати, тому повільніше розвиваються. Змоделюємо ситуацію. Технічна команда може обрати рішенн я на хайповому стеці. Або н а старому (водночас НЕ застарілому), яке можна швидко реалізувати, і воно стабільно працюватиме. З дуже високою ймовірністю продуктова команда скаже: «Нащо ризикувати? Давайте просто зробимо так, щоби все надійно працювало». Кінцевому користувачеві неважливо, що у вас під капотом — звичайна Java чи блокчейн, якщо продукт закриває їхні потреби. Розробникам від цього боляче, адже всі прагнуть самовдосконалення, бути актуальними на ринку, експериментувати. Але це не привід ставити на перше місце технології, а на друге — бізнесові потреби. Якщо у вас є готовий продукт, користувачі, метрики тощо — вам є що втрачати. Ви не будете без нагальної потреби стрибати на нову технологію, тому що щось чули про неї. Одна з речей, яка вирізняє мідла від сеньйора — це розуміння, що ти пишеш код не заради технології, а щоби закривати бізнес-потреби. Цей скіл найкраще качається в продуктових компаніях. Якщо ви не вивчаєте нову технологію щомісяця, це не означає, що ви стоїте на місці. Ви розвиваєте інші навички. Втім, є завдання, де нові технології дійсно потрібні. І тут розробнику знадобляться софт-скіли: вміння пояснити та аргументувати, чому це важливо для бізнеса. Якщо технологія справді вирішуватиме певну проблему, а не просто «прикольна», то її з високою ймовірністю впровадять без вагань. МІФ №3 У розробника є можливість вплинути на продукт тільки під час запуску, надалі — це переважно підтримка та одноманітна робота. Правдивість цього міфу залежить від стадії, на якій знаходиться продукт. Коли відбувся повний «feature freeze», немає розвитку, а є лише сапорт — фактично це стадія стагнації, у якій розробник дійсно не може впливати на продукт. У всіх інших випадках вплив є і досить потужний. Крім основних флагманських продуктів компанії часто розвивають додаткові напрями, вивчають нові ніші та запускають у них мініпродукти, які із часом також можуть стати флагманами. Це досить поширена практика для продуктових бізнесів у всьому світі та в Україні. Наприклад, в Universe є напрям «утиліти», який запустили ще 2018 року, і він продовжує розвиватися та постійно доповнюється новим функціоналом. І є R&D , у якому команда експериментує з технологіями, нішами та зараз працює над продуктом, якого ще рік тому не було. Середовище в продуктовому ІТ постійно змінюється, тому ця робота для розробників досить драйвова та динамічна. МІФ №4 Роль розробника менш важлива. Усі рішення диктують цифри в аналітиці (користувачі, маркетинг) тощо. Це правда, але це стосується будь-якої IT-компанії, не лише продуктової. Навряд чи існує команда, у якій розробник може одноосібно приймати суперечливі рішення з аргументацією: «Я художник, я так бачу». У кожній ІТ-компанії є розробники, які відповідають за код. І є менеджери, які відповідають, щоби задовольнялися вимоги замовника (в аутсорсі) або користувача (в продукті). Якщо розробнику в продуктовій компанії хочеться більше контролювати процес, є багато суміжних позицій, наприклад, Technical Product Manager. Або можна світчнутися на продакт-менеджера . Також це не означає, що до розробників не прислуховуються, а просто дають завдання. Проактивних спеціалістів, які проявляють ініціативу, аргументують та доводять свою думку, завжди почують. Розробники часто бачать, як покращити процес або продукт зсередини, і в них завжди є можливість запропонувати ідею під час, наприклад, грумінгу чи іншої командної зустрічі. МІФ №5 У продуктових компаніях багато овертаймів та нерівномірна завантаженість. Наявність овертаймів залежить не від типу компанії, а від побудови процесів. Зазвичай у стартапах їх більше — адже від цього залежить виживання бізнесу. Також овертайми досить часто трапляються в невеликих сервісних компаніях, які бояться втратити замовників — навіть неадекватних, які в останній момент змінюють концепцію і просять усе переробити. Кожен овертайм — це використання майбутнього ресурсу. З погляду менеджменту, це дуже бʼє по команді, особливо, якщо вона не розуміє кінцевої мети. Якщо менеджер заганятиме команду просто тому, що він так хоче, він швидко втратить її. Щоб уникнути овертаймів, у великих компаніях (як продуктових, так і аутсорсингових) багато часу приділяється плануванню на квартал, епізод, рік, складають роадмапи, командні цілі. МІФ №6 Більшість команди складають нетехнічні спеціалісти, тому розробнику немає, з ким обмінюватися експертизою. Продуктові компанії бувають різні. Genesis — це велика екосистема, яка складається з компаній, всередині яких можуть бути різні проєкти. Коли в структурі таких масштабів правильно побудовані процеси, розвивати нетворкінг легко: завжди можна знайти контакт колеги з іншого проєкту та попросити поділитися досвідом. В Genesis побудована система профільних спільнот, в яких можна обмінюватися експертизою, кейсами, проводити воркшопи, мітапи, дискусії. Або просто зустрітися на каву та поспілкуватися. Для технічних спеціалістів є пʼять комʼюніті: бекенд, фронтенд, QA, DevOps та геймдев. МІФ №7 Працівники надто довго засиджуються на одному місці, втрачають мотивацію, тому проєктам бракує свіжих ідей. В ІТ-індустрії панує умовне правило, що фахівець має кожні декілька років змінювати позицію / проєкт / компанію. Інакше — втрачається мотивація, залученість, завдання здаються одноманітними та нецікавими. «Життєвий цикл співробітника» — це поняття показує, скільки фахівець проведе часу в проєкті. Продуктові компанії ретельно відстежують цю метрику та намагаються оптимізувати. Як команда прагне покращити досвід користувача в продукті, так і компанія зацікавлена допомогти співробітникам стрімко зростати та досягати спільних цілей. Як бізнес може мотивувати співробітників, окрім як фінансово? 1. Стимулювати професійний розвиток, допомогти опанувати нові скіли. Комусь потрібен ментор, хтось прагне опанувати нову технологію, а хтось накопичив експертизу і прагне нею поділитися. Освітніх форматів в екосистемі чимало (як внутрішніх, так і зовнішніх). Якщо спеціалісти практикують continuous learning, браку свіжих ідей та підходів у них не буде. 2. Допомагати у карʼєрному зростанні. Якщо у технічного спеціаліста зʼявилося бажання очолити команду, новий проєкт, або перейти в суміжну сферу, компанія має підтримати його ініціативу. Якщо не вистачає управлінських навичок, є школи менеджменту та лідерства (як в екосистемі загалом, так і в окремих компаніях). Наприклад, за останні пів року в Universe виросли QA engineer та IOS Engineer до QA Lead та IOS Lead відповідно. Вони пройшли внутрішні курси менеджменту, а також мали специфічні завдання на квартал, які треба було виконати за допомогою делегування на команду. 3. Сильна корпоративна культура. Залученість — потужний інструмент мотивації. Розробник має відчувати свою роль не на рівні «я написав код і зробив пуш», а на рівні «я зробив пуш, задеплоївся код, а за ним продакшн, тому користувачі побачили фічу, тому LTV збільшився на 2%. І все це завдяки мені!».