Дякую за відгук!

який саме підхід ви використовували при переході, поетапний чи одразу весь проєкт?

При обох міграціях переводили одразу весь проєкт в окремих гілках.

чи можна підтримувати стару та нову інфраструктуру паралельно?

Можна! Подси дозволяють під’єднувати SPM-пакети, а з Tuist головне спочатку перевести xcodeproj у декларативний вигляд, а потім можна всі існуючі модулі під’єднати пакетами, і переносити їх по одному.

як щодо делівері нових фітч, паралельно тому поки був перехід?

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

Дякую вам за відгук)

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

дякую за відгук! не впевнена, що Tuist допоможе з розробкою бекенда на лінуксі, бо він в першу чергу генерує Xcode проєкти, а Xcode на лінуксі нема 😅. Можливо, є аналогічні інструменти для таких цілей)

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

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

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

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

Звісно, не завжди у розробників є можливість безпосередньо повпливати на грошові результати. Є і інші важливі показники. Проте, такий досвід буде вигідно вирізнятися на фоні інших кандидатів.

Дивіться блоки «що має бути у CV» та «чого не має бути у CV», там всі поради)

Не знаю коли писалась стаття, але цікаво — це копіпаста, чи дійсно хтось ще вказує скайп?

Найм відбувався на початку 2026 року, і у декількох кандидатів у CV був Skype. Так він і опинився в цій статті)

А чи використовували ви AI для обробки CV?

Для цієї вакансії — не використовували.

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

Така структура процесу якраз і покликана знизити ризик помилки. Але, звісно, жоден процес не дає 100% гарантії.

Чи дійсно компаніям вигідно ось так і процеси важливіші за саму роботу?

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

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

Але написати в LinkedIn — чудова порада, теж рекомендую.

Дякую!

Справді гарна стаття з рекомендаціями щодо того, що робити і чого уникати в хайринг процесі!

Дякую!

Однак, мені дивно чому у автора «погано» заповнений LinkedIn профіль.

Я роботу зараз і не шукаю 😅

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

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

Може, варто було відразу добавити вимогу «досвід роботи на дейтинг-проектами 6+ місяців обов’язковий».

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

Так само цей критерій не є і достатнім для найму: ми спілкувалися з іншими кандидатами з досвідом в дейтингу, але не дійшли з ними до оферу, бо вони не підійшли по основним вимогам.

Дякую)

А що підсвічувати в резюме, якщо на попередніх роботах все було під NDA, включно із назвами проектів?

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

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

Тут універсальної поради немає, особисто моя думка: не треба терпіти умови, які вам не підходять.

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

А скільки взагалі людей зробили тестове?

Тестове зробили 18 людей.

У вас на прев’ю статті теж використане ваше фото. 🙂

Але це ж і не моє CV)

Загалом, чіткого правила на тему фото у CV дійсно немає, з мого досвіду — його переважно не додають, і це така собі «норма» у нашому IT. Я не стану відмовляти кандидату через те, що у нього є фото в резюме, але і на перше враження наявність фото не матиме бажаного позитивного впливу для мене. Навіть, якщо фотографія дуже вдала 😄