Android Middle: критерии перехода

Переход на middle: почему «ещё год опыта» не работает

Middle — это не «джуниор, который подольше поработал», а другой уровень ответственности. На собеседованиях я регулярно вижу кандидатов с опытом 2–3 года, которые делают задачи, но не переходят на следующий грейд — и почти всегда причина одна: они готовятся не к тем критериям.

Если на junior собеседовании проверяют «можете ли вы писать код», то на middle проверяют другое: можете ли вы принимать решения и отвечать за них. Стаж тут вторичен — известны случаи, когда за год до middle дорастают, и случаи, когда на junior застревают на три года.

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

Что на самом деле отличает middle

Самая частая ошибка — сводить грейд к «объёму знаний». Джуниор и мидл могут знать одинаковый набор технологий, но работать по-разному:

• джуниор выполняет задачи, мидл — решает проблемы: «как это сделать» превращается в «что сделать и почему»;
• джуниор спрашивает «как», мидл сам находит варианты и приносит готовое решение с обоснованием;
• джуниор отвечает за свою часть кода, мидл — за результат модуля или экрана целиком;
• джуниору дают архитектуру, мидл участвует в её обсуждении и защищает свои предложения.

Поэтому собеседование на middle редко начинается с «расскажите про жизненный цикл». Оно начинается с «спроектируйте экран», «как вы решили бы эту проблему», «почему вы выбрали такой подход».

Технические критерии: глубина, а не широта

Техническая часть на middle — это не «знаю больше технологий», а «глубже понимаю то, что уже использую». Вот по каким темам проверяют глубину:

Kotlin и Coroutines. От мидла ждут понимания механики, а не синтаксиса: диспетчеры, скоупы, отмена корутин, обработка ошибок в Flow. На этих темах падает большинство кандидатов — разбор типичных промахов есть в отдельной статье.

Архитектура. MVVM, слои приложения, DI, работа с состоянием. Отличие от джуна: вы не просто используете паттерн, а можете объяснить, почему выбрали его и какие есть альтернативы. Официальную позицию Google по слоям архитектуры можно посмотреть в документации — но на собеседовании важнее ваша аргументация, чем цитата из доков.

Компоненты Android. Жизненный цикл на уровне «что произойдёт с ViewModel, Fragment и корутинами при сворачивании приложения», память и утечки, работа с потоками.

Вот типичный пример, на котором видно разницу между уровнями:

fun load() {
    viewModelScope.launch(Dispatchers.IO) {
        val data = repository.load()
        withContext(Dispatchers.Main) {
            state.value = data
        }
    }
}

Код рабочий, и джуниор объяснит его примерно так: «запустили в фоне, потом переключились на главный поток и записали данные». Мидл объяснит так же — а потом добавит: почему viewModelScope, а не GlobalScope; почему диспетчер переключают здесь, хотя это обычно делают внутри репозитория; что будет, если repository.load() бросит исключение; как это покрыть тестом. Это и есть глубина — не «как работает», а «что здесь не так и как сделать лучше».

Нетехнические критерии: на них проваливаются чаще

Парадокс: большинство кандидатов на middle проваливаются не на технике, а на вопросах, которые к ней не относятся. Интервьюер на позицию middle проверяет четыре вещи:

• Умение защитить решение. «Зачем вы сделали именно так?» — если ответ «так принято» или «ментор так сказал», это красный флаг. От мидла ждут: какие варианты рассматривали, что выбрали, какие компромиссы приняли.
• Оценка сроков. Реалистичная оценка с запасом — признак зрелости. «Сделаю за два дня» без уточнений хуже, чем «два-три дня, плюс день на тесты и ревью».
• Работа с чужим кодом. Мидл регулярно ревьюит чужой код и работает с легаси. Вопросы «как вы будете разбираться в незнакомом модуле» — почти обязательная часть собеседования.
• Приоритизация. Умение сказать «это сделаю, это не буду, потому что не влияет на цель» — вместо того чтобы делать всё подряд.

Как это проверяют на собеседовании

Собеседование на middle строится иначе, чем на junior. Вместо вопросов «что такое» — вопросы «как бы вы» и «почему»:

• «Спроектируйте экран каталога: состояния, ошибки, пагинация»;
• «Как бы вы организовали загрузку данных, если сервер иногда отвечает медленно?»;
• «Что будет с корутиной, если пользователь вышел с экрана, и как это обработать?»;
• «Опишите структуру приложения, которое вы сейчас пишете, и объясните каждое решение».

Обратите внимание: правильного ответа на эти вопросы нет. Интервьюер смотрит на ход мысли: как вы рассуждаете, какие вопросы задаёте, где останавливаетесь, что уточняете. Поэтому подготовка к middle — это не зубрёжка ответов, а наработка способа мышления: «сначала требования, потом варианты, потом решение с обоснованием».

План перехода: 4–8 недель

Если вы делаете задачи 1–2 года и хотите на middle, переход — это конкретная работа с началом и концом. Для разработчиков с опытом 1–2 года типичный срок — от месяца до двух плотной работы:

Порядок работы одинаковый, независимо от того, готовитесь вы сами или с ментором:

• Диагностика уровня: честная оценка, где вы сейчас, — по коду, по ответам на вопросы, по резюме.
• Список пробелов: конкретные темы, которых не хватает именно вам, без «учить всё подряд».
• План в порядке приоритета: сначала глубина в Kotlin и Coroutines, потом архитектура, потом подача на собеседовании.
• Практика: не чтение, а код и объяснение решений — каждую тему до уровня «могу защитить».
• Мок-собеседования: тренировка ответов с разбором, что спрашивают в Яндекс, Авито и других сильных компаниях.
• Выход на реальные интервью: собеседования как источник обратной связи, а не экзамен.

Важный момент: не пытайтесь перескочить порядок. Натренировать ответы, не закрыв пробелы, почти всегда проваливается — интервьюер копает глубже, и фальшь видна сразу. Зато когда каждая тема закрыта до уровня «могу объяснить и защитить», собеседование на middle становится формальностью.

Я — Рустем Бикбулатов, senior Android-разработчик, ментор Яндекс Практикума. Провожу технические собеседования и помогаю разработчикам с опытом 1–2 года перейти на middle: закрываю пробелы в Kotlin, Coroutines и архитектуре, тренирую ответы на собеседованиях. За моими плечами больше 100 учеников и разборов — критерии middle и типичные причины провалов я вижу постоянно.

Итоги

Переход на middle — это не ожидание «ещё одного года опыта», а работа по конкретным критериям:

• Грейд определяет ответственность и самостоятельность, а не список выученных технологий: умение принимать решения и защищать их.
• Техническая глубина проверяется на Coroutines, архитектуре и жизненном цикле, а нетехническая — на «почему»: аргументация, оценка сроков, работа с чужим кодом.
• Переход занимает 4–8 недель плотной работы, если знать свои пробелы и закрывать их в правильном порядке.

Если не знаете, где ваш уровень на самом деле, — напишите в Telegram, разберём вашу ситуацию: бесплатная диагностика покажет пробелы и даст план перехода на middle.