Looker LookML Interview Questions: Joins, Fanout, Explores, and Measures

Looker LookML interview questions: what this guide covers

A dashboard shows revenue of $1,195, but the finance report says $795. The SQL runs, the dashboard loads, and yet the answer is wrong. In a Looker interview, this tests whether you can model the grain of data, encode that relationship in LookML, and verify that aggregate measures stay trustworthy.

This guide focuses on Looker LookML interview questions about joins, fanout, Explores, and measures. It is aimed at analytics engineers, BI developers, and data engineers. Examples are original practice scenarios, not claims about questions asked by a particular employer.

Key takeaways

• Fanout occurs when a join repeats rows from one side; summing a repeated value can inflate a measure.
• The relationship parameter describes cardinality from the Explore's base view to the joined view.
• Symmetric aggregates can protect supported measures from fanout, but accurate, unique non-null primary keys and relationships still matter.
• Debug grain and row counts before changing a measure or disabling symmetric aggregates.
• Validate detail rows and aggregate totals against a trusted baseline; a plausible chart is not proof.

What is an Explore, and what does a LookML join define?

An Explore is a query starting point for users. A LookML join defines how another view relates to it: join type, match condition (sql_on), relationship cardinality, and optionally which fields to expose.

Suppose orders has one row per order and order_items has multiple rows per order. With orders as the base, the relationship is one_to_many. Reverse the base view and the direction changes.

explore: orders {

join: order_items {

type: left_outer

sql_on: ${orders.order_id} = ${order_items.order_id} ;;

relationship: one_to_many

}

}

The condition says which rows match; the relationship says how many matches are expected. If the data violates that cardinality, results can surprise you.

How does fanout change an aggregate?

Imagine two orders with totals $100 and $200. The first has two items; the second has one. After joining, order A's total appears twice.

Order	Order total	Item rows	Joined values
A	$100	2	$100, $100
B	$200	1	$200

The correct sum is $300; a naive sum after the join returns $400. The join can be syntactically correct while an aggregate is semantically wrong for the resulting grain. State each input's grain before proposing a fix.

Symmetric aggregates: useful protection, not a substitute for modeling

Looker uses symmetric aggregates to calculate supported aggregations correctly in certain fanout situations when the dialect supports them and the model has the required key and relationship information. Primary keys must genuinely be unique and non-null.

1. State the intended grain of the base Explore and each joined view.
2. Test whether the join key is unique on the side believed to be one-to-one or many-to-one.
3. Confirm relationship direction from the base view.
4. Confirm each relevant view has a valid primary key.
5. Inspect generated SQL and compare joined rows with the business grain.
6. Check dialect support and whether symmetric aggregates were changed.

Do not reach first for SUM(DISTINCT amount). Two legitimate orders can have the same amount, so distinct values can undercount. Deduplicate by the entity key that defines the measure's grain, not a coincidentally repeated number.

Debug a measure that changes after a join

Pick a small known date range and a few entities. Record the baseline at the source grain, add one join at a time, then compare row counts, distinct keys, and totals. Identify which rows multiplied and why.

Check	Question	Evidence
Grain	What does one row represent?	Source definition and key columns
Uniqueness	Is the supposed key unique and non-null?	Duplicate and null checks
Cardinality	How many matches can each row have?	Counts per join key on both sides
Measure	At what grain is the metric defined?	Business definition and SQL
Query	Where did rows multiply?	Generated SQL and distinct key counts

Interview answer: “I would not start by changing SUM to SUM(DISTINCT). I would establish the measure's grain, profile the join keys, reproduce the mismatch on a small slice, and inspect SQL. Then I would correct model metadata or pre-aggregate the many-side if that matches the metric definition, and reconcile totals with a baseline.”

Primary keys and relationship: explain the direction

A LookML field marked primary_key: yes must identify rows with unique, non-null values. A display name, date, or amount is not a safe key merely because it looks unique in a sample. If no single field works, a composite key is suitable only if the combination is reliably unique and non-null.

If the Explore starts from orders and many orders can belong to one customer, orders to customers is many_to_one. If it starts from customers and joins all orders, it is one_to_many. Name the base view, then state cardinality.

Google's Looker docs explain join relationships and symmetric aggregates.

Common interview follow-ups

Declared many_to_one but duplicates remain? Data may violate uniqueness or the join condition may omit part of a key. Profile actual join columns.

Always enable symmetric aggregates? Dialect support, accurate keys, and relationships matter; inspect generated SQL and performance rather than claiming a universal setting.

When pre-aggregate? When the metric is defined at a coarser grain and detail is unnecessary, aggregate to the intended key. Explain the trade-off in detail and maintenance.

How test a model change? Validate LookML, query representative fields, inspect SQL, reconcile to a trusted result, and include missing matches, duplicate keys, and multiple children.

Practical preparation plan

1. Draw a one-to-many example and calculate joined rows by hand.
2. Write a join and declare cardinality from a named base view.
3. Explain the row key and how you would test it.
4. Reproduce an inflated sum and debug from grain and key profiling.
5. Explain why SUM(DISTINCT value) is not a general fix.

Final checklist

What is one row here? What is the measure's intended grain? Which keys match? How many matches are possible? Are keys unique and non-null? Does the result reconcile to a baseline? Those answers make a model trustworthy and an interview explanation clear.

Research note: Confirm Looker behavior against official documentation for the version and database dialect in use. Numeric examples and scenarios here are illustrative.