Как организована удаленная работа с учетом часовых поясов
Что проверяют
Этот вопрос чаще задаёте вы работодателю, и по нему видно, насколько осознанно вы идёте в распределённую команду. Если интервьюер переворачивает его и спрашивает о вашем опыте, он проверяет самостоятельность: сможете ли вы двигать задачу, пока ревьюер спит.
Как отвечать
Спрашивайте о том, что прямо повлияет на работу Android-разработчика:
- пересечение по времени: сколько часов в день команда онлайн одновременно и есть ли обязательное окно для созвонов. Два-три общих часа это нормально, ноль означает, что всё решается перепиской;
- ревью: кто смотрит ваши pull request и за какой срок. Если единственный ревьюер живёт на восемь часов впереди, одна правка может занимать сутки;
- релизы: кто выкладывает сборку в Google Play, кто следит за крашами в Firebase Crashlytics после выкладки и в какое время по вашему поясу это происходит. Поэтапная раскатка с остановкой при росте крашей требует, чтобы кто-то был на связи;
- асинхронность: фиксируются ли решения в Confluence, Notion или задачах Jira, записываются ли встречи, какое время ответа в мессенджере считается нормой;
- формальности: по какому поясу считается рабочий день и оплачиваются ли дежурства вне ваших часов.
Если спросят о вас, опирайтесь на свой опыт: какая была разница во времени, как вы договаривались о ревью, как формулировали вопросы, чтобы на них можно было ответить без созвона. Нужны свои детали, а не общие слова про Slack и календарь. Если удалённой работы с другими поясами не было, скажите об этом прямо и опишите, как будете работать: заранее отмечать блокеры, писать подробные описания к PR, самому предлагать окно для синхронизации.
Где спотыкаются
Спрашивают только, можно ли работать откуда угодно, и не узнают про пересечение часов. Потом выясняется, что планирование идёт в одиннадцать вечера по вашему времени.
Отвечают про инструменты вместо процессов. Список мессенджеров не показывает, что вы умеете работать асинхронно.
Не уточняют, кто отвечает за релиз и инциденты. В мобильной разработке это особенно важно: выпущенную в стор сборку нельзя просто откатить, раскатку можно лишь остановить и выпустить исправление.