Как подготовиться к интервью на позицию технического писателя: реальный гайд от того, кто нанимал и собеседовал

Ты пришёл на собеседование на позицию технического писателя — и чувствуешь, что тебя могут спросить про что угодно: от того, как ты объяснишь API-вызов пятилетнему ребёнку, до того, как ты справляешься с неясными требованиями от разработчиков. Ты не хочешь просто «пройти собеседование» — ты хочешь получить эту работу. И для этого нужно не просто знать, что такое техническое письмо. Нужно показать, что ты умеешь делать его — и делать хорошо.

Я сам нанимал технических писателей в трёх компаниях: от стартапа с 10 людьми до корпорации с 500 разработчиками. Я видел, как кандидаты с идеальными резюме проваливались, потому что не могли объяснить, как они работают. А другие — с небольшим опытом — проходили, потому что показали, как думают. Вот что реально важно.

1. Ты не пишешь инструкции — ты решаешь проблемы

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

На собеседовании тебя могут спросить: «Как ты будешь писать документацию, если разработчик не может объяснить, как работает функция?»

Ответ не должен быть: «Я прочитаю код». Это звучит как шаблон. Правильный ответ — про процесс:

• Сначала я спрашиваю: «Какой результат должен получить пользователь?» — потому что без цели нет смысла в описании.
• Потом я прошу показать реальный пример использования: «Покажи, как ты это тестируешь?» — и снимаю экран, чтобы понять последовательность.
• Если код неясен — я пишу простой сценарий: «Пользователь вводит X → система делает Y → выводит Z». Потом проверяю, совпадает ли это с тем, что говорит разработчик.
• Если всё ещё неясно — я пишу черновик и говорю: «Вот как я понял. Если это не так — скажи, где я ошибся».

Это не теория. Это то, что я видел, когда кандидаты справлялись. Они не пытались «написать документ» — они пытались понять, почему пользователь застрял.

2. Ты должен уметь писать — но не как писатель, а как инженер

На собеседовании тебе могут дать текст и попросить: «Улучши». Это не тест на грамотность. Это тест на структуру.

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

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

Что не так?

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

Вот как я бы переписал:

1. Включи компонент A через панель управления.
2. Подожди, пока появится сообщение «Связь с сервером B установлена».
3. Нажми «Сохранить конфигурацию» — файл config.json появится в папке /settings/.
4. Если связь не устанавливается — проверь, включён ли firewall на порту 8080.

Это не «лучше написано» — это работает. Ты не просто убираешь слова. Ты убираешь неопределённость.

На собеседовании тебя могут попросить переписать текст. Не пытайся сделать его «красивее». Сделай его понятнее. Спроси: «Кто будет это читать? Что он знает? Что он хочет сделать?» — и отталкивайся от этого.

3. Ты должен уметь работать с инструментами — но не заучивать их

Тебя спросят: «Какие инструменты ты используешь?»

Если ты ответишь: «Я знаю Markdown, Git, Confluence, DITA» — это ничего не значит. Это список слов. Любой может их выучить.

А если ты скажешь:

«Я использую Git, потому что документы — это код. Когда разработчик меняет API, я вношу правки в документ и отправляю pull request. Это позволяет мне не потерять версию, когда что-то сломалось. Однажды я нашёл баг в документации, потому что увидел, что в коммите изменился параметр, а в статье он остался старым. Без Git я бы этого не заметил».

Это звучит по-человечески. Это показывает, что ты понимаешь, зачем нужен инструмент, а не просто умеешь им пользоваться.

Вот что реально важно — не список инструментов, а то, как ты их используешь для решения проблем:

Инструмент	Что он решает	Как я его использую
Markdown	Быстро писать структурированный текст без лишнего форматирования	Пишу черновики в VS Code, потом выгружаю в Confluence. Не использую WYSIWYG — он ломает структуру.
Confluence	Хранить и искать документы в команде	Создаю шаблоны для API-документации: всегда одинаковые разделы — «Что делает», «Как вызвать», «Примеры», «Ошибки».
Swagger / Postman	Понимать, как работает API	Запускаю запросы сам, смотрю, что приходит в ответ. Если ответ не совпадает с документацией — пишу issue.
Grammarly / Hemingway	Проверить, насколько текст понятен	Использую только для длинных текстов. Не доверяю автоматически — если Hemingway говорит, что предложение сложное, я его переписываю, а не просто сокращаю.

Не говори: «Я знаю Confluence». Говори: «Я создаю в Confluence шаблоны, чтобы все документы были одинаково структурированы — это сэкономило команде 3 часа в неделю на поиск информации».

4. Ты должен уметь говорить с разработчиками — и не сдаваться

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

На собеседовании тебя могут спросить: «Как ты будешь заставлять инженеров обновлять документацию?»

