Airbnb Senior Business Intelligence Analyst Interview Preparation Guide

Direct answer
Additive seasonality assumes the seasonal swing is a roughly constant absolute amount regardless of the series' level; multiplicative seasonality assumes it scales proportionally with the level. Choosing the wrong one distorts both baselines (an additive model under-predicts the seasonal swing at a high level, or over-predicts at a low one) and anomaly thresholds (a fixed-width band around an additive baseline will be too tight during high-level periods and too loose during low-level ones).

Structured elaboration

• Additive: $y_t = \text{trend}_t + \text{seasonal}_t + \text{residual}_t$ - the seasonal swing stays roughly the same size in absolute units no matter what the trend level is doing.
• Multiplicative: $y_t = \text{trend}_t \times \text{seasonal}_t \times \text{residual}_t$ - the seasonal swing grows or shrinks proportionally with the trend level; a multiplicative model can be fit as an additive one on the LOG of the series, since $\log(y_t) = \log(\text{trend}_t) + \log(\text{seasonal}_t) + \log(\text{residual}_t)$.
• Which metrics favor which: revenue-style metrics that grow substantially over time, where the seasonal spike naturally grows alongside the business (e.g. a December bump that's proportionally consistent but has grown from $10K to $50K as the business scaled), are usually multiplicative. Metrics with a roughly stable base level and a genuinely fixed-size seasonal effect (e.g. a fixed number of extra support tickets every Monday, regardless of overall ticket volume trend) are more often additive.
• Testing which model fits better: the simplest visual test is whether the peak-to-trough seasonal amplitude visibly GROWS alongside the trend on a raw plot - if it does, additive is the wrong assumption. More formally, fit both, compare residual variance (an additive fit on a genuinely multiplicative series will show residual variance that itself grows with the level, a clear diagnostic on a residual-vs-fitted plot), or simply compare backtested forecast error between the two.
• Why the choice matters for baselines/anomaly detection: an anomaly-detection threshold built on additive-model residuals (e.g. "flag anything more than 3 residual-standard-deviations away") implicitly assumes constant residual variance across the whole series; if the true process is multiplicative, that fixed threshold will be too sensitive (false positives) during low-level periods and too insensitive (missed real anomalies) during high-level periods.

Worked example
Two metrics side by side: daily active users growing from 10,000 to 100,000 over two years, with a weekend dip that's always been roughly 15% below the weekday average - that's multiplicative (the absolute size of the dip has grown 10x alongside the user base, but the RATIO has stayed constant). A metric like "number of scheduled maintenance windows per week," with a fixed operational cadence unrelated to overall traffic growth, is more likely additive.

Trade-offs & pitfalls
Log-transforming to convert a multiplicative problem into an additive one is convenient (lets you reuse additive-model tooling) but changes how you have to interpret and back-transform prediction intervals - a symmetric interval in log-space becomes an ASYMMETRIC interval once exponentiated back to the original scale, which is correct behavior (uncertainty genuinely should be asymmetric on a multiplicative series) but is easy to get wrong if you forget to back-transform properly.

Direct answer

Structuring this conversation means showing the actual trade-off explicitly, how much conversion moves versus how much retention moves, and over what time horizon each pays off, rather than letting the debate stay abstract; the recommendation then depends on which horizon the business can afford to prioritize right now, not on which metric sounds more urgent in the room.

Structured elaboration

The first step is to make sure both sides are looking at comparable evidence: pull the historical or experimental relationship between the specific onboarding elements under debate and each of the two metrics, since "prioritize conversion" and "prioritize retention" often are not actually in tension for every possible onboarding change, only for the specific ones being proposed. Where they genuinely trade off, the useful visualization is a simple two-axis comparison: short-term conversion lift on one axis, medium-term retention impact on the other, for each candidate onboarding change under discussion, so stakeholders can see which changes are win-win, which are a genuine trade-off, and which help neither.

For changes that are a genuine trade-off, the recommendation should hinge on an explicit, quantified comparison of value over time: a conversion gain realized immediately versus a retention gain that compounds over a longer horizon (since a retained user keeps generating value repeatedly, while a one-time conversion does not) usually favors retention when the horizon is long enough, but that conclusion depends on the business's actual runway and near-term revenue needs, which is a business input the data alone cannot supply, so naming that dependency explicitly to the room is part of a well-structured recommendation, not a hedge.

Worked example

Suppose a proposed onboarding change is projected to lift conversion by 2 percentage points immediately but reduce 90-day retention by 4 percentage points relative to the current flow, based on a completed A/B test. If the product monetizes primarily through a one-time purchase, the immediate conversion lift may dominate, since there is little future retained-user value being given up. If instead the product monetizes through an ongoing subscription where a retained user generates revenue every month, the 4-point retention loss compounding over many months of subscription revenue is very likely to outweigh a one-time 2-point conversion gain, and laying out that monthly-compounding comparison explicitly, rather than debating "conversion versus retention" as two competing slogans, is what turns the disagreement into a decision.

Trade-offs and pitfalls

The most common failure in this kind of conversation is treating it as a philosophical debate about which metric matters more in general, rather than a specific, quantifiable trade-off for the specific change on the table; grounding the discussion in the actual measured or projected impact of THIS change avoids that trap. It is also worth flagging explicitly when the data does not yet exist to make the trade-off precise (for example, only a short-term A/B test result is available, with no data yet on whether the retention impact persists past 90 days), rather than presenting a confident recommendation built on an extrapolation nobody has validated.

Direct answer. Test the candidate index against a realistic copy of production data and a representative slice of the actual query mix, not just the one query you're trying to speed up, measuring both the target query's improvement and any change in resource usage (write latency, cache pressure, overall throughput) for everything else sharing that instance.

Structured elaboration. Estimating benefit for the ONE target query is the easier half: capture a baseline latency and plan shape before the index, add it (ideally on a staging environment with production-representative data volume and distribution, since selectivity and index size behave very differently on a small dev dataset), and compare after. Estimating blast radius is the harder, easier-to-skip half: every additional index adds write-time cost to every INSERT, UPDATE, and DELETE that touches its columns, and adds ongoing background maintenance and cache pressure, none of which shows up if you only measure the one query you added the index to speed up. A test that runs the target query in isolation, on an otherwise idle instance, will systematically overstate the benefit and completely miss the cost, since neither concurrent write load nor cache contention from other queries is present in that setup.

A more honest test replays (or approximates) the instance's actual concurrent write rate alongside the read-side benchmark, and watches for a REGRESSION in unrelated queries' latency or in overall write throughput, not just an improvement in the target query, before concluding the index is a net win.

Worked example. An index that takes one dashboard query from multi-second and sluggish to near-instant in an isolated test looks like an unambiguous win; the same index, tested under the table's real concurrent write load, might reveal a measurable increase in write latency across every other write to that table, which the isolated test never would have surfaced. Only the second test tells you whether the trade is actually worth it for the system as a whole, not just for the one query someone was staring at.

Trade-offs and pitfalls. It's tempting to treat "the target query got faster" as sufficient evidence to ship, since it's the visible, easy-to-demonstrate half of the story; insist on at least a rough measurement of the write-side and concurrency-side cost too, even if it's less precise than the read-side benchmark, since shipping an index that helps one query while quietly degrading everything else is a worse outcome than not shipping it at all.

Direct answer

Compute a deterministic running total (tie-broken order, since created_at alone can repeat), then locate the row where it first exceeds the threshold using MIN(CASE WHEN running_total > threshold THEN rn END) OVER (PARTITION BY user_id), and mark every row from that point onward as flagged by comparing each row's own tie-broken position to that stored first-crossing marker. The key design choice is comparing against the first-crossing marker, not re-checking running_total > threshold on every row directly: once a row is marked, it stays marked even if a later refund or a NULL amount temporarily pulls the running total back under the threshold, which is exactly what "don't flicker" requires.

Structured elaboration

• Deterministic ordering: ORDER BY created_at, order_id inside every window clause, so ties on created_at resolve the same way every time the query runs; without a tie-breaker, two rows with an identical timestamp have an engine-dependent relative order, and the running total (and therefore the flag) is not reproducible.
• NULL amounts: SUM() (and MIN(), used below) already skip NULL values on their own, so a NULL amount does not poison the running total even without an explicit COALESCE. COALESCE(amount, 0) is still worth writing, not because the math needs it, but because it makes the intended treatment of missing amounts explicit in the query rather than relying on an aggregate's default behavior that a future reader might not know about.
• First-crossing marker: MIN(CASE WHEN running_total > 10000 THEN rn END) OVER (PARTITION BY user_id) relies on the same NULL-skipping behavior; the CASE produces NULL for every row that has not yet crossed the threshold, and MIN ignores those NULLs, landing on the smallest rn where the condition was true.
• Sticky flag: rn >= first_exceed_rn stays TRUE for every row from the first crossing onward, regardless of what the running total does afterward. This is what prevents flicker: the flag is locked onto a position, not re-derived from a live comparison each row.

Worked example

WITH prep AS (
  SELECT order_id, user_id, COALESCE(amount, 0) AS amount, created_at
  FROM orders
),
ordered AS (
  SELECT order_id, user_id, amount, created_at,
    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at, order_id) AS rn,
    SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at, order_id
                       ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_total
  FROM prep
),
flagged AS (
  SELECT *, MIN(CASE WHEN running_total > 10000 THEN rn END) OVER (PARTITION BY user_id) AS first_exceed_rn
  FROM ordered
)
SELECT order_id, created_at, amount, running_total,
  CASE WHEN first_exceed_rn IS NOT NULL AND rn >= first_exceed_rn THEN TRUE ELSE FALSE END AS threshold_reached
