​​Разбор задачи из реального собеседования в 🎵TikTok.Часть 2

Теперь, обладая минимальной теорией, давайте вернемся к задаче. В задаче требуется выполнить три метода по порядку, при этом каждый метод выполняется в отдельном потоке.

  public void first() { print("first"); }
  public void second() { print("second"); }
  public void third() { print("third"); }
}

Конечно, сейчас вы можете возразить, что можно использовать корутины или RxJava. Но обычно на таких собеседованиях использовать библиотеки не рекомендуется, потому что проверяется насколько хорошо вы знаете java.util.concurrent.
Чтобы обеспечить последовательность выполнения, мы могли бы создать некоторые зависимости между парами методов, т. е. второй метод должен зависеть от завершения первого метода, а третий метод должен зависеть от завершения второго.Зависимость может быть реализована с помощью механизма параллелизма, как мы обсуждали в предыдущем разделе. Идея состоит в том, что мы могли бы использовать общую переменную с именем firstJobDone для координации порядка выполнения между первым и вторым методом. Аналогичным образом мы могли бы использовать другую переменную SecondJobDone, чтобы обеспечить порядок выполнения второго и третьего метода.

Алгоритм решения задачи следующий
1️⃣ Прежде всего, нам нужно создать координационные переменные firstJobDone и SecondJobDone, чтобы указать, что методы еще не выполнены.
2️⃣ В функции first() у нас нет зависимостей, поэтому мы можем сразу приступить к работе. В конце функции мы обновляем переменную firstJobDone, чтобы указать, что первый метод завершил работу.
3️⃣ В методе second() мы проверяем статус firstJobDone. Если не обновилось, то ждем, иначе переходим к выполнению логики метода. И в конце функции мы обновляем переменную secondJobDone, чтобы отметить завершение второго задания.
4️⃣ В методе third() мы проверяем статус secondJobDone. Как и в случае с методом second(), мы ждем сигнала secondJobDone, прежде чем приступить к выполнению третьего метода.

class Foo {

  private AtomicInteger firstJobDone = new AtomicInteger(0);
  private AtomicInteger secondJobDone = new AtomicInteger(0);

  public Foo() {}

  public void first(Runnable printFirst) throws InterruptedException {
    printFirst.run();
    // mark the first job as done, by increasing its count.
    firstJobDone.incrementAndGet();
  }

  public void second(Runnable printSecond) throws InterruptedException {
    while (firstJobDone.get() != 1) {
      // waiting for the first job to be done.
    }
    printSecond.run();
    // mark the second as done, by increasing its count.
    secondJobDone.incrementAndGet();
  }

  public void third(Runnable printThird) throws InterruptedException {
    while (secondJobDone.get() != 1) {
      // waiting for the second job to be done.
    }
    printThird.run();
  }
}

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

Плюсы решения
✅ Lock-free: Отсутствие блокировок. Это решение позволяет избежать блокировок или явной блокировки, уменьшая потенциальную конкуренцию и повышая производительность в некоторых сценариях.
✅ Простота: Использование AtomicInteger делает реализацию простой и лаконичной.

Минусы решения
❌ Холостой цикл (Busy-wait): Цикл while работает вхолостую при этом потребляет циклы процессора. Это может быть уменьшено с помощью небольшой задержки(например, Thread.yield() или Thread.sleep())) внутри цикла.
❌ Проблемы с масштабированием: Холостой цикл может быть неэффективным при масштабировании до более сложных cценариев синхронизации.

Чтобы было удобнее прочитать все целиком с примерами и картинками, оформил все в статью в блоге

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

​​Стоит ли ехать работать в Сингапур Android-разработчику. Впечатления и мысли.

В прошлом посте я привел пример задачки из собеседования в сингапурский TikTok, а сегодня расскажу о своих впечатлениях и мыслях после поездки в Сингапур. Кстати россиянам можно находиться в Сингапуре до 96 часов если вы потом летите в другую страну. Например Россия-Сингапур-Индонезия. Так что для удаленщиков мечтающих работать с Бали, есть отличная опция посетить Сингапур без визы. Делюсь своими впечатлениями почему мне было бы интересно поработать в Сингапуре:

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

