System Analyst
Обрати внимание, что нужно построить именно матрицу для сквозной аналитики, а не просто список событий.
Кейс 1: Нужно спроектировать event-матрицу кредитной заявки. Контекст: пользователь проходит финтех-онбординг — приходит по рекламе, регистрируется, заполняет анкету, проходит скоринг, получает решение, подписывает договор, получает деньги на карту. Задача — набросать логическую структуру event-матрицы для сквозной аналитики: какие события фиксируются на клиенте, а какие на сервере (фронтенд/бэкенд) и почему, а также прописать критические атрибуты для ключевых шагов.
С качеством данных как-то работали? Использовали ли систему проверки?
Кейс 3: Мы льём трафик с веба на лендинг. Пользователь кликает «оформить кредит», переходит в сторы, скачивает приложение. При первом запуске он должен увидеть экран конкретного кредитного продукта с сохранением исходных UTM-меток маркетинговой кампании и источников. Нужно спроектировать схему движения параметров: какие методы вызываются для достижения цели, ожидаемый результат — схема потока данных, этапы текстом, схема должна содержать конкретные методы и логику обработки и передачи меток в аналитическую систему.
Знаком ли вам формат аутстаффинга? Работали когда-то по такому принципу?
ГазпромнефтьОцените ещё раз свой уровень SQL (после технических проблем со связью).
Расскажи про проект в [организация] по разработке DWH и near real-time аналитики строительных объектов: какие задачи стояли, как их решали, какие достижения?
3. Представь, что ты порекомендовал друга на позицию разработчика, однако ты замечаешь, что в этой компании он не справляется с задачами. Что ты будешь делать?
Есть ли у вас вопросы? Готовы приступить к решению задач?
Кейс 5 (заменённый): Мы хотим создать новое приложение — сервис для переводов, чтобы можно было отправлять переводы от одной стороны к другой. Какова должна быть архитектура этого приложения? Спроектируй архитектуру такого приложения.
Каждая собака совершает один укус в день, направляя его хаотично на себя, на другую собаку или на владельца. Через неделю зафиксировано 40 укусов у владельца и по 3 укуса у каждой из собак. Сколько собак в приюте?
Расскажите, как взаимодействовали сервисы между вашими проектами.
Кейс 4: Нужно защититься от фрода при атрибуции, когда события отправляются напрямую с нашего сервера на сервер AppsFlyer. Контекст: приложение подвергается атакам эмуляторов, фроду установок, фейковому заполнению анкет. Базовый антифрод AppsFlyer (Protect360) отсекает часть трафика, но бизнес требует внедрения внутренней кастомной валидации перед отправкой финальных целевых событий в рекламные каналы. Рекламные каналы передают click_id, по которому нужно отбивать события — платим только за выдачу кредита. Нужно разработать схему API-взаимодействия и бизнес-правил для безопасной передачи конверсии: при каких условиях событие маркируется как валидное и отправляется партнёру, а когда оно невалидное, и как оно обрабатывается в каждом случае.
Как дальше будут двигаться данные?
Интересует конкретно последовательность шагов сценария: какие этапы происходят и как данные двигаются по этим этапам?
Представь flow клиента с его точки зрения.
Нужно ли будет работать в нерабочие часы/выходные на текущем проекте?
Учти, что App Store вообще ничего не запоминает и не передаёт, а Google Play запоминает только referrer, и то не всегда — только если пользователь дал разрешение на передачу referrer. Какие данные мы должны сохранить, когда пользователь зашёл в приложение и должен увидеть экран конкретного кредитного продукта?
По какой логике, по какому правилу будет происходить мэтчинг?
Пользователь пришёл, и мы про него вообще ничего не знаем — нет никаких идентификаторов, известен только клик и рекламный источник. Какие в этом случае остаются варианты для мэтчинга?