Looker and LookML in 2026: Business Intelligence and Interview Questions

Looker interview questions consistently focus on LookML modeling, data exploration workflows, and how the semantic layer translates business logic into reusable definitions. This tutorial covers the core LookML concepts, practical implementation patterns, and the exact questions data analysts face when interviewing for Looker-focused roles in 2026.

Understanding the LookML Semantic Layer

LookML acts as a translation layer between raw database tables and business-friendly metrics. Instead of writing complex SQL joins repeatedly, analysts define relationships in model files that Looker compiles into optimized queries.

The semantic layer solves three problems that interviewers frequently ask about:

• Consistency: Every user sees the same metric definitions
• Reusability: Dimensions and measures exist once, referenced everywhere
• Governance: Changes propagate automatically across all dashboards

Google Cloud's Looker documentation describes LookML as a "dependency-aware" language—when one definition changes, downstream references update automatically. This dependency awareness becomes critical when maintaining enterprise-scale models.

LookML Views and Explores: The Building Blocks

Views define the columns available from a single table or derived table. Explores combine views through joins and expose them to business users.

# views/orders.view.lkml
view: orders {
  sql_table_name: `analytics.orders` ;;

  dimension: order_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.order_id ;;
  }

  dimension_group: created {
    type: time
    timeframes: [raw, date, week, month, quarter, year]
    sql: ${TABLE}.created_at ;;
  }

  dimension: status {
    type: string
    sql: ${TABLE}.status ;;
  }

  measure: total_orders {
    type: count
    drill_fields: [order_id, created_date, status]
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount ;;
    value_format_name: usd
  }
}

The dimension_group declaration generates multiple time-based dimensions from a single timestamp column. Interviewers often ask candidates to explain why this pattern reduces code duplication and ensures consistent date handling across the model.

The drill_fields parameter defines what users see when clicking on a measure value—a UX detail that demonstrates understanding of how analysts actually interact with Looker.

Joins and Relationships in LookML

Explores define how views connect through SQL joins. The join type and relationship declaration directly impact query performance and aggregation accuracy.

# models/ecommerce.model.lkml
explore: orders {
  label: "Order Analysis"
  description: "All orders with customer and product details"

  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
    relationship: many_to_one
  }

  join: order_items {
    type: left_outer
    sql_on: ${orders.order_id} = ${order_items.order_id} ;;
    relationship: one_to_many
  }

  join: products {
    type: left_outer
    sql_on: ${order_items.product_id} = ${products.product_id} ;;
    relationship: many_to_one
  }
}

The relationship parameter tells Looker how to handle aggregations. A one_to_many relationship means the measure should aggregate at the "one" side to avoid double-counting. Getting this wrong causes incorrect totals—a common debugging scenario in interviews.

Symmetric aggregates solve the fanout problem automatically. When joining tables with different granularities, Looker generates SQL that calculates measures at the correct level before joining.

Derived Tables for Complex Transformations

Derived tables create virtual tables from SQL queries or LookML-defined aggregations. Native derived tables use LookML syntax; SQL-derived tables embed raw SQL.

# views/customer_order_facts.view.lkml
view: customer_order_facts {
  derived_table: {
    explore_source: orders {
      column: customer_id { field: customers.customer_id }
      column: first_order_date { field: orders.created_date }
      column: lifetime_orders { field: orders.total_orders }
      column: lifetime_revenue { field: orders.total_revenue }
      derived_column: customer_tenure_days {
        sql: DATE_DIFF(CURRENT_DATE(), first_order_date, DAY) ;;
      }
    }
    datagroup_trigger: daily_etl
    indexes: ["customer_id"]
  }

  dimension: customer_id {
    primary_key: yes
    hidden: yes
    type: number
  }

  dimension: first_order_date {
    type: date
    sql: ${TABLE}.first_order_date ;;
  }

  dimension: lifetime_orders {
    type: number
    sql: ${TABLE}.lifetime_orders ;;
  }

  dimension: customer_tier {
    type: string
    sql: CASE
      WHEN ${lifetime_orders} >= 10 THEN 'Gold'
      WHEN ${lifetime_orders} >= 5 THEN 'Silver'
      ELSE 'Bronze'
    END ;;
  }
}

The datagroup_trigger controls when Looker rebuilds the derived table—typically after upstream ETL completes. Persistent derived tables (PDTs) materialize in the database, trading storage for query speed.

Interviewers ask about PDT rebuild strategies. The sql_trigger_value parameter runs a SQL query; when the result changes, Looker rebuilds the PDT. A common pattern uses SELECT MAX(updated_at) FROM source_table.

Looker Interview Questions: Model Design

Technical interviews for Looker roles focus heavily on LookML modeling decisions. These questions assess whether candidates understand the tradeoffs between flexibility and performance.

Question: How would you model a fact table with multiple date dimensions?

The answer involves creating separate dimension groups and explicitly naming the joins:

# views/orders.view.lkml
view: orders {
  dimension_group: order_created {
    type: time
    timeframes: [date, week, month, year]
    sql: ${TABLE}.created_at ;;
  }

  dimension_group: order_shipped {
    type: time
    timeframes: [date, week, month, year]
    sql: ${TABLE}.shipped_at ;;
  }

  dimension: days_to_ship {
    type: number
    sql: DATE_DIFF(${order_shipped_date}, ${order_created_date}, DAY) ;;
  }
}

