Role Specific Job Understanding Questions

Covers familiarity with specific job families and titles and the typical responsibilities and challenges associated with them. Examples include customer success, project management, account management, business intelligence, operations, sales operations, and executive roles such as vice president positions. Candidates should show domain knowledge about daily tasks, common tools, stakeholder interactions, and specific outcomes expected in those named roles, and ask role specific questions about scope and priorities.

HardSystem Design

28 practiced

Hard: Propose an SLA and escalation path for a BI service that guarantees report availability to executives. Include monitoring thresholds, on-call rotations, runbooks, and the communication templates for different incident severities.

Sample Answer

Requirements & SLAs- Scope: Executive-facing BI reports/dashboards delivered via Tableau/Power BI/Looker and underlying ETL/warehouse pipelines.- Availability SLA: 99.9% uptime for dashboards during business hours (Mon–Fri 7:00–20:00 local) — ≤8.8 minutes downtime/month. Data freshness SLA: critical executive reports updated within X hours (e.g., hourly or EOD depending on report).- RTO (Recovery Time Objective): Sev1: 1 hour; Sev2: 4 hours; Sev3: 24 hours.- RPO (Data loss): Sev1: ≤15 minutes; Sev2: ≤1 hour; Sev3: ≤24 hours.

Monitoring & Thresholds- Synthetic dashboard render check every 1 minute; alert on >3 consecutive failures.- ETL job success/fail status per run; alert on failure or duration >150% of baseline.- Data freshness metric per dataset; alert if lag > SLA threshold (e.g., >65 minutes for hourly feeds).- Query latency: alert if median dashboard load >5s or 95th percentile >15s.- Error rates: alert if API/connector errors >1% of requests in 10m window.- Health dashboard aggregating these signals for on-call.

On-call Rotation- Primary on-call (BI engineer/analyst): 1-week rotation, weekdays 7:00–20:00; secondary on-call for nights/weekends.- Escalation chain: Primary → Secondary (30 min) → BI Lead (30 min) → Data Platform/SRE (60 min) → CTO/stakeholder (as needed).- Handover: 15-minute overlap + written notes in shared on-call doc.

Runbooks (short summary, each as checklist)Sev1 (dashboard unavailable or stale for execs)1. Triage: Confirm incident via synthetic check and user reports. Record time and impacted reports.2. Scope: Identify affected layer — visualization, BI service, API, ETL, or warehouse.3. Immediate fixes: - If visualization service down: restart service/container, check service logs, revert recent deploy. - If ETL failed: re-run job, apply idempotent reprocessing for missing partitions. - If DB overloaded: throttle heavy queries, enable read-replica failover.4. Communication: Send initial incident notice (see template).5. Workaround: Provide CSV exports, screenshot snapshots, or cached static PDF reports to execs.6. Postmortem: Within 48 hours; root cause, actions, follow-up timeline.

Sev2 (partial impact / performance)- Investigate slow queries, cache TTLs, card-level timeouts; implement temporary cache warm or increase resources; notify stakeholders with ETA.

Sev3 (non-critical)- Log, schedule fix in next sprint, notify requestor.

Communication TemplatesInitial (within 10 min for Sev1):Subject: [INCIDENT] Executive BI Reports unavailable — investigatingBody: We are investigating an issue affecting executive dashboards (impacted: [list]). First detected: [time]. Users impacted: Execs. Immediate action: on-call BI is triaging. ETA initial update: 20 minutes. Workaround: [e.g., CSV export available]. Contact: on-call [name, phone, slack].

Update (every 30 min):Subject: [UPDATE] Executive BI — ongoingBody: Current status: [triage progress]. Actions taken: [restarts, re-runs]. Next ETA: [time]. Impact: [scope]. Temporary access: [link or contact].

Resolution:Subject: [RESOLVED] Executive BI incidentBody: Issue resolved at [time]. Root cause (prelim): [short]. Actions taken: [fixes]. Data integrity: [confirm reprocessing/reconciliation]. Postmortem timeline: [date]. Contact: [owners].

Postmortem Summary Template (within 48 hours)- Summary, timeline, root cause, detection gaps, mitigation, permanent fixes, owners, metrics to monitor, closure criteria.

Additional Practices- Run synthetic SLA tests publicly visible to execs (status page).- Monthly SLA review with stakeholders; capacity planning if alerts frequent.- Automate common runbook steps (restart scripts, re-run ETL jobs) and test in staging.- Maintain playbook and on-call rota in shared ops repo; require on-call shadowing for 2 weeks before primary duty.

This SLA and path ensure fast detection, clear ownership, practical workarounds for executives, and structured follow-up to prevent recurrence.

MediumSystem Design

33 practiced

Medium: Describe how you would evaluate a BI tool change (e.g., migrating from Tableau to Looker) from the perspective of costs, training, reporting capability, semantic layer support, and stakeholder disruption. What steps would you take to pilot and roll out the change?

Sample Answer

Requirements & constraints:- Minimize disruption to business reporting and decision-making.- Match or improve existing visualization & data model capabilities (Tableau → Looker).- Control total cost of ownership (license, infra, dev effort, training).- Maintain data governance, lineage, and performance SLAs.

