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 assessed one’s 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
The Looker LookML Developer exam was retired on April 1, 2022.
Quick links
The exam assessed an individual’s capacity in the following topics:
Section 1: Model management
1.1 Troubleshoot errors in existing data models. For
example: a. Determine error sources b. Apply procedural concepts to resolve
errors 1.2 Apply procedural concepts to implement data
security requirements. For example: a. Implement permissions for users b. 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: a. Determine which views and tables to
use b. Determine how to join views into
Explores c. 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: a. Ensure existing contents are working
(e.g., use Content Validator, audit, search for errors)
b. Resolve errors
Section 2: Customization
2.1 Design new LookML dimensions or measures with given
requirements. For example: a. Translate business requirements
(specific metrics) into the appropriate LookML
structures (e.g., dimensions, measures, and derived
tables) b. Modify existing project structure to
account for new reporting needs c. Construct SQL statements to use with
new dimensions and measures 2.2 Build Explores for users to answer business
questions. For example: a. Analyze business requirements and
determine LookML code implementation to meet
requirements (e.g., models, views, join structures) b. 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: a. Determine which solution to use based
on performance implications (e.g., Explores, merged
results, derived tables) b. Apply procedural concepts to evaluate
the performance of queries and reports c. 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: a. Determine appropriate caching settings
based on data warehouse’s update frequency (e.g.,
hourly, weekly, based on ETL completion) b. Determine when to use persistent
derived tables based on runtime and complexity of
Explore queries, and on users’ needs c. 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: a. Determine appropriate setup for Git
branches (e.g., shared branches, pull from remote
production) b. Reconcile merge conflicts with other
developer branches (e.g., manage multiple users) c. Validate the pull request process 4.2 Assess code quality. For example: a. Resolve validation errors and warnings
b. Utilize features to increase usability
(e.g., descriptions, labels, group labels) c. 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: a. Determine why specific queries return
results by looking at the generated SQL in SQL Runner
b. Resolve inconsistencies found in the
system or analysis (e.g., different results than
expected, non-unique primary keys) c. Optimize SQLs for cost or efficiency
based on business requirements