Looker developers build and maintain the LookML data models and dashboards that allow business stakeholders to explore data, build their own analyses, and access consistent metrics across the organization — designing Explores that expose the right joins and fields for business users to query, writing LookML views that define dimensions, measures, and the business logic that transforms database fields into meaningful metrics, and implementing the Looker governance structure that ensures every team is working from the same metric definitions rather than independently calculating numbers that contradict each other. At remote-first technology companies, they serve as the semantic layer architects who translate raw data warehouse tables into a business-readable data model — enabling distributed non-technical stakeholders to answer their own questions through Looker's Explore interface without writing SQL, while ensuring that the metrics those stakeholders produce are consistent with the definitions agreed on by finance, product, and operations.
What Looker developers do
Looker developers write LookML models — defining views that map to database tables with dimensions, measures, and derived tables; building Explores that expose joinable views with appropriate relationship definitions, access filters, and SQL WHERE clauses that scope data for business domains; design dimensions and measures — writing dimension groups, yesno dimensions, tier dimensions, and measures (count, count_distinct, sum, average, max, min) with appropriate SQL expressions, labels, and descriptions; implement derived tables — building PDTs (Persistent Derived Tables) and NDTs (Native Derived Tables) for complex aggregations that can't be expressed directly in LookML measure syntax; build dashboards — creating Looker dashboards with tiles, text tiles, filters, and cross-filter interactions that provide business stakeholders with operational visibility; configure access controls — implementing access filters for row-level security, model-level permissions for restricting Explore access by team, and field-level access grants for sensitive data; implement Looker parameters and liquid — using Looker's Liquid templating to build dynamic queries, parameterized content, and user-attribute-driven filtering; maintain LookML code — managing version control in Git, reviewing Looker CI validation results, and refactoring LookML as underlying data models change; create and maintain the Looker data catalog — documenting views, dimensions, and measures with descriptions that make the self-service environment genuinely usable for non-technical stakeholders; integrate Looker — configuring Looker Embedded (iframe and signed URL embedding) for customer-facing analytics, connecting Looker Actions to external systems, and using the Looker API for programmatic dashboard and report management.
Key skills for Looker developers
- LookML: view files, model files, Explore definitions, join syntax (one-to-many, many-to-one, many-to-many fanout handling), derived tables
- Dimensions and measures: dimension types (string, number, yesno, date, tier), measure types (count, sum, average, count_distinct), custom measure SQL
- Derived tables: PDT (Persistent Derived Tables) with materialization triggers, NDT (Native Derived Tables), SQL derived tables for complex calculations
- Looker Explores: join cardinality, symmetric aggregates, access filters, always_filter, conditionally_filter, required_access_grants
- Liquid templating: liquid parameters, user attributes in LookML, dynamic SQL generation, referencing other fields in Liquid
- LookML refinements: extending views with refinements for modular model building, override patterns for database-agnostic LookML
- Looker features: dashboards, Looks, schedules and alerts, Looker Blocks (marketplace templates), Looker Embedded Analytics
- SQL: understanding underlying SQL generated by LookML for debugging and optimization, writing efficient derived table SQL
- Looker Admin: project configuration, Git integration, connection management, user and group management, caching policies
- dbt integration: using dbt-generated documentation as Looker metadata, referencing dbt models as Looker views, dbt Semantic Layer integration
Salary expectations for remote Looker developers
Remote Looker developers earn $100,000–$165,000 total compensation. Base salaries range from $85,000–$140,000, with equity at technology companies where data accessibility and self-service analytics maturity directly affect decision-making velocity. Looker developers with deep LookML modeling expertise, symmetric aggregate understanding for complex join patterns, Looker Embedded implementation experience, and demonstrated ability to build self-service data environments that non-technical teams actually adopt command the strongest premiums. Those with experience building enterprise-scale Looker environments — hundreds of Explores, complex access control hierarchies, multi-database connections — earn toward the top of the range.
Career progression for Looker developers
The path from Looker developer leads to senior analytics engineer (expanding upstream data modeling with dbt alongside Looker), BI manager (leading a team of analytics engineers and BI developers), or data product manager (where LookML modeling depth informs decisions about how data products are designed and governed). Some Looker developers specialize into Looker administration and platform governance, becoming organizational authorities on LookML standards, access control policy, and performance optimization. Others transition into broader analytics engineering, where their semantic modeling skills apply across the full dbt + Looker + BI tool stack. Google's acquisition of Looker (2020) and the integration of Looker into Google Cloud's data analytics ecosystem creates career paths into Google Cloud data and analytics engineering.
Remote work considerations for Looker developers
Building a self-service analytics environment at a remote company requires LookML modeling discipline and documentation standards that make Looker genuinely usable for distributed non-technical stakeholders without requiring a Looker expert to guide every analysis. Looker developers at remote companies write meaningful descriptions for every dimension and measure — explaining in business language what the field measures, how it's calculated, and any edge cases — so distributed stakeholders can understand what they're querying without a synchronous explanation; organize Explores with appropriate labels, hidden fields for technical dimensions, and groups that structure the field picker so business users can find what they need; enforce strict naming conventions and LookML review standards so the model remains navigable as it grows to hundreds of fields; create Looker training resources — written guides, recorded walkthroughs, example Explores for common use cases — that allow distributed team members to onboard to Looker independently; and maintain consistent metric definitions through LookML's single-source-of-truth architecture, preventing the metric fragmentation that occurs when distributed teams define the same metric differently in different tools.
Top industries hiring remote Looker developers
- Data-mature SaaS technology companies where Looker serves as the self-service analytics layer for distributed product, growth, finance, and operations teams who need to answer data questions independently without waiting for analyst support
- Fintech and financial services companies where consistent metric definitions for revenue, customer lifetime value, and portfolio performance are business-critical requirements that Looker's LookML semantic layer enforces across the organization
- Healthcare and life sciences companies where clinical analytics, operational efficiency metrics, and patient outcome reporting require Looker deployments with HIPAA-compliant infrastructure and row-level security for PHI access control
- E-commerce technology companies where customer funnel analytics, marketing attribution metrics, inventory reporting, and growth metrics are queried by distributed teams who need a self-service environment with guardrails against incorrect metric calculation
- Enterprise analytics platforms and data-as-a-service companies where Looker Embedded enables customer-facing analytics features — embedded dashboards, white-labeled reporting, customer data exploration — delivered through the Looker Embed SDK
Interview preparation for Looker developer roles
Expect LookML modeling questions: given a database schema with an orders table, an order_items table, a products table, and a customers table, design the LookML Explore that allows business users to analyze order-level and product-level metrics without duplicating data due to join fanout — what the join relationships look like and how you'd implement symmetric aggregates. Derived table questions ask how you'd write a PDT that calculates each customer's first purchase date and their 30-day and 90-day retention status — what the SQL logic looks like and when the PDT should persist. Metric definition questions ask how you'd define Monthly Recurring Revenue in LookML for a subscription business where customers can have multiple subscriptions with different statuses — what the measure type is, what the SQL expression looks like, and how you'd handle subscription start and end dates. Access control questions ask how you'd implement row-level security in Looker so that each sales regional manager sees only their own region's data. Be ready to walk through the most complex LookML model you've built — the join complexity, the derived table challenges, and how you measured whether business stakeholders actually adopted the self-service environment.
Tools and technologies for Looker developers
Core: Looker (Google Cloud) for semantic modeling and self-service analytics; LookML for data model definition; Looker Explore for ad-hoc analysis; Looker Dashboards for shared reporting. Development: LookML syntax in Looker's built-in IDE with validation; Git integration for version control and branching; Looker's CI validation for syntax and reference checks. Databases: Looker supports 50+ database dialects including BigQuery (native Google Cloud integration), Snowflake, Redshift, Databricks, PostgreSQL, MySQL, and Azure Synapse. dbt integration: lookml-tools for generating LookML from dbt manifest; dbt-looker package for generating LookML views from dbt models automatically; Looker's dbt Semantic Layer integration. Looker Embedded: Looker Embed SDK for iframe embedding; Signed URL embedding for cookieless contexts; Looker API for programmatic content management. Monitoring: Looker System Activity Explores for query performance analysis, user engagement tracking, and database load monitoring. Complementary tools: Mode Analytics, Hex, and Sigma as adjacent BI tools for context; Census and Hightouch for reverse ETL from Looker-modeled data into operational tools.
Global remote opportunities for Looker developers
Looker expertise is in strong demand globally, with the platform's adoption as the semantic layer standard in Google Cloud-centric data stacks and its position as a premium self-service analytics tool at growth-stage and enterprise technology companies. US-based Looker developers are in demand at technology companies with sophisticated data teams where Looker's LookML governance model is chosen precisely because it prevents the metric fragmentation that occurs in less governed BI tools. EMEA-based Looker developers are well-positioned given Google Cloud's strong European enterprise adoption and Looker's integration with BigQuery, which many European organizations use as their primary analytical data warehouse. The platform's integration into Google Cloud's broader data analytics ecosystem — Vertex AI, BigQuery, Dataform — creates career opportunities for Looker developers who develop complementary skills in Google Cloud's data platform offerings.
Frequently asked questions
What is LookML and how is it different from writing SQL directly in a BI tool? LookML (Looker Modeling Language) is a Git-versioned, code-defined semantic data model that sits between your database and Looker's UI. Rather than writing SQL each time someone needs data, developers write LookML once — defining how tables join, what every metric means, and how every dimension is calculated — and business users interact with a structured, controlled interface that generates correct SQL automatically. The key differences from writing SQL directly: version control (LookML in Git means every metric definition change is auditable and reversible); single source of truth (when "Monthly Active Users" is defined once in LookML, every dashboard and Explore that uses it is automatically consistent); validation (Looker validates LookML against your database schema at save time, catching broken references before they reach production); access control (LookML's access_grant and access_filter systems control which users see which data through Looker's interface, enforced at query generation time). The trade-off: LookML adds a modeling layer that requires dedicated development investment; it's not appropriate for ad-hoc SQL work or organizations without a dedicated analytics engineering resource.
How do Looker developers handle many-to-many join relationships and fanout in LookML? Fanout occurs when joining a one-to-many relationship causes measures to be overcounted — for example, joining orders (one-to-many) to order_items means a SUM of order revenue in an Explore that fans out to items will sum revenue once per line item rather than once per order. Looker's solution is symmetric aggregates — when a view has a primary_key defined, Looker automatically generates SQL that uses COUNT(DISTINCT) and conditional aggregation to compute accurate aggregates regardless of join fanout. Implementation: always define primary_key on every view with a stable, unique identifier; use type: sum, type: count, type: average measures (Looker handles the symmetric aggregate SQL); avoid type: number measures that compute SQL expressions directly (these don't get symmetric aggregate treatment). For true many-to-many relationships (e.g., products-to-tags): don't join a bridge table through the main Explore; instead, create a separate Explore for the many-to-many analysis, or pre-aggregate in a derived table before exposing to Looker. The most common modeling mistake is creating joins without primary_keys defined, resulting in silent overcounting that business users discover when dashboard numbers don't match expectations.
How do Looker developers measure and improve self-service analytics adoption? Using Looker's System Activity — a built-in Explore that logs every query, dashboard view, and user action in Looker — to understand who is using which content, how frequently, and whether users are successfully getting value from the self-service environment. Key metrics: weekly active users by department (are non-technical teams actually exploring data?); Explore usage rate (which Explores get queries vs which are unused?); query success rate (do users find what they need, or do they frequently encounter errors?); dashboard tile load time (slow tiles reduce engagement). Common adoption problems: poor field discoverability (too many fields with technical names, no descriptions, no organization into groups) — fix with labels, descriptions, and hidden: yes on internal technical fields; confusing Explore organization (business users open the wrong Explore) — fix with Explore labels that map to business concepts ("Customer Orders" not "orders_order_items_products"); query timeouts discouraging exploration — fix with appropriate aggregate tables and caching policies. Looker developers who treat adoption as a product metric — running user research interviews with business stakeholders, iterating on Explore design based on usage data — build self-service environments that genuinely replace ad-hoc analyst requests.