High-level approach:1. Discovery & inventory- Catalog dashboards, owners, data sources, refresh cadence, usage metrics, KPIs, and complexity (custom SQL, table calculations, LODs).- Identify critical reports (SLA/ROI), regulatory reports, and kill-switch candidates.

2. Cost analysis- Compare licensing (per-seat vs. concurrent), LookML development effort, infra (BI DB compute), cost to refactor complex logic, and ongoing support.- Estimate one-time migration hours + recurring maintenance. Build ROI scenarios (3–24 month).

3. Technical feasibility & capability mapping- Map Tableau features to Looker alternatives: calculated fields → LookML measures/dimensions, table calculations → derived tables or persistent derived tables (PDTs), parameterized controls → Looker liquid/filters.- Validate semantic layer parity: model reuse, consistent business logic, version control (git), and lineage.- Performance testing on representative datasets.

4. Stakeholder impact & training- Segment users: execs, analysts, casual consumers. Define training curriculum: admins, power-users, end-users.- Create cookbook: LookML patterns for common KPI translations, migration playbook for typical dashboard patterns.- Estimate support load during cutover.

Pilot & rollout plan:1. Pilot (4–8 weeks)- Pick 3–5 representative dashboards: one executive, one operational, one complex analytic.- Build LookML models and dashboards; run parallel validation against Tableau outputs (row-level reconciliations, aggregations).- Measure performance, accuracy, UX gaps, and gather user feedback.- Success criteria: 1) parity in KPIs, 2) acceptable performance (<15% slower), 3) user satisfaction (>80% in pilot poll).

2. Phased migration- Phase 1: Migrate critical/high-value dashboards and train corresponding owners; keep Tableau read-only/archival.- Phase 2: Migrate high-usage departmental reports; expand training & create office-hours support.- Phase 3: Decommission remaining Tableau reports after verification and archive snapshots.

Risk mitigation & governance:- Dual-run period with clear rollback plan and Tableau as source of truth until reconciled.- Maintain change log, automated tests (CI for LookML), and reconciliation scripts.- Executive sponsor and data-steering committee to prioritize and arbitrate trade-offs.

Metrics to track:- Migration velocity (dashboards/week), reconciliation pass rate, end-user adoption, support tickets, cost delta, and query performance.

Outcome: measurable, low-risk migration with governed semantic layer, trained users, and a path to reduce costs and improve model reuse.

MediumTechnical

39 practiced

Medium: Describe a repeatable QA checklist you would enforce before shipping a dashboard to the business. Include data checks, visual checks, performance tests, documentation, and sign-off steps.

Sample Answer

Below is a repeatable QA checklist I would enforce before shipping any BI dashboard. It’s practical, tool-agnostic, and designed for Tableau/Power BI/Looker + SQL backends.

Data validation (must pass)- Source-to-target row counts: compare upstream table counts vs dashboard-level aggregates (±0% tolerance for financials; small tolerance for streaming data).- Key metric reconciliation: validate top KPIs with independent SQL queries (spot-check 5–10 cells across dates/segments).- Nulls & unexpected values: run checks for NULL, negative, or out-of-range values and for data type mismatches.- Refresh & incremental load: confirm last refresh timestamp and that incremental logic didn’t miss partitions.- Dim conformance: verify joins (FKs) have expected coverage; test slowly changing dimension behavior.

Visual / UX checks- Filter and interaction tests: confirm filters, drilldowns, cross-highlighting and bookmarks work for representative user paths.- Labeling & units: all axes, legends, and tooltips include units, date grain, and data source notes.- Accessibility & responsiveness: check color contrast, keyboard/tab navigation, and layout at common screen sizes.- Annotations & alerts: ensure threshold lines and conditional formatting render correctly.

Performance & reliability- Load time baseline: dashboard initial load < 5s (desktop execs) and < 8s for complex ones; interaction latency < 500ms for common actions.- Query profiling: capture slow queries, add indexes/materialized views or pre-aggregations as needed.- Concurrency test: simulate expected user concurrency (e.g., 5–20 users) to observe caching and DB load.

Documentation & governance- README: purpose, audience, data sources, refresh cadence, owner, and known limitations.- Data dictionary: definitions for each KPI, calculation SQL/formula, grain, and last validated date.- Versioning: store dashboard version, change log and deployment ticket/PR reference.

Sign-off & release- Peer review: at least one peer BI review + developer or data engineer validation for SQL logic.- Stakeholder UAT: business stakeholder verifies 3–5 representative scenarios and signs off in ticketing system.- Post-release monitoring: schedule automated smoke checks and a 48–72h review to catch anomalies; rollback plan documented.

Example: before shipping a monthly revenue dashboard I run SQL reconciliations for MTD/MTD-last-year, verify filter permutations for top 3 regions, ensure initial load <4s, update the data dictionary, get PM + finance sign-off, and enable a nightly smoke query that emails on large variance.

MediumSystem Design

31 practiced

