💎 Задача по архитектурам: Модуль Избранного

Я продолжаю претендовать на сеньорский контент и заполнять ноушен уникальными задачами. Похожее не найдете ни в одной статье, а если найдете — скиньте в комменты, сам поизучаю 😬

Эту задачу я почти всегда давал своим менти. Почти невозможно решить её идеально, если вы самоучка и ваш опыт только по статьям в интернете или по постам в каналах.

Звучит так: Нужно спроектировать модуль избранного. Всё. Одно предложение, а работа на пару дней.

Эту секцию ведут всегда максимально свободно. Но оцениваю экспертность по общим качествам:

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

Обязательно рекомендую эту задачу, если понравились предыдущие:

🧬 Custom Notification Center
🖥 Service vs Repository

🧬 Получить доступ можно по подписке через бусти или по скидке тут

🌿 Подборка видео про архитектурные секции

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

Мобильные системы усложняются: появляются офлайн режимы; устройства имеют больше мощности; кроссплатформы расширяют горизонты;

Для этого всего требуется системное мышление, которое поможет оценить множество узлов и связей, избежать ошибок.

Компании адаптируются и вводят новую секцию по оценки кандидатов. Вот подборка интересных секций от бигтехов:

📺Как проходит архитектурная секция в команду мобильной разработки Яндекс 360

🌿Как собеседовать мобильных инженеров? Системный дизайн спешит на помощь!

📺Проводим и проходим Mobile System Design-интервью

🧑‍🦰 А я напоминаю, что сделал форк известного фреймворка и адаптирую его под iOS. Скоро туда будут выложены некоторые задачи и решения из закрытого контента.

#podcast #crossplatform

Ideas on Why Cross-Platform Development Might Be Challenging

Тенденция к кросс-платформенной разработке продолжает развиваться определенными темпами. Автор подкаста постарался перечислить причины, по которым это может быть проблематично:

1️⃣ Performance Issues
• Кроссплатформенные технологии часто приводят к снижению производительности по сравнению с нативной разработкой. Это особенно заметно в сложных приложениях с значительной интеграцией аппаратного обеспечения.
• Хотя кроссплатформенные инструменты улучшаются и некоторые из них транслируются в нативный код, производительность все равно может не соответствовать уровню нативных приложений.
2️⃣Complexity & Maintenance
• Кроссплатформенная разработка часто требует обработки множества кандишенов, специфичных для каждой платформы (например, if iOS, if Android), что приводит к усложнению и увеличению размера кода. Конечно это также может быть решено, но теперь у вас на одну задачу больше. Пусть небольшую.
• Такие платформы обычно сильно зависят от сторонних библиотек, что приводит к возникновению новых проблем, включая риски безопасности и вопросы управления зависимостями.
• Зависимость от сторонних библиотек означает, что вы полагаетесь на их постоянное обновление и поддержку, что не всегда гарантировано (стоит вспомнить Xamarin).
3️⃣ Security Risks
• Внедрение стороннего кода увеличивает потенциальный риск возникновения уязвимостей в безопасности, особенно если эти библиотеки не подвергаются тщательной поддержке и обновлению..
4️⃣ Compatibility & Debugging
• Обеспечение совместимости на различных устройствах с разными аппаратными характеристиками может привести к сложным проблемам и необходимости использования обходных решений в коде.
• Дебаггинг кроссплатформенных приложений может быть более сложным по сравнению с нативными приложениями, где инструменты и среды более зрелые и интегрированные.
5️⃣ Engineering Concerns
• Управление отдельными нативными кодовыми базами может поначалу казаться более сложным, но часто приводит к более плавным циклам разработки и меньшему количеству проблем с интеграцией в долгосрочной перспективе.
• Высокий уровень абстракции приводит к появлению дополнительных слоев, что, в свою очередь, вносит элемент непредсказуемости. Да простые элементы делать легче, но будут ли они всегда таковыми по мере жизненного цикла продукта - вопрос открытый.
• Нативные платформы, как правило, легче поддерживать и они более надежные, так как зависимости напрямую управляются владельцами платформ.
6️⃣ False Promises of Cross-Platform Tools
• Просит единой кодовой базы для нескольких платформ часто не оправдывается на практике, приводит к неожиданным сложностям и утрате видимой простоты, которая изначально была обещана.
• Поддержка и координация кроссплатформенных проектов может превратиться в логистический кошмар, особенно по мере роста и усложнения приложения.
7️⃣ General Preference for Native Development
• Нативные приложения легче поддерживать благодаря лучшей интеграции с экосистемой платформы.
• Нативные приложения часто приводят к меньшему количеству неожиданностей во время разработки, что снижает количество непредвиденных проблем, способных нарушить циклы разработки и выпуска.

