Не подписывайся на канал, пока не прочитал этот пост.

Этот канал для Android-разработчиков, которые пишут нормальный код - но раз за разом получают отказы на собесах в Яндекс, Авито, Ozon.

Здесь не будет советов "учи leetcode по 3 часа в день" и мотивационных постов. Только то, что реально режет кандидатов - глазами интервьюера.

Меня зовут Рустем. Получил отказы в Озоне и Альфе - не понимал, где именно сыплюсь. Разобрал свои ответы, пересобрал подготовку и закрыл оффер в Райффайзене. Потом перешёл на другую сторону и лично провёл 200+ интервью как интервьюер - теперь точно знаю, на что смотрят и за что режут. 4 ребят после наших разборов получили офферы в Авито и Т-Банке.

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

→ Подпишись - здесь разбираю только то, что реально спрашивают в Яндексе, Авито и Т-Банке. Без воды.

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

Несколько мест в мае. Напиши @android_career_booster - скажи, в какую компанию целишься.

Первый раз я увидел код синьора и завис минут на пять.

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

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

И вот тут разница между "учиться самому" и "учиться рядом с кем-то сильнее".

Когда учишься сам - растёшь в рамках того, что уже знаешь. Гуглишь то, что умеешь формулировать. Решаешь задачи так, как умеешь их решать.

Когда рядом есть кто-то сильнее - видишь то, что даже не думал искать.

Если ты сейчас в команде, где не у кого учиться - это не приговор. Насмотренность можно брать и в другом месте: открытый код сильных команд, чужие код-ревью на GitHub, видосы с реальных собесов. Ну или менторство, если хочется фидбек на свой конкретный код, а не в целом по вселенной.

Моя первая работа разработчиком началась с FizzBuzz и дрожащими руками.

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

С дрожащим сердцем пошёл показывать.

Сказали: "Ок." Через пару дней позвали работать. Радости было не то что полные штаны, а весь комплект одежды в шкафу.

Потом один разраб мне по-дружески сказал: "Остальные кто приходил вообще ничего не могли сделать. Твоё решение хотя бы работало."

Вот и весь секрет.

Я не был лучшим. Я просто пришёл, вывалил всё что знаю, и не ушёл с пустыми руками.

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

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

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

Рынок не стал добрее к джунам. Но он не стал и беспощаднее к тем, кто хотя бы пробует.

Если не знаешь с чего начать - напиши, разберём твою ситуацию: @android_career_boost

Однажды я готовился к собесу по корутинам.

Прям серьёзно — повторял, читал, смотрел примеры. Зашёл с ощущением "ну корутины я точно знаю". Начал отвечать — и что-то пошло не так. Говорю, интервьюер смотрит, и в какой-то момент понимаю что говорю неправильно. Как это произошло — загадка. Вроде только что знал.

Там была задача на последовательность вызовов корутин. Примерно вот такая:

val deferred = async {
    throw Exception("упало")
}
println("я выполнился")
deferred.await()

Вопрос: что выведется и когда упадёт исключение?

Я знал про async. Но не знал нюанс: исключение внутри async не бросается сразу — оно "лежит" внутри Deferred и прилетает только в момент вызова await(). То есть "я выполнился" успеет напечататься.

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

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

Что помогает: найди видео с реальных Android-собесов этого года — не туториалы, а именно записи собесов. Смотри как люди думают вслух, где спотыкаются, какие вопросы задают. И ищи кого-то кто разберёт с тобой именно такие ловушки, а не просто теорию.

Я как‑то открыл очередной roadmap по Android для джуна и понял, почему у ребят едет крыша.

Там список на полэкрана: Java, Kotlin, ООП, структуры данных, алгоритмы, паттерны, базы данных, сети, фреймворки, архитектуры, CI/CD, тесты, многопоточность, корутины, Compose, старый UI, чистая архитектура и ещё штук 20 пунктов. Читаешь и думаешь: "Я это всё когда‑нибудь выучу? Или сразу в такси пойти работать?"

Проблема не в том, что авторы врут. Проблема в том, что это общая карта по вселенной, а не твой конкретный маршрут.

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

Вместо "выучить всё из roadmap" задай один вопрос: какая ближайшая реальная цель?
Не "стать синьором", а конкретно: стажировка, позиция джуна в продуктовой, поддержка легаси‑приложения в аутсорсе и т.п.

Под эту цель у тебя обычно вылезают 3–5 блоков, а не 25.

Например, под "джун в типовую продуктовую компанию":

язык + основы Android SDK;

