Разговор на техническом собеседовании часто ломается на одной фразе: «Крутой проект, но не совсем понятно, какую задачу он решает». До этого интервьюер полистал ссылки на GitHub, кивнул резюме — и пошёл к следующему пункту. Обидно, когда внутри лежат аккуратные тесты и внятная архитектура.
Проблема не в коде, а в подаче. Репозиторий не рассказывает историю, и читателю приходится самому догадываться, зачем всё это существует.
Почему первые тридцать секунд решают всё
Человек на другой стороне просматривает десятки репозиториев за вечер. У него есть работа, созвоны и ещё пять резюме в папке. Если за первые полминуты непонятно, что вы построили и какую боль это снимает, дальше он не пойдёт — даже если проект технически сильный.
Отсюда простой вывод: README работает как короткая презентация. Всё остальное — код, тесты, структура папок — проверяется потом и только у тех, кто задержался на первых строках.
Формула: питч из трёх строк плюс STAR
Схема, до которой я дошёл после нескольких провальных показов, состоит из двух блоков. Первый — питч в самом верху README. Второй — разбор по классической схеме STAR.
Elevator Pitch
Problem — одна строка про боль, которую вы заметили.
Solution — одна строка про то, что вы собрали в ответ.
Impact — одна строка с измеримым результатом: пользователи, сэкономленное время, прирост производительности.
Дальше идёт STAR, и здесь важна сдержанность. Не пересказ хронологии разработки, а четыре смысловых куска:
- Situation — контекст: масштаб задачи, ограничения по стеку, кто пользователь.
- Task — что именно вы взяли на себя. Две фразы, не больше.
- Action — два-три технических решения с обоснованием. Не список библиотек, а логика выбора: почему localStorage вместо бэкенда, зачем понадобился Hammer.js.
- Result — цифра плюс вывод, который вы сделали для себя.
До и после: одностраничный трекер расходов
Пример из личной практики — приложение для учёта трат, которое я показывал в портфолио.
Как выглядел README «до»
Название, стек, список фич, инструкция по запуску. React, Redux, Node, Express, MongoDB, CSS Modules. Из фич — добавить расход, посмотреть список, удалить запись, адаптивная вёрстка. Читается как спецификация из тикета: чтобы понять ценность, надо самому придумать, кому и зачем это нужно, а потом ещё поверить, что оно работает.
Как выглядит README «после»
Открывается тремя строками. Проблема: студенты с подработками не видят, куда утекают деньги за неделю. Решение: трекер, куда трата заносится меньше чем за десять секунд, с недельным графиком. Результат: больше тридцати однокурсников пользовались приложением месяц и по самоотчётам сократили импульсивные покупки на 22%.
Дальше — STAR. В Action видно логику решений: React с хуками и Chart.js уложились в бандл меньше 120 КБ gzip; данные легли в localStorage, поэтому бэкенд оказался не нужен; удаление свайпом сделали через Hammer.js; Jest и React Testing Library покрыли 85% логики компонентов. В Result — 30+ активных пользователей за четыре недели, средняя сессия две минуты и вывод про дизайн от ограничений: клиентское хранилище заставило вкладываться в интерфейс вместо лишних API.
Разница принципиальная. Читатель уходит с готовой мыслью, которую может пересказать коллеге: «Там трекер для студентов, который снизил импульсивные траты на 22%». Такую фразу запоминают и приносят на обсуждение кандидата.
Четыре ловушки
| Ловушка | Почему не работает | Что делать |
|---|---|---|
| Жаргон в первых строках: «Redux-saga middleware с async thunk» | Интервьюеру нужен результат, а не словарь технологий | Начать с проблемы и решения, технику убрать в Action |
| Простыня из фич на пол-экрана | История тонет в списке кнопок и тултипов | Оставить две-три фичи, которые прямо подкрепляют Impact |
| Нет цифр: «пользователям понравилось» | Субъективная оценка не отличается от «мне понравилось» | Добавить процент, сэкономленное время, отзыв или число участников теста |
| Нет ссылки на демо | Проверить нечего, доверие падает | Выложить сборку на Netlify, Vercel или GitHub Pages — это занимает минуты |
Чек-лист перед отправкой резюме
- Первые три строки отвечают на вопросы: какую задачу решали, что сделали, что получилось.
- В блоке Result есть хотя бы одна цифра. Если метрики нет — годится время, сэкономленное на ручной операции, или количество людей, которые протестировали сборку.
- Ссылка на живое демо открывается в один клик и не ведёт на пустой экран.
- Action объясняет хотя бы одно решение через ограничение: почему отказались от бэкенда, почему ограничили размер бандла, почему выбрали такую схему хранения.
- Инструкция по запуску никуда не делась — просто переехала вниз.
Когда схема не подходит
Если проект — библиотека для других разработчиков, акцент смещается. Читателю в первую очередь нужны сигнатуры, примеры вызовов и совместимость версий, а пользовательские истории там почти некуда вставить: питч ужимается до одной строки, STAR — до раздела с изменениями API.
Учебные задачи из туториала — todo-листы, клоны известных сервисов — от STAR тоже не выиграют. Своей проблемы в них нет, измеримого результата тоже. Такие репозитории лучше не вытаскивать в резюме или честно подписывать как практику по курсу.
И последнее: цифры должны быть настоящими. 22% из самоотчётов однокурсников — это 22% из самоотчётов, а не результат лабораторного эксперимента, и в README так и написано. Придуманная метрика разваливается на первом же уточняющем вопросе, а вопрос про Impact-строку интервьюеры задают охотно.
Собеседование — это разговор, в котором хорошо пересказывается только то, что хорошо рассказано. Если через час после просмотра вашего репозитория человек может повторить его суть своими словами, README получился.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.