• Главный мотив заключается в том, чтобы привнести бОльшую осведомленность/осторожность кросс-платформы, но ни в коем случае не вносить дополнительную дозу карго-культизма в ту или иную сторону.
• Важно помнить, что кросс-платформа это такой же инструмент и пока небыло однозначно доказано, что он может хорошо работать во всех юзкейсах.
• Не обязательно быть на 100% согласным или не согласным - полезные идеи можно найти в неожиданных местах.

[Duration: 13:39 | Language: Eng]

🏛 Polymorphic Blueprint

🖥 Github с решениями алгоритмов

Алгоритмы — новая реальность. Огромный поток желающих войти в ИТ сильно нагружает HR. Раньше алгоритмы были только у пары компаний, а сейчас даже стартапы берут одну или две алгоритмические задачи в процесс.

Решение алгосов это не только попытка пройти неумолимо усложняющиеся собесы и оставаться в форме, но и отличный тренажер формировать новые нейронные связи, натренировать усидчивость, навыки тестирования и не бояться лайфкодинга.

Мы в сообществе уже почти 5 месяцев регулярно качаем эти навыки. Прорешав уже около 100 задач. Попытались разобрать частые задачи из Яндекса, Авито, ФААНГОВ и других компаний.

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

Я решил потихоньку делиться, что накопилось за 5 месяцев сообщества. Пока в публичный доступ вышло три раздела с тремя страницами в каждой:

🟣Техники решения алгоритмов
🟣Задачи с массивами
🟣Задачами со строками

🧬Получить доступ ко всему складу можно по подписке через бусти или по скидке тут

💎 Вопросы на собеседованиях | Память | Junior ч. 3

Давно не было подборок. Выпустил третью часть вопросов для джунов по управлению памятью.

В этом блоке мы затронем:
🟣Где хранятся статические свойства?
🟣Что такое инлайнинг?
🟣Как работают указатели с weak и unowned ссылками?
🟣Какие типы подвязаны под машинное слово?
🟣И еще 10 дополнительных вопросов

Также можно ознакомиться с другими частями:

🟣Вопросы для собесов на память | Junior | ч. 1
🟣Вопросы для собесов на память | Junior | ч. 2

🧬Получить доступ ко всему складу можно по подписке через бусти или по скидке тут

🪙Рекрутер чуть лучше, чем подброс монетки

У нас часто жалуются о том, что индустрия сломана и есть фильтры. Чаще путая это с проблемами агрегаторов и других рекрутерских инструментов.

У рекрутеров своя задача — найти сильное резюме. Можно выделить его, а можно не надеяться на них и пойти напрямую.

Эксперимент такой, 76 рекрутеров просмотрели порядка 1000 резюме и сделали свои прогнозы. После этого кандидаты прошли mock-интервью на платформе. Полученные результаты сравнили между собой.

Первый вопрос, на который должны были ответить рекрутеры «Стоит ли собеседовать этого кандидата?». То есть при посмотре резюме, пропустит ли рекрутер кандидата дальше или нет? Прогноз совпадает с реальностью только в 55% случаев.

Второй вопрос «Какова вероятность, что кандидат пройдет техническое интервью?».
Те кандидаты, которым пророчили провал (0-5%), на деле успешно сдали в 47% случаев. Те кандидаты, которые по мнению рекрутеров должны были порвать собеседование (95-100%), прошли только в 64%.

Результаты:

🔘Это означает очевидное, что рекрутеры на самом деле не могут предсказать, пройдет ли кандидат или нет. Они оценивают резюме за несколько секунд.

🔘Рекрутеры ищут в резюме упоминания сильных компаний типа MAANG (+35% к успеху) или же представителей меньшинств (+21%).

🔘Если рекрутеры будут тратить 45 секунд на каждое резюме, вместе усредненных 30, то точность исхода вырастет на 34%.

🧬 Подборки WWDC про управление памятью

Сейчас готовлю первый материал по первому ролику и готовлю методичку. Решил пересмотреть все ролики по управлению памятью, которые есть в WWDC и разобрать на конспекты. Делюсь некоторыми с вами:

🟣iOS Memory Deep Dive — один из лучших роликов, где раскрывают почти все о памяти

🟣Profile and optimize your game's memory — как выжимать из дебагера максимум

🟣ARC in Swift: Basics and beyond — как работает ARC и его кишки

Делитесь еще интересными роликами в комментах

🧬Получить доступ к общей подборке обязательных секции WWDC можно по подписке через бусти или по скидке тут

🌿 UIKit: Задачи на hitTest

Почти 3.5 года назад я писал статью про управлению жестами в iOS. Тогда я собрал одни из самых частых вопросов и кейсов по ним.

Жесты до сих пор одна из популярных задач. Они помогают узнать глубину и обширность работы кандидата.