базовая архитектура (MVVM) и работа с сетью/БД;

Git и умение хотя бы не ломать репозиторий;

базовые темы собеса (жизненный цикл, коллекции, корутины на уровне "не умереть").

А вот всякие сложные штуки типа "идеальный CI/CD", "advanced Compose анимации" и "глубокий system design" можно оставить на потом. Они нужны, но не для твоего первого оффера.

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

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

3 причины, почему мидлы годами не получают оффер

Не джуны. Именно мидлы - люди с реальным опытом, живыми проектами и нормальным кодом в портфолио. Разбираю три паттерна, которые вижу снова и снова.

1. Пишет нормальный код - но не может объяснить trade-off

На собесе спрашивают: "Почему выбрали такой подход?" И человек теряется. Код работает, логика есть - а слов нет. Я уже разбирал это на примере Compose: можно знать инструмент вдоль и поперёк, но если ты не можешь объяснить, почему выбрал именно его в конкретном месте - интервьюер делает вывод, что ты просто копируешь чужие решения, не понимая их. Это не про знание API, это про умение думать вслух.

2. Резюме без цифр и без контекста

"Участвовал в разработке приложения" - и что? Какого? Сколько пользователей? Что именно делал? Я разбирал это подробнее в посте про резюме, но суть одна: рекрутер читает десятки резюме в день и у него нет времени угадывать твой масштаб. Если ты не написал - он не спросит, он просто перейдёт к следующему.

3. Готовится "как придётся"

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

Рынок не плохой. Просто хаотичная подготовка даёт хаотичный результат.

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

Я дважды подряд завалил один и тот же вопрос. И оба раза был уверен, что знаю ответ.

Вопрос был про flowOn. Интервьюер показывает цепочку с map и filter, спрашивает: "В каких потоках это всё выполняется?" Я отвечаю уверенно - мол, flowOn переключает поток, всё выше него уходит в указанный диспатчер. Логично же? Я это каждый день использовал, оно работало, я знал, что делаю.

Интервьюер смотрит на меня и говорит примерно следующее: "Ну не совсем поток - он контекст меняет. Диспатчер - это часть контекста."

Я поправился. Интервьюер принял. Но осадок остался - потому что это была не оговорка. Я реально так думал. Четыре года писал корутины и в голове держал упрощённую модель: flowOn = переключить поток. Работало - и ладно.

Второй раз та же история, другая формулировка. "Что выполнится быстрее: 10 тредов с delay(1000ms) или 10 корутин на Dispatchers.Main?" Я ответил правильно - корутины на main не параллельны, треды отработают за секунду. Но потом последовало: "А как вообще Dispatchers.Main работает под капотом?" И вот тут я уже лез в Handler, Looper, handler.post - и понял, что никогда не формулировал это вслух. Использовал каждый день, но объяснить точно не мог.

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

Тогда мне некому было сказать, где именно я не догоняю. Сейчас я это делаю для учеников.

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

Большинство людей готовятся к собесу примерно так: "прорешаю задачки на LeetCode", "посмотрю видосики по Android", "потрачу неделю на пет-проект". Звучит разумно. Не работает.

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

Я сам через это прошёл. Поэтому у меня есть другой вариант.

Хаотичный план (как делает большинство)

Нет порядка, нет приоритетов. Сегодня LeetCode, завтра видео про Compose, послезавтра решил начать пет-проект. Через две недели - усталость, ощущение что "много сделал", и ноль уверенности на реальном собесе.

Системный план (4 недели)

Неделя 1 - резюме, список компаний, анализ вакансий. Не "выучить всё", а сначала понять куда идёшь и как ты выглядишь на бумаге. Потому что резюме - это фильтр, который либо пускает тебя дальше, либо нет, и об этом почему-то вспоминают в последнюю очередь.

Неделя 2 - Android core и алгоритмы под конкретный уровень. Не "повторить всё", а именно то, что реально спрашивают на твоём грейде в компаниях из твоего списка. Это разные вещи.

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

Неделя 4 - точечная работа по слабым местам, которые вылезли на мок-собесах. Не по всему подряд, а именно по тому, что конкретно тебя валит. У каждого это своё.

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

Реальный вопрос с собеса. Кандидату показывают код:

@Synchronized
fun count(n: Int) {
    if (n == 0) return
    count(n - 1)
}

fun main() {
    count(10)
}

"Что произойдёт при вызове count(10)?"

Плохой ответ

"Дедлок. Метод залочен на объекте, при рекурсивном вызове он попытается взять тот же лок снова - и встанет намертво."

