Об алгоритмах на собеседовании

У меня, на первый взгляд, противоречивое мнение про алгоритмы. С одной стороны, я долго их решал и даже учавствовал в соревнованиях и шел "365 дней Богу Алгоритмов". С другой, я все также не умею проходить алгоритмические собеседования 😄

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

Но эти секции точно не стоит бояться. Мне нравится, как о них расписал наш руководитель отдела разработки Яндекс Еды Дима Александров @vit_ded

У нас во фронтендах часто не понимают зачем алгосы, а автор не редко сравнивает разные точки зрения и может найти сложные алгоритмы даже в нашей практике!

Действительно ли вы хорошо знаете SwiftUI?

Нашел супер крутую статью, о которой преступно умалчивают другие авторы.
В этой статье автор задает вопрос "А действительно ли вы хорошо знаете SwiftUI?".

Взяв самую популярную демо-задачу с Counter'ом он начинает подсвечивать самые частые заблуждения: начиная от использования незадокументированного _printChanges() заканчивая причинами зависаний экрана.

As you can see by adding .debugBackground() to every Text cell we can observe updating each cell whenever we click on theCounter +1 button. And as you remember we have 100_000 values🤯. That causes lagging! To be more precise — lagging is caused by the List cell creation behavior. Whenever List is created, it has to create all its inside items first because it needs to know how many items are on the screen. By clicking on the button we change the view state, and SwiftUI detects the state change and starts rebuilding the view, and because of the large number of values — this view rebuilds long.

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

Автор круто подчеркивает, что SwiftUI лишь обманчив простотой. Чтобы сделать хороший по перфомансу лайаут нужно приложить много ресурсов и изучить много вещей, которые плохо задокументированы и требуют собрать мозаику знаний. Ну и главное, чтобы это все не сломал Apple со след версией iOS 🙂

Многие советы вам известные, но дают чуть контекста на проблему. Например, тема про POD vs Non-POD чуть лучше расскрывается.

P.S. Говорят, что одна из ключевых черт зрелого инженера — умение выбирать правильные инструменты. Ну и одно из моих любимых правил: Если слишком сложно, то возможно не ты тупой, а плохой дизайн и проектирование инструмента для этих задач. Попробуй взять или придумать другой инструмент.

✅ Вернуть блюрную заливку
⏳ Убрать стекло
⏳ Переименоваться в iOS 19

Swift Concurrency: Cooperative thread pool

Если затрагивать SC, то нельзя не остановиться отдельно на этой теме.

Для чего это придумали? GCD и DispatchQueue.global().async мог создавать на каждую задачу отдельный поток. Это приводит ко многим пролемам оптимизации, но главная — это thread explosion. Это когда создается слишком много потоков одновременно и врызвается жопа ОС.

for _ in 0..<10_000 {
    DispatchQueue.global().async {
        // что-то делает
    }
}

Cooperative Thread Pool — это ключевая часть архитектуры Swift Concurrency. Если простыми словами, то это пул с потоками, которые делят CPU по договорённости. Swift Concurrency использует ограниченный пул потоков — примерно от 4 до 8, в зависимости от устройства и от кол-ва ядер в устройстве. Они уступают управление когда задача "приостанавливается" (await и Suspension points).

Swift runtime использует global concurrent executor. Этот executor основан на libdispatch (GCD), но с отдельной очередью с флагом COOPERATIVE. Это concurrent dispatch queue с названием com.apple.root.default-qos.cooperative. Даже если ты создашь тысячу Task { ... }, они не запустятся параллельно. Они будут ставиться в очередь и по очереди исполняться на тех же 8 потоках.

Чуть позже разберем пару НО и как Swift 6 помогает их избежать.

Полезные ссылки:
- How is the Cooperative Thread Pool integrated in Swift?
- Swift concurrency: Behind the scenes
- How does cooperative thread pool work?
- Limit Swift Concurrency's cooperative pool

2/5

Эстетика сырого текста в эпоху AI

