ANDROID SCHOOL.RU - Android на практике

Как быть Android-разработчику в эпоху перемен?

Спасибо всем, кто принял участие в опросе про сокращения. Почти половина ответивших столкнулась с сокращениями в компании. Причём 24% лично. Ещё 36% говорят, что сокращений нет, но найм заморожен. Только 15% сообщили, что у них есть вакансии. Тут повод задуматься о своей устойчивости в эпоху перемен.

Что я бы рекомендовал Android-разработчику 👇

1. Подушка безопасности

Хорошо, когда вы можете спокойно потратить 1–3 месяца на поиск работы: выбирать команду, отказываться от неподходящих условий, обсуждать деньги. Кстати я заметил, что вилки у компаний сильно упали, то, что казалось зарплатой мидла - в этом году спокойно является верхом вилки для Senior-специалиста. Поэтому поиск офера с хорошими условиями может занимать время. При этом лучше иметь максимум подготовки чтобы можно было поторговаться, переходим к следуюущему пункту.

2. К собеседованиям нужно готовиться отдельно

Сильный разработчик и человек, который хорошо проходит интервью, — пересекающиеся, но разные наборы навыков.

Если раньше получалось зайти «на авось» и получить оффер, сейчас я бы на такую стратегию не рассчитывал. При небольшом количестве вакансий и высокой конкуренции у компаний больше возможностей выбирать.

Для Senior-позиций в подготовку я бы обязательно включил:

— System Design: уточнять требования, обсуждать ограничения, объяснять архитектуру и компромиссы.
— Live coding: писать работающий код, проговаривать решения, проверять граничные случаи.
— Мок-интервью: получать обратную связь до настоящего собеседования.

Если нужен взгляд со стороны, то вы знаете, к кому обращаться 🙂 Записывайтесь ко мне на мок или менторство: найдём пробелы и составим план подготовки.

3. Расширяйте зону ответственности и осваивайте ИИ

Полезно уметь не только реализовать экран, но и разобраться, какую задачу бизнеса он решает, что происходит на backend, как измерить результат и поддерживать решение в проде. То же самое с ИИ. Попробуйте встроить его в реальные задачи: исследование незнакомого кода, подготовку тестов, ревью, прототипирование.

4. Используйте работу как площадку для обучения

Можно взять небольшую backend-задачу на Kotlin, поучаствовать в проектировании API или внедрить ИИ в процесс команды. Кстати, подготовка к System Design здесь тоже помогает: начинаешь лучше понимать систему целиком - от мобильного клиента до очередей, баз данных и отказов сервисов.

5. Начните свой проект

В своём проекте можно и backend написать, и ИИ попробовать, и разобраться с аналитикой, платежами и привлечением пользователей.

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

Не нужно делать всё сразу. Начните с самого слабого места: финансового запаса, подготовки к интервью или навыка, который давно хотели применить.

А что сейчас делаете вы, чтобы чувствовать себя увереннее?

​​Как ChatGPT украл у начинающих разработчиков самое важное.

Вчера был День программиста, и я неожиданно поймал себя на мысли: я программирую уже больше 20 лет.

🦖 Как и многие школьники, я тогда увлекался динозаврами. И в какой-то момент решил: а почему бы не сделать про них свой сайт? Так появился мой первый проект - сайт о динозаврах на легендарном крупнейшем бесплатном хостинге рунета narod.ru. Я тут же его монетизировал, встроив рекламу, правда забыл пароль от рекламного кабинета, сейчас там наверное неплохая сумма накопилась. Самое забавное, что его до сих пор можно найти в интернете.

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

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

И вот что особенно интересно вспоминать сейчас. Не было ChatGPT. Не было Stack Overflow в привычном нам виде. Не было бесконечного количества бесплатных курсов и туториалов.

Если ты чего-то не знал — шёл на форум и искал похожую проблему, потом читал десятки сообщений. Пробовал один вариант - он не работает. Второй. Опять не работает. Сидишь вечером перед компьютером и пытаешься понять, почему эта штука вообще не работает. Но именно поэтому каждый маленький результат приносил невероятное удовольствие. Когда после нескольких часов или даже дней попыток что-то наконец заработало - это было почти магией.

Книги по программированию тоже были далеко не так доступны. Хорошую книгу ещё нужно было найти, а стоить она могла для школьника каких-то совершенно безумных денег. Я черпал вдохновение в журналах Игромании, тогда они стоили около 100 рублей, что было довольно дорого для журнала. Зато сколько контента было на дисках которых прилагались к журналу. Демки, утилиты, примеры из туториалов, музыка из игр...

Прошло больше 20 лет.