Именно так отвечает большинство - и именно так проваливается. Слово synchronized автоматически включает цепочку: лок → другой поток не войдёт → дедлок. Мозг нашёл знакомый паттерн и выдал ответ раньше, чем голова успела подумать. Это не незнание - это ловушка быстрого мышления.

Сильный ответ

Дедлока не будет. Программа выполнится нормально, count дойдёт до n = 0 и завершится без каких-либо проблем.

Причина - synchronized в JVM реентерабелен. Если поток уже владеет локом на объекте, он может войти в тот же synchronized-блок повторно - без блокировки. JVM видит, что лок запрашивает тот же поток, и просто увеличивает внутренний счётчик вхождений. При каждом выходе - уменьшает. Блокировка снимается только когда счётчик возвращается к нулю. Дедлок - это история про два разных потока, которые ждут друг друга. Здесь один поток, один объект, ноль проблем.

Что на самом деле проверяет интервьюер

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

Интервьюер проверяет не знание - а мышление.

Таких вопросов я разбираю десятки на диагностиках.

Easy на LeetCode - не то же самое, что easy на собесе

Пригласили на собес, скинули методичку: будут алгоритмические задачи.

Окей. Открываю LeetCode. Easy-уровень. Коллекции. Решается бодро, особенно когда рядом есть ИИ, которому можно скинуть задачу и уточнить, идеально ли решение.

Час-другой и я уже чувствую себя готовым.

Собес начинается. Сначала 40 минут теории.

Что-то забываю. Где-то нервничаю. К моменту, когда дошли до задачи - я уже немного на износе.

Дают задачу. Лёгкую. Прогон строки. Я такое решал вчера.

И я начинаю тупить.

В голове паника. Рука тянется скопировать задачу и закинуть в ЛЛМ.

Копипаст. Не. Работает.

Окей. Выдыхаю. Начинаю решать сам, объясняю интервьюеру подход - вроде нормально идёт. Но в конце понимаю: результат будет не тот, что нужен по условию.

Пытаюсь перестроиться. Шестерёнки не крутятся.

Пробую скопипастить ещё раз. Lol. Не работает.

Дописываю как есть.

Разбираем решение с интервьюером - приятный парень, кстати. Обсуждаем сложность. Он говорит: "Меня всё устраивает".

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

На следующий этап позвали.

Нужен ли джуну GitHub с учебными проектами в 2026?

На разборах я постоянно слышу один и тот же вопрос про GitHub:
- А нужно ли вообще его прокачивать?
- Нужно ли заводить туда учебные проекты?
- И какие проекты вообще туда вести?

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

Когда мы искали стажёров, я пересмотрел тонны резюме.
И вот честно, если в профиле была ссылка на GitHub, я почти всегда по ней переходил.
Через репозиторий за 30 секунд видно больше, чем через полотно резюме:
что человек делал, как пишет код, есть ли живые проекты или он просто "ищет себя".

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

Чтобы GitHub реально добавлял тебе очков, а не отнимал, достаточно базового порядка:
- нормальное фото и имя, по которому тебя можно найти, а не "DarkLord228"
- в шапке по‑честному: кто ты и куда целишься
- 1-2 проекта, которые ты можешь внятно объяснить на собесе
- в README написано, что это за проект и какие технологии ты трогал, а не просто "my app"

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

У меня сложное отношение к ИИ в разработке.

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

Схема стандартная: пришла задача → закинул в LLM → получил код → вставил → не заработало → попросил поправить → вставил снова. Всё. Задача закрыта. Понял ли что-то - отдельный вопрос. Чаще всего нет.

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

Но. Я нашёл для себя использование ИИ, которое реально работает - и про которое почти никто не говорит.

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

Промпт, который использую сам:

Выступи в роли технического интервьюера Android-команды в крупной продуктовой компании (уровень Авито, Т-Банк, Яндекс). Проводи со мной техническое интервью на позицию junior/middle Android-разработчика. Задавай вопросы строго по одному, жди моего ответа, не подсказывай и не комментируй до конца. Фокус: Kotlin, корутины, архитектура (MVVM/Clean), жизненный цикл, Jetpack. Когда я скажу "стоп" - дай фидбек: что ответил уверенно, где было размыто, что переформулировал бы, и общая оценка готовности к реальному собесу.

или, если готовишься к секции с hr

