Техническое собеседование на руководителя проектов, Twinby

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

Порядок общения был стандартным — 15 января написал рекрутерше, что увидел на канале Прожект Джобс эту самую вакансию, 16 пинганул, 17 она ответила, что рассмотрит обращение. 21 января договорились о скрининге, 23 января провели скрининг. 24 января запланировали техсобес, 27 января он состоялся и 31 я получил ответ, что компания выбрала другого кандидата. На мой вопрос, каких навыков не хватило, получил ответ, что всего хватило, просто выбрали другого кандидата. На что я ответил, что сделаю из этого собеса кейс в блоге, чтобы как-то отбить столько потраченного впустую времени.

Давайте разбираться. Напоминаю, что в постах такого типа всячески приветствуются комментарии о том, на какой вопрос я ответил неправильно и что на него стоило ответить по вашему мнению. Опущу неинтересные вопросы про мой фактический опыт, оставлю, по большей части кейсы, которые могут прилететь на интервью и вам.

UPD: Добавил комментарии Дениса Пешехонова о том, как выглядели бы ответы в реальной практике. Забавно и близко к правде :-)

Предположим, у нас есть штук пятьдесят задач в бэклоге. Кто с продуктовой точки зрения ими занимается?

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

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

— В бэклоге 50 задач, кто их приоритизирует?
— Продакт или представитель заказчика
— Заказчик говорит, что задачи одинаково важны без исключений
— Так не бывает, нужно определить приоритет
— Заказчик настаивает
— Хорошо, зададим очередь сами
... через два спринта
— Где задача номер 10? Почему ещё не сделано?
— Потому что очередь мы задали сами, и 10-я задача в конце очереди
— Заказчику нужно было уже сейчас, вы плохо справились, чем вы там занимаетесь вообще вместо работы

Как сматчить продуктовые хотелки и пожелания команды?

Разделять время итерации в пропорциях, например, 70-30 %. Мы знаем велосити команды, сколько стори поинтов она может сделать за спринт. И исходя из этого берём продуктовые и технические хотелки.

Например, у меня в практике была история, когда руководство очень хотело делать А/Б тесты, которые было сделать невозможно из-за того, что никак не могли забороть одну техническую задачу. Пришлось её вставлять в эти самые 30 % и пилить в течение нескольких итераций.

Я реально, на практике реализовывал такое разделение.

— Как учесть пожелания команды?
— Дать команде 30 % на разбор техдолга
...
— Руководитель звена узнал, что 30 % времени разработчики не делают бизнесовые фичи для заказчика, срочно переключаемся на фичи
— Но ведь техдолг...
— Техдолг и архитектура это задротство для гиков, а нужно дело делать
...

Какие метрики использовал, что собирал, на что опираешься?

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

Помимо перечисленных метрик, я практически во всех компаниях считал план/факт. Во сколько оценили задачи, сколько они реально заняли.

Пообещали продактам, что сделаете фичу за итерацию, но в середине итерации поняли, что не успеваете. Что делать?

Выяснить причины, почему не укладываемся. Самая частая причина — легаси. В одном месте правим, в другом расползается. Иногда недооценивается сложность задачи.

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

Разработчики могут назвать внутренние причины мне, может у них какой-то внутрикомандный конфликт, который я могу разрулить. Поработать с командой. Чаще всего это делается в рамках ретроспективы. Не реже двух раз в неделю собираюсь с техническими руководителями команды — тимлидом, техлидом.

— Почему не сделали фичу за итерацию?
— Потому что сроки, названные разработкой, не устроили руководство, и оно само задало втрое меньше

Расскажи о конфликте с сотрудниками. Какой был самый интересный, как решил?

У меня был младший пиэм, который плохо себя вёл, токсичил, оскорблял коллег из соседних департаментом, а кроме того, давал отрицательные результаты по план-факту. Однако руководство стояло на том, что уволить его мне не даст, он очень хорошо знает нашу линейку продуктов и поэтому ценен.

Я рекомендовал ему поработать на соседний продукт, в котором была не продуктово-заказная, а чисто продуктовая разработка, продукт зарабатывал, преимущественно, на продаже коробок и требования к план-факту не были такими серьёзными. Пиэм ушёл в соседний продукт, поработал там какое-то время, а потом сам уволился и проблема решилась сама собой.

У тебя есть команда бэкенда. Она делает бэкенд-часть, отдаёт в другие команды, и в какой-то момент ты обнаруживаешь, что копятся задачи на ревью. Что будешь делать?

— А правда, что ревью занимается один тимлид или техлид?

— Нет, неправда, сотрудники ревьюят друг друга по кругу.

— Возможно, проблема в технологии ревью, надо разобраться, как они ревьюят. Может быть, много времени занимает проверка и исправление оформления кода? Может быть, стоит внедрить линтеры? Выяснять, на что тратят время.

— Команда говорит, что с ревью всё в порядке, задачи просто не отдаются дальше, потому что тестирование загружено. Несколько тестировщиков прикреплены к команде бэкенда, Они всегда с ней.

— Идём к тестировщикам, выясняем, что с ними, хватает ли рук, хватает ли квалификации. Может быть, стоит добавить пару тестировщиков.

— Тестировщики говорят, что много возвратов. Мы делаем сборку, там 20 задач, 19 проверены, готовы, последняя на возврате. Не может продолжить тестирование. Возвратом называем ситуацию, когда проверили, там недоработка, вернули.

— Мысль такая. Самотестирование задач разработчиками. Ещё может быть такая история как несовпадение среды. Решается внедрением докера. Возможно, стоит подумать о том, как реализовать частичную передачу оттестированного кода, чтобы не ждать последнюю задачу.

— Почему ревью долгое?
— Задачи не идут дальше из-за задержки тестирования
— Почему тестирование долгое?
— Много возвратов
— Почему много возвратов? Может пусть разработчики сами себя тестируют?
— Им на это времени не дадут
— Тогда может автотесты?
— Некому писать

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

Мысль в том, что мобильщики и фронтендеры не должны дожидаться реализации бэками ручек. Они должны иметь возможность кодить на моковых данных. Предварительная договорённость о формате обмена, моковый сервер, кодим одновременно. Как только бэки заканчивают работу, нам останется только интегрировать. Это улучшит ТТМ.

— А что если бэки сначала обещают один формат обмена данными, а потом предоставляют всё совсем по-другому?

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

— Наняли системного аналитика, но бэк всё равно, пилит всё по своему.

— Есть подозрение, что системный аналитик просто молча пуляет в разрабов спецификацию. Реализовать демо требований и разбор их на очной встрече.

— Фронт ждёт бэк
— Делайте контракты заранее
— Техлида и архитектора нет, руководство считает, что он слишком дорогой и не особо нужный

Опубликовано

в

от


Подпишитесь на рассылку новых постов, чтобы их не пропускать:

Предыдущий пост
Разбираемся, как улучшить ретроспективу, внедрив фреймворк 4L и начав основывать…