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

Рекомендую прочитать вот эту статью. В ней ведущий рекрутер ЕПАМа Илия Чукмарова приводит свой перечень из 50 возможных вопросов. 

Мне же кажется, что 50 вопросов задавать не надо, а надо поинтересоваться следующим:

В связи с чем открыта вакансия? Это новая должность или у меня есть предшественник? Почему он ушёл? 

Хороший ответ — что это новая вакансия, открытая в связи с ростом и развитием компании. Если же есть предшественник, вам имеет смысл покопать, вычислить, как его зовут, связаться с ним в линкадине и спросить его версию событий. Я как-то раз проводил в линке опрос, нормально ли такое поведение, большинство проголосовало, что вполне нормально. 

Расскажите о составе, численности и квалификации команды.

Как однажды сказал один гендиректор одному арт-директору: «Теперь твой инструмент не рисовальная программа, а дизайнеры». Основной инструмент прожект-менеджера не эксель и не майрософт прожект, а его люди. Будет неприятно, устроившись на работу, узнать, что в данной компании, к примеру, принципиально нет тестировщиков. 

Как поставлено тестирование?

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

Сколько проектов может быть в одновременном производстве?

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

Какие существуют формы отчётности? Надо ли логировать время и если надо, насколько подробно?

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

Как долго продолжается испытательный срок? 

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

Кто занимается договорной работой по проектам? 

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

В чём общаетесь, какой у вас таск трекер?

Чаще всего, это слак для внутреннего общения и телеграм для переговоров с заказчиком. Иногда встречаются Тимс или Дискорд. В качестве таск-трекера сейчас почти повсеместно джира. 

Как будем оформлять отношения?

Лучше избегать компаний с «чёрной» схемой, когда вы никак не оформляетесь, он несёт риск того, что в случае прекращения отношений, вас кинут на последнюю зарплату. Вариант с самозанятостью (при компенсации работодателем налога, конечно) более предпочтительней. Серьёзные ребята трудоустраивают по ТК, это сложнее, так как придётся обменяться бумажными документами, зато даёт некоторую надежду на пенсию в старости. 

Во сколько фактически начинается рабочий день? 

Если вы жаворонок или живёте в восточных широтах, этот вопрос можно не задавать, но если необходимость ежедневно просыпаться в 8 утра, чтобы посетить дейлик, для вас мучительна, лучше узнать об этом заранее. Я стараюсь задать этот вопрос даже не на собеседовании с руководителем, а на скрининге. 

Как у вас организованы продажи?

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

Как вы определите, хорошо я работаю или плохо? 

Очень крутой, я бы сказал, сениорский вопрос. Хороший знак — наличие и зафиксированность смартовых целей на испытательный срок. KPI на пиэма повесить трудно. «Решим по ощущениям» — таких компаний лучше избегать.

 

Ранее я публиковал посты с типовыми вопросами для собеседования на менеджера проектов и бизнес-аналитика. Сегодня хотелось бы поделиться минимумом теоретических знаний для собеседования на технического менеджера проектов. 

Что такое DNS?

Domain Name System — это технология, которая позволяет браузеру вроде Firefox, Chrome или Edge найти запрошенный пользователем сайт по его имени. Если быть точным клинически, эта служба позволяет сопоставлять IP-адрес сервера с доменным именем. 

Каждому имени сайта соответствует набор цифр формата 000.000.000.000. Этот набор называется IP-адресом, примером реального IP-адреса является 192.168.0.154 или 203.113.89.134. Когда пользователь вводит в адресной строке браузера имя сайта, например google.com, компьютер запрашивает IP-адрес этого сайта на специальном DNS-сервере и после получения корректного ответа открывает сам сайт.

Вопрос со звёздочкой. Как происходит сопоставление IP-адреса и сайта, если на одном сервере несколько сайтов?

DNS-серверы отвечают за то, чтобы несколько доменов вели на IP-адрес, а веб-сервер с помощью механизма виртуальных хостов распределяет к какому из сайтов.

