СБЕР: отзывы о работе на должности Backend-разработчик
Оценка компании
4,3
очень хорошо
5 отзывов
5
4
3
2
1
3
1
1
0
0
77%
Рекомендуют работодателя
Оценки по категориям
Junior Backend-разработчик
Январь 2023
Что мне нравится в работодателе
- адекватные руководители
- уровень зп
- шикарный офис на кутузе для любителей офисов)
- есть чему и у кого поучиться
- уровень зп
- шикарный офис на кутузе для любителей офисов)
- есть чему и у кого поучиться
Что можно было бы улучшить
- существует правило, по которому энный процент команды должен быть в офисе, поэтому ваш фулл дист - результат переговоров и компромиссов
- бюрократия, которая иногда чувствуется (но это же банк)
Список льгот
- бюрократия, которая иногда чувствуется (но это же банк)
Backend python-разработчик
Январь 2024
Что мне нравится в работодателе
Высокий годовой бонус, большое количество проектов, стабильность выплат зарплаты.
Что можно было бы улучшить
Необходимо составлять треки профессионального и карьерного развития сотрудников.
Список льгот
Middle backend-разработчик
Ноябрь 2022
Что мне нравится в работодателе
Отличное руководство
Что можно было бы улучшить
Уровень дохода и все
Список льгот
backend Python разработчик
Февраль 2024
Что мне нравится в работодателе
- продукт затрагивает многих людей
- приемлемый тех. стек в ПРОМе
- есть компетентные люди
- реалистичные сроки выполнения
- гибридный формат работы. Достаточно гибкий график. Спортзал/сауна. Доступная столовая
- хороший уровень компенсации
- приемлемый тех. стек в ПРОМе
- есть компетентные люди
- реалистичные сроки выполнения
- гибридный формат работы. Достаточно гибкий график. Спортзал/сауна. Доступная столовая
- хороший уровень компенсации
Что можно было бы улучшить
- безопасность могла бы быть более сбалансирована с интересами самого производства. Речь о порядке величины или более падении производительности
- внутренние отделы могли бы быть менее бюрократичными, более клиентоориентироваными
- больше соответствия между решениями и ответственностью. Отвечать должен тот кто принимает решения
- в целом хотелось бы меньше поиска крайних и больше наладки/выстраивания устойчивых и эффективных процессов разработки
- формировать команды (одна общая цель--выгода клиенту), а не просто рабочие группы (каждый за себя)
- более гибкие процессы разработки
- больше автономии разработчикам в определении процесса разработки
- хотелось бы менее иерархичную, более эгалитарную культуру внутри команды. К примеру, меньше обязательных встреч, интересных только начальству
- меньше "водопадных" односторонних сверху-вниз многомесячных процессов, больше коротких итеративных шагов/задач недельного масштаба
- меньше геройства при решении самосозданных проблем, больше опоры на общепринятые практики разработки
- больше интеллектуальной скромности (все ошибаются или что-то не знают, не стыдно ошибиться, стыдно не признаться)
- меньше практик, которые "job security" повышают: могло бы быть меньше недокументированных предположениях о коде, кол-во unit-тестов отличное от нуля, меньше богоподобных "manager" классов, которые делают всё, имея огромное состояния (практически эквивалент изменяемых глобальных переменных), больше объектов с явно очерченной тестируемой ответственностью. Меньше сложного неявного/недокументированного поведения размазанного между разными методами, классами, модулями и даже разными проектами в разных репозиториях! Больше практик, которые делают отдельного программиста redundant, например: документировать неявные предположения и/или создавать тесты их проверяющие. Явно бюджетировать задачи на поддержание скорости разработки
- больше фокуса/приоритета на фактической/измеримой пользе для клиента, а не внутренние бюрократические правила.
Список льгот
- внутренние отделы могли бы быть менее бюрократичными, более клиентоориентироваными
- больше соответствия между решениями и ответственностью. Отвечать должен тот кто принимает решения
- в целом хотелось бы меньше поиска крайних и больше наладки/выстраивания устойчивых и эффективных процессов разработки
- формировать команды (одна общая цель--выгода клиенту), а не просто рабочие группы (каждый за себя)
- более гибкие процессы разработки
- больше автономии разработчикам в определении процесса разработки
- хотелось бы менее иерархичную, более эгалитарную культуру внутри команды. К примеру, меньше обязательных встреч, интересных только начальству
- меньше "водопадных" односторонних сверху-вниз многомесячных процессов, больше коротких итеративных шагов/задач недельного масштаба
- меньше геройства при решении самосозданных проблем, больше опоры на общепринятые практики разработки
- больше интеллектуальной скромности (все ошибаются или что-то не знают, не стыдно ошибиться, стыдно не признаться)
- меньше практик, которые "job security" повышают: могло бы быть меньше недокументированных предположениях о коде, кол-во unit-тестов отличное от нуля, меньше богоподобных "manager" классов, которые делают всё, имея огромное состояния (практически эквивалент изменяемых глобальных переменных), больше объектов с явно очерченной тестируемой ответственностью. Меньше сложного неявного/недокументированного поведения размазанного между разными методами, классами, модулями и даже разными проектами в разных репозиториях! Больше практик, которые делают отдельного программиста redundant, например: документировать неявные предположения и/или создавать тесты их проверяющие. Явно бюджетировать задачи на поддержание скорости разработки
- больше фокуса/приоритета на фактической/измеримой пользе для клиента, а не внутренние бюрократические правила.
Backend Developer
Июнь 2022
Что мне нравится в работодателе
Очень хороший работодатель
Что можно было бы улучшить
Уменьшить число встреч
Список льгот
Самые высокие зарплаты в СБЕР
Популярные компании
Похожие компании в отрасли
Информация о СБЕР
О корпоративной культуре в компанииСайт: https://rabota.sber.ru/
Категория: Финансовый сектор