Ну я начинал с 1с, никакой английский там нафиг не нужен (а где нужен хватало онлайн переводчиков). При этом можно реально неплохой опыт получить если с 1сной конторой повезет.

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

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

Вот не надо тут. Пришел на проект в котором с базой локальной кошмарно обращаются (N+1), sqlite как key-value база почти используется, и прочее. В итоге часть функций приложения знатно тормозит.
Плюс сейчас понемногу пишу свою читалку в свободное время, и тут тоже надо над оптимизацией некоторых моментов думать.

Зато архитектуру наархитектурили под руководством лида из сбера... Это да. Интерфейс за интерфейсом и интерфейсом погоняет. Куча слоев где каждый слой все что делает это берет dto из одного слоя и в другой перекладывает. При том что над приложением работает 2 человека.

Исключения всегда есть. Я под iOS пишу уже 10 лет, за это время могу вспомнить от силы пару проектов, где была такая необходимость. Опять же, эти задачи легко отдаются сеньору и он делает как надо. А оставшиеся 95% вёрси экранов делают вчерашние аниматоры из Центрального Парка практически за еду и опыт. И всем хорошо.

Работа с БД и сеткой — это частая проблема мобильщиков. Любят нахуевертить так, что из-за этого всё тормозит)

Такой мощный наброс, что даже не знаю, с чего и начать)

Хм, общий опыт работы 7 лет - и еще на первой работе в 1сной конторе пока стажером был привили что за производительностью нужно следить. За всякие циклы в цикле, N+1, списки вместо множеств/мап, отсутствие правильных индексов/наличие неправильных индексов, кривые реализации обходов структур, отсутствие inmemory кэша где это нужно и т.п. по рукам били.

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

Ну я по опыту говорю. На любом проекте, где работал, как минимум, Android-разрабы вообще ужасный код писали по работе с SQL'кой.
Если у вас разрабы за это шарят, то круто)

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

А отвечать и не нужно, я про то, что вывод "мобильщики любят нахуевертить именно сетку и БД, так что лагает" – звучит голословно

Лагает, потому что верстка переусложненная, например

Да утрировано же. Понятно дело, что это от места к месту зависит.

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

Тормозит это не "лагает анимация", а тормозит это "открылся экран -> в память из разных таблиц подтянули элементы -> и циклом в цикле эти элементы секунду-две вертим", вместо того чтобы простым запросом обойтись который бы все за миллисекунды сделал

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

Я могу, я такое сам делал. Но таки да, гораздо проще всё испортить кривой вёрсткой, чем адовыми алгоритмами с тройным пузырьком.

Верстка обычно просто лагает, это еще как то терпеть можно, в отличие от залипаний на N секунд на ровном месте (на дешманских девайсах за 3к рублей так секунд на 10) из за кривой работы с базой.

Какие таблицы? О чём речь? Запросы в базе в другом потоке работают. Там же всё асинхронно.