Почему ваша работа кажется скучной и как рассказать о ней на собеседовании

Можно неделю распутывать проблему, а потом на собеседовании сказать: «небольшой багфикс». Часы расследований, неудобные вопросы, выбор между плохим и чуть менее плохим вариантом — исчезают. Остаётся название тикета, которое кто-то напечатал до того, как проблему вообще поняли.

Если кажется, что рассказывать нечего — вокруг все «запустили платформу» и «переписали архитектуру», а вы чинили экспорт, — дело не в опыте. Дело в том, как он описан.

Тикет написан для другого разговора

Трекер существует, чтобы координировать работу. Заголовок отлично справляется, когда рядом коллеги, у которых уже есть контекст: они помнят, почему задача горела, кто жаловался и что уже пробовали.

У человека, который видит вас впервые, контекста нет вообще. Фразу «пофиксил таймаут экспорта» он прочитает как «поменял настройку». Вы в этот момент помните про размер данных, повторяющиеся запросы и живой сценарий клиента. Никто не ведёт себя неразумно — просто вы принесли на встречу разное количество информации.

Поэтому начните с одной законченной задачи. Не с резюме, не с отрепетированного ответа. С задачи, где была развилка, которую вы помните, даже если сама задача звучит непрестижно.

Найдите момент, когда пришлось выбирать

Дальше — вымышленный пример, чтобы показать механику. Все детали в нём придуманы и не годятся в качестве чужого интервью-опыта.

Небольшие выгрузки проходят нормально, большая упирается в таймаут запроса. Поддержка вручную обходит сбой, команда хочет сохранить текущий сценарий скачивания, пока идёт разбор. Инженер воспроизводит падение и обнаруживает, что метаданные аккаунта запрашиваются заново на каждую строку выгрузки, хотя не меняются в течение всего экспорта.

Вот она, развилка. Можно переделать экспорт в фоновую задачу — но тогда понадобится отчитываться о прогрессе и как-то забирать готовый файл. А можно сначала убрать повторный запрос и посмотреть, снимет ли это воспроизведённый случай. Инженер рекомендует второй вариант, получает ревью, делает один запрос метаданных на экспорт, сохраняет прежние проверки доступа. Коллега смотрит границу авторизации, QA проверяет выгрузку.

В истории появились расследование, рамки, совместная работа и компромисс. Ничего из этого не потребовало более громкой должности.

Свою задачу разберите по четырём вопросам — сначала черновыми заметками, не пытаясь звучать внушительно. Попытка вспоминать факты и одновременно производить впечатление даёт на выходе абзац, где много уверенности и мало содержания.

• Кто не мог работать. Назовите человека или процесс и то, что у них не получалось стабильно.
• Что ограничивало варианты. Совместимость, сроки, доступы, стоимость, чужое владение кодом, зависимость, которую нельзя было менять.
• На что вы повлияли. Какую альтернативу рассматривали и почему рекомендовали то, что рекомендовали.
• Что случилось потом. Какие доказательства у вас реально есть и чего из них не следует.

Что сказать вслух

Продолжая вымышленный пример: большая тестовая фикстура, которая раньше падала, теперь проходит. Проверки подтверждают ожидаемое число строк, содержимое и ограничения доступа в протестированных случаях. Из этого уже складывается внятный рассказ.

Большие выгрузки падали по таймауту, поддержка обходила это вручную. Я воспроизвёл сбой и увидел, что метаданные аккаунта запрашиваются внутри цикла по строкам. Предложил брать их один раз на экспорт: так мы закрываем воспроизведённый случай и не ломаем текущий сценарий скачивания. Реализовал, коллега проверил границу доступа, QA посмотрел выгрузку. Раньше падавшая фикстура прошла с ожидаемыми данными. Для больших нагрузок это всё ещё не финальное решение — их надо отдельно оценивать.

Слышно, где уместен уточняющий вопрос: почему метаданные вообще не меняются, какие проверки доступа остались, при каких условиях фоновая задача станет оправданной. Такие вопросы добираются до логики работы. Расплывчатое резюме оставляет собеседнику меньше способов понять, что вы умеете.

«Мы» и «я»

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

В рекомендациях Amazon к интервью кандидата прямо просят объяснять личный вклад и опираться на релевантные доказательства. Результат при этом остаётся командным, а роль должна быть видна.

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

Не спасайте абзац придуманным процентом

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

Лучше версия, которую вы защитите, когда спросят, как измеряли. В примере с экспортом прохождение большой фикстуры поддерживает узкое утверждение: конкретный проверенный случай работает. Оно не доказывает ускорение в продакшене и не доказывает, что поддержка перестала обходить баг руками.

Есть сопоставимые замеры до и после — опишите нагрузку, окружение и период измерения. Нет — сузьте формулировку. Качественные доказательства тоже годятся: пользователи перешли на новый сценарий, ревьюер подтвердил поведение, которое раньше ломалось, документированный ручной шаг исчез.

Даже «повторов не наблюдалось» требует окна наблюдения и понимания, что мониторинг поймал бы. Тишина в рабочем чате — слишком восторженная замена доказательству. Иногда честный финал звучит так: работа вышла, результат пока не измерен. Об этом можно говорить — решение, ожидаемая польза отдельно, план наблюдения.

Записывайте историю, пока память не сжала её до номера тикета

Будущий вы вспомнит совещание, которое должно было быть письмом. Причину, по которой отвергли первую реализацию, восстановить будет труднее. Короткая заметка раз в неделю даёт этим деталям место, где жить.

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

Пять минут на заметку — нормальный стартовый бюджет, сложная работа займёт больше. Формулировки могут быть корявыми: задача — оставить контекст, а не текст для публикации. Храните заметки там, где это разрешено, а для внешних разговоров держите отдельную обезличенную версию без внутренних данных компании.

Если вы ещё учитесь или ищете первую роль, берите групповой проект, курсовую, опенсорс. Масштаб оставляйте честным: выбор, который вы можете объяснить на маленьком проекте, даёт собеседнику больше поводов копать, чем громкое заявление без опоры.

Тренируйте уточняющие вопросы

Расскажите историю вслух, не подчитывая каждую строку. Попросите кого-нибудь перебить вас разумным уточнением. Заметьте, где объяснение поплыло: реализацию помните, а отвергнутую альтернативу нет; результат команды знаете, а свой вклад не отделили. Эти провалы и показывают, что дочинить.

Одни и те же факты в разных разговорах

Заметка выдерживает несколько версий, но детализация в каждой своя.

Если правите формулировки с помощью ИИ, отдавайте только материал, который разрешено выносить наружу, и просите отдельно отметить неясное авторство, недостающие доказательства и необъяснённые решения. Каждое утверждение в переписанной версии проверяйте сами: гладкий текст должен остаться текстом про вашу работу.

Часть задач правда рутинная. Тут нечего рассказывать, и это нормально — берите другой пример.

Но прежде чем решать, что опыт скучный, дайте одной обычной задаче чуть больше внимания. Кто не мог работать, где была неопределённость, что вы сделали, когда очевидного ответа не было. Начинать с этого полезнее, чем с заголовка тикета.