Готуємось до співбесіди на позицію iOS-розробника

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Всім привіт! Мене звати Павло. Понад чотири роки я працюю iOS-розробником в різних компаніях, з різноманітними замовниками та проєктами. За цей час я мав достатньо досвіду, щоб зробити власні висновки та виділити основні проблемні моменти, які слід враховувати під час співбесід. Особистими спостереженнями та порадами я хочу поділитись в цій статті.

Для початку потрібно розібратися, для чого взагалі проводиться співбесіда.

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

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

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

Правильно поставлені питання справлять позитивне враження на співрозмовника, а також дозволяють отримати відповіді на питання, яких не покаже гугл.

Основні етапи підготовки

1. Огляд актуальних пропозицій

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

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

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

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

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

2. Створення резюме

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

  • Імʼя прізвище, посада, контактні дані (обовʼязково).
  • Посилання на соціальні мережі, посилання на github/gitlab/портфоліо.
  • Досвід роботи. Зазвичай він описується в порядку зворотного хронологічного розташування, тобто найновіші здобутки першими. Такий підхід дозволяє роботодавцю швидко побачити ваші найбільш актуальні навички та досягнення. Варто звернути увагу, що досвід потрібно подавати у вигляді досягнень/користі, яку ви принесли компанії.

❌ - фіксив баги.

✅ - Виявив та виправив програмні помилки у мобільному застосунку. Реалізував unit-тести для автоматизації тестування та раннього виявлення помилок, що дозволило заощадити витрати часу на тестування та відповідно зменшило навантаження на мануального тестувальника.

Якщо комерційного досвіду немає, то готуємо портфоліо. Створюємо 3-5 проєктів. Використовуємо різні архітектури (MVC/MVVM/VIP/VIPER), описуємо проблеми, які вирішують ваші апки. Основа задача — написати код, який можна буде легко читати іншим розробникам. Необхідно задати зрозумілі назви змінним/функціям/класам/файлам тощо. Застосунки мають вміти працювати з сервером (REST), а також логіку роботи з локальною БД (Realm/CoreData/UserDefaults). Фреймворк для UI може бути як UIKit, так і SwiftUI, якщо покажете розуміння обох, то це буде плюсом. Однак, я б зробив більший акцент на UIKit, який використовується для реалізації більшої частини проєктів. SwiftUI дуже крутий, але проєктів на ньому мало. Відповідно і вимога до знання UIKit залишається пріоритетною.

  • Перераховуємо технології, з якими працюємо. Я б не рекомендував згадувати ті технології, в яких ви погано орієнтуєтеся. Вказуйте тільки ті, які ви дійсно використовували і можете пояснити, як вони працюють (виключенням може бути ситуація, коли ви хочете дізнатись, які питання ставлять з певних технологій).
  • Додаємо блок з описом здобутої освіти (якщо освіта не технічна, то я б не вказував), перелік здобутої освіти описується в такому ж порядку, як і досвід (зворотний хронологічний).
  • Також варто зазначити мови, якими ви володієте, рівень знання мови описати словами (intermediate, advanced etc).

Краще користуватись спеціальними сервісами для створення резюме (resume.io, jobseeker тощо). Це значно пришвидшить створення CV, блоки інформації будуть розміщені в правильному порядку. Шрифти та кольори оформлення легко сприйматимуться рекрутером — на ознайомлення з резюме рекрутер витрачає 6-15 секунд, тому це слід врахувати.

Якщо складно писати CV без зразка, можете пошукати у LinkedIn резюме іншого iOS-розробника.

3. Підготовка до питань технічної частини

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

Що має знати Senior iOS Developer у 2024 роціПеред кожною співбесідою потрібно прочитати питання, освіжити відповіді на них в памʼяті. Ще я люблю дивитись проходження публічних технічних співбесід. Вони проводяться для кандидатів на посади різного рівня, тому кожен охочий може знайти щось цікаве саме для себе. Після кожного поставленого питання ставлю відео на паузу і стараюсь дати відповідь сам, а потім порівнюю свою відповідь з тою, яку дає кандидат та інтервʼюер.

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

  1. OOP (Abstraction, Encapsulation, Polymorphism)
  2. UIViewController Lifecycle
  3. Array/Set/Hash/Map
  4. Reference vs Value types
  5. Class/Struct/Enum
  6. SOLID
  7. Memory management (ARC, strong/weak references, retain cycle, memory leak)
  8. Stack vs Heap
  9. Closures + escaping/non escaping
  10. Frame vs Bounds
  11. UIView vs CALayer
  12. Multithreading (concurrency vs parallelism, deadlock, race condition, critical section)
  13. Protocol
  14. Generic
  15. Methods Dispatch
  16. GCD, Async/await, Actors, NSOperation
  17. REST (JSON, Codable, Decodable, Encodable)
  18. CoreData/Realm
  19. Architecture patterns (MVC, MVVM, VIPER etc)

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

Є ймовірність того, що замість тестових вам доведеться розв’язувати алгоритмічні завдання (часто така вимога зустрічається у закордонних компаніях). До таких задач нам допоможуть підготуватися leetcode та hacker rank.

4. Self Introduction

Важливо добре підготуватись до Self Introduction, оскільки ваше представлення себе як гарного спеціаліста може визначити успіх на наступних етапах співбесіди та вплинути на шлях отримання посади в компанії. Грамотно підготовлене та добре вивчене представлення допоможе вам виділитись серед інших кандидатів на співбесідах у будь-яку компанію.

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

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

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