🖥️ Сильный рынок технологий. Сингапур является одним из ведущих технологических хабов в Азии. Здесь расположены офисы многих международных компаний, таких как Google, Facebook, Amazon и других, что открывает широкие возможности для карьерного роста.

💵 Высокие зарплаты. Зарплаты Android-разработчиков в Сингапуре достаточно высокие, особенно в сравнении с другими странами региона. Средняя зарплата варьируется от 60 000 до 120 000 $ в год в зависимости от опыта и компании.

🏦 Низкие налоги. Сингапур предлагает одну из самых привлекательных налоговых систем в мире. Ставка подоходного налога для резидентов начинается от 0% и достигает максимум 22% для высоких доходов.

🌎 Международная среда. Сингапур — мультикультурный город с большим количеством экспатов. Это создает уникальную среду для networking и культурного обмена.

📍 Удобное расположение. Сингапур является отличной базой для путешествий по Азии благодаря своему центральному расположению и развитой транспортной инфраструктуре. До Бали можно долететь буквально за пару часов например.

🌳 Зеленый город и отличная инфраструктура. Когда гуляешь в центре Сингапура складывается ощущение что ты в огромном ботаническом саду. Одни только супер-деревья чего стоят.

Для себя я отметил следующие минусы, пока был там

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

🚴 Конкуренция на рынке труда. Несмотря на высокий спрос на IT-специалистов, конкуренция среди разработчиков, включая Android-разработчиков, достаточно высокая, особенно в крупных компаниях.

🧑‍⚖️ Жесткие законы и правила. Сингапур известен своими строгими законами и высокими штрафами за их нарушение. Например нельзя пить и есть в метро - в жаркую погоду это очень странно.

🥵 Климат. Тропический климат с высокой влажностью и постоянной жарой может быть непривычным и некомфортным для некоторых людей.

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

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

​​Вы не сможете сделать это тестовое задание… если не знакомы с теорией графов.

В этом посте (еще один пост про курс доллара😁) хочу поделиться с вами одним реальным тестовым заданием, которое без знаний теории графов выполнить не получится.

Если кратко, то задача звучит так: необходимо реализовать Android-приложение для конвертирования валют. Данные о курсах валют предоставляются в json-файле. Что может пойти не так? При этом тут стоит задуматься о нескольких моментах:

1) Когда есть несколько вариантов конвертации, лучше минимизировать количество конвертаций и сократить расходы. Вы можете представить, как работает обмен валют в реальном мире: чем больше промежуточных конвертаций вы делаете, тем больше денег теряете за каждую транзакцию. Например если известен курс USD -> GBP то лучше использовать его вместо USD -> EUR -> GBP
2) Если есть выбор, вы, вероятно, предпочтете более выгодные курсы вместо более дорогих, чтобы максимизировать прибыль.

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

📌 Моделирование задачи как графа
- Вершины графа представляют валюты.
- Рёбра графа представляют возможные конвертации между валютами. Вес ребра может быть равен комиссии или курсу конвертации (в зависимости от постановки задачи).

📌 Выбор алгоритма
Для поиска кратчайшего пути (минимального количества конвертаций) подходят следующие алгоритмы:

- Алгоритм Дейкстры — если учитываются веса рёбер (например, комиссии или курсы). Основным ограничением алгоритма является невозможность работы с отрицательными весами рёбер.
- Алгоритм поиска в ширину (BFS) — если веса рёбер не учитываются, а важно только количество конвертаций.
- Если есть отрицательные веса, можно использовать алгоритм Беллмана-Форда.

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

Как сбор Performance - метрик и анализ помог нам ускорить работу Android-приложения на 20%.

Всем привет! В апреле буду выступать на конференции Merge в Казани, расскажу о том, как мы разработали собственный инструмент сбора метрик и мониторинга Android-приложения.

В платформенной команде, в которой я являюсь лидом, мы сконцентрированы на качестве приложения и поэтому в прошлом году сделали большую работу по сбору, анализу и улучшению метрик приложения. А еще разработали собственный инструмент с визуализацией трейсов на Python. Так что, если будете в Казани приходите - поделюсь массой полезной информации.
Кстати я заметил, на том же Мобиусе есть тоже несколько докладов связанных с Performance-метриками, тема действительно актуальна для многих компаний. Мало уметь сверстать красивые экранчики - необходимо чтобы они работали быстро и плавно.

