Analytics Engineer

An Analytics Engineer is a specialist who transforms data into reusable models for analysis and decision-making. They organise data so that analysts and business teams can use it and understand what it means. Their work combines building models, testing, documentation and maintaining transformations.

For a role focused on analytical transformation, deliverables include SQL models developed with dbt. The work goes beyond one-off queries: it makes transformations understandable and reusable by other people.

Analytics Engineer, Data Analyst and Data Engineer: who does what?

• An Analytics Engineer builds and maintains the models that prepare data for analytical use. They apply development practices, such as version control and code review, to transformations.
• A Data Analyst focuses on analysing and interpreting data to answer business questions. The Analytics Engineer’s models provide a foundation for their work.
• A Data Engineer is the person to consider for a need primarily focused on ingestion and pipelines. These responsibilities are not all included in a role focused on analytical transformation.

The role sits at the interface between business users, analysis and data engineering. To define reporting arrangements, specify who prioritises the models to be built, who reviews the code and who validates the definitions used. These responsibilities must be explicit, even when one person combines several activities. Designing the overall data architecture goes beyond this scope of analytical transformation.

Having data in a warehouse is not enough to make it easy to use. The company still needs to translate its requirements into structures suited to analysis. The purpose of the role is to make this work reusable: users should be able to understand what a model contains, how it was built and which uses it supports.

Reliability also requires explicit checks. In dbt, tests can identify missing values, duplicates in a column that should be unique or missing relationships between models. They check the assertions chosen by the team. They do not determine on the team’s behalf whether a metric’s definition meets the business need.

Hypothetical example: two teams use different definitions of an active customer. A model can run correctly and pass its tests while applying the definition expected by only one team. Before sharing this model, clarify its uses, the differences between definitions and the people responsible for validating them. The documentation should make the choice understandable to future users.

Hiring also affects the ability to adapt transformations over time. A model delivered without explanations or a review of changes can become difficult for others to take over. Version control allows changes to the code to be examined, while documentation helps explain dependencies and associated checks. Ask for maintainable deliverables, not just a result that works during a demonstration.

Finally, match the expected level of autonomy to the support available. Developing an assigned model with support is not the same as coordinating changes across several models and reviewing other people’s work. Assigning these broader responsibilities without providing a technical point of contact is a mistake in defining the role. Defining the users the person will support and the decisions they will be able to make helps you choose the right level of responsibility.

• Gather user requirements to define the analytical models to build.
• Translate business processes into data structures suited to analysis.
• Develop reusable SQL transformations in dbt models.
• Define tests to identify data that does not meet the expected rules.
• Document models, their columns, sources and dependencies.
• Examine code changes with the people responsible for reviewing them.
• Maintain transformations as requirements or the data used evolve.
• Explain modelling choices and the limitations of the available data to users.

Relevant skills can be developed through data analysis or engineering. The aim is to connect an understanding of how data is used with the development of maintainable transformations.

A background as a Data Analyst can provide a good understanding of business questions. Moving into analytics engineering also requires skills in version control, testing and code organisation. A query used for a one-off analysis does not, on its own, demonstrate the ability to maintain a shared model. An engineering background, for its part, should include clear experience of translating user requirements into analytical structures.

In terms of education before entering the role, GitLab cites subjects including computer science, mathematics, information systems and data analysis. These are examples from one employer, not a compulsory qualification for this role in France. The British framework also provides for a supported entry route, with training and learning on the job.

Developing and testing assigned models with support allows these skills to be built in practice. Experience of technical review, coordinating changes and supporting colleagues prepares people for broader responsibilities.

GetPro’s common assessment framework

GetPro structures assessment around a framework that prioritises the skills and expectations of the role. It distinguishes what can be verified from a candidate’s background from what needs to be explored further in an interview, with a defined assessment method for each criterion. Interviews explore key criteria through open questions and concrete examples.

Reference checks complement the interview by clarifying the context of the working relationship, skills and areas to explore further. They draw on examples of skills put into practice.

Suggested applications for an Analytics Engineer

The following guidance adapts this framework to the role. The suggested technical criteria and exercises are not documented GetPro-specific practices.

1. Define the criteria to observe

Start with the models the person will need to build or maintain. Distinguish delivery with support, independent design and reviewing other people’s work. Link each responsibility to something observable.

Use a shared assessment framework: quality of SQL reasoning, suitability of the model, usefulness of the tests, clarity of documentation and explanation of choices. Specify which skills are essential from the outset and which can be developed with support.

Do not infer autonomy solely from the names of the tools mentioned. A precise explanation of decisions made is a positive sign. A list of technologies without a description of contributions leaves that autonomy unclear.

2. Examine past work

Invite the candidate to present a model they helped build, using material they can share. Ask which user need it was intended to meet, which transformations they carried out and who reviewed their choices.

Ask them to clarify their personal contribution and that of their colleagues. Examine how the model was tested, documented and later modified. Look for an explanation of the difficulties encountered and the decisions made to resolve them.

An account that connects the need, model and use helps you assess their understanding of the work. A presentation limited to the final result calls for questions about maintenance and the responsibilities they actually held.

3. Set an exercise that reflects the role

Hypothetical example: provide order and customer tables, together with an analytical need shared by several users. Ask for a SQL transformation, the tests they consider necessary and brief documentation.

If the role uses dbt, ask them to explain how the models are organised and their chosen materialisation. Observe the assumptions they make before development. Ask how the candidate would handle an ambiguous business definition.

Then introduce a change to the requirement or the data. Examine the proposed changes, their consequences for dependent models and the checks that need revisiting. Assess the approach as much as the result presented.

The ability to justify each test by linking it to an expected rule is a positive sign. Technical success without an explanation of what the tests check warrants further exploration.

4. Assess communication and support for others

Include a user of the models in part of the discussion. Ask the candidate to explain a technical choice and its consequences for analysis. Observe whether they clarify terms and check the other person’s understanding.

For a role involving technical review, provide a code change for them to comment on. Look for understandable comments that relate to the requirement and help the author improve their work.

If the role includes management, examine experience of supporting colleagues and coordinating a team separately. A good command of SQL does not, on its own, demonstrate experience of these responsibilities.

5. Compare observations and references

Compare the assessors’ observations against the initial framework. Distinguish a demonstrated skill, a skill that needs further exploration and learning that would be feasible with the planned support.

With the candidate’s consent, use references to clarify the responsibilities they held, their interactions with users and their maintenance of past work. Avoid asking for a general assessment without context.

If your company lacks the necessary expertise, have the technical exercise reviewed by someone with a command of SQL, modelling and testing. Ask business stakeholders to assess the candidate’s understanding of how the data is used.