Medium: Design a lightweight SLA and monitoring approach for ETL jobs that feed your BI dashboards. Include what to monitor (latency, row counts, schema changes), alerting thresholds, and how you would communicate incidents to stakeholders to maintain trust.

Sample Answer

Requirements & goals:- Lightweight SLA: ensure dashboards are updated within business windows, data correctness, and schema stability with minimal ops overhead.- Target audience: product owners, analysts, ops, execs.

SLA definition (examples):- Freshness: critical dashboards must reflect source systems within 1 hour; non-critical within 4 hours.- Completeness: row-count parity >= 99.5% vs source aggregates for each load window.- Schema stability: no breaking schema change without 24h notice.- Success rate: nightly ETL success >= 99%.

What to monitor:- Job status: success/failure and runtime.- Latency/freshness: time between source event and dashboard update.- Row counts & high-level aggregates: total rows, key KPI sums, distinct counts.- Schema fingerprint: column names, types, nullability, partition keys.- Data quality checks: null-rate thresholds, referential integrity samples, duplicate key counts.- Resource anomalies: retries, backfill attempts, queue/backpressure metrics.

Alerting thresholds & actions (examples):- Job failure: immediate P1 alert to on-call + Slack + email.- Latency breach (> SLA): P2 alert if > 2x SLA for critical dashboards; include last successful run, ETA to recover.- Row-count delta > 0.5% but <2%: warning to data owners; >2%: P2 alert.- Schema change detected: P1 to data engineering and BI if column removed/renamed; P3 if a new nullable column added.- Repeated transient failures (3 in 1 hour): escalate to on-call.

Monitoring implementation (lightweight):- Use existing stack: scheduler hooks (Airflow), simple monitoring pipeline that emits metrics to Prometheus/Datadog and stores baseline aggregates in a metadata DB.- Small daily "health" job: compare expected row counts & fingerprints; produce digest.- Alerting rules in Datadog/PagerDuty; use templated messages with run links and quick remediation steps.

Incident communication to maintain trust:- Immediate: automated alert + concise Slack channel post with what failed, impact (dashboards affected), ETA for fix or mitigation (if known), and run links.- Within 30 minutes: incident summary to stakeholders (POs, analysts, ops) via email/Teams with scope, root cause hypothesis, and mitigation steps (e.g., manual backfill, disable feature).- Resolution: note actions taken, time to recovery, and verification steps (e.g., row-counts back to baseline).- Postmortem within 3 business days: blameless write-up with timeline, root cause, corrective actions, and SLA/alert tuning.- Maintain transparency: publish dashboard showing pipeline health and SLA compliance accessible to stakeholders.

Why this works:- Balances low operational overhead with business-relevant signals (freshness, completeness, schema).- Clear thresholds map to business impact and drive appropriate urgency.- Fast, structured communication preserves stakeholder trust and creates feedback loops for continuous improvement.

MediumTechnical

35 practiced

Medium: Describe how to build a dashboard that different audiences (executives, managers, individual contributors) can all use: discuss layout, filtering strategy, data granularity, and training materials you would provide for each audience.

Sample Answer

Situation: Building a single BI dashboard that serves executives, managers, and individual contributors while remaining performant and easy to use.

Layout:- Top row: KPI summary (3–6 KPIs) with current value, trend sparkline, and variance vs target — aimed at execs for a one-glance health check.- Middle: Manager view — cohort breakdowns, segment comparison, and actionable drivers (top 3 contributors to change).- Bottom / right panel: Detailed tables and event-level visualizations for ICs to investigate root causes.- Use a consistent visual language (colors, fonts, icons) and progressive disclosure: start high-level and allow drill-downs.

Filtering strategy:- Global filters for time range, region, product to set context.- Scoped filters per section (e.g., manager area pre-filtered to team/region based on user role).- Cross-filtering enabled so clicking a chart filters related views.- Provide sensible defaults (last 30/90 days) and reset button.

Data granularity:- Aggregates for KPIs (daily/weekly/monthly) for performance and trend accuracy.- Intermediate-level aggregates (team, channel) for managers.- Ability to access raw/event-level records behind the dashboard for IC troubleshooting — either via linked report or parameterized table with sampling/pagination to protect performance.

Access & personalization:- Row-level security to show only relevant data.- Saved views and subscriptions for execs (email PDF), managers (weekly digest), and ICs (real-time alerts).

Training / materials per audience:- Executives: One-page cheat sheet + 15-min walkthrough video showing how to read KPIs and subscribe to snapshots.- Managers: 30–45min workshop + playbook with common queries, how to use filters, and how to interpret driver charts; include 2–3 scenario-based exercises.- Individual contributors: Hands-on session (60min) + searchable FAQ and step-by-step guide for drilling to raw data, exporting, and troubleshooting patterns.- Maintain a short release notes log and sample queries/LookML/SQL snippets for power users.

Measurement & iterate:- Instrument usage (click paths, filter usage) and run quarterly feedback sessions to simplify or expand features based on real usage.

Unlock Full Question Bank

Get access to hundreds of Role Specific Job Understanding interview questions and detailed answers.

Join thousands of developers preparing for their dream job.