Поговорим о важном культурном сдвиге. Я заметил, что в эпоху, когда ИИ умеет делать красиво, правильно и гладко это тупо перестаёт быть ценностью. Люди начинают искать неидеальность, трушность, эмоцию.

Очередной пересказ статьи, факт из доки, спор про интерпретации — перестали быть интересными. Люди начали искать живой опыт. Грубый, без ретуши и спецэффектов. Домашний, знакомый и понятный.

80% контента стало стерильным. Все утомились от «слишком правильного», которое не отличаешь от сотен других. Сырые же текста и контент стали более живыми.

Даже с играми и фильмами. Мне стали нравятся твердые четверки, кто не идеален. The Alters, expedition 33, tainted grail. Эти игры имеют уйму минусов, багов, но в них есть много плюсов, которые перевешивают. Они пахнут потом и любовью, а не пугающе белыми стенами больниц.

Я стал любить простоту. Ходить в самые обычные места. Есть самую обычную еду. Пить просто воду.

Мы стали будто жить по правилу «слишком идеально, чтобы быть настоящим».

Возможно, скоро неотредактированный текст станет новым жанром. Как raw photo в инсте или живой звук в музыке.

Люди захотят читать не идеальные тексты, а тексты с дыханием.

Систем дизайн в деле

Есть огромное минное поле заблуждений по систем дизайну. От "это про нарисовать схему из интернета" до "это про знание паттернов проектирование и архитектур". От "бэкенд систем дизайн отличается от мобильного" до "весь систем дизайн можно зазубрить".

Грамотное проектирование — это впервую очередь диалог. Он не должен быть по шаблону и идет оценка условий. Их нужно менять. Как с ремонтом. Вот вроде решил поменять пол и стены, а вышло тысяча нюансов и мелочей.

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

Нашел полезное видео, которое пусть и для бэкенда, но очень крутое.

Туториал по Container

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

Мы уже разбирали в чем разница software developer vs software engineer. А также подробно проходили по виртуализации.

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

Когда это поможет:
- Ускоряет и упрощает CI/CD-процессы для ios‑разрабов. например, сразу fastlane, swiflint и тп с другими версиями
- изолировать версии в разных окружениях
- тестировать пуши, авторизацию, базы данных с быстрым запуском нужных сервисов.
- настраивать ручные и автотесты за счет мок-сервисов
- проще подготавливать окружение для новичков
- если баги воспроизводятся только на конкретной версии окружения, то ты можешь легко ее собрать
- запуск новых либ или сдк в "чистом" окружении

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

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

«Концентрированность опыта важнее количества лет и суммы в оффере»
или
«Где вырастает настоящий сеньор? В деньгах или в деле?»

⸻

💡 Ключевые идеи, которые можно раскрыть:

1. Концентрированность опыта vs Количество лет
• Пример: у двух людей по 5 лет опыта. Один — писал UI-фичи и фиксил баги, другой — запускал 3 проекта с нуля, внедрял CI/CD, строил архитектуру.
• 👉 Первый “набрал время”, второй — сжал опыт в концентрат.
• Формулировка: “Опыт – это не часы, проведённые в коде. Это задачи, которые требовали от тебя расти.”

⸻

2. Цена опыта и окупаемость
• Вставь понятие «опыт как инвестиция»:
• Проект без вызовов = “депозит под 2%” (низкий рост).
• Проект с болью, сложностями и ростом = “венчур” — сначала тяжело, потом x3.

Метафора: «Ты не на зарплату работаешь, а на апгрейд себя.»

⸻

3. Короткие фичи vs Большие системы
• Проекты на 1 спринт не дадут тебе знания работы с техническим долгом, масштабированием, поддержкой, интеграциями.
• Проекты на кварталы формируют скиллы, которые не прочитать в туториале.

👉 Задай вопрос читателю: «Вы когда-нибудь доживали до последствий собственных решений через 6–12 месяцев?»

⸻

