Articles
Domo Interview Questions for BI Developers: Beast Mode, Data Grain, and Dashboard Filters
Practice Domo interview questions with Beast Mode calculations, join-grain checks, weighted ratios, and dashboard filter traces that explain wrong totals.
A Domo dashboard shows revenue of 280, while the order system shows 180. The card refreshes successfully, the Beast Mode validates, and the chart looks plausible. Your first interview answer should be a question: what does one row represent after every join? A valid calculation cannot repair duplicated facts unless you first identify how they became duplicated.
This guide prepares BI developers to explain Domo calculations and dashboard behavior. It covers proficiency with the tool, rather than the hiring process at the Domo company. Official facts are linked to current Domo documentation. The datasets, calculations, and interview follow-ups below are original practice exercises; no candidate reports establish that an employer asks these exact questions. Recommendations are our reasoning from the stated data contract.
1. Why does this card overstate revenue?
Use this original fixture. The orders DataSet contains one row per order:
| Order | Region | Revenue |
|---|---|---|
| O1 | West | 100 |
| O2 | West | 80 |
The shipment input contains two rows for O1 and one for O2. Joining on order ID produces three rows: O1/100, O1/100, and O2/80. Summing revenue now yields 280, rather than 180. This is a change in grain: revenue belongs to an order, but the joined rows represent shipments.
A strong answer names the intended output grain and repair. If the dashboard needs shipment counts alongside order revenue, aggregate shipments to one row per order before joining. Then validate uniqueness of the shipment summary's order key and preserve orders without shipments through the appropriate join. If shipment-level analysis is required, define an allocation rule instead of repeating the full order amount on every shipment.
Do not immediately reach for SUM(DISTINCT Revenue). Distinct numeric amounts are not distinct orders. Add O3 with revenue 100: the correct order total becomes 280, but summing distinct amounts still gives 180. A repair that works on two convenient numbers can erase legitimate business facts.
Interview follow-up: what if the order table itself has several versions per order? First establish whether those are duplicates, legitimate adjustments, or historical snapshots. Selecting the latest version requires a defined ordering and tie rule. Summing every version may be wrong, but arbitrarily dropping duplicates can also lose real corrections.
Explain your reconciliation in layers: input row count and distinct keys, join output row count, amount before and after the join, and unmatched keys. The total identifies a discrepancy; the key checks explain it. Keep a small failing fixture so a later transformation change cannot silently reintroduce fan-out.
2. When should you use Beast Mode versus upstream transformation?
Official fact: Domo describes Beast Mode as adding calculated fields in Analyzer. Saving a calculation to a DataSet makes it available to other cards using that DataSet. Its instructions also distinguish calculations inherited through a same-DataSet drill from drilling to a different DataSet. Create a Beast Mode Calculation.
That does not make every business rule a good card calculation. In our example, the shipment join establishes the relationship between facts. Our recommendation is to repair that grain upstream, in Magic ETL or another controlled transformation, where you can inspect output rows and reuse the corrected input.
Beast Mode suits a clearly defined calculation over a trustworthy DataSet: a display bucket, conditional amount, or aggregate ratio. An upstream transformation suits key normalization, source deduplication, stable joins, and facts that many dashboards must reconcile consistently. These are design choices, rather than an official mandate that every calculation must live in one place.
The trade-off is materialization versus flexibility. A precomputed daily conversion percentage is easy to display but may not roll up correctly to a month. Preserve its numerator and denominator so each card can compute the appropriate ratio. Conversely, repeatedly implementing a shared classification in many cards increases the chance that definitions diverge.
Before choosing, state the rule's owner, reuse, refresh requirement, and validation method. “I would put it in ETL” is incomplete until you explain what output key and reconciliation make the result trustworthy.
3. Why is averaging row conversion rates misleading?
Consider two original rows: campaign A has 20 conversions from 100 visits; campaign B has 9 conversions from 10 visits. Their rates are 20% and 90%. An unweighted average is 55%. The overall conversion rate is 29/110, approximately 26.36%.
Both calculations are mathematically valid answers to different questions. The first describes the average campaign rate with equal campaign weight. The second describes the fraction of visits that converted. State the business question before calling one answer wrong.
For a visit-weighted conversion metric, an illustrative Beast Mode is:
SUM(`Conversions`) / NULLIF(SUM(`Visits`), 0)
Official fact: Domo's reference documents aggregate functions and NULLIF, which returns NULL when its arguments are equal. That supports the denominator guard here. The fixture's business interpretation is our own. Beast Mode Functions Reference Guide.
The aggregate expression should be reasoned about at the displayed group. A campaign chart produces each campaign's ratio; a region chart produces regional sums before division. Formatting the output as a percentage is a display decision, not permission to multiply some cards by 100 while leaving others as fractions.
Ask what zero and NULL mean. Zero visits might represent a genuine empty population; a NULL visit count might represent missing ingestion. Treating both as zero can hide a pipeline problem. Document whether missing rows are excluded, surfaced as unknown, or rejected upstream.
Interview follow-up: can you average the two campaign percentages if both have 100 visits? Yes, the results agree under equal nonzero weights. That agreement is a special case, not a reason to store only percentages. Preserve the counts because later filters or grouping can change the weights.
4. Why does filtering change the denominator?
Define two different metrics before touching FIXED: “share of the currently selected sales” and “share of regional sales before a State selection.” The first should change its comparison population with the selection. The second deliberately preserves a broader denominator.
Official fact: Domo documents FIXED expressions for level-of-detail calculations with an aggregation over an aggregated expression. Without explicit filter logic, filters apply. FILTER DENY excludes specified fields from that calculation's filter handling. Current documentation limits FIXED to non-federated DataSets and lists incompatibility with window functions in the same calculation. Beast Mode FIXED Functions.
For our second definition, this illustrative expression preserves a regional denominator against a State filter while allowing other filters:
SUM(`Sales`)
/
SUM(SUM(`Sales`) FIXED (BY `Region` FILTER DENY `State`))
Use a tiny original fixture: California has 60 of West's 100 sales; Oregon has the other 40. With no State selection, California's regional share is 60%. Selecting California leaves its numerator at 60. A denominator that follows that selection becomes 60, giving 100%; the stated fixed regional denominator remains 100, giving 60%.
Neither label should merely say “percentage.” One compares with selected sales; the other compares with regional sales under a specified filter policy. Put that meaning in the card title or description so users can interpret a nonchanging denominator.
Now add a date filter. Does the regional denominator represent the selected month or all history? Our expression denies State, not Date, so the intended comparison retains the date selection. Test both fields independently and together. Do not use broad filter exclusion simply because it makes one screenshot match a spreadsheet.
This is a documentation-grounded example, not a claim that we executed the formula in a Domo tenant. Validate syntax, supported DataSet type, actual card behavior, and access scope in the environment you are discussing.
5. How do you debug a dashboard filter that misses a card?
Official fact: Domo's dashboard documentation describes Page Filters and saved Filter Views. When a field appears in multiple DataSets, the selection can target DataSets; its instructions distinguish the DataSet supplying filter values from the scope to which values apply. PDP also limits available filter options. Page Filters and Filter Views on Dashboards.
Use this original acceptance matrix. Assume two sales cards share a line-level DataSet and a target card intentionally uses a separate monthly target input:
| Selection | Sales detail card | Sales KPI card | Monthly target card |
|---|---|---|---|
| West, no State | West detail | West sales total | West target, if Region mapping is configured |
| West + California | California detail | California sales total | Regional target remains unchanged by design |
| Selected month | That month's rows | That month's sales | That month's target |
| Impossible combination | No matching rows | Defined empty result | Check independently rather than assume it must be empty |
The target card's unchanged State result can be correct. It is a monthly regional target without a State dimension. Inventing a State mapping would fabricate precision. If users need state-level targets, obtain that business allocation rule and a compatible input.
For a card that should change, inspect its DataSet identity, field name and values, filter scope, saved view, interaction configuration, and permanent Analyzer filters. Reproduce one selection at a time. Similar display labels do not prove equivalent fields: one Region can describe customer residence while another describes sales ownership.
Do not compare screenshots taken under different selections. Record the viewer, DataSet refresh, active filters, expected row population, and result. This makes “it does not filter” a testable statement.
6. Why do two users see different totals?
Separate a temporary analysis choice from data permission. Official fact: Domo says Card Details filters are personal and temporary; permanent chart filters are set in Analyzer. Filtering Data in a Card Details View.
Our diagnostic order is to compare the exact card, refresh time, saved or active filter state, and viewer access. Do not ask a restricted viewer to match an administrator's total as the definition of correctness. Confirm the population that each person is entitled to see and reconcile against that population.
A FIXED denominator is a calculation choice, not a proposal to bypass PDP. If a regional share requires data outside a viewer's permitted rows, ask the data owner what authorized aggregate can be provided. Do not promise that clearing dashboard filters exposes every record.
Describe the evidence you would gather without collecting unnecessary sensitive data: card and DataSet identifiers, permitted-region scope, active filter names, timestamps, and aggregate counts. A small synthetic reproduction usually explains the grain error more clearly than exporting a customer's entire dataset.
Practice the reasoning before the product syntax
For each, explain the input key, intended output grain, missing-data rule, and comparison population before implementing the query.
| Question | Domo preparation focus |
|---|---|
| Calculate Daily Survey Response Rates by Country | Define the population behind a rate |
| Reason About Composite Join Keys and Predicate Placement | Trace join keys and filtered unmatched rows |
| Compare Survey Satisfaction for New and Established Users | Explain group definitions before comparing averages |
| Reconcile Monthly Bank-Account Balances Across Two Datasets | Reconcile two representations at a common grain |
| SQL: Top 5 Vehicle Models by Miles per kWh Under a Maintenance Cost Cap | Avoid child-table fan-out and divide safely |
A defensible final answer can be short: “The join duplicated order revenue. I will summarize shipments to an order key, reconcile totals, then calculate the card's ratio from preserved counts. The State filter changes sales but intentionally leaves the regional comparison population fixed.” Every sentence identifies a behavior you can test.