Как рассказать о дипломном проекте на собеседовании: скрипт на две минуты

Первый технический вопрос на входном собеседовании в сервисных IT-компаниях почти всегда один и тот же: «Расскажите про ваш дипломный проект». Панели TCS Ninja и Digital задают его первым делом, интервьюеры Infosys, Wipro, Accenture, Cognizant и Capgemini — в первые пять минут разговора. Стартапы спрашивают потому, что это единственная настоящая инженерия, которую вы к этому моменту сделали.

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

Что панель на самом деле проверяет

Ей нет дела до вашего проекта как такового. Ей важно, что он говорит о вас:

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

Закроете эти четыре вещи — содержание подтянется само.

Скрипт на две минуты: шесть блоков

Шесть блоков примерно по двадцать секунд. Порядок один и тот же каждый раз.

1. Проблема в одном предложении (15 секунд). У кого она была и во что обходилась. «В хостеле на шестьсот студентов заявки на ремонт собирали в чате WhatsApp: ничего не отслеживалось, никто не знал, закрыта заявка или нет».
2. Что вы построили, одним предложением (15 секунд). «Мы сделали веб-приложение: студент оставляет заявку, комендант назначает исполнителя, статус виден всем».
3. Ваша роль и команда (15 секунд). «Нас трое. Я делал бэкенд и базу, один человек — интерфейс на React, один — тестирование и развёртывание». Без «мы в основном».
4. Архитектура и стек (30 секунд). Фронтенд, бэкенд, база, хостинг — по предложению на каждый, с причиной выбора. «React на фронте, Node и Express на API, PostgreSQL: заявки, комнаты, персонал и история статусов явно связаны отношениями, нужны отчёты по блокам и категориям. Развёрнуто на одной облачной виртуалке, перед ней Nginx».
5. Самое трудное и как вы это решили (30 секунд). Здесь набираются баллы. Одна настоящая техническая сложность: медленный запрос, гонка состояний, переобучение модели, шум датчика. Симптом, найденная причина, исправление, способ проверки.
6. Результат и что бы изменили (15 секунд). Цифра, если есть («комендант закрывал заявки за два дня вместо девяти»), и одно честное улучшение («сделал бы ролевой доступ сразу, а не прикручивал в конце»).

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

Уточняющие вопросы, к которым стоит подготовиться

Сгруппируйте их по тому, что они проверяют, и держите по одному отточенному ответу на группу.

Принадлежность работы

• Какие части написали лично вы, а что взяли из библиотеки, туториала или сделал напарник?
• Если я открою репозиторий, какой файл читать первым, чтобы увидеть вашу работу?
• Что сделал научный руководитель?

Проектные решения

• Почему именно эта база данных? Что сломается при переезде на другую?
• Как устроена аутентификация, где хранятся пароли и в каком виде?
• Что произойдёт, если два пользователя сделают одно и то же действие одновременно?

Глубина реализации

• Разберите один API от начала до конца: запрос, валидация, обращение к базе, ответ.
• Какой запрос или функция в проекте самые сложные? Проведите по ним.
• Покажите, как данные идут от датчика (или формы, или датасета) до экрана.

Тесты, развёртывание, рефлексия

• Как вы это тестировали и что осталось непротестированным?
• Что сломалось в последнюю неделю перед демо и как вы это починили?
• Что бы сделали иначе, если бы начинали заново?

И совсем простой вопрос, который часто выбивает из колеи: проект ещё жив, он сейчас запущен?

Что спросят отдельно: веб, ML и IoT

Типовые уточнения сильно зависят от типа проекта.

Ошибки, которые стоят баллов

• Начинать со стека. «Мы использовали React, Node и MongoDB…» — раньше, чем интервьюер понял, что эта штука вообще делает. Сначала проблема, всегда.
• Говорить «мы» обо всём. Панели нужна ваша часть. «Я» — про свою работу, «мы» — про командные решения.
• Пересказывать аннотацию. Её писали для экзаменатора. Интервьюеру нужна история с одной трудной задачей внутри.
• Заявлять технологию, которую не защитите. Сказали «микросервисы» или «глубокое обучение» — следующий вопрос будет о них.
• Ни одной цифры. Пользователи, записи, время отклика, точность, сэкономленные дни. Даже приблизительные числа показывают, что вы что-то измеряли.
• Прятать провал. Панель доверяет тому, кто описывает поломку и починку, больше, чем тому, у кого всё прошло идеально.
• Уходить за время. Две минуты с сильным блоком про сложность дают больше уточняющих вопросов, чем шестиминутная экскурсия по проекту.

Как репетировать

Прочитать гайд — лёгкая половина. Трудная — сказать двухминутную версию вслух, под таймер, и выдержать восемь уточняющих без вечного «ну, типа».

1. Выпишите шесть блоков на одну страницу. Больше ничего.
2. Запишите себя на телефон. Слушайте, не начинаете ли со стека и не говорите ли «мы» там, где нужно «я».
3. Попросите друга задать десять уточняющих из списков выше — включая те, которые вы надеетесь, что пропустят.
4. Прогоните полный ответ три раза: первый с листом перед глазами, третий — без.

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