Я всё ещё занимаюсь разработкой. Только вместо Flash и сайтов — мобильные приложения, распределённые системы, System Design, AI и совсем другой масштаб задач.

И мне кажется, сейчас одно из самых интересных времён за всю историю IT.

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

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

Потому что раньше между идеей простенькой программы и результатом было несколько бессонных ночей и огромное количество ошибок. А сегодня между ними всё чаще помещается один промпт в ChatGPT.

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

Иногда полезно не спрашивать сразу готовое решение. Покопаться самому. Попробовать несколько вариантов.
Разобраться, почему сломалось. И почувствовать то самое удовольствие, когда наконец заработало.

Поэтому с прошедшим Днём программиста всех, кто пишет код ❤️

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

На скришоте мой первый сайт, зацените) Это раздел галереи, справа было меню с подразделами, а слева основной контент.

Как научиться решать задачи на Leetcode

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

Недавно рассказывал, как получил оффер от Яндекса. Одним из этапов был live coding с алгоритмическими задачами.

А сегодня решил показать свою статистику на LeetCode: всего решил примерно 100 задач: 61 easy, 33 medium. Кому-то наверное нужно больше, кому-то меньше, но думаю что этого количество должно хватить.

Как я готовился и чтобы посоветовал тем, кто готовится.

1. Разбирайте задачи по паттернам.
Два указателя, скользящее окно, HashMap, бинарный поиск, обход деревьев. Решите несколько задач на один подход, чтобы понять, что у них общего. Так проще увидеть знакомую идею в новом условии.

2. Не превращайте одну задачу в испытание на весь вечер.
Если за 25–30 минут совсем нет продвижения, возьмите подсказку. Если не помогла — разберите решение. Потом закройте его и напишите самостоятельно. Прочитать понятный разбор и самостоятельно воспроизвести решение — разные уровни понимания.

3. Возвращайтесь к уже решённому.
Повторите задачу через несколько дней без подсказок. Именно здесь становится понятно, разобрался ты или просто запомнил, как выглядел код.

4. Тренируйтесь объяснять вслух.
На live coding нужно показать ход мысли: что уточняю, какое простое решение вижу, где оно тормозит и как его улучшить. Полезно иногда решать так, будто интервьюер уже рядом.

Для меня в этом есть ещё один плюс: когда пишешь самостоятельно, глубже разбираешься в Kotlin и вспоминаешь детали, которые в повседневной работе легко упустить. Где создаётся копия коллекции? Что происходит при изменении исходного списка? Не спрятались ли за удобной операцией дополнительные проблемы по перформансу?

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

5. И самое главное — продумывайте краевые случаи до написания кода.
Что будет с пустым массивом? С одним элементом? С дубликатами? Не случится ли переполнение?

Для меня это один из самых полезных навыков, который можно перенести с LeetCode в реальный продакшн. Там вопросы другие: что, если ответ пустой, запрос пришёл повторно, сеть пропала посередине операции, а события пришли в неожиданном порядке?

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

Поэтому я бы не ставил себе цель «решить 500 задач». Мне ближе другая идея: научиться быстро разбираться в условии, выбрать подход, объяснить решение и проверить, что оно работает за пределами happy path.

А у вас что сложнее на LeetCode: придумать решение или написать его без багов?

🎓 1 сентября - хороший повод снова чему-то поучиться. Особенно если осенью планируете ходить по собеседованиям.

Недавно я сам прошёл полный цикл собеседований в Яндекс и получил оффер.

В процессе были HR-интервью, live coding, System Design и behavioural-интервью. В итоге этот опыт я тоже переиспользовал в своём курсе Mobile System Design Interview: добавил наблюдения, вопросы и подходы, которые действительно встречаются на собеседованиях.

За это время в курсе появилось еще несколько тем и разборы реальных кейсов, множество положительных отзывов, а рейтинг от тех кто прошел курс 5.0. Потому что это не набор абстрактных архитектурных паттернов, а концентрат того, что действительно нужно уметь делать на System Design интервью:

- правильно собирать требования;
- проектировать мобильную архитектуру;
- продумывать API, кеширование, offline-first и синхронизацию;

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

В честь 1 сентября всем подписчикам дарю промокод.

🎁 Промокод: ДЕНЬЗНАНИЙ на скидку 15% до конца недели.

Если давно откладывали подготовку к System Design — кажется, это хороший повод начать.

👉 Подготовиться к Mobile System Design со скидкой

​​Получил оффер в Яндекс и ... отказался.

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

Я довольно много готовлю разработчиков к собеседованиям в BigTech: разбираю алгоритмы, System Design, архитектуру, помогаю с подготовкой к техническим интервью. Поэтому конечно необходимо и самому периодически выходить на рынок, чтобы понимать текущие тренды и реалии.

Заодно хотелось немного побороть синдром самозванца и получить независимую оценку своего текущего уровня.

Как проходило собеседование

1. HR-интервью
Знакомство, обсуждение опыта, мотивации, ожиданий и возможных команд.

2. Техническое собеседование по Kotlin и Android SDK.
Тут были задачки на знание особенностей языка и некоторых структур данных, корутины, а также специфичные вопросы по Android SDK. Была небольшая задачка приближенная к реальной задаче.

3. Live Coding
Алгоритмические задачи примерно в духе LeetCode. Чтобы подготовиться я решил примерно около 100-150 задач на Leetcode уровня Easy и Medium. В целом, мне кажется этого достаточно. Главное понять паттерны решения.

4. System Design
Нужно структурировать достаточно размытые требования, определить ограничения, предложить архитектуру и обсуждать компромиссы.

5. Фит в команду.
У меня было несколько команд с которыми я общался. То есть 2-3 интервью с командой. Для меня это был самый изматывающий этап. Ты выбираешь проект и команду, а команда оценивает насколько твой опыт и вайб подходят. Обсуждение реальных ситуаций из прошлого опыта: сложные решения, конфликты, ошибки, лидерство.

В итоге все этапы прошёл и получил оффер.Но принимать его не стал. Хотя жалко было времени и хотелось как-то отбить потраченные усилия.

Почему?
Когда я рассматриваю новую работу, обычно смотрю на сочетание трёх вещей:

Проект - насколько мне интересны задачи и есть ли там пространство для профессионального роста

Условия - компенсация, формат работы, удалёнка/офис, другие бенефиты

Бренд компании - насколько эта строчка усиливает резюме и открывает следующие карьерные возможности.

В идеале должны совпасть хотя бы два пункта из трёх.

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

Но по остальным параметрам предложение оказалось менее привлекательным.

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

При обсуждении оффера заметный акцент делался на потенциальные премии. Но потенциальная премия и гарантированная компенсация — всё-таки разные вещи. Особенно в текущей экономической ситуации

Сам проект тоже не оказался настолько интересным, чтобы ради него хотелось существенно поступиться другими условиями.

Поэтому в этот раз решил отказаться.

При этом сам процесс точно считаю полезным. Отдельный респект HR. Общение было комфортным и все этапы описаны.

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

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

И наконец, ещё раз убедился в простой вещи:

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

Собеседование — это проверка соответствия в обе стороны.

Компания оценивает тебя, но и ты точно так же оцениваешь компанию.

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

Куда расти мобильному инженеру: 10 направлений

В какой-то момент мобильная разработка перестает быть только про новые экраны, архитектуру фич и знание Android SDK. Если ты уже Senior-разработчик, возникает вопрос: а что изучать дальше, чтобы расти как инженер?

Недавно прочитал статью Jacob Bartlett про самые сложные проблемы в mobile engineering. И мне понравилась идея посмотреть на них с другой стороны: каждая такая проблема — потенциальная зона профессионального роста.

Вот 10 направлений, в которые можно углубляться.

1. Архитектура больших приложений

Не MVVM vs MVI, а архитектура системы целиком. Как разделить приложение на десятки модулей? Как построить dependency graph? Как определить границы между командами и фичами? На масштабе архитектура начинает влиять не только на качество кода, но и на скорость разработки всей команды.

→ Modularization, dependency management, API boundaries

2. Release Engineering

Написать код — половина задачи. Нужно еще безопасно доставить его миллионам пользователей. В отличие от backend, мобильное приложение нельзя просто передеплоить за пять минут.

→ CI/CD, staged rollout, feature flags, backward compatibility, release automation

3. Offline-first и синхронизация данных

Стоит приложению начать нормально работать без сети — и mobile engineering внезапно превращается в distributed systems.
Что делать с изменениями на нескольких устройствах? Как разрешать конфликты? Как повторять запросы? Что делать после убийства процесса?

→ Sync Engine, queues, retries, conflict resolution, idempotency, local-first architecture.

4. Работа с ограничениями OS

Мы не контролируем среду выполнения. Android/iOS могут убить процесс, ограничить background execution.
→ Lifecycle, WorkManager, process death.

5. Performance Engineering

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

→ Startup Time, ANR, memory, GC, rendering, battery, profiling.

6. Permissions & Privacy

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

→ Permissions, graceful degradation, security.

7. Multiplatform

Идея shared code выглядит просто только на презентациях. На практике появляются вопросы: что именно шарить? Где проходят platform boundaries?

