Looker Interview Questions (2026)
Practice 45 Looker interview questions on LookML, Explores, views, joins, dimensions, measures, PDTs, dashboards, security, and model governance.
45 questions with answersWhat Is Looker?
Key Takeaways
- ✓Looker is a Google Cloud BI platform where teams define governed metrics and reusable data models with LookML.
- ✓Interviews test SQL judgment, LookML modeling, Explores, joins, dimensions, measures, derived tables, permissions, and dashboard choices.
- ✓Strong answers explain the business metric, model grain, join path, Explore design, and how users avoid inconsistent definitions.
- ✓Looker rounds often probe governance because LookML turns metric definitions into reusable code.
Looker is a business intelligence platform that uses LookML to define governed dimensions, measures, joins, Explores, dashboards, and reusable business logic. In interviews, Looker is not treated as only a dashboard tool. Hiring teams test whether you can model data safely, write SQL-backed fields, choose join relationships, control access, use derived tables, and explain why a metric should live in LookML instead of being rebuilt in every dashboard.
Watch: Getting started with Looker: From database to dashboard
Video: Getting started with Looker: From database to dashboard (Google Cloud, YouTube)
Test yourself and earn a certificate
6 quick questions. Score 70%+ to download your Looker certificate.
All Questions on This Page
45 questions- 1. What is LookML and why do teams use it?
- 2. What is a LookML view?
- 3. What is an Explore in Looker?
- 4. How do dimensions and measures differ in Looker?
- 5. Why does join relationship matter in LookML?
- 6. What is fanout in a Looker Explore?
- 7. What is a derived table in Looker?
- 8. When should you use a persistent derived table?
- 9. What does a datagroup control?
- 10. What are access filters in Looker?
- 11. How are user attributes used in Looker?
- 12. What are sets in LookML?
- 13. How do drill fields improve Looker analysis?
- 14. What is aggregate awareness in Looker?
- 15. Why does Looker have development mode?
- 16. Design a Looker Explore for orders, customers, and products.
- 17. How would you define a trusted revenue measure?
- 18. How do you model completed order count?
- 19. After adding a join, revenue doubled. What do you check?
- 20. When would you turn a derived table into a PDT?
- 21. How do you decide a datagroup trigger?
- 22. A sales manager should only see their region. How do you model it?
- 23. How do you validate a Looker dashboard before release?
- 24. An Explore has 300 fields and users are confused. What do you do?
- 25. Why review generated SQL?
- 26. How do you choose drill fields for a KPI?
- 27. How do you release LookML safely?
- 28. A Looker dashboard is slow. What do you inspect?
- 29. How do dashboard filters connect to LookML fields?
- 30. How do you move a dashboard-only metric into LookML?
- 31. Two dashboards show different revenue. What do you investigate?
- 32. Users can join fields that create wrong totals. What do you change?
- 33. A PDT is stale during morning reporting. What do you check?
- 34. A multi-tenant customer asks how Looker restricts account data.
- 35. A field can join through two paths and totals look wrong. What do you do?
- 36. An Explore times out when users add several fields. How do you respond?
- 37. Who owns a LookML measure definition?
- 38. A LookML field rename breaks dashboards. What is the safer release?
- 39. Users can download rows they should not see. What do you check?
- 40. The project has many derived tables with copied SQL. What would you refactor?
- 41. A key KPI exists only as custom tile logic. Why is that risky?
- 42. Aggregate awareness returns a different total. What do you inspect?
- 43. Two modelers edit the same LookML file. What process prevents damage?
- 44. Business users avoid an Explore and ask analysts for everything. What do you improve?
- 45. What changes when Looker is embedded in a product?
Looker Fundamentals
Foundational15 questionsStart here. These are the definitions and first-principle checks that open most rounds.
Q1. What is LookML and why do teams use it?
LookML is Looker's modeling language for defining fields, joins, Explores, dashboards, and reusable business logic.
Use it when metric definitions must be governed and reused. The direct answer is LookML sits between SQL tables and business users so every report does not redefine revenue, margin, or active customer logic.
Key point: Mention governed metrics and generated SQL.
Watch a deeper explanation
Video: Validate your Looker workflow from data to dashboard (Google Cloud Tech, YouTube)
Q2. What is a LookML view?
A view maps a database table or SQL query into dimensions, measures, and field metadata that users can query.
Views should reflect the source grain clearly. A view can be based on a physical table, a derived table, or a native derived table.
Q3. What is an Explore in Looker?
An Explore is the user-facing query surface where one base view and its joins define what fields users can analyze together.
A good Explore protects users from unsafe joins and messy table structure. It is not just a list of all available fields.
Looker query path
Good answers trace this path.
Q4. How do dimensions and measures differ in Looker?
Dimensions describe values at row level. Measures aggregate rows, such as count, sum, average, or filtered metrics.
Dimensions usually map to columns or expressions. Measures should respect the view grain and join behavior.
Dimensions and measures changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
| Answer part | What to say | Evidence to mention |
|---|---|---|
| Definition | Dimensions and measures in one direct sentence. | Official docs or course material |
| Use case | The work where it changes a decision. | Dataset, model, query, dashboard, or pipeline |
| Risk | What breaks when it is misunderstood. | Metric, log, test result, or review note |
Q5. Why does join relationship matter in LookML?
The relationship setting tells Looker how rows relate across joined views, which affects aggregate correctness and fanout handling.
Wrong relationship assumptions can inflate measures. Strong answers include testing with generated SQL and known source totals.
Watch a deeper explanation
Video: Getting started with Looker (Google Cloud Events, YouTube)
Q6. What is fanout in a Looker Explore?
Fanout happens when a join duplicates rows from the base view, causing measures such as revenue or count to inflate.
Fix fanout with correct join grain, symmetric aggregates where appropriate, aggregate tables, or redesigning the Explore around the right base table.
Q7. What is a derived table in Looker?
A derived table is a query-defined table in LookML used when the model needs a shaped dataset that is not directly available as a physical source table.
Use derived tables for reusable SQL logic, but do not hide poor warehouse modeling inside every Explore.
Q8. When should you use a persistent derived table?
Use a PDT when a derived query is expensive and should be materialized for reuse instead of rebuilt for every user query.
The production-ready answer mentions rebuild triggers, datagroups, storage cost, and stale data risk.
Q9. What does a datagroup control?
A datagroup defines caching and PDT rebuild behavior using SQL triggers or time-based rules.
Datagroups help align freshness with source updates. They should be tied to business freshness needs, not guessed.
Datagroup changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q10. What are access filters in Looker?
Access filters limit data users can query, often through user attributes such as region, customer, or team.
They are part of model security. Test them as real users and pair them with content permissions.
Q11. How are user attributes used in Looker?
User attributes store values attached to users or groups and can drive access filters, connections, or custom behavior.
Common examples include region, department, tenant id, and allowed customer account.
User attributes changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q12. What are sets in LookML?
Sets group fields for reuse, usually to control drill fields or organize commonly used field lists.
Sets make the model easier to maintain when many fields are reused across views or drills.
Sets changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q13. How do drill fields improve Looker analysis?
Drill fields define what users see when they click into a summarized value.
Good drill paths help users move from KPI to row-level explanation without leaving the governed model.
Drill fields changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Learn LookML: fields, dimensions, and measures (Looker training, YouTube)
Q14. What is aggregate awareness in Looker?
Aggregate awareness lets Looker use pre-aggregated tables for eligible queries while keeping the same Explore interface.
It improves performance when common queries hit summarized data instead of scanning large base tables.
Aggregate awareness changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q15. Why does Looker have development mode?
Development mode lets modelers edit and test LookML changes before merging them into production.
Mention validation, content impact, version control, and review before production release.
Development mode changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Looker Practical Interview Questions
Intermediate15 questionsThese questions test whether you can apply the topic to real data, real code, and messy constraints.
Q16. Design a Looker Explore for orders, customers, and products.
Use orders as the base view if the main question is order metrics, then join customers and products at many-to-one relationships.
The order grain first. Add measures such as order count and revenue in the orders view, then expose clean customer and product dimensions.
Q17. How would you define a trusted revenue measure?
Define it once in LookML using the approved sales amount field, filters for valid orders, and clear value formatting.
Also document whether refunds, tax, shipping, and canceled orders are included.
revenue measure changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
measure: revenue {
type: sum
sql: ${TABLE}.sale_amount ;;
filters: [status: "completed"]
value_format_name: usd
}Q18. How do you model completed order count?
Use a filtered measure so users do not rebuild the same filter in every tile.
This keeps dashboards consistent and easier to audit.
filtered measure changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
measure: completed_orders {
type: count
filters: [status: "completed"]
}Q19. After adding a join, revenue doubled. What do you check?
Check join keys, base grain, joined view uniqueness, relationship setting, and generated SQL.
Compare totals before and after the join against a known SQL query.
join fanout check changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q20. When would you turn a derived table into a PDT?
Use a PDT when the derived query is expensive, reused often, and has a clear freshness rule.
Do not persist a table only to hide a slow warehouse query. Fix the model where possible.
Q21. How do you decide a datagroup trigger?
it maps to source freshness, such as the latest successful warehouse load timestamp.
The rule should match user expectations for fresh data.
datagroup trigger changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q22. A sales manager should only see their region. How do you model it?
Use a user attribute for allowed region and apply it through an access filter in the Explore.
Test with a real manager account and a user outside the region.
access filter design changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q23. How do you validate a Looker dashboard before release?
Compare key tiles against source SQL, test filters, check drill paths, confirm permissions, and inspect query performance.
Document metric definitions so users know what they are reading.
dashboard validation changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q24. An Explore has 300 fields and users are confused. What do you do?
Hide technical fields, group useful fields, use labels and descriptions, and split workflows into better Explores if needed.
Self-service works only when the field surface is understandable.
field cleanup changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q25. Why review generated SQL?
Generated SQL shows joins, filters, grouping, and aggregate behavior that may not be obvious from the Explore UI.
It is the fastest way to debug wrong totals or slow queries.
generated SQL review changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Look and Learn: development mode (Looker, YouTube)
Q26. How do you choose drill fields for a KPI?
Choose fields that explain the KPI, such as id, date, customer, product, status, and amount.
Avoid dumping every column. Drill fields should answer the next question.
drill design changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q27. How do you release LookML safely?
Use development mode, validate LookML, test affected Explores, review content impact, then merge through version control.
The production-ready answer includes rollback and stakeholder communication.
release workflow changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q28. A Looker dashboard is slow. What do you inspect?
Inspect tile queries, generated SQL, joins, filters, row limits, PDT opportunities, aggregate awareness, and warehouse performance.
Fix the measured bottleneck rather than adding cache blindly.
slow dashboard changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q29. How do dashboard filters connect to LookML fields?
They map to fields in tiles or Explores, so field naming and model consistency affect how filters behave.
Broken or inconsistent filters often point back to model design.
dashboard filter changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q30. How do you move a dashboard-only metric into LookML?
Confirm the business definition, create a measure or dimension, validate it against the old dashboard, then update tiles to use the governed field.
This reduces drift across dashboards.
metric migration changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Looker Advanced Scenarios
Advanced15 questionsAdvanced rounds test trade-offs, failure modes, and whether the decision can hold up under production pressure.
Q31. Two dashboards show different revenue. What do you investigate?
Compare measures, filters, Explores, joins, source freshness, and whether both dashboards use the same governed LookML field.
The fix is usually to move the approved definition into LookML and update both dashboards.
conflicting revenue changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q32. Users can join fields that create wrong totals. What do you change?
Redesign the Explore, hide risky fields, fix join relationships, or split the workflow into safer Explores.
Self-service should not expose combinations that produce misleading numbers.
unsafe self-service changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q33. A PDT is stale during morning reporting. What do you check?
Check datagroup trigger, rebuild schedule, warehouse load time, PDT errors, and dashboard cache behavior.
Then show users freshness status or adjust the rebuild rule.
PDT stale data changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q34. A multi-tenant customer asks how Looker restricts account data.
Use user attributes, access filters, model permissions, and database-level controls where needed.
Test as users from different tenants and check downloads, schedules, and embeds.
tenant security changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q35. A field can join through two paths and totals look wrong. What do you do?
Choose a clear base Explore, remove ambiguous joins, or create separate Explores for separate workflows.
Ambiguity in analytics models becomes wrong business logic.
join path ambiguity changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q36. An Explore times out when users add several fields. How do you respond?
Inspect generated SQL, join fanout, filters, selected fields, aggregate tables, PDTs, and warehouse plan.
A governed Explore still needs performance guardrails.
slow Explore changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q37. Who owns a LookML measure definition?
The analytics owner should maintain the LookML, but the business owner must approve the definition.
Good governance separates technical ownership from business approval.
metric ownership changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q38. A LookML field rename breaks dashboards. What is the safer release?
Add the new field, keep the old field temporarily hidden or deprecated, update content, then remove after review.
Avoid breaking live dashboards without a migration window.
breaking field rename changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q39. Users can download rows they should not see. What do you check?
Check access filters, model permissions, content permissions, user attributes, and database grants.
Security must apply to the query, not only the dashboard surface.
dashboard download risk changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q40. The project has many derived tables with copied SQL. What would you refactor?
Move repeated logic into warehouse models, reusable views, or PDTs with clear ownership.
LookML should govern metrics, not become a dumping ground for unmanaged SQL.
overused derived tables changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q41. A key KPI exists only as custom tile logic. Why is that risky?
It is hard to reuse, test, document, or keep consistent across dashboards.
Move approved KPI logic into LookML when it becomes shared business logic.
dashboard-only logic changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q42. Aggregate awareness returns a different total. What do you inspect?
Check aggregate table grain, filters, dimensions, measure definitions, and whether the query is eligible for the aggregate table.
Aggregate tables must preserve the metric definition.
aggregate table mismatch changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q43. Two modelers edit the same LookML file. What process prevents damage?
Use version control, branches, validation, code review, and small changes.
LookML is code. Treat it like code.
development conflict changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q44. Business users avoid an Explore and ask analysts for everything. What do you improve?
Simplify fields, add labels and descriptions, create starter dashboards, improve drills, and remove risky joins.
Adoption depends on trust and clarity.
poor Explore adoption changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q45. What changes when Looker is embedded in a product?
Access control, tenant isolation, performance, caching, theming, and user attributes become part of product design.
Embedded users should not need to understand the internal data model.
embedded analytics changes Looker decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
LookML View vs Explore vs Dashboard
Looker interviews often test whether you know where each decision belongs. A view defines fields. An Explore defines how users query related views. A dashboard presents approved questions to users.
| Layer | Purpose | Interview signal | Common mistake |
|---|---|---|---|
| View | Defines dimensions, measures, and SQL mapping | You can model fields at the right grain | Putting business logic only in dashboard tiles |
| Explore | Defines joins and the user query surface | You can create a safe self-service path | Exposing every table without guardrails |
| Model | Groups Explores and connection settings | You understand project structure | Mixing dev and production logic casually |
| Dashboard | Shares curated analysis | You can answer a business workflow | Using dashboards to hide model problems |
What Looker interviews score
LookML modeling and SQL correctness matter more than chart polish.
- LookML model: Views, Explores, joins, fields
- SQL: Grain, aggregation, filters, derived tables
- Governance: Reuse, permissions, version control
- Performance: PDTs, aggregate awareness, query design
How to Prepare for a Looker Interview
Prepare from model to dashboard. Practice mapping SQL tables into LookML views, joining them into Explores, writing measures, validating generated SQL, and explaining how users get trusted metrics.
- Review dimensions, measures, views, Explores, joins, models, and project files.
- Practice SQL grain and aggregation before writing LookML measures.
- Understand derived tables, PDTs, aggregate awareness, and dashboard performance.
- One example where LookML prevented metric drift across teams is useful.
Looker interview prep flow
Most rounds reward clear reasoning more than memorized phrasing.
How Strong Looker Answers Sound
A strong Looker answer starts with the metric and data grain, then places logic in the right LookML layer. Say which table is the base Explore, how joins behave, which measures are approved, how access is controlled, and how generated SQL is validated. Senior candidates also discuss version control, PDT build cost, caching, and how business users avoid rebuilding the same metric five ways.
Model the metric once
LookML is useful because shared metrics can live in code. Explain which definitions belong in measures and which should stay as dashboard filters or user choices.
The join relationship is explicit
the question needs to know whether you can prevent fanout. The one-to-one, many-to-one, or one-to-many behavior and how you test totals after joining.
Check the generated SQL
Looker generates SQL from LookML. Good candidates inspect the SQL, test row counts, and compare totals against source queries before trusting a new Explore.
Treat security as model design
Access filters, user attributes, model permissions, and content permissions should match the user workflow. Do not rely on hiding a dashboard tile as security.
Test Yourself: Looker Quiz
Ready to test your Looker knowledge?
6 questions, about 4 minutes. Score 70% or higher to earn a shareable certificate.
Frequently Asked Questions
What do Looker interviews usually ask?
How much SQL do I need for Looker?
What Looker project should I discuss?
What separates experienced Looker candidates?
Match your Looker work to the role
Use Hyring's resume checker after this Looker practice page to show the right SQL, LookML, modeling, dashboard, and analytics ownership signals in your resume.
Check your resume fitSources
Written by Adithyan RK