​​Сегодня буду выступать в Ульяновске на конференции Стачки 2025 крупнейшей IT-конференция России с 6 направлениями и более 200 докладов от лучших спикеров IT-индустрии.
Всем привет! Сегодня буду рассказывать о разработанном в Звуке инструменте сбора метрик производительности мобильного приложения в секции по Мобильной разработке. Кто в Ульяновске, приходите на доклад, пообщаемся. Кроме того у меня есть один билет, можно посетить оффлайн или посмотреть онлайн-трансляцию (по билету). Кому нужен билетик и кто планирует посетить/посмотреть доклады - пишите в комменты, рандомно выберу одного из подписчиков и скину в лс.

🔥 Вернулся со Стачки 2025 — делюсь впечатлениями!

1. Лаконичность — сила
Краткость - сестра таланта. Большая часть докладов были в районе 25 минут. С одной стороны времени маловато, чтобы глубоко раскрыть какую-то тему. С другой, достаточно, чтобы озвучить ключевые тезисы и поделиться выводами и опытом. А дальше, кому тема была интересна можно пообщаться со спикером на after party или попросить DeepSeek рассказать поподробнее. И мне такой подход очень нравится. Получаешь концентрацию идей и потом копаешь глубже если необходимо.

2. Мобилка & Архитектура
Из докладов что отметил: в основном успел на мобильную разработку и архитектуру. Коллеги из мобильной разработки рассказали про то, как работают Kotlin Sequences под капотом, как внедрить JNI если необходимо кроссплатформенное взаимодействие (например переиспользование функционала в браузере и в других проектах).

🏗 ADR/RFC и 🤖 AI + код-ревью
По архитектуре понравился доклад про рефакторинг процесса защиты архитектуры (про ADR, RFC) и примеры когда это действительно упрощает разработку, а когда нет. Ну и в заключение послушал доклад ребят, с которыми учились на одном факультете и кафедре математического обеспечения про разработку и внедрение собственного инструмента на базе ИИ для автоматического код-ревью и ускорения этого процесса.

⚙️ Техдолг в дизайн-системах
Еще был хороший небольшой доклад про техдолг и как его минимизировать на примере компонентов Дизайн-системы. Понравилась аналогия с рулем для пилотов Формулы-1 и обычный седан. Идея в том, что API компонента ДС должно быть как руль для седана-покрыает 99% кейсов для обычных пользователей.

3. Космос ближе, чем кажется
В завершение — выступление Антона Шкаплерова, героя России и космонавта. Потрясающие истории о работе на МКС, сложностях и триумфах. Апрель вообще богат на космические события — и после таких рассказов хочется следить за этой темой ещё внимательнее! 🚀

Как задача по добавлению одной простой зависимости увеличила размер APK почти на 10%, но мы вовремя разобрались.

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

Но не тут то было. У нас есть мониторинг, который вычисляет разницу релизной APK до и после изменений. Оказалось, что после добавления этой библиотеки размер проекта увеличился почти на 10%. Как следствие pipeline на CI/CD упал с отчетом, что такое увеличение не допустимо. После тщательного изучения проблемы, оказалось, библиотека притащила агрессивные Proguard-правила, которые отключили оптимизацию для всего приложения.

⚠️Как работают Proguard-правила в Android-проекте:

1. Основные правила проекта – находятся в файле proguard-rules.
2. Правила из зависимостей (библиотек) – могут поставляться внутри AAR/JAR-файлов как proguard.txt.

Что происходит при сборке:
Если библиотека предоставляет свои Proguard-правила, они объединяются с правилами основного проекта.
Порядок применения зависит от порядка зависимостей, но обычно:
- Сначала применяются правила библиотек.
- Затем – правила основного проекта ( proguard-rules).

В моем кейсе были следующие проблемные правила:

1. -keepclassmembernames class  * { public protected <methods>; }
 - Действует на все классы приложения (из-за  *), отключая оптимизацию методов. В коде SDK нужно уточнить правило, чтобы оно затрагивало только классы SDK.

2. -keep public class  **.BuildConfig {  *; }
 - Сохраняет все BuildConfig в проекте, хотя нужно только свои.

3. -keep class ru.example. ** {  *; }
 - Полностью отключает оптимизацию всего SDK, хотя можно ограничиться только моделями (например, сериализуемыми классами).