FROM flagged ORDER BY order_id;

Executed against 5 orders for one user, including a NULL amount and a same-timestamp tie: order 1 (4000, running total 4000), orders 2 and 3 tied on the same created_at (3000 then 2500, tie-broken by order_id, running totals 7000 then 9500), order 4 (NULL amount, running total unchanged at 9500), order 5 (1000, running total 10500). The flag is false through order 4 and flips to true at order 5, the first row where the running total exceeds 10000.

Trade-offs & pitfalls

• Skipping the tie-breaker on created_at does not just risk a wrong-looking output once; it makes the running total (and therefore exactly which row the flag flips on) non-deterministic across re-runs, which is a correctness bug even when no individual run looks obviously broken.
• Relying on SUM and MIN silently skipping NULL is standard SQL behavior, not an engine-specific quirk, but it is worth stating explicitly in code comments so the next reader does not assume NULL amounts are being dropped from the row set entirely (they are not; only from the aggregate math).
• If the actual requirement is a "reactive" flag that un-sets when the running total dips back under the threshold (say, after a large refund), compare running_total > threshold directly per row instead of locking onto the first-crossing marker; that alternative is simpler but is exactly what reintroduces flicker if amounts can go negative.
• An index on (user_id, created_at, order_id) keeps the window functions' per-partition sort and scan cheap on large tables; without it, every partition's ordering work falls back to an in-memory sort.

Situation: Choosing core collaboration tooling for a global BI org requires balancing discoverability, inclusion, regulatory security/residency, and tight integration with BI pipelines.

Trade-offs and evaluation:

1. Discoverability

• Slack + Confluence: Slack is great for real‑time alerts and ad‑hoc discussion; Confluence provides strong hierarchical docs and page metadata for long‑term knowledge. Search across the two can be good but requires strong taxonomy and page linking to prevent siloed knowledge (alerts in Slack, docs in Confluence).
• Teams + SharePoint: Native single-search surface (Microsoft Graph) across chats, files, and pages improves discoverability. Deep Office integration means dashboards, Excel exports, and meeting notes are easily findable.
• Google Workspace + Looker: Google’s search (Drive + Gmail) is fast and universal; Looker content can be surfaced via Drive or linked, but requires governance to ensure LookML docs live in Drive or Looker’s own catalog.

2. Inclusion for non‑native English speakers

• Slack/Confluence: Offers message translation plugins and Confluence macros; good for asynchronous threads but requires guidelines (thread summaries, simple language). Confluence supports page translations but needs process.
• Teams/SharePoint: Built‑in live captions and meeting transcription in multiple languages; Office file localization and translation services aid comprehension.
• Google Workspace/Looker: Strong built‑in translation in Docs/Slides and auto‑captions in Meet; Looker’s UI is English‑centric but dashboards can include translated labels and content via LookML localization.

3. Security & Data Residency

• Slack/Confluence (Atlassian): Enterprise plans offer SSO, SCIM, eDiscovery, data residency per-product but can be fragmented across offerings. Good for cloud-first orgs; may need add‑ons for advanced DLP.
• Teams/SharePoint (Microsoft 365): Strongest for enterprise compliance — granular DLP, retention policies, legal hold, Azure AD conditional access, and multi‑region data residency controls. Good fit if org already on Azure/Office.
• Google Workspace/Looker: Good compliance footprint and data region controls; Looker (now Google Cloud) allows VPC peering, private IPs, and integrates with Google Cloud IAM — strong if data already in GCP.

4. Integration with BI flows

