MiddleUX/UI Designer > UX Research > Интервью с пользователями
Как вы проводите пользовательское исследование?
Исследование начинается с вопроса к продукту, а не с набора вопросов к пользователю.
Загрузка…
База вопросов
Все вопросы из всех профессий в одном списке: краткая суть, развёрнутые ответы, примеры и практические задания.
JuniorData Analyst > SQL и данные > SQL
Как выбрать заказы, сделанные в диапазоне дат с 1 по 31 марта 2024 года включительно, без риска случайно упустить последний день?
Короткий ответ Безопаснее использовать полуоткрытый интервал order_date >= '2024-03-01' AND order_date , чем BETWEEN '2024-03-01' AND '2024-03-31', особенно если order_date хранится как timestamp, а не как чистая дата. Как это работает подробнее BETWEEN a AND b эквивалентно >= a AND . Если поле — date, BETWEEN '2024-03-01' AND '2024-03-31' действительно включает весь март. Но если поле — timestamp, то '2024-03-31' интерпретируется как полночь 2024-03-31 00:00:00, и заказы, сделанные позже полуночи 31 марта (например, в 15:00), в диапазон не попадут. Пример кода Что использовать на практике На практике: полуоткрытый интервал [начало месяца, начало следующего месяца) работает одинаково надёжно независимо от того, date это или timestamp, и его проще обобщить на произвольный период, вычисляя границы динамически. Результат: Результат — все заказы марта 2024, включая сделанные в последнюю секунду 31 марта. Проверка: сравнить максимум order_date в результате с максимумом order_date по всей таблице за март, отфильтро
MiddleData Analyst > SQL и данные > Статистика и теория вероятностей
Как выбрать между t-test, Mann-Whitney и z-test в зависимости от данных?
Короткий ответ z-test обычно применяют для сравнения пропорций (конверсий) на больших выборках; t-test — для сравнения средних непрерывных метрик, особенно при умеренных выборках и допущении о нормальности (или достаточно большом n для центральной предельной теоремы); Mann-Whitney — непараметрическая альтернатива t-test, когда данные сильно скошены, есть выбросы или выборка мала. Как это работает подробнее t-test сравнивает средние и чувствителен к форме распределения на малых выборках, а также к выбросам, так как опирается на среднее и дисперсию. Mann-Whitney сравнивает ранги значений, а не сами значения, и проверяет сдвиг распределений, а не именно равенство средних — это делает его устойчивее к выбросам и скошенности. z-test для пропорций использует нормальную аппроксимацию биномиального распределения, которая хорошо работает при достаточно большом n и не слишком экстремальной конверсии. Пример кода Что использовать на практике На практике. для метрик вроде revenue per user, где распределение сильно скошен
JuniorPerformance Marketer > Google Ads > Взаимодействие с командами и бизнес-практики
Как выглядит простая приоритизация гипотез по фреймворку ICE (Impact, Confidence, Ease) и зачем она нужна, если гипотез для тестирования больше, чем ресурсов на их проверку?
Короткий ответ ICE оценивает гипотезы по трём критериям: Impact — ожидаемое влияние, Confidence — уверенность в эффекте, Ease — простота реализации. Команда сравнивает оценки по согласованной шкале и сначала проверяет наиболее перспективные идеи. Как это работает подробнее Каждую гипотезу оценивают по одинаковым шкалам, часто от 1 до 10. Итоговый балл считают как среднее или произведение оценок, затем сортируют гипотезы по убыванию. Например, новый оффер может иметь высокий потенциальный эффект, но меньшую уверенность и более сложную реализацию, чем изменение таргетинга. Impact. Насколько заметно гипотеза может изменить целевую метрику. Confidence. Насколько надёжны данные или наблюдения, на которых основано ожидание эффекта. Ease. Насколько быстро и просто командой можно подготовить и провести проверку. Что использовать на практике Согласовать шкалу. До оценивания договориться, какие наблюдаемые результаты соответствуют низким и высоким баллам. Оценивать вместе. Собирать оценки маркетолога, дизайнера и други
JuniorDevOps Engineer > Контейнеры и доставка > Мониторинг, логирование и observability
Как выглядит простейший PromQL-запрос и как выбрать конкретный временной ряд по labels?
Короткий ответ Простейший PromQL-запрос — это просто имя метрики, например http_requests_total, которое вернёт все текущие временные ряды с этим именем; чтобы выбрать конкретный ряд, к имени добавляют фильтр по labels в фигурных скобках, например http_requests_total{job="api", status="500"}. Как это работает подробнее каждая метрика в Prometheus — это набор временных рядов, различающихся комбинацией labels (пар ключ-значение). Запрос без фигурных скобок возвращает все ряды с данным именем; оператор = внутри {} фильтрует по точному совпадению значения label, != — по несовпадению, =~ и !~ — по регулярному выражению. Пример кода Что использовать на практике Практика. при построении дашборда или алерта почти всегда нужно сузить выборку до конкретного сервиса/окружения, иначе график смешает данные разных инстансов. Полезно сначала посмотреть доступные labels метрики через вкладку "Metrics explorer" в Grafana или curl к /api/v1/series, а затем писать точный фильтр. Практика. Выполнение второго запроса в Prometheus
JuniorPython Developer > Основы Python > Внешние интеграции
Как вызвать внешний API через библиотеку requests и корректно обработать таймаут?
Короткий ответ Нужно явно передавать параметр timeout в вызов requests.get/requests.post и оборачивать вызов в try/except, обрабатывая requests.exceptions.Timeout и requests.exceptions.RequestException отдельно от бизнес-логики успешного ответа. Как это работает подробнее без явного timeout запрос может "висеть" бесконечно, если внешний сервис не отвечает, занимая поток/соединение и потенциально истощая пул ресурсов приложения. timeout можно задать как одно число (на соединение и чтение вместе) или tuple (connect_timeout, read_timeout). Пример кода Что использовать на практике Рекомендация. таймаут стоит выбирать исходя из SLA внешнего сервиса и допустимой задержки для вашего пользователя, а не ставить "на глаз" — слишком маленький таймаут даст ложные обрывы под нагрузкой, слишком большой — удержит ресурсы при реальном отказе внешнего сервиса. При таймауте нужно решить: вернуть пользователю ошибку, попробовать retry, или отдать fallback-данные — выбор зависит от критичности операции. Подводные камни Риски. вы
SeniorSMM Manager > Общее > Публикация и кампании
Как выстроить протокол эскалации для отката кампании, когда решение нужно принять за считанные часы, а не все данные ещё доступны?
Короткий ответ Единственно верного баланса между скоростью решения и полнотой данных не существует — нужно заранее определить, кто имеет полномочия принять решение об откате при неполных данных (обычно это заранее назначенный ответственный с правом единоличного решения в экстренной ситуации), и установить, какой минимальный набор сигналов достаточен для экстренного решения, принимая, что это решение может оказаться неоптимальным при последующем полном анализе. Как это работает подробнее протокол эскалации обычно описывает уровни серьёзности ситуации (от «требует мониторинга» до «требует немедленной остановки») и для каждого уровня — кто принимает решение, за какое время и на основе каких минимальных данных, без ожидания полного набора аналитики. Сравнение Компромисс. вариант А — делегировать единоличное право экстренной остановки одному ответственному (например, руководителю SMM) по ограниченному набору явных триггеров: плюс — скорость, минус — риск ошибочного решения без коллегиального обсуждения; вариант Б
MiddleSMM Manager > Общее > Публикация и кампании
Как действовать, если пост, вызвавший волну негатива, уже набрал широкий охват и репосты?
Короткий ответ Нужно сначала проверить факты и причину негатива, согласовать позицию с руководством и, при необходимости, юристом, прежде чем предпринимать публичные действия, и только после этого решать — редактировать, оставлять с официальным комментарием или удалять, понимая, что удаление уже распространённого поста редко останавливает негатив и может усилить подозрения. Как это работает подробнее при широком охвате и репостах скриншоты поста уже распространились за пределы управляемого аккаунта, поэтому удаление не убирает контент из инфополя — решение должно учитывать, что увидит аудитория дальше: тишину, извинение, объяснение или исправление по существу. Что использовать на практике На практике. быстрая, но непроверенная реакция может усугубить ситуацию, если факты позже окажутся неполными; при этом слишком долгое молчание тоже воспринимается негативно — нужен баланс между скоростью и точностью, обычно достигаемый через заранее подготовленный план эскалации с понятными ролями (кто согласует публичный от
MiddlePython Developer > Основы Python > Django и DRF
Как диагностировать проблему N+1 запросов, возникающую при сериализации связанных объектов через DRF ModelSerializer, и как её устранить на уровне view?
Короткий ответ Проблема диагностируется по логам SQL-запросов (например, через django-debug-toolbar или connection.queries в тестах) — при сериализации списка объектов с related-полем выполняется по одному дополнительному запросу на каждый объект; решение — select_related/prefetch_related в queryset view. Как это работает подробнее Сериализатор с полем типа PrimaryKeyRelatedField/вложенным сериализатором для ForeignKey/ManyToMany при обращении к instance.related_field для каждого объекта списка вызывает отдельный SQL-запрос, если связанные данные не были заранее загружены вместе с основным queryset. Пример кода Что использовать на практике Практика. select_related('author') используют для ForeignKey/OneToOne (JOIN в одном запросе), prefetch_related('tags') — для ManyToMany/обратных ForeignKey (отдельный запрос с последующим Python-соединением в памяти). Это нужно применять именно в queryset, который передаётся в ListAPIView/viewset (get_queryset), а не в самом сериализаторе. Подводные камни Риск. Добавляют se
MiddleSMM Manager > Общее > Площадки и основы SMM
Как корректно поставить KPI для A/B-теста «карусель против Reels» на одну и ту же тему контента?
Короткий ответ Нужно заранее определить одну главную метрику успеха, соответствующую цели теста (например, ER по охвату или переходы по ссылке в профиле), зафиксировать равные условия публикации (похожее время, отсутствие параллельных платных кампаний, сопоставимая тема), и только после этого сравнивать результаты — иначе разница в форматах смешается с разницей в условиях публикации и выводы будут ненадёжны. Как это работает подробнее у карусели и Reels разные встроенные метрики (глубина просмотра слайдов против процента досмотра видео), поэтому для честного сравнения нужна общая метрика более высокого уровня — ER по охвату, количество сохранений или переходов, а не сравнение несопоставимых внутренних показателей каждого формата. Что использовать на практике Рекомендация. тест стоит планировать на нескольких парах публикаций (не на одной паре), чтобы сгладить случайные колебания охвата, и заранее решить минимальный срок наблюдения (например, 7 дней на пост), прежде чем снимать итоговые цифры. Подводные камни