Вывод:
Обязательно добавьте проверки на CI/CD, чтобы мониторить изменения в вашем приложении. Если вы разрабатываете SDK или библиотеку - обязательно проверяйте настройки proguard, чтобы не влиять на проекты, которые будут внедрять ваше решение. Свою обратную связь мы передали разработчикам и в следующей версии уже все поправили, так что все хорошо.
Правила должны быть:
📌 Конкретными (без дженериков, где возможно).
📌 Ограниченными только своим кодом (не затрагивать классы приложения).
📌 Проверки на CI/CD помогут вам оперативно выявить проблемы до релиза в прод.

А у вас есть проверки на CI/CD и как они вам помогают?

Посещение конференций как способ оценить обстановку на рынке труда.

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

И выводы неутешительные.

💃 Во-первых, заметил кратное уменьшение кол-ва HR-специалистов. Еще пару лет назад, приходилось буквально уворачиваться от цепких рук HR-специалистов, которые активно охотились на айтишников во время конференции. А если все-таки заполнил анкету на стенде - жди минимум нескольких десятков сообщений от разных HR-ов с предложениями о работе.

🛍️ Во-вторых, уменьшение стендов и каких-то интересных инициатив со стороны компаний. Раньше были хакатоны, стажировки и просто конкурсы в стиле: реши несколько задачек и выиграй iPhone 15 Pro Max. Компании ценят свое время и деньги и времена, когда после конфы можно было уйти с новенькой Playstation закончились. Высокая ключевая ставка готовит компании к оптимизации расходов.

🔹 Отмена конференций. Я готовился в том числе на конференцию AppsConf25, но, за несколько недель, пришла новость, что конфы не будет. Подробностей не знаю, но сам факт отмены конференций (не из-за ковида) вижу впервые.

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

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

Количество этапов сильно увеличилось, будьте готовы порешать задачки и пройти этап System Design Interview. Кстати именно этот этап, я считаю самым эффективным, который позволяет оценить опыт кандидата. В тоже время для мобильных разработчиков этот этап считается и самым тяжелым, так как материалов именно для мобильных разработчиков не так много. Планирую как раз раскрыть несколько важных тем по System Design для Android в следующих постах. А как вы оцениваете текущий рынок мобильной разработки?

Работа с метриками приложения: измеряем, анализируем, улучшаем производительноть приложения

Появилась запись моего доклада с конференции Merge 2025 в Иннополисе, где я поделился опытом внедрения метрик производительности в мобильное приложение Звук. В прошлом году мы уделили много времени именно качеству работы приложения и его производительности. В докладе рассказал, какие инструменты рассматривали для анализа, как в итоге разработали собственный Performance-tracer, и какие метрики получилось улучшить. Тут опишу основные тезисы:

📌Зачем собирать метрики производительности?
Стабильность – ловим баги до пользователей.
UX – ускоряем старт и рендеринг.
Ресурсы – экономим трафик и батарею.
Бизнес – рост конверсии и удержания.
Техдолг - проще анализировать и планировать работу

🛠 Из каких инструментов выбирали:
Firebase Crashlytics: Простота, детальные отчеты о сбоях
Firebase Performance: Удобные дашборды, автоматически собирается статистика о работе приложения. Но немного замедляет старт приложения и нет гибкой настройки.
Sentry: Мониторинг ошибок + перфоманс, из минусов дорого, сложная настройка self-hosted решения
OpenTelemetry: Гибкость, open-source. Но изначально это решение для backend-разработки, не нашел ни одного примера кто использовал бы в мобильных приложениях и нет документации для Android.
В итоге, мы как настоящие разработчики решили сделать свое кастомное решение на базе Redash + кастомные трейсы

📌 Какие метрики собирали?
Холодный/горячий старт
Отрисовка экранов
Скорость сетевых запросов
Парсинг JSON, инициализация DI
Бизнес-логика и воспроизведение контента

🚀 В итоге, используя все доступные инструменты для оптимизаций мы добились
Холодный старт: -20%
DI-инициализация: -15%
Inflate-методы: стали в 2-20 раз быстрее

Выводы:
1. Собирайте метрики до того как заметили проблемы в проде
2. Начинайте с бесплатных инструментов (Firebase, Profiler).
3. Дашборды – мощный аргумент для построения roadmap и инструмент тимлида для планирования работы с техдолгом.

