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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот вам ещё англоязычный документ на эту же тему: