Как написать README проекта, который заметят на собеседовании: питч, STAR и разбор ошибок

Разговор на техническом собеседовании часто ломается на одной фразе: «Крутой проект, но не совсем понятно, какую задачу он решает». До этого интервьюер полистал ссылки на 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%». Такую фразу запоминают и приносят на обсуждение кандидата.

Четыре ловушки

Чек-лист перед отправкой резюме

1. Первые три строки отвечают на вопросы: какую задачу решали, что сделали, что получилось.
2. В блоке Result есть хотя бы одна цифра. Если метрики нет — годится время, сэкономленное на ручной операции, или количество людей, которые протестировали сборку.
3. Ссылка на живое демо открывается в один клик и не ведёт на пустой экран.
4. Action объясняет хотя бы одно решение через ограничение: почему отказались от бэкенда, почему ограничили размер бандла, почему выбрали такую схему хранения.
5. Инструкция по запуску никуда не делась — просто переехала вниз.

Когда схема не подходит

Если проект — библиотека для других разработчиков, акцент смещается. Читателю в первую очередь нужны сигнатуры, примеры вызовов и совместимость версий, а пользовательские истории там почти некуда вставить: питч ужимается до одной строки, STAR — до раздела с изменениями API.

Учебные задачи из туториала — todo-листы, клоны известных сервисов — от STAR тоже не выиграют. Своей проблемы в них нет, измеримого результата тоже. Такие репозитории лучше не вытаскивать в резюме или честно подписывать как практику по курсу.

И последнее: цифры должны быть настоящими. 22% из самоотчётов однокурсников — это 22% из самоотчётов, а не результат лабораторного эксперимента, и в README так и написано. Придуманная метрика разваливается на первом же уточняющем вопросе, а вопрос про Impact-строку интервьюеры задают охотно.

Собеседование — это разговор, в котором хорошо пересказывается только то, что хорошо рассказано. Если через час после просмотра вашего репозитория человек может повторить его суть своими словами, README получился.