→ KMP, shared business logic, cross-platform architecture.

8. Build Systems

Когда приложение большое, сборка сама становится продуктом. Gradle, dependency graph, code generation, caching и CI начинают напрямую влиять на productivity десятков разработчиков.

→ Gradle, build optimization, convention plugins, remote cache, CI infrastructure.

9. Работа с другими устройствами

Телефон всё чаще становится лишь одним узлом системы.
Наушники, часы, автомобили, BLE-устройства, TV — и обычное мобильное приложение начинает напоминать распределенную систему.

→ Bluetooth/BLE, Wear OS/watchOS, Android Auto/CarPlay, device synchronization.

10. Distribution & Product Engineering

Можно сделать технически идеальное приложение, которое никто не установит. Поэтому сильному инженеру полезно понимать не только код, а Analytics, A/B testing, ASO, activation, retention, monetization.

Мне кажется, это хороший способ посмотреть на карьеру после Senior. Не обязательно становиться менеджером и не обязательно бесконечно изучать новые UI-фреймворки. Можно выбрать 2–3 направления из списка и стать человеком, который умеет решать сложные системные проблемы мобильных продуктов.

И именно здесь, на мой взгляд, проходит переход и рост грейда. Чем выше уровень инженера, тем чаще вопрос звучит так:
«Как построить систему, в которой десятки инженеров смогут безопасно и быстро развивать сотни таких фич?» Вместо того, какой фреймворк выбрать. Последнее, кстати очень часто спрашивают на собеседованиях. И тут грамотный ответ - не какой то набор популярных технологий, а вдумчивый анализ что именно мы делаем и на какой масштаб, и только потом выбираем технологию или архитектуру.

7 собеседований и оффер выше рынка в Германии. Что помогло пройти самый сложный этап?

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

Процесс оказался совсем не простым.
Всего было 7 интервью, объединённых в четыре этапа:

• HR Screen
• Hiring Manager
• Technical Interview
• Финальный этап сразу из четырёх интервью:
— Behavioral
— Behavioral
— Mobile System Design
— AI Interview (про это расскажу отдельно)

Именно System Design вызывал у него больше всего вопросов.
Не потому что не хватало Android-знаний. А потому что формат Mobile System Design — это совсем другой уровень. Здесь оценивают не знание API Android, а умение проектировать систему целиком и объяснять архитектурные решения.

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

Во время обсуждения разбирали вопросы, которые редко встречаются в обычных Android-интервью:

• как отображать десятки тысяч объектов на карте;
• когда использовать кластеризацию и какие у неё есть компромиссы;
• как работать с офлайн-картами;
• как уменьшить объём передаваемых данных;

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

Параллельно кандидат проходил мой курс по Mobile System Design, чтобы закрыть теорию: как структурировать интервью, обсуждать trade-offs, проектировать API, базы данных, offline-first архитектуру и объяснять свои решения.
Спустя некоторое время получил такое сообщение:

«Мне дали оффер 🙂
Спасибо большое за курс и за мок-собеседование. Думаю, что это повлияло на получение оффера.»

А чуть позже — полноценный отзыв:

Я проходил интервью в одну компанию, и одним из этапов был Mobile System Design интервью. В таком формате собеседований у меня не было большого опыта, поэтому я хотел, чтобы мне кто-нибудь провел мок-собеседование, на котором я бы мог потренироваться перед реальным интервью. Я нашел Михаила на GetMentor и связался с ним. Он написал мне довольно быстро, и мы договорились о встрече на следующей неделе. Также Михаил заранее поделился полезными ссылками на материалы для изучения в качестве подготовки к собеседованию.

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

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

По итогу собеседование прошло успешно, и я получил оффер! Я очень благодарен Михаилу за помощь в подготовке и считаю, что его вклад сыграл важную роль в получении оффера!

Такие истории особенно радуют. Я убеждён, что хороший mock — это не набор случайных вопросов.
Это возможность заранее оказаться в условиях, максимально близких к тем, что будут ждать кандидата через неделю.

Если вы готовитесь к Senior или Lead интервью, особенно если впереди есть этап Mobile System Design, то рекомендую адаптированный под мобильную разработку авторский курс на Stepik. В связке с мок-собеседованием гарантированный результат 😉

Как работать с изображениями эффективно.

На этой неделе занимались с командой избыточным потреблением памяти bitmap'ами.

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

Что сделали:

• пересмотрели логику выбора размеров изображений при загрузке;
• добавили допуск при подборе размера ресурса, чтобы избежать загрузки более тяжелых вариантов без реального выигрыша в качестве;
• для ряда кейсов начали явно ограничивать размер bitmap'ов в памяти через override;
• изменили fallback-логику: если размер View неизвестен, больше не загружаем максимально крупный вариант изображения;
• оптимизировали декодирование некоторых часто используемых обложек и баннеров.

