Automated Reporting & Report Development Questions
Build automated reports that refresh on schedule. Understand refresh schedules, data pipeline integration, and deployment to production. Create parameterized reports for different stakeholder needs. Know how to version control and manage report changes.
MediumTechnical
66 practiced
Write a SQL-based data quality test to detect duplicate orders and extreme outliers in order_amount per customer. Given schema:Describe how you'd integrate this test into a CI pipeline to block report deployments if it fails.
orders(order_id INT, customer_id INT, order_ts TIMESTAMP, order_amount NUMERIC)Sample Answer
Approach: write two SQL tests — one to detect duplicate orders (same customer_id + order_ts or same order_id repeated) and one to detect extreme outliers in order_amount per customer using robust statistics (IQR) per-customer or global z-score if sample small. Fail if any rows returned or if > threshold percent of customers have outliers.Duplicates test:Outliers test (per-customer IQR; flag customers with extreme orders):Reasoning:- Duplicates: exact duplicates indicate ingestion/ETL bugs.- IQR with multiplier 3 reduces false positives vs z-score; per-customer handles varying spending patterns.- Fail criteria: any row returned from duplicates OR if flagged rows > X orders or affect > Y% customers (e.g., 1%) then test fails.CI integration:- Add these SQL checks as steps in the data/BI CI pipeline (dbt tests, Airflow task, or a CI job that runs SQL against a snapshot/staging replica).- Run against latest production-like data before report deployment. If query returns rows (or exceed threshold) exit non-zero to block deployment.- On failure: create ticket + notify Slack/email with sample failing rows and suggested triage (ETL job, data source).- Add metadata: run frequency, tolerance thresholds, and automatic acceptance override only via PR with justification and owner sign-off.Edge cases & mitigations:- New customers with few orders — require min_n (e.g., at least 5 orders) before IQR.- Seasonal/promotional spikes — tune multiplier or whitelist known campaigns by tagging orders.- Performance: pre-aggregate indexes on customer_id and order_ts; limit CI run to recent window (e.g., last 90 days) for speed.
sql
-- duplicate orders by order_id or same customer+timestamp
WITH dup_order_ids AS (
SELECT order_id, COUNT(*) AS cnt
FROM orders
GROUP BY order_id
HAVING COUNT(*) > 1
),
dup_customer_ts AS (
SELECT customer_id, order_ts, COUNT(*) AS cnt
FROM orders
GROUP BY customer_id, order_ts
HAVING COUNT(*) > 1
)
SELECT 'dup_order_ids' AS issue, order_id::text AS key, cnt
FROM dup_order_ids
UNION ALL
SELECT 'dup_customer_ts', customer_id::text || '|' || order_ts::text, cnt
FROM dup_customer_ts;sql
WITH stats AS (
SELECT customer_id,
percentile_cont(0.25) WITHIN GROUP (ORDER BY order_amount) AS q1,
percentile_cont(0.75) WITHIN GROUP (ORDER BY order_amount) AS q3
FROM orders
GROUP BY customer_id
),
flagged AS (
SELECT o.*
FROM orders o
JOIN stats s USING (customer_id)
WHERE o.order_amount < (s.q1 - 3*(s.q3 - s.q1))
OR o.order_amount > (s.q3 + 3*(s.q3 - s.q1))
)
SELECT * FROM flagged;EasyBehavioral
68 practiced
Tell me about a time when you had to change or deprecate a widely used report. Explain how you planned the change, communicated with stakeholders, managed access to the old report, handled versioning, and what you learned from the experience.
Sample Answer
Situation: Our finance team relied on a monthly revenue reconciliation report I owned in Looker that had been in use for three years. The data model underneath changed (new invoice table and business rules), so keeping the old report risked misleading decisions.Task: I needed to introduce a new, corrected report, retire the old one safely, and ensure minimal disruption to finance, sales, and exec stakeholders.Action:- Planning: I mapped every consumer of the report (scheduled emails, dashboard links, automation jobs) and created a phased deprecation plan with timelines: parallel run (2 months), warning period (30 days), read-only archive (60 days), then delete.- Communication: I announced the change in a kickoff email to all consumers, presented the differences in a short demo to finance and sales leads, and posted an FAQ in our team channel. I included a clear playbook: what changes they’d see, why, and who to contact.- Managing access: During the parallel run both reports co-existed. I set the old report to read-only (disabled scheduling and API access) after the first month to prevent new dependencies. I created an archive folder with a timestamped copy for audits.- Versioning: The new report used semantic naming: ReportName v2 (date). I updated all internal links and created a redirect page listing canonical reports and their versions. I tagged the data model and report in our repo with Git commits for traceability.- Risk mitigation & monitoring: I ran reconciliation checks and built a small validation dashboard comparing key KPIs between versions weekly. I scheduled office hours for questions and kept a rollback plan (restore scheduling) if a critical issue emerged.Result: Adoption was smooth — by the end of the parallel run 95% of consumers had switched to v2, support tickets dropped 80% compared to prior major changes, and audit requests were satisfied using the archived copy. Finance reported more accurate month-end close numbers.Learnings: Early stakeholder mapping and running both versions in parallel greatly reduce risk. Clear naming, disabling rather than immediately deleting the old asset, and automated validation checks make deprecation auditable and low-friction. In future I’d add an automated dependency scanner to catch hidden references sooner.
EasyTechnical
70 practiced
Describe the trade-offs between extracts (data extracts/extract-based datasets) and live connections from BI tools to the warehouse. Address performance, freshness, cost (compute), security, and maintenance for scheduled automated reports in enterprise settings.
Sample Answer
Situation: As a BI analyst deciding between extracts (materialized datasets) and live connections to the warehouse, you balance performance, freshness, cost, security, and maintenance for scheduled automated reports.Trade-offs:- Performance - Extracts: Fast dashboard load and predictable SLAs because precomputed data lives in the BI tool or a cache — good for heavy visualizations and concurrent users. - Live connections: Dependent on warehouse query performance and concurrency; can be slower under load and cause variable response times.- Freshness - Extracts: Stale by design; refresh frequency determines timeliness (hourly/daily). Best for historical/operational reports that tolerate lag. - Live: Near real-time; ideal for time-sensitive metrics.- Cost (compute) - Extracts: Cost shifts to scheduled refresh jobs (batched compute). Usually cheaper overall for frequent dashboard views since queries run once per refresh. - Live: Repeated ad-hoc queries increase warehouse compute and concurrency costs, especially with many users or complex visuals.- Security & governance - Extracts: Requires careful handling of exported data; needs access controls, encryption, and refresh workflows to enforce row-level security. Potential risk if extracts are saved outside governed systems. - Live: Centralized in warehouse so governance, RLS, auditing, and PII controls are easier to enforce.- Maintenance - Extracts: Manage refresh schedules, storage, and schema drift; need monitoring for failed refreshes and versioning. - Live: Less extract-management overhead but requires query optimization, warehouse tuning, and monitoring for runaway queries.Recommendation: Use extracts for high-concurrency, stable reports where latency tolerance exists; use live connections for real-time needs, sensitive data that must stay centralized, or ad-hoc exploration. Hybrid approach: extracts for dashboards, live for alerts/operational queries; implement governance, caching, and cost controls (query limits, materialized views, scheduled refresh cadence) to balance trade-offs.
EasyTechnical
62 practiced
A scheduled daily dashboard failed to refresh overnight and stakeholders noticed yesterday's data still showing this morning. Describe step-by-step how you would investigate and resolve the issue. Include which logs, monitoring metrics, and stakeholders you would involve, and how you would communicate status and ETA to affected users.
Sample Answer
Situation: Overnight the daily executive dashboard did not refresh; stakeholders saw yesterday’s data at morning review.Step-by-step investigation & resolution:1. Triage (first 15–30 min)- Confirm scope: ask stakeholders which dashboard, which visuals, expected refresh time, and whether other reports are affected.- Check scheduler/status page (Airflow/DBT/cron/Power BI Gateway/Looker scheduler) for failed runs or delays.2. Inspect logs & metrics- Scheduler logs: job start/finish, error messages, exit codes.- ETL/ingestion logs (Airflow task logs, DBT run logs, Glue logs) for upstream failures.- Database logs and query history (slow queries, failed transactions) and row counts for source tables.- BI tool logs (Tableau/Power BI/Looker refresh logs) for authentication, timeout, or data source errors.- Monitoring metrics: data latency, job duration, CPU/memory on ETL nodes, DB connection/connection pool usage, failed API calls.3. Identify root cause- If ETL failed: fix code, re-run the job, validate source data.- If DB issue (locks/replication): coordinate with DBAs to resolve and run appropriate recovery.- If BI tool refresh failed (credential expired, gateway down): update credentials or restart gateway and retry refresh.4. Remediation & validation- Re-run failed tasks in isolation; verify incremental/full refresh depending on data volume.- Spot-check key KPIs and row counts, compare with source.- If long replay needed, run targeted backfill for missing days.5. Stakeholder communication- Immediate: send short incident note within 30 minutes to affected users with: what’s impacted, initial findings, next steps, and ETA for fix (e.g., “Investigating; estimated fix 60–90 minutes”).- Ongoing: provide hourly status updates or sooner on major changes.- Resolution: confirm fix, describe root cause, validation steps taken, and any mitigation to prevent recurrence.- Postmortem: within 48–72 hours share a blameless report with timeline, root cause, corrective actions, and SLA impact.Stakeholders to involve:- Data engineering/ETL owner (if ingestion related)- DBA or infra/ops (if DB or gateway issues)- BI platform admin (Tableau/Power BI/Looker)- Product/Business owners and executive stakeholder(s) for impacted dashboards- Support/Service desk if SLAs or downstream tickets are affectedPrevention & follow-up:- Add alerting on job failures, data latency, and KPI thresholds.- Implement retries with exponential backoff, health checks for gateways, and a runbook describing these steps.- Review SLA and update stakeholders on changes.This approach ensures fast containment, transparent communication, root-cause resolution, and actions to prevent recurrence.
HardTechnical
76 practiced
Design a multi-region automated reporting setup for low-latency dashboards in three continents with local data residency constraints. Discuss data replication/ETL strategies, consistency models, conflict resolution, and how to keep report automation (scheduling, versioning) consistent across regions while controlling cost.
Sample Answer
Requirements & constraints:- Low-latency dashboards on 3 continents, data residency per continent, global analytical views occasionally needed, cost-sensitive, eventual freshness SLA (e.g., <5 min for local, hourly for cross-region aggregates).High-level architecture:- Local region: ingestion → raw zone (local data lake / cloud storage) → regional ETL → regional reporting warehouse (columnar store: BigQuery/Redshift/Snowflake or Snowflake reader accounts) → BI layer (Tableau/Looker/Power BI) served from regional clusters.- Global aggregation: scheduled, privacy-compliant aggregate export (no PII) from regional warehouses to a central analytics region for cross-region reporting.Data replication / ETL strategy:- Use push-based CDC for event sources (Debezium / cloud CDC) into region-local Kafka/topic or cloud ingestion service, then lightweight regional transform (dbt/ETL) to produce denormalized reporting tables optimized for dashboards.- For cross-region needs, publish only aggregated, anonymized materialized views (e.g., daily/hourly aggregates) to central store via secure transfer (encrypted S3/GCS buckets or controlled Snowflake shares) to respect residency.- Keep raw PII data strictly local; replicate only synthetic/aggregated datasets that comply with residency rules.Consistency models & conflict resolution:- Local dashboards: strong read-after-write within the region (ETL writes then marks tables ready). Use transactional writes or atomic swaps of table partitions to ensure consistency.- Cross-region: eventual consistency acceptable. Use timestamped, idempotent upserts for aggregates; adopt last-writer-wins for commutative aggregates or CRDT-like strategies for counters (merge-sum).- Maintain provenance metadata (region, window, schema version) for audit and conflict debugging.Report automation, scheduling & versioning:- Centralized CI/CD for ETL/semantic model (dbt + git) with region-specific branches/configs. Use infra-as-code to deploy ETL jobs and BI model changes per region.- Scheduling: region-local orchestrator (Airflow / cloud Composer) per region for low-latency tasks; a central orchestrator for cross-region jobs. Use event-driven triggers (CDC stream) for near-real-time local refresh and time-based jobs for global aggregates.- Versioning: tag transforms and BI semantic layers together; include schema and model versions in table metadata. Automate canary rollouts in one region before global promotion.Cost control:- Use tiered storage: hot regional warehouses for active dashboards; cold object storage for raw/older partitions and infrequent cross-region joins.- Materialize only necessary aggregates for global needs; prefer aggregated transfers over full replication to reduce egress.- Rightsize compute with autoscaling, query caching, BI extracts for heavy dashboards, and query optimization (denormalized star schemas).- Monitor costs via tagged resources and alerts; run periodic TTL cleanup of intermediate datasets.Operational & governance:- Automated tests (data quality, row-count, schema) in CI pipeline; audit logs for data transfers; privacy checks before cross-region exports.- Runbook for conflict incidents; SLA definitions per dashboard; stakeholder communication via release notes when semantic models change.This design balances local low-latency, compliance, and cost by keeping raw data local, pushing only compliant aggregates globally, using region-local orchestration for speed, and centralized versioned CI/CD for consistency.
Unlock Full Question Bank
Get access to hundreds of Automated Reporting & Report Development interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.