Теперь детали, как это работает. В частности, протокол HTTP 1.1 включает в себя заголовок, называемый «host:», который указывает, к какому веб-сайту на конкретном сервере клиент пытается получить доступ.

Таким образом, если snoopy.net и woodstock.org совместно используют 192.0.32.10 и ваш браузер пытается получить контент из http://snoopy.net/doghouse конкретного http-запроса, он будет выглядеть так:

GET /doghouse HTTP/1.1
Host: snoopy.net

Если желаемым URL является http://woodstock.org/seeds запрос будет выглядеть

GET /seeds HTTP/1.1
Host: woodstock.org

В обоих случаях между вашим компьютером и портом 80 сервера будет TCP-сокет. Сервер будет знать, как получить содержимое из /var/www/snoopy.net или /var/www/woodstock.org/ на основе заголовка Host.

Были бы другие заголовки для файлов cookie и другие вещи, такие как тип браузера и разрешенный контент, но именно заголовок «Host» — это то, что позволяет веб-серверу знать, какой виртуальный веб-сайт желателен.

Что такое кэш?

Кэш — это память с большей скоростью доступа, предназначенная для ускорения обращения к данным, содержащимся постоянно в памяти с меньшей скоростью доступа («основная память»). Кэширование применяется ЦПУ, жёсткими дисками, браузерами, веб-серверами, службами DNS и WINS.

Вопрос со звёздочкой. Какие уровни кеша существуют в вебе? 

Есть пять уровней кэша:

Клиентские

Ускорение получения веб-контента от веб-сайтов (браузеры или устройства)

DNS

Определение IP-адреса для домена

Интернет

Ускорение получения веб-контента от серверов веб-приложений Управление веб-сеансами (на стороне сервера)

Приложение

Повышение производительности приложений и ускорение доступа к данным

База данных

Сокращение задержек, связанных с запросами к базе данных

Что такое https?