Результат после полного прохода по основным экранам приложения:

📉 Потребление памяти на отдельных экранах уменьшилось на -34,6%
📉 Размер отдельных bitmap'ов получилось значительно уменьшить: 7 МБ → 0,8 МБ (-89%)

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

Для понимания масштаба проблемы:

Bitmap 1000×1000 в ARGB_8888 ≈ 4 МБ памяти.
Bitmap 600×600 ≈ 1.4 МБ.
Bitmap 300×300 ≈ 0.34 МБ.
Разница между xlarge и small может составлять более 10 раз по памяти на одном изображении.

Во многих проектах Glide/Coil уже используются, но это не гарантирует эффективного потребления памяти. Если приложение активно работает с изображениями, рекомендую периодически проверять:

— какие Bitmap занимают память;
— какого они размера;
— соответствуют ли размеры bitmap реальному размеру View;
— правильно ли работает ваша стратегия image loading.

Полезные материалы по теме:

🔹 Android Developers — Loading Large Bitmaps Efficiently
https://developer.android.com/topic/performance/graphics/load-bitmap

🔹 Android Developers — Managing Bitmap Memory
https://developer.android.com/topic/performance/graphics/manage-memory

🔹 Android Developers — Optimizing Bitmap Images
https://developer.android.com/develop/ui/compose/graphics/images/optimization

Запись моего доклада на тему Mobile System Design c конференции Стачки 2026

Организаторы поделились записью моего доклада, а я делюсь с вами.

В докладе на основе своего опыта рассказал:

— как именно мобильному разработчику подходить к System Design
— на какие аспекты обращают внимание интервьюеры
— типичные ошибки, которые могут стоить оффера
— реальный кейс из Big Tech (разберём вместе)

Будет актуально всем разработчикам, ставьте лайки, подписывайтесь на канал
https://www.youtube.com/watch?v=xeNIDQcw_Eg&t=115s

​На прошедших выходных в Ульяновске прошла юбилейная 15-я «Стачка». Для меня это уже 3-й раз когда я выступаю в роли спикера и в этом году на конференции увидел три ключевых тренда: усиление роли ИИ, рост интереса к System Design и размывание границ между ролями разработчиков. Интересный факт - в программе было заявлено сразу 2 доклада про System Design, один мой, а второй про проектирование систем для аналитиков. Это еще раз подтверждает интерес к этой теме среди аудитории.

📌Поделюсь самыми интересными идеями и докладами, которые удалось посетить после выступления:

Рост: от тимлида к руководителю руководителей. Любой рост - это расширение зоны ответственности, но как ее расширять? На этом докладе обсуждали различные аспекты роста. Ключевые из них это: коммуникации, личный бренд внутри компании, возможность наладить отношения уже между отделами а не просто с разработчиками. Рост - это не про увеличение количества задач, а про смену уровня ответственности и коммуникаций.

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

Путь инди-хакера или как заработать на своем пет проекте.

Отдельно зацепил доклад про пет-проекты и инди-разработку (тема мне близка — в прошлом году я сам выступал с похожим докладом). Сейчас, с учетом ИИ, все больше будет инди-разработчиков, потому что код стало писать проще и можно действительно сконцентрироваться на идее, а остальное поручить агентам. В этом докладе были рассмотрены логичные этапы любого проекта: идея, онбординг, способы монетизации и маркетинг. Далее автор поделился своими проектами, более-менее выстрелил один проект из 10 предыдущих. Вывод тут простые: не полировать проект до идеала, как можно быстрее тестировать гипотезу на рынке и слушать своих пользователей.

Работа мобильного приложения с экзоскелетом.

Ну и 3-ий доклад был про разработку мобильного приложения для медицинских экзоскелетов. Там не было описания какой-то сложной архитектуры или крутых оптимизаций в коде, но мне понравился доклад потому что тема находится на стыке разработки и реального мира/робототехники. И самое главное эти экзоскелеты реально помогают людям. Иногда мы закапываемся в архитектуру и оптимизации и забываем, зачем вообще всё это делаем. Мне кажется это отличная таблетка от выгорания - понимание что твоя работа помогает людям жить лучше.

Что изменилось: ключевые тренды. Который год замечаю, что докладов про мобильную разработку стало меньше. Очень много было про ИИ, а мобильная разработка уже давно сформировалась. Под любую задачу есть решение, читай документацию и делай. Поэтому все больше разработчиков комбинируют подходы начиная от BDUI и заканчивая AI агентами и автоматизациями.Быть просто Android-разработчиком уже недостаточно. Нужно иметь продуктовое мышление и уметь проектировать системы целиком, чтобы поручить ИИ реализацию рутины.