• Slack + Confluence: Slack is great for alerts (scheduled report pings, anomaly notifications) and Confluence serves as runbooks and requirements. Integrations with Looker/Tableau via webhooks and bots are mature but sometimes third‑party.
• Teams + SharePoint: Tight integration with Power BI — embed dashboards, single sign‑on, and Teams tabbing; SharePoint lists can be data sources. If your BI stack is Power BI, Teams is optimal.
• Google Workspace + Looker: Best when primary data/warehouse is in BigQuery and Looker is used — embedding, scheduled deliveries to Drive/Gmail, Looker webhook actions and Data Actions provide direct workflows.

Recommendation (BI Analyst perspective):

• Align choice with core data platform: choose Microsoft if heavy Power BI/Azure use and strict residency/DLP needs; choose Google if BigQuery/Looker are central and you want seamless embedding and data actions; choose Slack+Confluence when you prioritize developer/analytics culture, flexible tooling, and asynchronous documentation but plan for added governance.
• Cross-cutting practices: enforce taxonomy, dashboard catalog with metadata (owner, SLA, audience, language), standardize message templates (summary + link + translation), enable SSO/SCIM and DLP, and pilot multilingual templates and captions. These governance steps often matter more than the single-vendor choice.

Situation: Our BI team was growing rapidly and demand for onboarding, dashboard reviews and stakeholder coaching outpaced our senior mentors. I designed a “mentor‑of‑mentors” program to create a second‑tier coaching layer that preserves quality while scaling mentorship.

Selection criteria:

• Minimum 2 years BI experience and ownership of >=3 end‑to‑end dashboards
• Demonstrated coaching aptitude (peer feedback score ≥4/5) and stakeholder empathy
• Technical proficiency (SQL + one viz tool) validated via a practical assessment: produce a short dashboard and a 15‑minute coaching demo
• Commitment: 6‑month rotation with 4–6 hours/week coaching allocation

Curriculum for mentor leaders (12 weeks, blended):

• Week 1–2: Adult learning & coaching frameworks (GROW, deliberate practice)
• Week 3–4: BI‑specific pedagogy — translating analytics concepts, data storytelling, critique techniques
• Week 5–6: Technical QA standards — data lineage, tests, dashboard performance tuning
• Week 7–8: Facilitation skills — running feedback sessions, difficult conversations
• Week 9–10: Assessment & calibration — using rubrics to evaluate dashboards and mentorship
• Week 11–12: Shadowing practicum + capstone: lead 3 coaching sessions with senior mentor observation

Feedback loops:

• Weekly 1:1 with assigned senior mentor for coaching review
• Biweekly aggregated mentee feedback via short pulse surveys (NPS + qualitative)
• Monthly calibration workshops where mentor leaders rate anonymized dashboards and discuss scoring to reduce drift
• Quarterly stakeholder surveys (consumers of dashboards) to measure perceived improvement

QA processes:

• Initial shadowing: new mentor leaders shadow senior mentors for 3 sessions; seniors complete a checklist
• Session audits: random sample 10% of coaching sessions recorded (with consent) audited against a rubric (clarity, actionable feedback, technical correctness)
• Dashboard audits: mentor leaders review mentee dashboards using a standardized QA checklist (data lineage, filters, KPIs, performance)
• Escalation: any audit scoring <70% triggers one‑on‑one retraining and paired coaching for 2 weeks

Measuring improvement:

• Mentor teaching quality score = weighted composite of: mentee NPS (40%), session audit rubric (30%), dashboard QA pass rate (20%), peer calibration alignment (10%)
• Track cohorted baselines and measure delta month‑over‑month; target: +10 pts composite within 3 months
• Business KPIs: reduce post‑release dashboard defects by 30% and decrease onboarding time for new BI hires by 25% over 6 months
• Use BI dashboards to monitor program metrics (time to proficiency, audit scores, stakeholder satisfaction) and publish monthly reports to leadership

Result & learnings: Piloted this with 6 mentor leaders; within 3 months we saw mentee satisfaction climb 18 points, dashboard defects drop 28%, and senior mentors freed ~20% time for higher‑value work. Key learning: rigorous calibration and measurable QA rubrics are critical to avoid quality drift while scaling coaching.

Direct answer

The underlying finding stays identical, but you change altitude, vocabulary, and level of supporting detail. An executive gets the headline, the business impact, and the recommended decision in one or two lines up front. The implementation team gets the mechanism, the caveats, and enough of the underlying data to act on it correctly.

Structured elaboration

