Есть ли работа на тестовых стендах в Москве
Что проверяют
Вопрос обычно про формат работы: часть задач требует присутствия у физического стенда в московском офисе, и интервьюер проверяет, готовы ли вы к этому и работали ли со стендами вообще. Следом спрашивают, как вы убеждаетесь, что на стенде нужная версия, и что делаете, когда стенд сломан.
Как отвечать
Сначала ответьте прямо на организационную часть: готовы ли приезжать, как часто, есть ли ограничения. Уточните встречно, сколько дней в офисе и нужен ли стенд постоянно или только на регресс перед релизом.
Затем покажите, что различаете виды стендов:
- программные окружения: dev, test, stage, preprod. Вы знаете, какая сборка где стоит, кто её выкатывает, чем стейдж отличается от прода по данным и интеграциям;
- физические стенды: платёжные терминалы, кассы, банкоматы, сетевое оборудование, автомобильная электроника, набор реальных телефонов. Здесь добавляются прошивки, питание, кабели и запись на стенд по расписанию.
Каркас рассказа о своём опыте: какие стенды были, как узнавали версию (номер сборки, эндпоинт /version, тег в CI), как делили стенд между командами, как собирали логи (Kibana, adb logcat, SSH на сервер), как отличали дефект продукта от поломки окружения. Цифры и примеры давайте свои: сколько стендов, сколько человек, что конкретно ломалось.
Если с физическим оборудованием вы не работали, так и скажите и опишите близкий опыт: тестовые окружения, эмуляторы, ферма мобильных устройств. Готовность разобраться в железе ценят выше, чем придуманный опыт.
Где спотыкаются
Уходят от прямого ответа про офис. Если ездить вы не готовы, лучше сказать сразу, это сэкономит время обеим сторонам.
Заводят баг, не проверив стенд: не та сборка, кончилось место на диске, лежит соседний сервис. Такие баги подрывают доверие к тестировщику.
Рассказывают шаблонную историю про Docker, Ansible и сокращение сроков «на 30%» без деталей. На первом уточняющем вопросе она рассыпается.