​​🏕️ Выступил на ИТ-кэмпе Summer Merge 2025.
На прошлых выходных получилось совместить казалось бы абсолютно разные вещи: ИТ и отдых на природе. 2 насыщенных дня на берегу Волги на конференции Summer Merge пролетели незаметно. Утром: йога и сапсефринг, днем ИТ-доклады и полезный нетворкинг, а вечером кавер-группы и эндуро-покатушки на мотоциклах.

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

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

​​Список литературы на лето для Android-разработчика

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

Карьера Software Engineering Manager. Эффективное управление командой разработчиков. Лидом я работаю уже давно, часть описанных идей для меня не были новыми, однако всегда полезно структурировать то, что уже есть и подметить известные решения с новой стороны. Очень понравилось, что повествование книги выстроено как в симуляторе. В каждой главе рассматривается какой-то отдельный аспект менеджера команды, описывается типичная ситуация и ты уже представляешь себя в этой ситуации и начинаешь думать как поступил бы. Считаю что обучение на каких-то типовых ситуациях приближенных к реальной жизни самое эффективное. Можно смело брать и читать. Будет полезно тем, кто хочет вырасти из senior в лида.

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

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

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

Наглядные примеры работы Kotlin Flow операторов

Кто работал с RxJava, возможно, помнит интерактивные Marble-диаграммы, для более наглядного понимания работы операторов.
Было бы круто что-то похожее увидеть и для Kotlin Flow для наглядности работы.

Нашел классную статью с крутыми анимациями с пиксельной графикой, которые автор создал для объяснения работы популярных операторов в Kotlin Flow. Ощущается, как будто играешь в какую-то игру на Nintendo.

​​LRU-кэш: Как сделать историю поиска за 3 строки кода (и пройти собеседование)

Мы в Звуке уже давно используем System Design для проверки знаний и умений кандидата. И часто, задача состоит в том, чтобы спроектировать 1-2 экрана похожих на те, что реализованы в приложении. Обычно это поиск + лента. И тут можно до бесконечности обсуждать способы реализации: пагинации списков, эффективного поиска, офлайн-кэширования и так далее. В этом и сложность этого этапа.

Так вот, один из таких вопросов это: "Как реализовать историю поиска и показывать пользователю последние запросы, а старые удалять?" Очень часто, кандидаты предлагают решение на базе HashMap. Предлагают хранить кол-во запросов/дату запроса и потом сортировать их от наиболее свежего до старого. Такой подход будет работать, но можно предложить более эффективное решение. Называется такой подход LRU-кэш.

LRU (Least Recently Used) — это алгоритм кэширования, который автоматически удаляет редко используемые данные, чтобы освободить место для новых.

Какие плюсы от LRU-кэша в данной задаче:

1. Автоматически удаляет старые элементы
Если пользователь искал много запросов, LRU удалит самые старые, оставив только последние (или N самых свежих).
Например, можно ограничить кэш 10 последними запросами.

2. Быстрый доступ к недавним элементам
LRU хранит элементы в порядке их использования, поэтому получить список недавних запросов можно за O(1).

