За уже прошедший год я успел поработал в трёх разных компаниях. А за последние месяца два в кои-то веки мне удалось неспеша пройти много разных собеседований, чтобы выбрать именно то место, в котором было бы максимально комфортно работать с возможностью дальнейшего роста. И для того, чтобы лучше готовиться к собеседованиям, я для себя фиксировал вопросы, которые чаще всего спрашивают.
Возможно, это поможет еще кому-нибудь лучше подготовиться.
Поэтому приготовьтесь, будет длинный пост.
Для себя я выделяю два типа собеседования:
- комфортная беседа с желанием произвести приятное и нужное впечатление друг на друга;
- допрос с пристрастием.
На первом типе собеседований интервьюер обычно спрашивает про релевантный опыт, в каких проектах принимал участие, как на практике применял навыки, какие действия надо предпринять в той или иной ситуации. В общем, всё то, что хочет видеть руководитель в своем будущем сотруднике. Такие собеседования обычно проходят в дружественной атмосфере.
Второй же тип предполагает, что соискателя будет собеседовать некая железная леди (или джентльмен) без чувств и эмоций. И на таком интервью необходимо показывать отличные теоретические знания, уверенное владение методологиями управления проектами, правильные решения предполагаемых кейсов. Практический опыт обычно отходит на второй план.
Поэтому разделю информацию в посте на две части: вопросы на знание теории и вопросы со свободным ответом: какие вопросы мне чаще всего задают и как я на них отвечаю. При этом подсвечу только ключевые и важные моменты.
Вопросы со свободным ответом.
Обычно у таких вопросов нет правильных или неправильных ответов. Собеседующий в первую очередь смотрит на то, каким путём идёт кандидат, как он думает и как отвечает в зависимости от контекста кейса. Кто-то полагает, что у менеджера проектов нет «графика работы», и он должен быть доступен 24/7, а у кого-то «у нас так не принято, нужно отдыхать во внерабочее время». Поэтому на один и тот же вопрос они ожидают услышать разные ответы. Я успел в свое время поработать и в тех, и в других компаниях.
В: Пятница вечер, приходит срочная задача, которую необходимо решить до понедельника. К сожалению, единственный разработчик, который может её выполнить, отказался от безвозмездной работы на выходных, а выписать денежную премию не позволяет бюджет проекта. К тому же, разработчик планирует посетить хоккейный матч его любимой команды. Ваши действия?
О: Зависит от контекста. Если задача не критичная и не принесёт для проекта репутационный или денежный ущерб, постараюсь перенести работы на понедельник. Если же такой возможности нет, то пойду таким путём:
- постараюсь выбить у руководства нематериальную премию (например, оплачиваемый отгул или согласовать покупку билетов на хоккейный матч на другую дату);
- если разработчик всё равно не готов тратить свои выходные на работу (что в принципе нормально), то пойду к CTO с просьбой найти сопоставимые ресурсы для выполнения задачи на выходных;
- если и такой вариант не пройдет, то всё же постараюсь договориться с клиентом/стейкхолдером о переносе работ на понедельник с дополнительными «плюшками» (например, сделать доп. объём задач)
В: Представьте ситуацию: суббота, на часах 21:00, звонит клиент и просит срочно что-то сделать по проекту. Ваши действия?
О: Пожалуй, это один из самых часто задаваемых вопросов. И тут есть над чем подумать и для кандидата, в зависимости от реакции на ответ. Обычно, я отвечаю так: всё зависит от контекста. Если с клиентом подписан SLA 24/7 и случилась аварийная ситуация, то постараюсь убедиться, что наша техподдержка/дежурный разработчик оперативно работают над устранением аварии. Если же такого договора нет, но с клиентом доверительные и дружеские отношения, и он очень важен для нашей компании - постараюсь помочь ему, чем смогу. В остальных случаях попрошу клиента подождать до понедельника, пообещав сделать всё, что требуется, но в рамках рабочих часов.
Если интервьюер начнет тонко намекать на то, что клиент всегда прав и нужно быть на связи 24/7, то подумайте - готовы ли вы устраиваться в такую компанию и тратить внерабочее время на решение рабочих моментов. В начале своей карьеры я так и делал ради опыта и прокачки скиллов, не обращая внимания на переработки.
В: Представьте ситуацию: команда работает над вашим проектом, есть определенные дедлайны, но срочно потребовалось подключить часть ваших разработчиков на другой проект, к другому менеджеру. Ваши действия?
О: Любимый вопрос на собеседованиях в веб-студиях. Большой поток проектов и частые переключения команд между проектами. Обычно, на такой вопрос я отвечаю так: в первую очередь обсужу с другим менеджером, насколько важно для него переключение моей команды на его задачу. Если для моего проекта не будет критично (а обычно я закладываю дополнительные бюджет и сроки на такие случаи), то поделюсь ресурсами — так как в такой ситуации могу оказаться я, и другой менеджер также cможет меня выручить. Если же переключение может оказать критическое значение для моего проекта — буду поднимать вопрос до руководителя/PMO, так как он владеет полной информацией по приоритетам проектов в отделе, и буду полагаться на его решение.
В: Представьте ситуацию, один из разработчиков в вашей команде не вписывается в сроки, тратит на задачи гораздо больше времени, чем сам оценивает, из-за этого иногда подводит команду тем, что его задача блокирует другую. Что будете предпринимать?
О: В первую очередь, я постараюсь обсудить с разработчиком тет-а-тет, в чем именно проблема. Если это временное затруднение, вызванное событием из личной жизни - постараюсь поддержать его и в дальнейшем иметь ввиду эту временную особенность при планировании задач. Если это систематическая проблема - также лично обсужу с разработчиком, возможно, он уделяет лишнее время на написание идеального кода, глубокое тестирование, написание излишних логов и т.д. Постараюсь донести до него, что иногда стоит выпустить неидеальную фичу с точки зрения чистоты кода, но уложиться в срок, тем самым влезть немного в технический долг. Если и это не помогает со временем — подсвечу ситуацию CTO или тимлиду с просьбой помочь в решении этой проблемы (чаще ревьюить его код, давая обратную связь, и т.д.), и уже в крайнем случае буду просить замену на проект.
В: Чем вы обычно пользуетесь для тайм-менеджмента?
О: Обычно использую матрицу Эйзенхауэра, она помогает определить, какие задачи необходимо сделать в первую очередь. Она состоит из двух осей — «важность» и «срочность». Сперва выполняются задачи важные и срочные, потом важные, но не срочные, и только потом уже срочные, но не важные, и не важные и не срочные. Также помогает упорядочить рутину GTD - Getting things done. Эта техника позволяет не держать всё в голове, фиксировать все задачи и раскидывать приоритеты по ним. Для этого я пользуюсь обычным блокнотом с ручкой, так как это быстрее и эффективней лично для меня, нежели открывать каждый раз приложение в телефоне или блокнот с ноутбука.
Теоретические вопросы.
В: В чем различия между гибкими и негибкими методологиями управления проектами? В чем отличия и особенности разработки по водопаду, scrum и kanban?
О: Теории в интернете по этой теме полно, поэтому раскрывать полностью вопрос не буду. А приведу в пример одну интересную аналогию, которую я иногда говорю на собеседованиях.
Водопад (Waterfall) — это как междугородний рейсовый автобус только с одной остановкой - конечной.
Scrum — это как городской автобус, с определенным маршрутом и частыми остановками (спринты по 2-3 недели).
Kanban — это как небольшая маршрутка, иногда ты можешь попросить остановку по требованию в любом месте, а бывает и водитель проедет дворами, пропустив пару остановок, если выходящих пассажиров на них нет.
В: Что такое «железный треугольник»?
О: Этот вопрос застал меня врасплох на одном из этапов собеседования в Прагу. Почему? Мне до этого ни разу не задавали вопрос именно в такой интерпретации, и я честно ответил, что не знаю. На что «железная леди» удивлённо сказала, что это же самые основы управления проектами! И такое бывает. На вопрос, я конечно, ответил, применив дедукцию (всплыло в подсознании термин «тройственная ограниченность», подумал, что именно это и есть железный треугольник). В двух словах — железный треугольник показывает взаимосвязь между его сторонами - бюджет, объём задач, время. Железный же он называется из-за того, что меняя одну из его «сторон» - это обязательно приведёт к изменению и другие стороны. Увеличивается объём задач? Значит увеличивается время и бюджет и т.д.
В: Какие стратегии управления рисками обычно используются?
О: Перед стартом проекта (и после каждого этапа) обычно обсуждаем с командой и фиксируем, какие есть риски и насколько сильно они могут повлиять на проект. Можно подготовить матрицу рисков, «вероятность-ущерб» и в зависимости от того, где расположен конкретный риск на матрице, принимать нужную стратегию. Прибегну опять к любимой аналогии, которую часто говорю на собеседованиях:
Есть кейс - утром ударил сильный мороз, а Петя не успел поставить зимнюю резину. На работу ехать надо, но есть риск повредить машину, а самому попасть в больницу. Можно применить разные стратегии по управлению этого риска:
- Делегируем риски: если Петя считает, что угрозы для здоровья нет, но за возможный ремонт платить много нет желания, можно делегировать этот риск страховой компании и оформить нужный полис.
- Снижаем риски: Петя может поставить цепи на колёса, как основной план, чтобы доехать до работы, но всё же нужно иметь при себе номер такси, как запасной вариант.
- Принимаем риски: сегодня у Пети очень важное совещание на работе, при этом ехать не так далеко, да и трафик в городе сегодня небольшой, поэтому можно просто принять незначительные риски и поехать на работу, ничего не предприняв.
- Отказываемся от затеянного: пожалуй, риски для Пети сегодня слишком велики, поэтому он просто останется дома, взяв отгул.
В: Как можно приоритизировать бэклог продукта?
О: Чаще всего использовал метод приоритизации RICE:
Reach - охват фичи;
Impact - влияние, которое окажет фича на продукт;
Confidence — уверенность в оценке охвата, влияния и трудозатрат;
Effort — трудозатраты на фичу;
Для того, чтобы получить оценку каждой фичи, чтобы отсортировать по ней бэклог необходимо: Score = (R*I*C)/E
В: Критический путь проекта - что это?
О: Критический путь — это путь, который проходит проект, состоящий из связанных между собой критически важных задач. Обычно они идут друг за другом. Например, подготовка документации → дизайн → верстка → разработка. Задержка одного из этапов на неделю приведет к задержке следующего и как итог - всего проекта на неделю. В этом случае при планировании необходимо просчитывать риски и создавать резерв по срокам, деньгам, ресурсам.
Бонусные вопросы.
Если же вы претендуете на позицию именно технического менеджера проекта (а в последних трёх местах работы я занимал именно эту должность), то на собеседованиях меня обычно спрашивали еще эти вопросы:
- что такое JSON/XML;
- что такое SQL;
- что такое IP-адрес;
- для чего нужен балансировщик и nginx;
- может ли одному доменному имени соответствовать несколько IP адресов;
- может ли одному IP соответствовать несколько доменных имен;
- что такое монолитная и микросервисная архитектура, их плюсы и минусы;
- коды возврата веб-сервера и что они означают: код 200, 301, 404, 403;
- что такое API;
- как работает браузер;
- что такое CDN и для чего он нужен;
- что такое DNS и для чего он нужен;
- для чего нужен маршрутизатор;
- что такое VPN;
- что такое cron и для чего он нужен.
P.S. телеграм https://t.me/jukka_white