Question: When would you use a PDT versus a dbt model?

PDTs work well for Looker-specific aggregations that change with the model. dbt transformations suit shared datasets consumed by multiple tools. The dbt + Looker integration pattern uses dbt for heavy transformations and PDTs for last-mile metrics.

Question: How do you handle slowly changing dimensions in LookML?

Type 2 SCD tables require filtering to the current record. Add a dimension that filters rows and use always_filter in the explore:

# views/customer_history.view.lkml
view: customer_history {
  dimension: is_current {
    type: yesno
    sql: ${TABLE}.end_date IS NULL ;;
  }
}

# In the explore
explore: orders {
  join: customer_history {
    sql_on: ${orders.customer_id} = ${customer_history.customer_id} ;;
    relationship: many_to_one
  }
  always_filter: {
    filters: [customer_history.is_current: "Yes"]
  }
}

Liquid Templating for Dynamic Models

Liquid templating enables conditional logic in LookML definitions. User attributes, filter values, and permissions can modify the generated SQL.

# views/regional_orders.view.lkml
view: regional_orders {
  sql_table_name: 
    {% if _user_attributes['region'] == 'EMEA' %}
      analytics.orders_emea
    {% elsif _user_attributes['region'] == 'APAC' %}
      analytics.orders_apac
    {% else %}
      analytics.orders_us
    {% endif %}
  ;;

  dimension: amount {
    type: number
    sql: ${TABLE}.amount ;;
    html: 
      {% if value > 1000 %}
        <span style="color: green;">{{ rendered_value }}</span>
      {% else %}
        {{ rendered_value }}
      {% endif %}
    ;;
  }
}

User attributes drive row-level security and dynamic table selection. The _user_attributes object provides access to values assigned in the Looker admin panel.

The html parameter customizes how values render in tables and visualizations—conditional formatting that appears frequently in interview take-home projects.

Performance Optimization Patterns

Looker generates SQL from LookML definitions. Optimization requires understanding both the model layer and the underlying database.

Aggregate awareness pre-computes common aggregations at different grain levels:

# views/orders.view.lkml
view: orders {
  aggregate_table: daily_orders {
    query: {
      dimensions: [created_date]
      measures: [total_orders, total_revenue]
    }
    materialization: {
      datagroup_trigger: daily_etl
    }
  }

  aggregate_table: monthly_orders {
    query: {
      dimensions: [created_month]
      measures: [total_orders, total_revenue]
    }
    materialization: {
      datagroup_trigger: daily_etl
    }
  }
}

Looker automatically routes queries to the smallest aggregate table that satisfies the request. A monthly dashboard query reads from monthly_orders instead of scanning the entire fact table.

Connection-level settings impact performance significantly. BigQuery connections should enable query caching and set appropriate timeouts. The max_connections parameter controls concurrent query slots.

For data analysts preparing for interviews, the SQL window functions guide covers query patterns that complement LookML modeling skills.

Access Controls and Content Management

Row-level security, model permissions, and content organization appear in senior-level Looker interviews. The access_grant mechanism controls feature availability:

# models/ecommerce.model.lkml
access_grant: can_view_pii {
  user_attribute: department
  allowed_values: ["data_team", "compliance"]
}

explore: customers {
  access_filter: {
    field: customers.region
    user_attribute: allowed_regions
  }
}

view: customers {
  dimension: email {
    type: string
    sql: ${TABLE}.email ;;
    required_access_grants: [can_view_pii]
  }
}

The access_filter dynamically adds WHERE clauses based on user attributes. A sales manager sees only their region's data. The required_access_grants parameter hides dimensions from users who lack the specified grant.

Content organization follows a folder hierarchy. Production dashboards live in shared spaces; development work stays in personal folders until validated. The LookML validator catches syntax errors before deployment.

Common Interview Mistakes to Avoid

Technical Looker interviews reveal common misconceptions:

Incorrect relationship declarations cause metric inflation. A one_to_one relationship on a one_to_many join produces wrong aggregates. Always verify cardinality with SELECT COUNT(*), COUNT(DISTINCT key) queries.

Over-relying on SQL-derived tables instead of native derives. Native derived tables integrate with Looker's dependency tracking; SQL-derived tables require manual management.

Ignoring datagroup caching. Without proper cache invalidation, dashboards show stale data. Define datagroups that align with ETL schedules and assign them to explores.

For comprehensive interview preparation on data modeling and analytics concepts, the data analytics interview questions guide covers broader topics beyond Looker-specific knowledge.

Conclusion

Succeeding in Looker interviews requires demonstrating both LookML syntax knowledge and understanding of why the semantic layer architecture benefits organizations:

• LookML views define dimensions and measures; explores combine views through declared joins with explicit relationship types
• Derived tables materialize complex transformations; datagroups control cache invalidation and PDT rebuild schedules
• Liquid templating enables dynamic SQL generation based on user attributes and filter selections
• Aggregate awareness pre-computes metrics at multiple grains, routing queries to the optimal table automatically
• Access controls combine row-level filters, access grants, and content permissions for governed self-service
• Performance optimization requires aligning LookML patterns with database-specific tuning (BigQuery slots, Snowflake warehouses)

Practice building LookML models against sample datasets before interviews. The BigQuery public datasets provide realistic schemas for modeling exercises.