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

Ниже — что поставить в шапку, как честно написать таймзону, какие формулировки показывают асинхронную работу, два полных каркаса (разработчик и поддержка/QA) и что не стоит обещать. Это не отдельный жанр CV «про фриланс». Это тот же документ, что в поиске работы, только с полями, без которых распределённая команда вас отсеет за 15 секунд.

Коротко:

  • Укажите таймзону, формат работы и язык команды в шапке, не в конце файла.
  • Покажите асинхронный опыт: тикеты, документация, релизы, инциденты, статусы в канале.
  • Инструменты команды важны не меньше фреймворка: issue tracker, чат, ревью, база знаний.
  • Не пишите «хочу удалёнку». Покажите, что вы уже так работали или умеете так работать.
  • Не обещайте 24/7 и не маскируйте офис под remote: на созвоне спросят детали.

Что добавить в шапку

Первый экран remote-резюме:

  1. Роль рынка, не внутренний грейд («Backend engineer», не «ведущий специалист 2 категории»).
  2. Город и таймзона явно: «Минск, UTC+3 (MSK)» / «Алматы, UTC+6».
  3. Формат: remote; если готовы к редкому офсайту — частота и кто платит дорогу, не «open to anything».
  4. Окно пересечения: «пересечение с CET 10:00–16:00» или «с MSK 9:00–13:00 при UTC+6».
  5. Язык команды: русский C2, английский B2 письменный / B1 созвон — честно.
  6. Контакты и ссылки, которые открываются: почта, Telegram, GitHub, портфолио, LinkedIn если целитесь в зарубежные команды.

Если вы в СНГ и целитесь на Европу, это должно быть видно сразу, без квеста по тексту. Рекрутер не будет искать пояс в десятом пункте опыта. Гибрид в Варшаве при проживании в Тбилиси в шапке не пишите как remote — это другой поиск. Для входа без сильного стека шапка всё равно нужна: роль поддержки или QA, пояс, смены. Вакансии смотрите в удалённых IT-вакансиях и, если стажа мало, в junior-каталоге — под них и собирайте файл, не «универсальный на офис и дом».

Таймзона и пересечение часов

Пояс — не декорация. От него зависят стендапы, дежурства, ревью и «почему вы молчали четыре часа». Пишите IANA или привычную пару: UTC+3, MSK, CET. Не «GMT+3» вперемешку с «Москва» без ясности, живёте ли вы сейчас в другом городе.

Пересечение: посчитайте 4–6 часов, которые вы реально можете быть на созвоне. UTC+6 против Калифорнии — это либо раннее утро у них, либо ночь у вас. Если не готовы, не откликайтесь и не пишите «flexible hours, anytime». Гибкость без окна читается как «поймаете, когда повезёт». Лучше: «Основное окно 9:00–18:00 UTC+3, два раза в месяц могу смену 12:00–21:00 под релиз, ночные дежурства не рассматриваю».

Если недавно переехали: укажите текущий пояс, не прописку. Команда планирует вас в календаре, а не в паспорте. Смену пояса на испытательном (двухнедельный отпуск в другом UTC) лучше заранее оговорить, а не ставить сюрпризом в Slack.

Как показать асинхронную работу

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

Ищите в своём опыте:

  • Задача, которую вели от тикета до релиза без ежедневного контроля.
  • Документ: RFC, описание решения, README, постмортем, инструкция для поддержки.
  • Статус в канале или тикете вместо «расскажу на стендапе».
  • Ревью кода или текста, которое делали не в паре за одним столом.
  • Онбординг человека по чек-листу, не «посидели рядом».
  • Инцидент: фиксация симптомов, что уже проверено, что не трогаете до утра.

Если всего этого не было, потому что офис и тимлид стоял за спиной — не выдумывайте. Можно честно: «Офисный опыт; для remote готов работать через тикеты и документацию, пример — учебный README / описание тестового». Враньё про «три года distributed» вскроется на вопросе «какой у вас был SLA на ревью?». Для первой remote-роли достаточно маленького доказательства плюс готовность к письменному формату. Курсы «цифровой кочевник» и список логотипов Slack в резюме не заменяют ни одной такой пули.

