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