Google LookML-Developer Looker LookML Developer Exam

About this certification exam
Length: 100 minutes
Registration fee: $250
Language: English
Exam format: Multiple choice and multiple select taken remotely or in person at a test center. Locate a test center near you.

Exam Delivery Method:
a. Take the online-proctored exam from a remote location, review the online testing requirements.
b. Take the onsite-proctored exam at a testing center: locate a test center near you.

Prerequisites: None
Recommended experience: Business analysts with 5+ months of experience using Looker for report development, data visualization, and dashboard best practices.

Looker LookML Developer
A Looker LookML Developer works with datasets and LookML and is familiar with SQL and BI tools. LookML Developers are proficient in model management, including troubleshooting existing model errors, implementing data security requirements, creating LookML objects, and maintaining LookML project health. LookML Developers design new LookML dimensions and measures and build Explores for users to answer business questions. LookML developers are skilled at quality management, from implementing version control to assessing code quality to utilizing SQL runner for data validation.

The Looker LookML Developer exam assesses your ability to:
Maintain and debug LookML code
Build user-friendly Explores
Design robust models
Define caching policies
Understand various datasets and associated schemas
Use Looker tools such as Looker IDE, SQL Runner, & LookML Validator

Exam overview
Step 1: Understand what’s on the exam

The exam guide contains a complete list of topics that may be included on the exam. Review the exam guide to determine if your knowledge aligns with the topics on the exam.

Certification exam guide
A Looker LookML Developer works with datasets and LookML and is familiar with SQL and BI tools. LookML Developers are proficient in model management, including troubleshooting existing model errors, implementing data security requirements, creating LookML objects, and maintaining LookML project health. LookML Developers design new LookML dimensions and measures, and build Explores for users to answer business questions. LookML developers are skilled at quality management, from implementing version control to assessing code quality to utilizing SQL runner for data validation.

Section 1: Model management

1.1 Troubleshoot errors in existing data models. For example:

Determine error sources
Apply procedural concepts to resolve errors

1.2 Apply procedural concepts to implement data security requirements. For example:

Implement permissions for users
Decide which Looker features to use to implement data security (e.g., access filters, field-level access controls, row-level access controls)

1.3 Analyze data models and business requirements to create LookML objects. For example:

Determine which views and tables to use
Determine how to join views into Explores
Build project-based needs (e.g., data sources, replication, mock reports provided by clients)

1.4 Maintain the health of LookML projects in a given scenario. For example:

Ensure existing contents are working (e.g., use Content Validator, audit, search for errors)
Resolve errors

Section 2: Customization

2.1 Design new LookML dimensions or measures with given requirements. For example:

Translate business requirements (specific metrics) into the appropriate LookML structures (e.g., dimensions, measures, and derived tables)
Modify existing project structure to account for new reporting needs
Construct SQL statements to use with new dimensions and measures

2.2 Build Explores for users to answer business questions. For example:

Analyze business requirements and determine LookML code implementation to meet requirements (e.g., models, views, join structures)
Determine which additional features to use to refine data (e.g., sql_always_where, always_filter, only showing certain fields using hidden: fields:, etc.)

Section 3: Optimization

3.1 Apply procedural concepts to optimize queries and reports for performance. For example:

Determine which solution to use based on performance implications (e.g., Explores, merged results, derived tables)
Apply procedural concepts to evaluate the performance of queries and reports
Determine which methodology to use based on the query and reports performance sources (e.g., A/B testing, SQL principles)

3.2 Apply procedural concepts to implement persistent derived tables and caching policies based on requirements. For example:

Determine appropriate caching settings based on data warehouse’s update frequency (e.g., hourly, weekly, based on ETL completion)
Determine when to use persistent derived tables based on runtime and complexity of Explore queries, and on users’ needs
Determine appropriate solutions for improving data availability (e.g., caching query data, persisting tables, combination solutions)

Section 4: Quality

4.1 Implement version control based on given requirements. For example:

Determine appropriate setup for Git branches (e.g., shared branches, pull from remote production)
Reconcile merge conflicts with other developer branches (e.g., manage multiple users)
Validate the pull request process

4.2 Assess code quality. For example:

Resolve validation errors and warnings
Utilize features to increase usability (e.g., descriptions, labels, group labels)
Use appropriate coding for project files (e.g., one view per file)

4.3 Utilize SQL Runner for data validation in a given scenario. For example:

Determine why specific queries return results by looking at the generated SQL in SQL Runner
Resolve inconsistencies found in the system or analysis (e.g., different results than expected, non-unique primary keys)
Optimize SQLs for cost or efficiency based on business requirements

QUESTION 1
Business users report that they are unable to build useful queries because the list of fields in the Explore is too long to find what they need.
Which three LookML options should a developer use to curate the business user?s experience? (Choose three.)

A. Add a description parameter to each field with context so that users can search key terms.
B. Create a separate project for each business unit containing only the fields that the unit needs.
C. Add a group_label parameter to relevant fields to organize them into logical categories.
D. Use the hidden parameter to remove irrelevant fields from the Explore.
E. Use a derived table to show only the relevant fields.

Answer: A,C,E

QUESTION 2
A user reports that a query run against the orders Explore takes a long time to run. The query includes only
fields from the users view. Data for both views is updated in real time. The developer runs the following query
in SQL Runner and quickly receives results:
SELECT * FROM users.
What should the developer do to improve the performance of the query in the Explore?

A. Create an Explore with users as the base table.
B. Create a persistent derived table from the user?s query.
C. Create an ephemeral derived table from the user?s query.
D. Add persist_for: ?24 hours? to the orders Explore.

Answer: A

QUESTION 3
A developer has User Specific Time Zones enabled for a Looker instance, but wants to ensure that queries run
in Looker are as performant as they can be. The developer wants to add a datatype: date parameter to all
dimension_group definitions without time data in a table-based view, so that time conversions don?t occur for these fields.
How can the developer determine to which fields this parameter should be applied through SQL Runner?

A. Open the Explore query in SQL Runner and validate whether removing the conversion from date fields changes the results.
B. Open the Explore query in SQL Runner to determine which fields are converted.
C. Use the CAST function in SQL Runner to ensure that all underlying fields are dates and conversions are not applied.
D. Use the Describe feature in SQL Runner to determine which fields include time data.

Answer: C