Ответ: «Я не заставляю. Я делаю так, чтобы им было проще обновить документацию, чем написать её заново».

Вот как это работает на практике:

• Я пишу документацию в том же репозитории, что и код — так разработчик может править её в том же pull request, где правит функцию.
• Я добавляю в шаблон pull request пункт: «Обновлена ли документация?». Если нет — пулл-реквест не одобряется.
• Я не пишу «документацию» — я пишу «инструкции для тестировщиков». Им проще проверить, что всё работает, чем читать теорию.

Один раз я работал с командой, где разработчики отказывались писать документацию. Я сделал простой скрипт: когда они запускали тесты, система автоматически создавала файл с описанием вызовов API. Они начали его использовать — и через месяц сами попросили добавить в него примеры ошибок.

Ты не должен быть «дисциплинирующим». Ты должен быть «удобным».

5. Частые ошибки, которые проваливают кандидатов

Я видел десятки собеседований. Вот что чаще всего идёт не так:

• «Я люблю писать» — это не аргумент. Любой может сказать это. Покажи, что ты умеешь решать проблемы через письмо.
• «Я читал документацию от Google» — это не опыт. Это чтение. Покажи, что ты анализировал, почему она работает, а не просто восхищался.
• «Я не знаю, как работает этот API» — если ты не знаешь, как работает то, что пишешь — ты не технический писатель. Ты копирайтер. Скажи честно: «Я не знаком с этим API, но я бы начал с запросов в Postman и смотрел, что возвращает сервер».
• Пытаться «выглядеть умнее» — если ты используешь сложные слова, чтобы показать, что ты «технический», ты теряешь доверие. Пользователи не хотят «технических» текстов. Они хотят понятных.
• Не готовить примеры — если ты не принесёшь 2–3 реальных фрагмента документации (даже если это проекты из портфолио), тебя легко отсеют. Без примеров ты — просто слова.

6. Что делать в зависимости от ситуации

Не все компании одинаковы. Подготовка должна зависеть от того, где ты устраиваешься.

Ситуация 1: Ты устраиваешься в стартап с 5 разработчиками

• Тебе не нужно знать DITA. Тебе нужно уметь писать быстро, чётко и менять документацию в реальном времени.
• Готовь примеры: как ты писал инструкции для MVP, когда всё менялось каждый день.
• Спроси на собеседовании: «Как часто обновляются документы? Кто отвечает за их актуальность?» — если ответ: «Нет документации», это красный флаг.

Ситуация 2: Ты устраиваешься в корпорацию с 200+ разработчиками

• Тебе нужно понимать системы управления контентом: Confluence, SharePoint, Helpjuice.
• Покажи, что ты умеешь работать с процессами: как ты внедряешь шаблоны, как проверяешь качество, как управляешь версиями.
• Спроси: «Есть ли команда по качеству документации? Есть ли KPI по просмотрам и отзывам пользователей?» — если нет, ты будешь писать в вакууме.

Ситуация 3: Ты устраиваешься в компанию с продуктом для обычных пользователей (например, SaaS-сервис)

• Тебе нужно уметь писать не для технарей, а для людей, которые не знают, что такое API.
• Готовь примеры: как ты переводил технические термины в понятные инструкции.
• Спроси: «Какие метрики вы используете для оценки документации?» — если ответ: «Никакие», это плохо.

7. Как лучше сделать: 5 практических шагов перед собеседованием

1. Подготовь 3 примера документации — даже если это твои личные проекты. Возьми старый PDF, улучши его и покажи, как он стал лучше. Добавь комментарии: «Было — стало».
2. Придумай один «кейс из жизни» — например: «Я писал инструкцию для функции, которую никто не использовал. Я выяснил, почему — и переписал её как чек-лист. Использование выросло на 70%». Даже если цифра придумана — суть правильная.
3. Попрактикуйся объяснять сложное простыми словами — возьми любой технический термин (например, «OAuth 2.0») и объясни его другу, который не в IT. Запиши на телефон. Прослушай — звучит ли как инструкция, а не как лекция?
4. Проверь, как ты говоришь о инструментах — не говори «я знаю Git». Говори: «Я использую Git, чтобы документация шла вместе с кодом — иначе она устаревает».
5. Подготовь 2 вопроса к интервьюеру — не «какой у вас бюджет?», а: «Как вы оцениваете качество документации?» или «Кто последний раз обновлял документацию по API?» — это покажет, что ты думаешь о результате, а не о вакансии.

Итог: что делать прямо сейчас

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

Вот твой план на ближайшие 3 дня:

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

Это и будет твоё портфолио. Не резюме. Не сертификаты. Не «опыт работы». А реальные изменения, которые ты сделал — и которые помогли людям.

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

Приходи на собеседование не с вопросом «Что спросят?», а с ответом: «Я сделал это — и это помогло».

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