HTTPS (аббр. от англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.

Протокол был разработан компанией Netscape Communications для браузера Netscape Navigator в 1994 году.

(далее…)

Ранее я писал, какие вопросы задают на собеседовании на project manager-а. Вот вопросы и ответы для бизнес-аналитика.

Какой основной инструмент бизнес-аналитика?

Единственный правильный ответ — критический ум. Перечисление программных продуктов, при помощи которых вы пишете требования, будет ошибочным.

Какие знаете методологии разработки?

Классический проектный подход (PMI), скрам, канбан. В принципе, этого достаточно.

Какие бывают требования?

Функциональные и нефункциональные. Функциональное требование описывает, что должна делать программная система, в то время как нефункциональные требования накладывают ограничения на то, как система будет это делать.

Также можно рассказать про уровни требований:

• бизнес-правила,
• бизнес-требования,
• пользовательские требования,
• требования к продукту.

Также можно рассказать про типы требований:

• ограничения,
• требования к графическим интерфейсам,
• требования к данным.

Какими свойствами обладают хорошие требования?

• завершённость,
• последовательность,
• правильность,
• абстрактность,
• осуществимость,
• измеримость,
• необходимость,
• прослеживаемость,
• однозначность.

Какие существуют методы сбора требований?

• интервью,
• анкетирование-опрос,
• фокус-группа,
• семинар,
• мозговой штурм,
• совещание,
• ролевая игра,
• обсервация,
• моделирование процессов,
• прототипирование,
• анализ вариантов использования,
• анализ интерфейсов.

Как строится процесс работы с требованиями?

Требования нужно:

• собрать,
• задокументировать,
• проанализировать,
• управлять ими.

(далее…)

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

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

Почему ушли с прошлого места работы?
Всех задолбавший вопрос, задаваемый на 100 % собеседований, честным ответом на который в 50 % случаев будет: «Зажали повышение зарплаты на сто долларов», и ещё в 50 % «Начальник — чудак». Однако есть нормы этикета, так отвечать нельзя, как и нельзя откровенно хаять предыдущее место работы, даже если оно было той ещё галерой. Если не можете придумать ничего корректного, скажите: «На этом месте работы я достиг своего потолка, дальнейшего развития не предвидится, а я хочу двигаться дальше»

Что будете делать, если поймёте, что не укладываетесь в сроки?
Правдивым ответом на этот вопрос было бы: «Нужно нормально оценивать и каждый раз после итерации вычислять ошибку, а для следующей итерации этим значением компенсировать оценку». Но от вас ждут: «Привлеку к проекту дополнительных людей». Как будто компании держат запасных программистов на этот случай.

Ещё на эту тему можно рассказать:

• Распараллелить всё, что можно, в частности, фронтенд и бэкенд можно делать одновременно. Легальный способ сжатия расписания, но вам лично придётся больше коммуницировать и координировать, плюс повышаются риски.
• Провести переоценку. Часто оценка делается до того, как детально проработаны все требования и её можно уменьшить с учётом новых знаний. Иногда подключение эксперта позволяет выявить участки, на которых менее опытный сотрудник решил перезаложиться.
• Урезать работы. Выкинуть ненужное, перенести его за пределы данного релиза.
• Урезать качество. Отказаться от некоторых видов тестирования. Не самый хороший путь, но это тоже метод.
• Привлечь в команду дополнительных специалистов того же уровня, что и имеющиеся или вообще, привлечь эксперта. Это увеличит стоимость проекта, но поможет сжать расписание. Однако нельзя забывать про закон убывающей предельной полезности.
• Сделать расписание с переработками. Запланировать больше часов в неделю, заставить сотрудников работать на выходных. Ведёт к выгоранию сотрудников и увольнениям. С переработками можно работать 3-4 недели, потом производительность упадёт. Если причина просрочки в изменениях, пришедших в середине проекта, можно отказаться от этих изменений.

Что будете делать, если за пару дней до релиза заказчик выкатил вам десяток новых фич, которые нужно сделать срочно и ВНЕЗАПНО?
В реальной ситуации заказчика нужно очень корректно и грамотно послать, но у HR-а записан в голове правильный ответ, который и нужно озвучить, а именно:

• Поговорить с заказчиком, выбрать самые важные, которые можно успеть.
• Подключить людей с другого проекта.
• Делегировать часть работы фрилансерам.

Разработчики оценили проект в 300 часов, а заказчик хочет, чтобы было 150.
Если с вами на реальном проекте приключится такая ситуация, нужно действовать так. Первым делом, нужно вместе со старшим разработчиком или аналитиком устроить созвон с заказчиком и уточнить требования. Есть вероятность, что разработчики не получили ответы на какие-то вопросы и перезаложились. Убрав неопределённость, можно оценку сократить. Если и после этого оценка не будет устраивать заказчика, возможно он возражает не против часов, а против рублей. Можно подключить коммерческого или генерального директора и выбить скидку в рублях, оставив оценку в покое.

Социально приемлемый ответ: «Надо посмотреть, что запланировали разработчики. Возможно, они хотят сделать сложную архитектуру, которая в данном случае абсолютно не нужна, а время съест много»

Что будете делать, если выяснится, что не успеваете протестировать?
В этой ситуации правдивый ответ совпадает с приемлемым для HR-а. «Посажу программистов тестировать вместе с тестировщиками, чтобы проверяли модули друг друга».

Чем хотите заниматься, какая работа вам интересна?
Ответ зависит от вакансии. Можно сказать: «Хочу делать качественные и востребованные потребителями продукты».

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

Ещё могут спросить, какой был ваш самый сложный проект, как справлялись со сложными заказчиками, приходилось ли нанимать людей, умеете ли писать ТЗ, какими системами трекинга задач владеете и проч. Тут никаких хитростей нет, просто ответы на эти вопросы нужно продумать заранее.