Формулировки, которые усиливают remote

Плохие пули: «работа в команде», «исполнял поручения», «знание Slack, Zoom, Jira» списком без задач, «хочу удалённый формат». Рабочие — задача, канал, результат.

  • Вёл задачу от тикета до релиза без ежедневного созвона с заказчиком: статусы в Jira, блокеры — в канале в тот же день.
  • Писал короткое описание решения в Notion, чтобы команда в CET могла ревьюить утром; среднее время ревью сократили, потому что контекст не терялся в чате.
  • Дежурил по инцидентам: фиксировал симптомы, id, что проверено и что не трогаем до появления коллеги в поясе UTC+1.
  • Онбордил стажёра удалённо по чек-листу из 12 шагов; доступы и первое ревью — асинхронно, созвон только на разбор спорных мест.
  • Согласовывал API-контракт комментариями в MR, без созвона: примеры запросов, ошибки, кто владелец поля.
  • Держал очередь поддержки в Zendesk, SLA первого ответа 15 минут в смене; эскалации в Jira с шагами воспроизведения, без обещаний фикса «сегодня».

Цифры ставьте только свои. Если сокращения времени ревью не мерили — не выдумывайте проценты. Достаточно процесса. Инструменты вплетайте в пулю, не отдельным «навыком удалёнки» из десяти логотипов.

Пример 1. Каркас резюме разработчика под remote

Цель: Python/Django, платежи, remote, пояс UTC+3, пересечение с CET. Не офис Минска.

Backend engineer (Python/Django) · Минск, UTC+3 · remote · пересечение с CET 10:00–16:00 · русский C2, English B2 (письменно и созвон)

Профиль. 4 года backend, биллинг и вебхуки. Работал с распределённой командой: тикет → MR → ревью на следующий день → релиз по чек-листу. Ищу remote с окном CET, не гибрид в ЕС.

Опыт. Fintech B2B, 2023–2026

— Вёл платежный инцидент без ночного созвона со всей командой: канал со статусом каждые 30 минут, постмортем на утро для CET.

— Описал контракт вебхука в RFC (2 страницы): команда поддержки закрывала типовые «деньги зависли» без пинга разработчика.

— Ревьюировал MR асинхронно, SLA комментария до начала своего следующего рабочего дня; блокеры помечал явно, не «посмотри когда будет время».

Стек: Python, Django, PostgreSQL, Redis, pytest. Процесс: GitHub, Jira, Slack, Notion.

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

Пример 2. Каркас для поддержки и QA

Коммерческой разработки нет. Цель: remote L1 или manual QA, русскоязычная команда, UTC+6, пересечение с MSK утром.

Специалист поддержки / junior QA (ручное) · Алматы, UTC+6 · remote · пересечение с MSK 9:00–13:00 · готов к сменам 2/2 без ночи · русский C2, English A2 (чтение интерфейса)

Профиль. Очередь обращений и тестовая документация. Коммерческого штата IT нет. Есть разобранные тикеты и папка тест-кейсов. Ищу линию 1 или junior QA с письменным форматом, не «работу с телефона».

Практика

— Чат сообщества курса, 2025–2026: 40–70 сообщений в день, первый ответ в рабочий день, эскалация со скрином и шагами, без обещаний «автор ответит через час», если срока не было.

— Учебный сервис записи: 14 сценариев, 9 баг-репортов в шаблоне шаги / ожидание / факт / окружение. Ссылка: [папка]. Коммерческого Jira нет, формат тот же.

— Готовность к Zendesk/Jira и сменам; AnyDesk «для оформления» и предоплату за обучение не рассматриваю.

Последняя строка не для пафоса: она отсекает схемы ещё на чтении. Подробнее про ловушки входа — в удалённой работе без опыта. Для самой линии поддержки берите смены и SLA из удалённой работы в поддержке и переносите в пули свои, не чужие.

Чего не делать