5. Створюємо список питань до ведучого співбесіди

Залежно від етапу співбесіди (screening/introductio, technical interview, pm interview etc) створюємо окремий список питань для співрозмовника. Наприклад, питання про компанію, робочий графік, відпустки, ведення бухгалтерії можна поставити на перших етапах інтервʼю рекрутеру.

Якщо співбесіда проходить з ПМ, то добре буде дізнатись, які методи аналізу використовуються для збору вимог і розробки стратегії продукту, як часто оновлюється ТЗ і чи взагалі його хтось пише, як ПМ реагуєте на зміни у вимогах або пріоритетах під час розробки продукту, хто створює задачі для команди, які технології використовуються для створення продуктів, як часто потрібно виходити на міти із командою/замовником тощо.

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

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

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

Окремо можу виділити завдання на логіку, live coding, алгоритми, задачі на розв’язання теоретичних проблем, які можуть виникнути під час роботи над проєктами чи в команді. До них підготуватись доволі складно, адже кожна задача унікальна і потребує унікального рішення. Часто їх ставлять, щоб зрозуміти, як ви реагуєте на виклики, чи можете шукати нестандартні рішення, а іноді такі завдання допомагають зрозуміти, чи достатній ви маєте досвід та розуміння процесів для роботи на позиції, яку ви хочете отримати.

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

Сподіваюсь, ця стаття допоможе вам ефективно підготуватись до співбесіди. Пам’ятайте, що практика та постійний саморозвиток грають важливу роль у вашій підготовці. Тож не зупиняйтеся на досягнутому, а продовжуйте вдосконалюватися і набиратися досвіду. Бажаю вам успіхів та професійного зростання!

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Хтось може поменторити щодо IOS? Є досвід розробки під Flutter 3.5 років

1. OOP — здається неактуальним для сучасної розробки на Swift. Дуже давно не зустрічав подібні запитання =)
6. SOLID — о так, чи не найтоксичніші запитання, які можна задати на співбесіді (принципи все ще працюють, але не для POP, та не в повному обсязі. Проблема у тому, що 90% інтервюверів догматизували своє відношення до SOLID, створивши токсичну бульбашку)
19. Architecture — MVC, MVVM, VIPER тощо — то не архітектури, а архітектурні патерни) Різниця суттєва.

О боже заскриньте кто то этот коммент, непризнаный гений))) ооп неактуально, солид тоже неаккуратно))) Гений!!!!

Нормально спілкуватись не здатний? Людина висловила свою думку по пунктам, а ти переходиш на особистості, як школяр якийсь.

Ага, ну ти якщо читав що там написано, то він точно школяр

Сейчас бы в этот топик загнать dou.ua/users/trimm

Коментар порушує правила спільноти і видалений модераторами.

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

Так я дізнався про pop)

Можете порадити щось почитати?

Почати можна з WWDC сесій на цю тему) Підхід не дуже обʼємний, швидкий до опанування)
www.youtube.com/watch?v=p3zo4ptMBiQ
developer.apple.com/wwdc16/419

Дякую! З ваших посилань далі погуглив і найшов ось такий допис із прикладами коду: scotteg.github.io/...​ocol-oriented-programming Є про що подумати.

Я не розбираюсь, що мається на увазі під «то не архітектри, а архітектурні патерни», що ви конкретно маєте на увазі під «архітектурою» в данному контексті? Я одразу подумав про RISC, ARM і т.д., але думаю, мається на увазі інше, тому уточнюю

У моїй статті я розглядаю architecture patterns — це загальноприйняті стратегії та шаблони організації коду та взаємодії компонентів ПЗ. Ці паттерни є ключовими для створення добре структурованих, підтримуваних та розширюваних додатків. Про RISC, ARM і т.д питань на співбесідах я не зустрічав.

Дякую за статтю, тут зрозуміло!

Питання було до коментаря Ігоря, де він зазначив що MVP, VIPER etc.. то не архітектури, а архітектурні патерни, цікаво що малось увазі тоді під «архітектурами» в його розумінні, чи це просто коментар стосовно виправлення написаного в статті

Архітектури — то мікросервіси, моноліти, N-tier, як приклад.
Також існують різні патерни та/або рішення що відповідають на питання організації коду, модулів та залежностей у межах обраної архітектури.

А MV* (включно з VIPER) — то спосіб налаштування UI-шару та повʼязаної з ним логікою.

Так, це стосується архітектури, але не є архітектурою

І так, лише на паттерні та рандомному накидуванні коду можна виїхати, вважаючи, що твій MVVM — то така чудова архітектура) Але це спрацює для маленького пет-проєкту. У великому продакшені зазвичай ігнорують всі ці модні MV* назви, та роблять самодостатні рішення.

Знання MV* важливо лише для того, щоб від них відштовхуватися. Якщо ми кажемо про інженерний рівень, а не формошльопський))

P.S. До певного рівня відповідальності на проєкті (умовний Middle у вакуумі, людина що пише код, та не продукує рішень), абсолютно нормально виїзжати лише на паттернах

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

Та в який момент проект можна вважати великим, якщо він починався як пет-проект наприклад

Так немає тої межі) Просто на старті взагалі не варто переускладнювати щось. А там буде зрозуміло, коли можна маcштабувати. Простіше через пів року розробки зупинитися, і переписати умовний 1 файл коду в 10 (розвести архітектуру, так би мовити))), аніж накидати 10 файлів одразу, без бачення чіткої картини, а потім через пів року звільнитися, бо ну його то підтримувати =)

Підписатись на коментарі