• Altitude: conclusion-first for the executive, versus enough method detail for the team to trust and reproduce the diagnosis.
• Vocabulary: business-impact language (revenue, risk, timeline) for the executive, technical specifics (segments, funnels, thresholds) for the team.
• Format: a one-slide or one-paragraph summary versus a working document with a data appendix.
• What must never change: the number itself and the direction of the conclusion, in both versions.

Worked example

Finding: onboarding drop-off at step 3 is costing an estimated 6% of new signups per month.
Executive version: "we're losing about 6 of every 100 new signups at the step-3 confirmation screen, fixing it could recover meaningful revenue this quarter, recommend prioritizing it."
Team version: "62% of that drop-off happens on mobile between form submit and confirmation render, median time to abandon is 9 seconds, this looks like a loading-state issue on mobile specifically."
Both versions agree on the 6% headline number and the recommendation to prioritize the fix.

Trade-offs and pitfalls

The two versions can quietly drift into different conclusions if you're not careful, always trace both back to the same underlying analysis. Over-simplifying for the executive can also strip out the one caveat that would have changed their decision, so pick what to omit deliberately, not by default.

What the interviewer probes next

Expect a question about what happens when the executive summary gets forwarded on without you in the room, and how you prevent it from being read out of context.

Direct answer

Three common statistical methods for flagging outliers in a numeric column are the z-score (how many standard deviations from the mean a value is), the interquartile-range (IQR) fence (flag anything outside 1.5x the IQR beyond the 25th/75th percentile), and a robust alternative based on the median absolute deviation (MAD), which is far less sensitive to the very outliers you are trying to detect than either of the first two.

Structured elaboration

• Z-score: assumes an approximately normal distribution; both the mean and standard deviation used in its own formula are themselves distorted by the outlier being measured, which weakens its sensitivity exactly when outliers are large or numerous (a masking effect). Computational cost: cheapest of the three, the mean and standard deviation are both computed in a single pass over the data, O(n) time and O(1) extra memory, and this single pass is trivially streamable (both can be updated incrementally as new values arrive) even on a huge table.
• IQR fence: distribution-free and robust to a small number of extreme outliers since it is based on percentiles, but the fixed 1.5x multiplier is a heuristic that can flag too aggressively on a genuinely skewed (not just outlier-contaminated) distribution. Computational cost: needs the 25th and 75th percentiles, which in the exact case requires a sort or a selection algorithm, O(n log n) for a full sort or O(n) on average with a quickselect-style approach; at very large scale this is usually done with an approximate-percentile data structure (a sketch) rather than an exact sort, trading a small amount of precision for bounded memory.
• MAD-based modified z-score: uses the median and median absolute deviation instead of the mean and standard deviation, both of which are far more robust to outliers, making it the most reliable of the three for a data-quality context where you specifically expect the sample to contain what you're testing for. Computational cost: needs the median twice, once for the data itself and once for the absolute deviations from that median, so it costs roughly the same as the IQR fence (a sort or selection step, generally O(n log n) or O(n) with quickselect), done twice rather than once, and more than the single-pass z-score. MAD itself can also mislead: on a sample with many tied or duplicate values, or a very small or coarsely-discretized sample, the median absolute deviation can collapse toward zero (more than half the values sitting exactly at the median), which makes the modified z-score's denominator tiny and inflates every deviation into an apparent extreme outlier, the opposite failure mode from the mean/std masking effect above but just as capable of misleading.

Worked example

For the sample [12, 14, 13, 15, 12, 14, 13, 90, 15, 13, 12, 14] (one clear outlier, 90), computed by execution: mean = 19.75, std = 22.15, giving the outlier a z-score of only 3.17, barely over the conventional threshold of 3, because the outlier itself has inflated the mean and standard deviation used to judge it. The IQR fence (Q1=12.75, Q3=14.25, fence = [10.5, 16.5]) correctly flags 90 as outside the fence. The MAD-based modified z-score uses the formula $0.6745 \times \frac{|x - \text{median}|}{\text{MAD}}$ (the constant 0.6745 rescales MAD so it is comparable to a standard deviation under a normal distribution); plugging in median=13.5, MAD=1.0, and x=90 gives $0.6745 \times \frac{|90 - 13.5|}{1.0} = 0.6745 \times 76.5 \approx 51.6$, dramatically clearer than the z-score's 3.17, because the median and MAD are barely moved by a single extreme value. This gap between 3.17 and 51.6 for the exact same outlier is the concrete illustration of why the z-score is fragile in exactly the situation it is meant to catch.