3. Простота реализации
Во многих языках есть готовые реализации (например, LinkedHashMap в Java,

LinkedHashMap часто используется для реализации LRU-кэша, потому что эта структура данных сочетает в себе преимущества хеш-таблицы и связанного списка. Например с помощью accessOrder = true при любом обращении (вставка/чтение) элемент перемещается в конец. А метод removeEldestEntry() позволяет автоматически удалять самый старый элемент при превышении размера.

Вот так знание патерна LRU позволит вам не изобретать велосипед, а просто и эффективно решить такого рода задачу. Такие задачи - частый вопрос на собеседованиях (например, в Яндексе, Тинькофф, VK). И на практике, в android - проектах такие задачи постоянно встречаются. Например, библиотека Glide для кэширования ресурсов также использует LRU. Эти и другие эффективные подходы мы разбираем на курсе по System Design

​​Как получить +30% к зарплате к осени?
Анонс курса по подготовке к Mobile System Design.

Друзья, 5 августа стартует интенсивный тренинг по подготовке к мобильному System Design. Таким образом, к осени, когда компании начинают сезон найма вы будете уже готовы! Почему стоит пройти этот курс:

1️⃣ Максимально приближенные к реальным кейсы из BigTech. Разберем типовые кейсы, которые спрашивают в Avito, Yandex и т.д. А на Mock-собеседовании потренируемся.

2️⃣ Хватит рассказывать про Load Balancer и рисовать общие диаграммы с репозиториями! На курсе мы разберем ошибки, из-за которых вы не получаете хороший оффер.

3️⃣ Это хороший способ систематизировать уже имеющиеся знания, и начать расти в сторону архитектора. Мы разберем различные инструменты кэширования, backoff policy, обсудим плюсы/минусы разных форматов передачи данных - в общем те темы, которые часто нужны на более высоком грейде.

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

Отзыв с Mock-собеседования по System Design.

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

Проходила мок-сосбес по System design. Понравилась атмосфера проведения, в процессе выписала для себя 3 страницы того, что нужно улучшить перед реальным собеседованием. После интервью получила развернутый фидбек. Что было хорошо, что нужно подтянуть. Причем фидбек был не абстрактный, а детализированный. Какие подходы/фреймворки стоит покопать, что стоит упоминать, и чего делать не надо. В общем, получила план развития, который, я уверена, приведет меня к моей цели!

А я напоминаю, что сегодня, последний день до повышения цены! Посмотреть отзывы и программу можно тут

​​Как спроектировать новостную ленту. Mobile System Design

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

Например мы в платформе когда делали свой инструмент для сбора performance-метрик задействовали Python для визуализации трейсов, Redash для бэкенда и еще сами писали SQL-запросы для Data-аналитиков. Так и на собеседовании по System Design, вас вряд ли спросят как сверстать кнопку. У меня как-то был кейс когда пришлось рассказывать про Message Queue на бэке и выбирать между Kafka и RabbitMQ.

А еще во многих компаниях (у нас в том числе) проходят так называемые защиты архитектуры той или иной фичи. И мобильные разработчики вправе выбрать и спроектировать такой API который будет удобен именно им и часто общаются с Backend-командой. Так что это тоже очень важный скил.

Закончился курс по System Design Interview

В августе я анонсировал курс по подготовке к System Design, и совсем недавно он завершился.

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

Я всегда собираю обратную связь в конце, и оценка NPS курса составила 9.33 (из 10) 🔥

Вот что говорили участники, когда пришли на курс:

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

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

Хотел бы структурировать знания по архитектуре мобильных приложений и приобрести навыки по прохождению system design собесов.

Судя по опросу, все цели курса были достигнуты.
Теперь ребята уверенно себя чувствуют в контексте System Design и смело выходят на непростой рынок ИТ.

✅ Могут спроектировать архитектуру сервиса,
✅ Подсветить edge-кейсы и выбрать наиболее подходящий стек,
✅ И самое главное — уложить это всё в 50 минут, которые обычно отводятся на system design собеседования.

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

Не успеваю написать пост, батарея садится или про анализ энергопотребления Android-приложений.

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

Анатомия энергопотребления
Анализ энергопотребления

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

🚗 Внедрили Звук в 2GIS - самый сложный проект этого года. Теперь вы можете слушать любимую музыку сразу в приложении 2GIS в режиме навигации. Вот где навыки System Design пригодились и прокачались. С точки зрения архитектуры и взаимодействия было очень интересно и нетривиально, необходимо было выделить в отдельный SDK логику для проигрывания, а также разделить дизайн-систему с минимум зависимостей так как у таких проектов обычно очень жесткие требования на размер и кол-во зависимостей. Кстати именно этот проект получил награду Релиз года от CEO.

⌚Разработали приложение для Huawei Watch GT 6 и 6 Pro - можно слушать музыку теперь и во время пробежек.

🚅 Множество рефакторингов и оптимизаций. Внедрили Baseline Profiles, а также распилили Shared Preferences на множество независимых DataSource-ов, в сумме ускорили старт приложения до 40%!

🦾 Одни из первых в команде внедрили AI-based code review в пайплайны (ну куда ж без AI), сократив время код-ревью, а также множество проверок для качества приложения: чекаем размер apk, делаем замеры энергопотребления.

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

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

А вы подводите итоги работы в своей компании?