Компания занимается развитием сервисов, а не производством программного продукта, поэтому высококвалифицированные разработчики компании нужны в очень ограниченном количестве. Гораздо больше нужны админы и девопсы. Отсюда следует, что большинство нанятых разработчиков попадают на неинтересные задачи по перекладыванию json из сокета в сокет и из базы в сокет, а также на них ложится большое количество непрофильных задач по созданию, развитию и поддержке сервисов 24/7, что приводит в том числе к неоплачиваемым дежурствам, когда разработчик должен быть 24 часа на связи и в шаговой доступности от своего рабочего ноутбука.
Кроме того, не всем нравятся непрофильные задачи по администрированию и аналитике, поэтому такие люди будут выполнять их без огонька, как это было со мной, за что будут получать низкие оценки на полугодовых ревью, низкую премию и низкий рост зарплаты, которая изначально ниже рынка.
Из-за особенностей системы performance review в компании никто (ни руководитель, ни степ, ни hr-партнер) не может гарантировать вам ни интересных задач, ни премии, ни хорошей оценки, ни роста грейда, ни даже того, что вас не уволят в очередное ревью.
Несмотря на громкие слова о легкости переходов внутри (ротация) вам также никто не гарантирует успешную ротацию, её в любой момент могут заблокировать и лишить вас обещанных интересных задач и это при согласии обоих руководителей - и принимающего и отпускающего. В результате вы вынуждены будете в панике искать себе новую команду под страхом увольнения, а на время поиска вас весьма вероятно отправят в отпуск за свой счёт. Также при ротации вы будете конкурировать за вакансию в новой команде с внешними соискателями, но при этом вам не поднимут зарплату, как это было бы при нормальном поиске работы, однако секции собеседований для перехода в другую команду вы будете проходить почти в таком же количестве как при устройстве в Яндекс, никаких поблажек за то, что вы уже работаете в компании вы не получите.
Велосипеды - они повсюду. А это значит что привычный паттерн поведения - столкнувшись с проблемой погуглить решение и найти ответ - здесь вас не спасет. Документации зачастую нет, что делать непонятно. Если код в едином репозитории еще можно посмотреть исходники, если сервис лежит в местном github/bitbucket - вы можете и не найти исходников или не иметь к ним доступа. Даже систему контроля версий теперь пилят свою, потому что у гита есть фатальный недостаток.
Устаревшие технологии - svn, python2, старые версии библиотек, старый линукс на проде (trusty, precise).
Большинство внутренних инфраструктурных сервисов представлены более чем одним конкурирующим продуктом, а отсюда следуют: постоянные бессмысленные изменения в инфраструктуре - вчера сервис разворачивали в одном облаке, сегодня надо срочно переезжать в другое, вчера графики мониторингов рисовались одним способом, сегодня надо переделывать на другой. Когда создаешь новый сервис никогда не угадаешь на чем его лучше делать, выбрал облако, а его стали закрывать нужно перевозить в другое, переделывать мониторинги, перенастраивать выкладку. Чтобы завести новый сервис нужно пройти три десятка шагов, каждый из которых будет требовать либо изучения очередного внутреннего велосипеда без документации либо создания тикета на смежников и долгого ожидания когда же они почешутся и сделают что от них требуется.