Trade-offs and pitfalls

Z-score is misleading on a small sample or a sample with more than one or two outliers, since the mean and standard deviation degrade fastest exactly when you need them most; IQR is safer but its 1.5x multiplier is a heuristic, not a statistically-derived constant, and can over-flag a genuinely skewed (e.g. revenue, latency) distribution that is not actually anomalous, just non-normal. A practical rule: default to the MAD-based method for automated production monitoring, and reserve the z-score for exploratory, one-off analysis where a human is looking at the output.

Direct answer

Persuading a skeptical stakeholder starts with diagnosing what kind of resistance you're actually facing, since the same "here's more data" response only works on an evidence-based objection. A political objection or a loss-of-control objection needs a different tactic entirely.

Structured elaboration

Objection taxonomy. Naming the type of resistance before choosing a tactic is what separates a senior answer from "I showed them more data":

Worked example

Situation. At a product org, a UX team relied on manual review of every design change against brand guidelines. A design systems lead proposed an automated linting check for a subset of mechanical rules. One senior designer resisted far more strongly than the proposal's scope seemed to warrant.

Stakes. The designer's review was a required approval gate; without their buy-in, adoption could be blocked or slow-walked indefinitely, regardless of how good the tool was.

The influence moves.

• Noticed the resistance didn't track with the evidence: false-positive-rate numbers didn't move the reaction at all, which was the signal something else was going on.
• Asked directly what was underneath the resistance, and learned it wasn't about accuracy: automating the check felt like it removed the designer's voice and shrank their judgment role.
• Reframed the proposal to preserve their say explicitly: the linter would catch only mechanical rule violations (spacing, contrast ratios), routing anything subjective to the designer's review, unchanged.
• Gave the designer a visible role in defining which rules counted as mechanical versus subjective, turning them from a blocker into the rule-owner.

Resolution. The designer became the tool's internal champion once their judgment role was made explicit rather than replaced.

What a senior candidate does differently. Doesn't try to win a trust objection with more data. A mid-level answer keeps citing the false-positive rate; a senior candidate diagnoses the objection type first and matches the tactic to it.

Trade-offs and pitfalls

• Misdiagnosis wastes your strongest tool. Aiming data at a political or trust objection wastes the one resource that can't solve that problem, and can read as tone-deaf to the stakeholder.
• Political objections sometimes can't be fully resolved through the stated concern, because the real driver is unstated. A senior candidate says plainly when they suspect this is happening rather than pretending the objection was purely rational.
• Preserving a role is not the same as granting a veto. The trade is scoping what the stakeholder keeps control over, not surrendering the decision.

Direct answer
Match the chart to the analytical task, not to what looks impressive: trends over time get a line chart, category comparisons get a bar chart, distributions get a histogram or box plot, and relationships between two continuous variables get a scatterplot.

Structured elaboration

• Trend: line chart with the metric on the y-axis and time on the x-axis. Use a bar chart only if the periods are few and discrete (e.g. quarterly totals).
• Category comparison: bar chart (horizontal if category names are long or there are more than ~7 categories), sorted by value rather than alphabetically unless alphabetical order itself is meaningful.
• Distribution: histogram for a quick shape read; box plot when you need to compare the same distribution across several groups side by side.
• Relationship between two continuous variables: scatterplot, optionally with a trend line; switch to a hexbin (a plot that divides the chart area into small hexagonal cells and colors each cell by how many points fall inside it) or a 2D density plot (a smoothed, heatmap-style view of where points concentrate) if points overplot (so many points stack on top of each other that individual points can no longer be told apart).

Worked example
Given three columns (revenue, active_users, conversion_rate) tracked daily: revenue and active_users each get their own line chart (or one line chart with two panels, not one dual-axis chart, since their scales differ by orders of magnitude); conversion_rate also gets a line chart, but a low-single-digit-percent metric benefits from a fixed y-axis range (e.g. 0-10%) rather than autoscaling, because autoscaling makes noise look like a trend.

Trade-offs and pitfalls
The common mistake is picking a chart type for its familiarity (bar charts for everything) rather than the task. Watch for: bar charts truncated to a non-zero baseline (distorts comparison), a histogram with too few bins masking multimodality (a distribution having more than one peak, e.g. two separate clusters of values instead of one hump) or too many bins turning real shape into noise (and a box plot hiding multimodality entirely, since it only shows quartiles), scatterplots that overplot at high N without any density adjustment, and combining unrelated scales onto one axis instead of separate panels.