iOS-разработчикам, которые хотят прокачать свои навыки работы с многопоточностью – совсем скоро стартует Podlodka iOS Crew!

С 11 по 15 ноября лучшие эксперты разберут многопоточность, Swift Concurrency и алгоритмы в формате удобных онлайн-сессий.

В программе:

🔹 Александр Андрюхин проведёт нас через особенности Swift Concurrency, которых ты точно не знал
🔹 Swift 6 глазами Александра Априамашвили – как переход на новую версию поможет в повседневной работе.
🔹 Антон Марченко расскажет, как async в алгоритмах делает их быстрее.
🔹 Александр Сычев раскроет механизмы работы Thread и объяснит, как это важно для работы с многопоточностью.

Я уже бывал на подлодке, планирую присоединиться к конференции снова.

Присоединяйтесь и вы 👉https://podlodka.io/ioscrew

А промокод ios_crew_14_nrnujZ сообщества даёт скидку в 500 руб🥳

Как же собеседовать эффективно?

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

Подготовительный этап
(Если вы-инженер, который проводит техническое интервью.)

Представьте, что вы джун с небольшим опытом. Понимаю, это сложно, сейчас рождаются мидлами, но постарайтесь.

- Откройте среду для разработки, но без подсказок компилятора;
- Сформулируйте задачу, которую необходимо решить. Допустим, это экран из приложения, на котором отправляется запрос в сеть, а данные отображаются в табличном представлении;
- Добавьте требования со звездочкой. Например, что-то закэшировать, преобразовать как-то данные или отсортировать по условиям;
- Напишите максимально джуновское решение. Намеренно сделайте ошибки, опечатки, используйте примитивные подходы и простую архитектуру. Часть задания можно вообще сделать неверно или пропустить.

Настало время интервью

- Кандидат получает текстовое описание вашей проблемы и ваш “джуновский код”;
- Его задача - затюнить это безобразие до наилучшего состояния;
- Вы легко можете направлять, обсуждать идеи, усложнять требования по ходу выполнения и смотреть, как кандидат реагирует на изменения;
- Заранее заготовить несколько фолоу аппов и в зависимости от перформанса и ожидаемого уровня от кандидата давать их как дополнительные задания.

Пример можно найти по ссылке, доступен всем.

Почему этот подход работает?

- Во-первых, я часто использовал этот способ на практике и пока не пожалел ни разу. Оценка грейда была точная и не вызывала вопросов у коллег или руководства;
- Возможность проверить сразу несколько аспектов. Умение решать задачу согласно требованиям, умение видеть проблемы/баги и исправлять их, уровень насмотренности. Также вы можете в любой момент попросить теоретическое обоснование принятых решений;
- Вы проверяете ту работу, которой действительно занимается разработчик бОльшую часть своего времени. Он видит код, читает его, пробует оптимизировать, исправить ошибки, добавляет новую логику;
- Большая свобода в интервью. Возможность подстроиться под уровень самостоятельности кандидата. Задачу можно сформулировать так, что она подойдет для оценки разработчика любого уровня и опыта;
- Не нужны узкие знания, чтобы кандидат решил задачу. Для него процесс будет комфортным и не травматичным, задание ведь уже решено вашим внутренним “джуном”. Если он не смог его улучшить - поздравляю, скорее всего перед вами джун! А пасхалки для гуру всегда можно прикопать поглубже.

Прошу заметить, что данный подход ориентирован на технические этапы.

Есть идеи, как избежать ошибок при найме? Может, просто поставить 5 этапов алгоритмических задач?

PS. Мемы в комментарии)

Топ бесячих вопросов в iOS собеседованиях ❌
Менти прислал несколько моковых интервью, и я в очередной раз убедился, что меня подбешивают некоторые бессмысленные вопросы. Уверен, многие разработчики сталкивались с такими на интервью и вряд ли были в восторге. Я всегда топил за проверку того, как разработчик умеет решать реальные проблемы, а не пересказывать определения из книг.

5. Вложенные очереди
Я делал такие разборы, чтобы помочь менти победить духоту на собеседованиях, есть такой грешок. Но, пожалуйста, перестаньте это спрашивать на интервью, никто не пишет такой код в продакшене. Это не показывает навыки программирования и решения проблем ровным счетом никак.

4. Диспетчеризация методов
На эти вопросы хорошо отвечают джуны, потому что готовились к ним. По факту же, в клиентской разработке эти знания не применяются. Не могу припомнить реальных багов на проекте, где проблемы были бы связаны с диспетчеризацией.

3. Value type vs Reference Type
Кто кого захватит? Когда освободит? И прочее… Складывается впечатление, что тебя хотят подловить и обмануть, а не действительно проверить твои навыки. Код в примерах выглядит все также искусственно, и проблема переоценена.

2. Нелогичные ограничения на задачу
Задачу можно решить в две строки, что показывает наличие этих условий? - Что вы выстрелите себе в ногу.

С таким же успехом можно предложить решить задачу, не используя циклы. Ну а что, пусть кандидат найдет решение хитрее. В таймере будет инкрементировать переменную, например.

1. Глубокая теория.
Чаще всего вам нет необходимости знать, где выделится объект в памяти, будет ли для него создана side table или что вообще такое heapObject (подставь любой булшит из своего языка). Скорее всего, вы как разработчик создаете конечный продукт, а не новый язык программирования. Проверяйте применимые знания.

Что спрашивают сейчас на интервью, можно посмотреть тут

Что думаете, найм в АйТи сломан или все нормально? Дальше напишу, как на мой взгляд выглядит хорошее интервью.