Не маскируйте офисную работу под удалёнку, если её не было: вас спросят, как проходил онбординг, где документация, какой был overlap. Не обещайте «доступен 24/7». Не прячьте, что работали из дома, если работали: для remote это плюс при результатах. Не ставьте отдельный раздел «навыки удалённой работы» из Slack, Zoom, Notion, TeamViewer — без задач это шум, а TeamViewer ещё и красный флаг для тех, кто читал про схемы.

Не пишите «цифровой кочевник, работаю с Бали» в шапке на вакансию с дежурствами в CET: это обещание нестабильного пояса. Не кладите в файл готовность к офису, гибриду и remote сразу — рекрутер не понимает, куда вас звать. Не прикладывайте фото рабочего стола вместо пуль. Оборудование в резюме обычно не нужно; на интервью спросят про интернет и место, этого достаточно.

Сомнительные вакансии, под которые вы «подчищаете CV любой ценой», сначала проверьте: как проверить вакансию и не попасть на мошенников. Подделывать remote-опыт ради схемы бессмысленно.

Инструменты команды vs стек

Стек отвечает на «можете ли вы сделать задачу». Инструменты команды — на «можете ли вы существовать в процессе без офиса». Jira, Linear, GitHub Issues, Slack, Telegram, Notion, Confluence, Zendesk, календарь с поясами. В резюме достаточно тех, с которыми готовы работать на созвоне. Врать «3 года Notion» ради ATS не стоит: спросят, как у вас устроены спеки.

Короткий блок «Процесс» из одной строки после стека работает лучше отдельной простыни. Пример: «GitHub + Jira + Slack; статусы в тикете, созвоны — по необходимости». Если вы только из универа, напишите, чем пользовались на практике и к чему готовы, без трёх лет выдуманного Agile.

Частые вопросы

Нужно ли писать оборудование?

Обычно нет. На интервью могут спросить про интернет, камеру и тихое место. В резюме «ноутбук 32 ГБ и кольцевая лампа» не продаёт роль и выглядит странно. Исключение — вакансия явно просит характеристики для тяжёлой сборки; даже тогда одна строка, не спецификация.

Помогает ли отдельный раздел «навыки удалённой работы»?

Короткий — да, если в нём пояс, окно часов и 2–3 инструмента процесса. Slack, Jira, Notion, Zoom сами по себе не продают, если в опыте нет асинхронных задач. Лучше вплести инструмент в пулю опыта.

Что писать, если remote-опыта не было вообще?

Честно: офис или учёба. Добавьте факты, которые переносятся: задачи без постоянного контроля, письменные отчёты, часовые пояса заказчика, волонтёрская очередь. Плюс готовность к письменному формату и реальное окно часов. Не рисуйте distributed-команду.

Нужны ли два файла — на русский и английский рынок?

Да, если целитесь в оба. Язык вакансии = язык резюме. Не смешивайте абзацы «для солидности». Пояс и overlap нужны в обеих версиях.

Стоит ли указывать город, если боюсь дискриминации по географии?

Пояс всё равно спросят. Прятать страну на remote почти бесполезно: договор, налоги, банки, санкционные ограничения всплывут. Лучше город + UTC + готовность к B2B/EOR, чем «location independent» без юридической ясности.

Как понять, что резюме всё ещё офисное?

Если за 20 секунд не видно пояса, формата и ни одной пули про тикет/документ/статус — оно офисное. Откройте шапку и последнюю роль. Если сомневаетесь, разбор файла полезнее ещё одного шаблона с иконками.

Что сделать сейчас

Добавьте таймзону, окно пересечения и два remote-пункта в опыт. Уберите «хочу удалёнку» и 24/7. Откликнитесь на удалённые вакансии этой версией, а не офисной. Если стажа мало — сузьте роль и смотрите junior-вакансии с явным remote.

Каждую вакансию перед тестовым проверьте по чек-листу мошенников. Поиск не меняйте на бесконечный скролл: держите систему из как найти работу и один файл под формат. Если шапка после правки всё ещё не читается — разбор резюме до следующей пачки откликов.