Рассказываем о проекте и своих решениях
Обсуждение проекта проверяет, понимаете ли вы свои решения. Подготовим рассказ о «Учебной библиотеке» так, чтобы собеседник мог проследить путь от задачи до проверки. Общие утверждения о современных технологиях здесь менее полезны, чем конкретное действие.
Пять опор рассказа
Запишем задачу, исходные данные, решение, проверку и ограничение. Для Анны задача — выбор материалов по названию. Данные — небольшой локальный список. Решение — фильтр на странице. Проверка — сценарии существующего и неизвестного названия, пустого запроса и очистки. Ограничение — отсутствие серверного поиска.
Не выдавайте этот список за фактически выполненные проверки своего проекта. В учебном примере это структура, которую нужно заполнить наблюдениями вашей работы. Если проверка выявила ошибку, расскажите и о ней: обнаружение проблемы является частью процесса.
Короткий рассказ может начинаться так: «Нужно было искать карточки без перехода на другую страницу. Я оставила исходный список и вычисляла видимые элементы по введённой строке. Для отсутствующего совпадения добавила сообщение. После очистки поле должно возвращать весь каталог».
Теперь у собеседника есть основания спросить, как обрабатывается регистр, что означает пустая строка и не теряются ли исходные данные. Это содержательные вопросы о механизме.
Почему выбран этот вариант
Назовите одну рассмотренную альтернативу. Например, поиск через сервер. Для небольшого учебного локального каталога Анна выбрала фильтрацию в браузере, потому что исходные данные уже находятся на странице. Но этот выбор не следует переносить на любой большой каталог.
Объяснение должно зависеть от условий. «Так делают все» не показывает рассуждение. «При данном объёме и учебной цели не понадобился отдельный сервер» связывает решение с границей проекта.
Если решение взято из урока, укажите происхождение и свою модификацию. Вопрос не в том, использовали ли вы внешние материалы, а понимаете ли результат и можете ли объяснить изменения.
Демонстрация одного сценария
Не открывайте сразу все вкладки и файлы. Покажите каталог, введите существующее название, затем неизвестное, затем очистите поле. После этого перейдите к месту реализации, если формат встречи предполагает код.
Если демонстрация ломается, остановитесь и разделите наблюдение и гипотезу. «После ввода список не изменился» — наблюдение. «Наверное, проблема события» — гипотеза, которую нужно проверить. Не скрывайте ошибку быстрым переключением на скриншот успешного состояния.
Для дизайнера демонстрация будет проходить по прототипу, для QA — по шагам воспроизведения, для SEO — по данным диагностики. Структура рассказа сохраняется: задача, действие, наблюдение и предел вывода.
Изменение условия во время разговора
Предположим, собеседник спрашивает, что изменится, если в каталоге станет намного больше карточек. Не нужно сразу обещать, что существующий фильтр работает при любом масштабе. Сначала уточните, какие ограничения имеются в виду: объём передаваемых данных, время ответа, устройство пользователя или обновление записей.
Анна может объяснить, что её локальный пример не даёт измерений большой нагрузки. Дальше она предлагает исследовать объём данных и наблюдаемое поведение, а после этого выбирать между сохранением текущего подхода и серверным поиском. Это рассуждение по условиям, а не попытка угадать самое модное решение.
Другой вопрос меняет качество сопоставления: теперь нужно искать с учётом опечаток. Существующая подстрока не решает такую задачу. Назовите отличие и новые требования. Не выдавайте простое игнорирование регистра за обработку всех опечаток: это разные механизмы.
Такие уточнения помогают показать границу знания. Хороший ответ может быть незавершённым: «Я не реализовывала этот вариант; понимаю, какое требование добавляется, и сначала проверила бы такие условия». Если после этого разрешают пользоваться документацией, найдите нужный механизм и объясните связь с задачей.
Неуспешное решение как часть кейса
Подготовьте один пример, где первая попытка оказалась неудобной или неправильной. Для учебного каталога это может быть потеря исходного списка после фильтрации. Историю нужно брать из своей реальной работы; вымышленный эпизод Анны служит только моделью разбора.
Рассказ строится вокруг наблюдения: после очистки запроса карточки не вернулись. Затем объясняется гипотеза, проверка причины и изменение. Если причину не удалось подтвердить, так и скажите. Нельзя превращать догадку в установленный факт только ради плавного рассказа.
Собеседнику важно видеть, как вы уменьшали неопределённость. «Переписала всё, и заработало» не раскрывает механизм. «Сравнила исходный список и видимые элементы, обнаружила изменение исходных данных, разделила их роли» даёт предмет для технического обсуждения — когда именно такая причина была проверена в вашем проекте.
Отдельно отметьте, что осталось после исправления: новый сценарий проверки, пояснение в README или более ясная структура. Это показывает, как опыт влияет на следующий шаг. Не приписывайте небольшой правке улучшение выручки и скорости, если таких данных нет.
В репетиции попросите слушателя изменить одно условие проекта и задать вопрос о первой неудачной попытке. Ваша цель — сохранить связное объяснение, а не выиграть спор. Если для ответа постоянно нужны новые неподтверждённые факты, уточните границы кейса до встречи.
Проверка личного вклада
Попросите знакомого после рассказа назвать ваше решение и его ограничение. Если он слышит только название стека, добавьте объяснение механизма. Если считает, что вы делали всю систему, хотя работали над одной частью, уточните вклад.
Результат урока — рассказ, который можно раскрыть на разной глубине. Он не заменяет техническую проверку навыков, но делает обсуждение прозрачным: собеседник видит, что именно вы знаете и где потребуется дальнейшее обучение.