🙌 Стачка остаётся одной из самых «ламповых» конференций. Это сложно формализовать, но разница со столичными событиями ощущается сразу: здесь больше живого общения, открытости и желания делиться опытом. Именно за этим хочется возвращаться.

10 апреля уже в 3-ий раз выступлю на конференции Стачка в Ульяновске. Буду рассказывать как раз про System Design для мобильных разработчиков в формате воркшопа, тема оказалась довольно интересной и сразу несколько конференций одобрили мою заявку, пришлось выбирать.

В докладе разберём:

— как именно мобильному разработчику подходить к System Design
— на какие аспекты обращают внимание интервьюеры
— типичные ошибки, которые могут стоить оффера
— реальный кейс из Big Tech (разберём вместе)

Вообще весна оказалась довольно насыщенной, только я закончил основной материал по курсу, и тут же принялся за подготовку доклада.
Хочется уже включить режим:"Давайте уже после майских 😁".

Если кто-то будет на конференции буду рад увидеться и пообщаться после выступления 🙌
https://ul.nastachku.ru/lp/ul26/speeches/osobennosti-prokhozhdeniya-system-design-interview-dlya-mobilnogo-razrabotchika-1

Mobile System Design за 5 минут

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

Именно на этой секции валятся ребята, которые по хардам отвечают на 9 из 10. Человек знает, как устроены корутины, работает GC, а потом начинается System Design и все.

Поэтому я собрал краткую шпаргалку, если собес поставили уже на завтра:

1) Сбор требований (10-15 мин)
Самая частая ошибка. Человек понял по-своему задачу и сразу начал рисовать диаграмму.

Сначала необходимо продумать требования, как будто разговариваешь с продуктом или тимлидом

Функциональные требования отвечают на вопрос: «что пользователь может сделать?» - выбери ТОП-3, не больше. Длинный список - минус, не плюс. Интервьюер оценивает умение приоритизировать

Нефункциональные: доступность, масштаб, локализация

2) Проектирование API и модели данных (10-15 мин)
Проектируем ленту постов? User, Post, UserReaction. Тут же можно продумать какой типа пагинации будет использоваться (да их несколько). Не забываем про идемпотентность

GET /v1/posts/:id -> Post
GET /v1/feed -> Post[]

3) Высокоуровневая архитектура (10-15 мин)
Вот тут основная работа. Архитектура клиента (Clean, MVI, MVVM, repository) API, рисуем сервисы, БД, показываем offline-first - подход, CDN, Message Queue, LRU-кэш

4) Углубление в реализацию (10 мин)
А вот тут ты показываешь глубину:

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


📹 Видеокурс для закрепления с примерами и упражнениями

Если ты планируешь менять работу или идти на повышение в ближайшие месяцы - сейчас лучшее время подготовиться.
P.s. Используйте только эту ссылку, иначе Stepik берет конскую (почти половину) комиссию
https://stepik.org/a/262641

ANDROID SCHOOL.RU - Android на практике pinned «Как не упустить выгодный оффер в 2026 году? Многие разработчики отлично пишут код, но сыпятся, когда на собеседовании просят спроектировать архитектуру приложения и теряют офферы уровня Middle+ и Senior в BigTech. Я запустил первый в Рунете курс по Mobile…»

Как не упустить выгодный оффер в 2026 году? Многие разработчики отлично пишут код, но сыпятся, когда на собеседовании просят спроектировать архитектуру приложения и теряют офферы уровня Middle+ и Senior в BigTech.

Я запустил первый в Рунете курс по Mobile System Design, который полностью посвящён подготовке к System Design именно для мобильных разработчиков.

В прошлом году я провёл несколько интенсивов, собрал реальные кейсы с собеседований и доработал материал. Теперь курс доступен в записи на Stepik - можно проходить в удобном темпе.

Внутри:

• 4 часа концентрированного контента - как структурно отвечать на System Design вопросы
• практические кейсы из реальных собеседований
• около 80 тестов для закрепления материала

В курсе разбираются реальные вопросы из мобильного System Design интервью:

• как спроектировать offline-first архитектуру
• как работает синхронизация данных
• чем отличается offset пагинация от cursor-based
• как решать конфликты данных

По мере добавления новых материалов стоимость будет расти, но все будущие обновления будут бесплатны для тех, кто купит курс сейчас.

Если ты планируешь менять работу или идти на повышение в ближайшие месяцы - сейчас лучшее время подготовиться https://stepik.org/a/262641

Менти получил офер в Revolut на €95 000.

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

Мы быстро определили план подготовки. Основной фокус сделали на двух вещах:

— System Design и архитектура высоконагруженных систем
— безопасность мобильных приложений (HTTPS, SSL pinning, MITM)

Провели несколько Mock System Design интервью. Я подготовил кейс с учетом специфики финтех-приложений: как проектировать систему, где учитывать безопасность, какие узкие места появляются при росте нагрузки.
На интервью такие вещи часто решают исход — кандидата смотрят не только на код, но и на то, как он думает об архитектуре системы.

В процессе разбирали:
— как структурировать System Design интервью
— какие trade-offs обсуждать
— где обычно кандидаты допускают ошибки

Через несколько недель менти написал:
«Получил офер. Спасибо за подготовку».

Полный отзыв:
Хочу сказать огромное спасибо Михаилу.
Мне нужно было срочно потренироваться в прохождении интервью по системному дизайну под android так как реальное интервью было у меня уже на следующий день.
Михаил оперативно откликнулся, задание было скорректированно под мои нужны, кроме опыта получил тонну полезной информации по финтех специфике что в том числе и помогло мне и пройти дизайн собес и в результате получить офер в "револют" приподняв сумму офера в процессе.

Оффер — €95 000 и релокация в Европу.
По моим ощущениям, рынок сейчас постепенно оживает. Компании снова активнее нанимают, но System Design интервью по-прежнему остаются одним из самых сложных этапов.
Если готовитесь к интервью в продуктовые компании — могу помочь разобрать ваш кейс и помочь подготовиться.

ИТ-Рынок в Европе be like. Вот вам и валютные удаленки 😁

​​Офис Alibaba и график работы 9-9-6.
Спустя пару дней после финального этапа мне прислали офер!

Честно — в тот момент я уже был морально готов к отказу. System Design был непростой, вопросы копали глубже, чем я ожидал. Но именно это, как оказалось, и сыграло в плюс — интервьюеры видели не заученные ответы, а ход мыслей.

А дальше началось самое интересное.
Через некоторое время я узнаю, что мобильная команда летит работать в штаб-квартиру Alibaba в Ханчжоу. Для меня это был первый настолько масштабный международный опыт. Когда я впервые приехал в кампус Alibaba в Ханчжоу 🇨🇳, ожидал увидеть что-то в духе «кремниевой долины» — футуристичный кампус, глянцевые офисы, сплошные лаунж-зоны.

Реальность оказалась другой.
Офис был довольно аскетичным. Никакого избыточного пафоса. Всё очень функционально и по-деловому. Минимум отвлекающих факторов — максимум фокуса на продукте.
Все работают в openspace, есть отдельные переговорки и маркерные доски рядом со столами для обсуждений. Не скажу, что было просторно, но, по крайней мере у разработчиков, довольно тихо и спокойно, в отличие от тех. поддержки.

Что меня больше всего впечатлило, после обеда китайцы любят вздремнуть, у многих есть подушки, маски, видел даже отдельно стоящие раскладушки. Но это и не удивительно. Начинают работать обычно все с 9 утра, и задерживаются до 9. Там, я впервые узнал про 996 - график работы, популярный в китайских технологических компаниях, это не миф, многие действительно так работают. У нас как раз был такой негласный график работы, потому что проект был срочный, необходимо было реализовать огромную часть функционала и перевести на новый стек технологий.

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

Ну и пару слов про еду. Думаю, кто хоть раз бывал в Азии, согласится, что азиатская еда на любителя. Все очень острое и жирное. Европейская еда есть - но она в 2-3 раза дороже. Столовые в кампусе довольно простые, но и еда на наши деньги стоила рублей 100-200 максимум. Больше всего мне нравились фреши из фруктов за 60 рублей. Кроме столовой на территории кампуса есть и кафе по типу Starbucks или Costa Coffe, но там кроме десертов и кофе больше ничего не было, поэтому все равно приходилось привыкать к традиционной китайской еде.

Почтовое отделение. Из необычного на территории кампуса есть почтовое отделение, без него я бы с очень большим трудом покупал бы в интернете. Приходишь, прикладываешь пропуск, тебе выносят посылку. Довольно удобно было заказывать всякие ништяки из Китая.

В следующем посте расскажу почему я всё-таки решил не строить карьеру в Китае. Если интересно — поставьте реакцию или напишите, задумывались ли вы о работе за границей. Будет любопытно обсудить ваш опыт.

​​Офис Alibaba и собеседование в Lazada

