Intellias

от 1500 специалистов
Киев, Харьков, Львов, Одесса, Ивано-Франковск, Краков (Польша)

26 января 2020 5:47

Мартынюк Игорь, Sr. Android developer с 2019 года

Поработал в компании что-то около полу-года. Есть позитивные моменты. Но в целом — ни на одном проекте я еще так не выгорал. Ушел месяц на то, чтобы отделаться от рвотного рефлекса при виде кода на новом месте.

История следующая. Есть крупный проект. С огромным БЭ и несколькими параллельными ФЭ на вэб\мобайл. Одно приложение уже ведется другой командой, другое начинаем с ноля вдвоем с напарником(далее условно Вован).
Начали. Обсудили архитектуру, разбили задачи. Работаем. Неделю работаем, две, месяц. Вроде порядок. Вован толковый. Все успеваем. Немного локтями толкаемся вдвоем, но в целом все хорошо.
Аутстаф уходит. Вована заберают на саппорт параллельной приложухи, но обещают вернуть. Ну ок. А че делать...
Вместо Вована, на проект приводят еще троих девов(далее условно Андрюха и два... Валентина). Андрюху с Валентинами, как андроид дэвов, с какого-то перепугу собеседует iOS разработчик. Все трое не имеют опыта с принятым архитектурным подходом и используемыми либами. И тут начинается жесть. 1\4 рабочего дня уходит на ревью, 1\2 — на попыки объяснить почему императивный код реактивными инструментами — это как-то неок и почему писать 1 приложение используя разные подходы и решения — хреновая затея, 1\4 + личное время на код собсно.
Замечание: «зачем 4 человека на проекте, где 2м то работы не всегда хватает» было успешно проигнорированно.
Когда стало очевидно , что распределение дэвов 5\1 на двух проектах(Вован все еще трудится на параллельной приложухе) — спросили «кого тебе оставить?». Попросил оставить Андрюху, несколько раз замеченного за чтением доков по RxJava, статей по CleanArch, VIPER и прочей нафиг не нужной ерунде. Оставили двух Валентинов. Андрюху забрали. Спасибо блин. Это че флэш-моб? Нахрена было спрашивать?
После ответов в стиле «Да иди ты в ж... будут баги — будем разбераться» на мои «не заливайте этого. Будут баги. Вот здесь и здесь», или «это не я писал. это на стековерфлоу было. Нет не читал. Так скопировал» — понял, что так мы каши не сварим. Стал орать менеджерам. Последние благополучно имели меня ввиду на протяжении месяца-двух. После чего пообещали «технческую экспертизу». Ну думаю, ладно. Ждем экспертизу тогда.
Когда стали всплывать баги, многие из которых были описаны в пулл-реквестах(да-да, тех самых, которые «будем фиксить») — жесть превратилась в АД. Овертаймы вплоть до ночных смен, написание костылей на костылях потому, что по-человечески отрефакторить уже времени нет и прочие радости.
В итоге менеджмент заявил мне, мол я плохо спроектировал архитектуру и мне пора бы уходить. Мое возражение «А ничего, что ее никто не придерживался и я вот уже два месяца бью тревогу двум ПМ-ам?» опять же никому не показалось весомым.

По итогу у меня остался один вопрос: зачем на собеседовании, львовский дэв гонял меня по SOLID, шаблонам проектирования, реактивной парадигме и т.д, если по факту вам этого всего не нужно. Почему было просто не спросить меня «как пишется stackoverflow»?

На out source конторах другой проект — это по сути другая контора. И говорить однозначно, мол на intellias все плохо я не могу. Но есть риск вот в эту женю, потратить массу личного времени, и три массы нервов, пытаясь эту женю как-то спасать, а потом оказаться крайним. Такие дела...


LinkedIn

2 комментария

Подписаться на комментарииОтписаться от комментариев

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

Игорь, добрый день!
Благодарим вас за детальный отзыв касательно этого проекта. Мы ценим вашу обратную связь -— она поможет улучшить наши внутренние рабочие процессы, а также предоставляемые заказчикам сервисы. Мы обязательно примем во внимание проблемы в коммуникации с менеджментом проекта, на которые вы указали.

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

Большое количество разработчиков на данном проекте было необходимо для введения новых сотрудников в специфику целой серии проектов. Через 1 месяц часть из них была переведена на другие проекты этой серии, чтобы сбалансировать нагрузку. При этом было учтено мнение и желание самих ребят уйти или остаться в этой команде.

Что касается выбранного архитектурного решения, к сожалению, оно действительно не было оптимальным и вызвало целый ряд проблем на проекте, в том числе переработки, о которых вы написали. Хотя изначально объем работ и сроки проекта не подразумевали такой нагрузки.

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

Поддержали: Oleksandr Reshetnikov

Всегда к вашим услугам.

Значит либо я вру, либо соврали мне, отвечая на вопрос: «кто его вообще собеседовал?!».
Кандидатов не просто так собеседуют сотрудники, непосредственно работающие над проектом. Знать все невозможно, а собеседование — это не екзамен. На собеседовании нужно выяснить, будет ли человек эффективен на проекте. А для этого нужно понимать, какие технологии, шаблоны, парадигмы используются, чтобы банально знать, о чем спрашивать.

Что касается выбранного решения.. Интересно, как вы это определили, если тех экспертизу так и не провели? Извините, но мнение «senior» дэвов, которые игнорируют ссылки на SOLID\OOD, шаблоны проектирования под предлогом «я ничего не понял», утверждают что MVP «нужен не для чего» и не понимают, чем реактивное программирование отличается от императивного, для меня не аргумент. И оценивать архитектурный подход, ссылаясь на проект, где 4 разработчика писали каждый по-своему, как минимум некомпетентно с вашей стороны.

Конечно с моей стороны были приняты неудачные решения. Были ошибки. Я не пытаюсь этого отрицать. Хоть они и не принимались мной единолично, а обсуждались с другими разработчиками, тем не менее предложены были мной. Они были описаны и занесены в тех. долг. Но все же есть разница между неоптимальным тех. решением и пофигизмом, с которым руководство относилось к замечаниям и предупреждениям.