Выступи в роли HR крупной IT-компании и проведи со мной интервью на позицию Android-разработчика (junior/middle). Задавай вопросы по одному, жди моего ответа и не подсказывай. После завершения интервью дай подробный фидбек: оцени структуру ответов, уверенность, понятность, укажи слабые места и предложи, как улучшить.

Разница с флэшкартами и списками вопросов - огромная. Попробуй один раз - поймёшь.

Нормальное код ревью - это редкость.

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

Но варианты есть.

ЛЛМ-ки

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

У меня на проекте стоит авто AI-ревью. Он регулярно выдаёт такое, что просто звиздец - весь контекст проекта в него не вгрузишь, поэтому часть комментариев просто шум. Но часть реально полезная. Нужно уметь отличать одно от другого, и это само по себе навык.

Detekt и линтеры

Более классический путь. Никакого ИИ - это просто скрипты, которые прогоняются по коду и ловят конкретные вещи: слишком длинная функция, слишком много параметров, нарушение соглашений по именованию.

Звучит скучно. Но на безрыбье - очень даже рабочий инструмент. По крайней мере код не будет выглядеть как черновик.

Книги

Звучит старомодно, но именно там собрано то, что стало стандартом не случайно. "Чистый код", "Чистая архитектура", "Грокаем алгоритмы", "Проектирование высоконагруженных систем" - это не список для галочки. Это объяснение того, почему код пишут именно так, а не иначе.

Читаешь и начинаешь сам замечать в своём коде то, что раньше не видел. Это и есть самостоятельное ревью.

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

Синьоры больше не нужны!

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

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

Кажется, что ситуация хреновая:
-Денег у компаний нет и дальше будет только хуже
-ИИ отжирает рабочие места (прямо или косвенно через распределение бюджетов)
-В стране кризис, да и в мире кризис

Но на самом деле - это отличная возможность залететь в бигтех
Потому что не будет конкуренции с супер опытными разрабами
Зачем им соглашаться на зп 350?
Туда пойдут хорошо подготовленные мидлы, зацепятся за место, а через год работы повысятся до синьора и получат 400-450к

Единственный нюанс: "хорошо подготовленный мидл" и "мидл, который думает, что хорошо подготовлен" - это два разных человека на одном собесе

Здесь могла бы быть реклама менторства. Но вы и так всё знаете.

Вопросы на собесах такие же реалистичные, как хакеры в кино

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

ГГ пишет драйвер в две строки и взламывает корпоративную сеть за 40 секунд. Красиво, но как же неправдоподобно🙈

Собесы - та же история

Спрашивают методы data class, ждут полный список. Выдал всё - шаришь. Запнулся на componentN() - хромаешь. К реальной работе это не имеет никакого отношения

Я видел ребят, которые знали контракт equals/hashCode наизусть и не могли объяснить почему корутина жила после закрытия экрана. И видел тех, кто путался в методах Object, но именно их я бы нанял

Компании годами задают одни и те же вопросы. И годами удивляются, почему нанятые люди не вывозят на проде

А вы часто не могли решить задачу без componentN()?

Я выберу Dagger - я с ним больше работал

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

Кандидат только что показал: он не решает задачу проектирования, он просто существует программистом. Это ближе к стажёру, чем к сильному мидлу.

Вопросы по DI бывают разные, и каждый вскрывает разный уровень понимания:

- Отвечают все: чем DI runtime отличается от compile time?

- Отвечает большинство: что конкретно теряешь, выбрав Koin вместо Dagger в большом проекте?

- Отвечают немногие: как DI может замедлять запуск приложения?

- Почти никто: когда DI-фреймворк не нужен вообще?


Перед выбором инструмента нужно выяснить: размер команды, уровень разрабов, критична ли скорость запуска, моно или мультимодуль, будет ли KMP. Вот это и есть ответ на вопрос про DI - а не просто вкинуть название фреймворка.

"Я выберу то, с чем работал" - это ок ответ для стажёра. От мидла и выше ждут понимания задачи, а не верности инструменту.

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

Jetpack Compose на собесах всегда был моей головной болью.

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

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

Помню первый раз на собесе в компанию, куда реально хотел пройти. Спросили про collectAsStateWithLifecycle(). Я не смог нормально ответить и ещё доказывал интервьюеру, что всё работает и без этого.

Зачем я это делал, до сих пор не понимаю.

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

После этого сел и нормально разобрал тему. И понял простую вещь: я эти штуки использовал в работе. Просто никогда не пробовал объяснить их вслух.

А это совсем другой навык.

Compose до сих пор не самая приятная для меня тема. Но теперь хотя бы отвечаю по делу.

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