Written Assessment - Head of Data
Engineering
Overview
This written assessment is part of our interview process.
It is not a test and there are no right or wrong answers.
We are interested in how you think, how you handle ambiguity, and how you make trade offs in
environments where context shifts and direction evolves.
Time: 90 minutes
Format: Written, open book
Style: Bullet points are welcome
You may ask clarifying questions in writing if you wish. You should assume you will not receive
answers.
Part 1: Establishing Control in a Moving System
Context
You join Block Labs as Head of Data Engineering.
The company operates in a fast moving environment with evolving priorities, incomplete
information, and frequent context switching.
Within your first 60 days, three things happen at the same time:
A strategic partner changes direction. A key upstream dataset you expected to build on will not
be available for at least six months, and may not arrive at all.
The CEO asks a broad question:
“Can we get to reliable, near real time operational reporting this quarter, and reduce manual
spreadsheet work?ˮ
No clear success criteria are defined yet.
You discover that core operational data is fragmented across multiple systems, inconsistently
defined, poorly documented, and in some cases partially owned or controlled by external
vendors.
Several teams rely on manual exports, spreadsheets, and ad hoc scripts to compensate.
You have no additional headcount approved yet, and the longer term data strategy is still forming.
Prompt
Describe how you would approach the next 30 days.
You may include:
How you would frame the situation and define the problem in a way leadership can align on
What you would prioritise vs defer (and why)
1
Written Assessment Head of Data Engineering
How you would decide where to standardise first: definitions, pipelines, tooling, access,
governance, or reliability
How you would communicate uncertainty and risk (including data quality risk)
How you would balance quick wins with foundations that prevent repeated fire drills
What you would explicitly choose not to do yet
Try to be specific about outputs you would aim to deliver by day 30 (even if imperfect).
Part 2: Designing a Practical Data Platform Roadmap
Context
You inherit a landscape that looks roughly like this:
Multiple data sources: product events, operational tooling, finance systems, vendor exports
A mix of batch and manual processes, with unclear ownership
No single source of truth for key metrics (different teams compute them differently)
Stakeholders who want dashboards and answers, but definitions are unsettled
Compliance and audit expectations are increasing
Leadership wants progress quickly, but also wants to avoid building something that collapses under
growth.
Prompt
Propose a 90 day roadmap that gets the business to a noticeably better place without over
engineering.
Please cover:
Your guiding principles (for example: reliability first, semantic consistency, minimum viable
governance)
Your recommended target architecture at a high level (no vendor names needed, but you can
include them if helpful)
How you would approach:
Ingestion (sources, change data capture vs batch, vendor feeds)
Modelling (raw, staging, curated, semantic layer, metric ownership)
Data quality (tests, monitoring, contracts, incident handling)
Access and security (least privilege, auditability, PII handling)
Documentation and discoverability (catalogue, ownership, definitions)
What you would deliver at the end of:
30 days
60 days
90 days
What you would explicitly de scope in the first 90 days, even if stakeholders ask
2
Written Assessment Head of Data Engineering
Part 3: Building Trust Through Delivery
Context
Some teams are frustrated. They feel the “data functionˮ historically says no, moves slowly, or
produces outputs that do not match how the business actually works.
At the same time, you see real risks:
Metrics are inconsistent
Data is used for decisions without confidence levels
Pipelines fail silently
Vendor controlled data has unclear SLAs
Ad hoc access patterns raise security and compliance concerns
Prompt
Explain how you would rebuild confidence across the company.
Please include:
How you would align stakeholders on metric definitions without endless debate
How you would handle competing priorities from the CEO, Ops, Finance, Product, and
Engineering
What you would measure to prove progress (beyond “more dashboardsˮ)
How you would set expectations about reliability, latency, and correctness
What your escalation and incident approach would look like for data issues
How you would avoid becoming the team that everyone queues behind
Part 4: Building a Small but Durable Team
Context
After initial alignment, you receive approval to hire up to five people for a Data Engineering team
over the next 12 months.
Constraints:
The roadmap is fluid and likely to change
Data is seen as both an opportunity and a risk
You expect high context switching and evolving scope
You are accountable for both delivery and sustainability
Prompt
Describe your approach to building this team.
Please cover:
The five roles or profiles you would prioritise (job titles are not required)
3
Written Assessment Head of Data Engineering
What you would deliberately avoid hiring at this stage
How you would structure responsibilities so the team does not become a bottleneck
How you think about platform work vs analytics enablement vs stakeholder embedded work
Your approach to on call, ownership, and operational load as the team scales
Part 5: Navigating a Strategic Pivot
Context
Six months in, leadership decides that:
The company will optimise for operational excellence and predictable reporting.
Near real time analytics and advanced experimentation are now lower priority.
The focus is reliable financial and operational truth, governance, and cost control.
As a result:
Some planned initiatives are no longer relevant
Some work in progress may be stopped or reframed
The team is aware that direction has changed
Prompt
Explain how you would:
Reset direction with your team and stakeholders
Decide what to stop, what to keep, and what to reframe
Protect morale and focus during the change
Handle sunk cost and prior commitments without losing credibility
Ensure the platform still supports future needs, without betting on them
Part 6: Leadership and Self Awareness
Please answer the following briefly and honestly:
What kind of data engineering problem do you personally tend to over optimise?
What kind of decision do you tend to delay longer than you should?
What type of person do you find hardest to work with, and why?
What would make you feel that staying in this role after 18 months is no longer the right choice
for you?
Final Notes
This exercise will be used as a starting point for a deeper conversation in the next interview.
We are not expecting perfect answers, only thoughtful ones.