По реакциям на прошлый пост (спасибо всем, кто отметился 🙌) вижу, что тема собеседований и опыта работы в Китае действительно откликается, поэтому продолжаем.

Я проходил собеседование именно в Lazada, которая входит в экосистему Alibaba. Возможно, процесс в самой Alibaba немного отличается, но по уровню требований вряд ли кардинально. У меня было 3 этапа собеседования:

1️⃣ Проверка знания Android SDK
Классический этап: жизненный цикл, работа с UI, многопоточность, базовые вещи. Здесь, как правило, проблем ни у кого не возникает.

2️⃣ System Design. И вот тут начинается самое интересное.
System Design был максимально приближен к реальному продукту. Учитывая, что Lazada — крупнейший e-commerce в Юго-Восточной Азии с сотнями миллионов пользователей, задача была не "нарисовать экран", а спроектировать устойчивую систему поиска.

Нужно было:
1) Спроектировать экран поиска с подсказками и категориями
2) Продумать кэширование запросов и локальную историю поиска
3) Предусмотреть debounce и обработку ошибок сети

Но этим всё не ограничивалось. Интервьюер ожидал, что мобильный разработчик понимает систему целиком, а не только работу клиента. Поэтому всплывали вопросы, которые многие Android-разработчики вообще не рассматривают:

1) Зачем нужен API Rate Limiter
2) Как работает балансировщик нагрузки
3) Что будет при всплеске трафика

И вот тут на собеседованиях валятся даже сильные кандидаты.

3️⃣ Алгоритмы. Вишенкой на торте были 2 задачи уровня Leetcode easy / medium. В те годы я, если честно, даже не знал, что такое Leetcode. Зато у меня была книга Роберта Лафоре «Структуры данных и алгоритмы в Java», которую я активно перечитывал за неделю до собеседования. Всем рекомендую кстати.
Одну из задач помню до сих пор — проверка корректности строки со скобками, классическая задача на стек.

Все эти этапы были не зря: спустя пару дней я получил офер. А уже потом узнал, что команда мобильной разработки летит работать в штаб-квартиру Alibaba в Ханчжоу 🇨🇳

Главный вывод, который я тогда сделал: большие компании ищут не Android-разработчиков, а инженеров, которые понимают, как работает вся система целиком. Компании ищут не верстальщиков интерфейсов, а именно инженеров способных выйти из своей зоны ответственности и при необходимости участвовать в проектировании API или процессе сбора продуктовой аналитики.

Именно поэтому сегодня я так много внимания уделяю system design и архитектуре в работе с Android-разработчиками — это самый частый пробел на собеседованиях в крупные компании.

В следующем посте покажу офис штабы-квартиры и расскажу почему я все таки не остался работать в Китае. P.S. На фото с коллегами в кампусе Alibaba.

​​Сейчас в соц. сетях модно вспоминать 2016 год и делиться фотографиями тех лет. Как раз примерно в те года я получил оффер и присоединился к работе над проектом Lazada и работал в штаб-квартире Alibaba в Китае.

Lazada - это крупнейший маркетплейс. Те из подписчиков, кто путешествовал по Юго-Восточной Азии, например, Тайланд или Бали, думаю точно слышали про этот проект. Я работал в команде Search, наша команда отвечала за все, что связано с поиском товаров, фильтрами, категориями и так далее. Особенно "весело" было во времена распродаж, например 11.11, приходилось очень много выполнять оптимизаций и кэширования чтобы поддерживать работу в пиковые нагрузки, а еще помню ночные дежурства всей команды.

Посетив штаб-квартиру Alibaba в Ханчжоу 🇨🇳 был удивлен некоторой аскетичностью офиса, по сравнению со многими ИТ-компаниями РФ. Даже в нынешние времена массажные кресла, собственный бариста и спортзал в офисе считается чуть ли не обязательными атрибутами любой крупной ИТ-компании. В Alibaba же было все просто и без излишеств, но при этом все необходимое для комфортной работы. Зато был мощнейший инженерный фокус: минимум лишнего, максимум результата.

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

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

Я начал смотреть на приложения не как на набор экранов, а как на распределённые системы: с узкими местами, SLA, деградациями и компромиссами. Именно это потом больше всего помогало мне на сложных собеседованиях и в проектировании архитектуры. Так что я всем рекомендую пробовать разные проекты, чтобы повышать ту самую насмотренность и выявлять лучшие практики. Сейчас я часто вижу, как Android-разработчики годами не могут пробиться в крупные компании именно из-за system design и архитектуры. Во многом — потому что у них не было опыта вроде этого.

Ставьте реакции, если интересно, в следующих постах покажу фото офиса Alibaba и расскажу о процессе собеседования.