4. Что такое “бесперспективный оффер”
• Деньги — не всегда сигнал “ты хорош”.
• Иногда это компенсация за рутину, токсичность, отсутствие роста, или необходимость “заткнуть дыру”.
• Идея: “Не каждая высокая зарплата — это признание. Иногда — это капкан.”

⸻

5. Продажа себя дороже
• Опиши идею: если сейчас ты работаешь на то, чтобы через год стоить дороже — ты на правильном пути.
• Пример: ты изучаешь GraphQL, учишь DevOps-практики, внедряешь архитектурные подходы — всё это капитал.

⸻

6. Роль ментальности и амбиций
• Некоторые “работают в IT”, а другие — “строят карьеру в инженерии”.
• Покажи разницу: первые просто кодят задачи, вторые — растут стратегически.

⸻

🧩 Завершающая мысль

Можно закончить вот так:

“Концентрированность опыта — это когда ты идёшь не по количеству строк кода, а по качеству вызовов, которые ты принял. Не каждый год делает тебя сильнее. Но каждый проект может — если ты выбрал его осознанно.”

Кстати, завтра будет репортаж корпоратива Яндекса из БАНИ

Неоспоримая база от любимого автора

Наш любимый блогер, а также автор лучшей книги 2024 года для инженеров, дал инфу о базе базовой.

1. Чем больше кода, тем больше багов. Чем больше приложение, тем сложнее делать его качественно.
2. Код - это для людей. Писать код сложнее там, где его читают. Чем больше разрабов в проекте, тем важнее его читабельность и понятность.
3. Архитектура - это про удобство. Чем сложнее, тем хуже.

Даже во времена AI эти правила не меняются

Каждый раз когда кто-то проходит испыталку Яндекс делает корпоратив

Кстати, я прошел испыталку. Работаем дальше

Гонка за концентрированностью опыта

У одного тимлида в блоге я увидел пост в стиле

"не нанимайте звезд, берите тех, кто не хочет х2 зп и не ищет челенджи, не выступает на конфах и не придумывает новые архитектуры. Инженера, кто не хочет расти и молча делает свою работу на одном грейде без амбиций роста — сложнее найти"

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

Почему я думаю что в ит такой путь развития не выгоден? Давайте по пунктам:
1. Знания быстро устаревают, и ценность на рынке падает. Вот я пишу про SUI и Async/Await сейчас не просто так, а потому что людей, кто решает задачи на собесах с помощью GCD разворачивают по причине "знает слишком архаитчный стэк". Ценят не твой опыт на пет-проектах, а реальный и боевой. Особенно, если он помог твоему продукту принести бизнес ауткамы и выгоду.

2. Пересмотр зарплаты. Окей, возможно ты не хочешь уходить. Тогда может быть рост зарплаты внутри компании быстрее чем инфляция на рынке? Сомневаюсь. Даже если тебе сейчас комфортно текущий менеджер с текущей политикой может уйти через 2-3 года и придет более голодный и амбициозный менеджер, который может посчитать что вы "слишком тихие".

Я понимаю, почему такие сотрудники удобны менеджерам: они стабильны, не спорят, не увольняются. Но с точки зрения самого инженера это путь к невидимости. В IT растет тот, кто проявляет инициативу: пробует новое, предлагает решения, прокачивает навыки. Без этого легко застрять на одном уровне, пока мир идёт вперёд. Рынок любит тех, кто развивает глубину или ширину но не тех, кто стоит на месте.

Что я хочу сказать?

Расти не нужно всем. Это нормально, что мы этого не хотим. Но:
1. Если ты инженер, то ты должен понимать все риски
2. А если ты менеджер, то должен понимать риски, когда даешь людям советы "сидеть тихо, не рисковать, не проявлять инициативу и не выделяться". Ведь спустя пару лет твои подчиненные не смогут найти работу, когда ты скорее всего найдешь себе новую.

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

Это Win-Win стратегия

Ставь лайк если жиза