В этой подборке я собрал старые задачи и актуализировал их:
🟣Написать сигнатуру метода hitTest
🟣Как увеличить размеры нажатия
🟣Как вырезать дырку в вьюшке и обрабатывать нажатия задних вьюх
🟣Обработка нажатий выпирающей вьюхи
🟣Обработка hitTest по слоям

🧬Получить доступ можно по подписке через бусти или по скидке тут

💎 Задачи на жесты (UIGestureRecognizer) ч. 1

В прошлой статье мы вспомнили одни из самых популярных задач про hitTets. В этой мы разберем другой механизм управления расширенными жестами.

Забавно, их чуть реже встретишь на собесах чем написания своего hitTest’а, но гораздо чаще на практике.

В подборке вы найдете:
🟣Что такое UIGestureRecognizer
🟣Как он связан с hitTest и Responder Chaing
🟣Какие виды состояний есть у UIGestureRecognizer?
🟣Как перенести вью при зажатии?
🟣Как решать конфликты жестов?
🟣А также еще 10 вопросов и 5 задач

🧬Получить доступ можно по подписке через бусти или по скидке тут

ChatGPT для Swift: Топ 5 подсказок для генерации кода

Для многих чатгпт стал один из главных ассистентов. Кому-то даже заменил гугл и стэк овервлоу. За полтора года хайпа революции не случилось, но появились полезные советы по использованию:

🟣Генерацию моделей под JSON
🟣Написание юнит-тестов и моков
🟣Написание кода под специфичные задачи
🟣Добавление документации
🟣Предложения по улучшению кода

😱 Как дела с увольнениями и что с рынком iOS?

ИТ уже давно переполняется спецами. Поиск работы занимает все больше времени. Например, на западе, чтобы найти работу даже сеньору, нужно сделать около 100 откликов и пройти 30-40 собеседований. А фильтр опыта и нехватка мест для джунов — меньшее из проблем.

Вкратце о треде:
🟣На каждую вакансию около 100 претендентов.
🟣В среднем поиск работы на любую позицию занимает 3-9 месяцев.
🟣Люди расширяют знанию или уходят в другой стэк: flutter, react native
🟣Рынок переполнен низко-качественными спецами, которые усложняют найм всем

Говорят, все что случается на западном рынке, с опозданием приходит к нам. Верим?

👆👇 Подборка статей как свичнуться из iOS в другой стэк

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

Тема горизонтального роста стоит очень остро. Она стоит гораздо чаще, чем в любой другой профессии. Самый популярный свитчинг из любой технической ветки — это в ветку манагера.

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

Для тех, кто задумался, собрал пару интересных статей:

🌄 Переход от iOS-инженера к Backend-инженера. Автор разбирает чем же отличаются или сходятся задачи, языки и мышление кнопкокрасов и джейсонокладов.

🌄 Mobile development vs Machine Learning. Если вы давно смотрите на ML, то автор собрал лучшие карьерные опции для вас. Какие скиллы нужны для той или другой области.

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

🌄 Переход из iOS в Android. Ну а этот тред для предателей и отступников. Кто решил бросить свое братство

Делитесь в комментах своим опытом перехода в другие стэки или наоборот, почему пришли в iOS

💎 Скидка на закрытый контент

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

Что вы можете получить за подписку?
🟣Большая база вопросов для подготовки к собесам, провалидированная экспертами из крупных компаний
🟣Сотня задач на кодинг-алгоритмы с разбором и комментариями
🟣Десяток уникальных статей про кишки и не очень iOS SDK
🟣Задачи на проектирование и систем дизайн: чаты, избранное, DI
🟣Задачи на рефакторинг
🟣Роадмап iOS разработчика
🟣Чат с крутейшими практикующими разрабами, где тебя не будут булить за глупые вопросы
🟣Многое другое

Предложение ограниченное (для старых подписчиков тоже действует скидка)

🚘🚘Подписку можно оформить через бусти или бота

SwiftUI: советы по оптимизации

Нативная разработка — это чаще лучший пользовательский и технический опыт. Приложения на нативе в 9 из 10 случаев смотрятся плавнее и красивее, но все зависит от рук разработчика. Любое приложение можно сделать медленным и забагованным, если у тебя руки рака.

Хорошего инженера от плохо отличает, что хороший хочет делать работу хорошо. И у этой оценки всегда растущие требования. Одно из них — оптимизация.

Мы знаем много советов по оптимизации UIKit, но со SwiftUI все не так очевидно.

Автор статьи собрала десяток советов, которые не всегда были бы очевидные:

🟣Для моделей используйте структуры вместо классов
🟣Избегайте AnyView
🟣Чаще используйте Lazy элементы
🟣Используйте @Stateи @Binding вместо @ObservedObject или @EnvironmentObject
🟣Используйте ForEach с явным id

И многие другие.