Отзыв о работодателе «Torrow Technologies» Добавлен: 06.06.20 02:30
Другие названия: ЗАО Торроу Технолоджис
Сфера деятельности: Торговля: Компьютеры, комплектующие, ПО
Сайт: torrowtech.com
Страна: Россия
Адрес: Россия, г. Санкт-Петербург
Просмотры: 726
Всего отзывов: 8
Описание деятельности:
Должность: Разработчик
Дата начала работы: Сентябрь 2018 г.
Полезность отзыва: 5 - 4 = +1
Всего комментариев: 9
Положительные стороны компании
1. Возможность развиваться. Новейшие технологии. Пришёл в компанию, не понимая, что такое микросервис. Спустя почти два года уверенно могу сказать - всё что я знаю, знаю благодаря Torrow.
2. Нет непосредственного начальника. Задачи ставятся и оцениваются самостоятельно.
3. Дружная команда и ламповая атмосфера. Коллеги всегда помогут, если помощь нужна. Никто не ограничивает Вашу творческую фантазию. Пишите код грамотно, покрывайте функционал тестами и будет Вам счастье.
4. Руководство всегда идёт на встречу. Нужно поработать из дома? Взять день в счёт отпуска? - без проблем. Нигде ещё не встречал такого лояльного и сотрудникоориентированного руководства.
5. Офис рядом с парковой зоной. Захотел - вышел прогуляться и подышать свежим воздухом. Никто слова не скажет и не спросит - куда это ты там пошёл?
6. Гибкий график. Главное - качественно выполнить свою работу.
7. Большой процент покрытия тестами. Unit/Интеграционное тестирование/ CI/CD
Отрицательные стороны компании
1. Нет непосредственного руководителя. И для многих - это будет минусом, потому что важна дисциплинированность и осознанность. Важно правильно оценить задачи, декомпозировать их и шаг за шагом двигаться к намеченной цели.
2. Офис самый обычный, но техника - новейшая (мониторов два). Печеньки, кофемашина, кулеры, увлажнитель воздуха, кондиционер, вентилятор.
3. Соц. пакет в привычном понимании отсутствует.
4. Многие сотрудники не выдерживают темпа разработки и вынуждены покидать команду, что, возможно, для кого-то будет минусом.
5. Процесс разработки идёт медленно. Большое внимание уделяется качеству продукта, рефакторингу компонентов, которые потенциально могут стать узким местом системы. Часто приходится переписывать то, что работает. Для меня это не минус, а показатель ответственного подхода к делу и желания сделать стоящий продукт.
В случае несогласия🙅 у вас всегда есть возможность опровергнуть отзыв😡, добавив комментарий к нему💩. А если вы замечали те же нарушения работодателя🤦, то можно поддержать автора🙌.
Не собираешься осуждать, но при этом осуждаешь.
Л - логика.
И перестань употреблять токсичность, ты ее везде видишь. Как и врать - 3 сотрудника компании ходили на курсы по НЛП и ты в том числе.
А уж про манипулирование и "все плохие и неправильные" - такого я не писал.
7 из 12 сотрудников ушли только за полгода. Это факты. Как и 3 любителя НЛП.
Код ревью в виде пуллреквестов, которые закрывались без одобрения коллеги? На второй год работы закрывались даже красные пуллреквесты.
На том же доменном слое сама бизнес-логика не отделена от инфраструктурной логики(!).
Ты противопоставил себя большинство разработчиков, а не я. Так кому ты решил претензию в высокомерии выставить?
2. Очень "похоже" на меня. Ты отдал 70 тысяч НЛП-мастерам и не смог придумать ничего правдоподобнее?
3. Люди уходили сами, хотя выставляли это в переговорке, как увольнение. Причем здесь совет компании, если просто клали заявление? Как я это сделал в ноябре.
4. Уместно. Если большая часть компании работает внеурочно. Это факт.
Факт в том, что людям ставили претензию уход во время.
Отмазки в виде "люди сами виноваты" попахивает неадекватом.
5. Это не мои слова, я специально закавычил. Смешно, что ты их не узнал.
2. Хорошо! Спасибо за рекомендацию. Жаль только, что во время работы ты мне не давал такой обратной связи, а просто говорил другим, что вся разработка висит на тебе, а все остальные - плохие.
3. Не вижу смысла комментировать внутреннюю кухню компании, но скажу одно. Решается всё на совете компании. Никто никого не вынужает и не принужает ни к чему. Автор приводит множество примеров, но я не понимаю для чего. Кому и что ты хочешь доказать?
4. Понятие переработки не уместно. Даже если вы не закрыли спринт, но объяснили причину возникших сложностей, - никто Вас не поругает :).
5. Понятное дело, что руководство есть. Но правило: "Как он сказал, так и будет" выглядит как конкретная внутрення обида именно Anth G не только на руководство, но и на всю команду в целом. Обидно.
1. Никакого акцента на качестве не было изначально. По всему коду были сплошь и рядом god class с кучей обязанностей. Собственно, некоторые разработчики еще круче делали - god method с одним god test.
На код ревью забили уже давно, хотя оно и бессмысленно в таких условиях.
2. Если ты покрываешь все условия работы в интеграционных тестах, то это не интеграционные тесты и/или ты не знаешь даже терминологии. Почитай хотя бы основы в виде Майерса.
3. Никого не вынудили покинуть команду за темпов разработки - это уже откровенное вранье и цитирование НЛП-мастера. Фронт ушел, потому что ему продлили испыталку и из-за несовместимости с продакт-оунером, дизайнер тоже не стала терпеть продакта-оунера, аналитик ушла по этой же причине, другой аналитик ушла в том числе опять же из-за продакт-оунера.
Меня и еще одного фронта - "оптимизировали" во время карантина. Все это факты. Это за полгода. Очень странная текучка для такой маленькой компании.
4. Никакой свободы нет. Потому что на свободу нужно время, а его органически ни у кого из разработчиков нет из-за переработок.
5. Руководитель есть, он же продакт-оунер, "как он сказал, так я и делаю, даже спорить не хочу" - слова одного разработчика.
1. Многие сотрудники не выдерживают темпа разработки.
- Это означает, что у сотрудника должна быть высокая степень осознанности.
- Вы можете разработать функцию, написать пару unit тестов, написать один интеграционный тест (проверить, что вроде что-то работает) и выкатить это всё на dev-окружение.
- Это быстрый путь разработки, который привычен большинству программистов. А зачем покрывать всё? И так сойдёт! Только когда до этой функции доберутся другие разработчики, - там чёрт ногу сломит.
- А высокий темп разработки - это разработать функции в 4 микросервисах, в каждом мироксервисе покрыть ВСЕ условия работы этой функции unit тестами. В интеграционных тестах покрыть ВСЕ возможные варианты работы с данной функцией. Чтобы как только Ваша работа была закончена, её абсолютно спокойно мог брать другой разработчик и спокойно с ней взаимодействовать, не дёргая вас по типу - а я вот тут передал null, и по zipkin у меня ошибка null reference на сервере.
2. Процесс разработки идёт медленно с точки зрения получения конечного результата. Продукт развивается, поэтому фокус внимания может смещаться. Сначала хотели сконцентрироваться на ресторанном бизнесе, теперь на фитнес. Поэтому что-то может меняться. Что-то, возможно, придётся переделать. Но если вы горите идей, Вам нравится команда, и Вы хотите двигаться с этой командой вперёд, а не просто отсиживаете свою ЗП, то для меня это не минус, а показатель ответственного подхода к делу.
P.S. надеюсь стало понятнее, что я имел ввиду.
5. Процесс разработки идёт медленно
Не выдерживают медленного темпа?