Cloud data
We ask candidates to choose batch or streaming components, control BigQuery cost and explain ordering, duplication and replay behaviour in an event-driven pipeline.
- BigQuery
- Dataflow
- Pub/Sub
- GCP
- Google Cloud
UK, Europe, USA
Data engineers screened for pipeline reliability, storage decisions and production-scale processing.
Technical screening by developers and CTOs is included.

We recruit data engineers for ingestion, transformation, storage and event-driven systems. Technical screening covers pipeline design, SQL and NoSQL trade-offs, cloud data services, observability and the operational behaviour of distributed data workflows.
When to hire Data engineers: A company building its first dedicated data platform. A high-volume ingestion or event-processing system. A product team improving data reliability and performance.
We map the data sources, volume, latency, consumers and cloud environment before deciding what experience is essential.
We ask candidates to choose batch or streaming components, control BigQuery cost and explain ordering, duplication and replay behaviour in an event-driven pipeline.
We test data modelling, partitioning, indexing and consistency decisions by asking how access patterns and retention requirements change the storage design.
We ask how pipelines recover from partial failure, remain idempotent and expose data quality problems before incorrect records reach downstream products.
We look for people who question surprising data, investigate causes rather than patch symptoms and can explain quality, uncertainty and trade-offs to colleagues who do not work directly with data systems.
Candidates work through the movement, quality and failure behaviour of data rather than describing tools in isolation.
Batch and streaming choices, orchestration, idempotency and recovery.
Schemas, query patterns, warehouse design and storage trade-offs.
Testing, observability, data quality, performance and incident diagnosis.
Tool names are not enough. Across every role, we look for technical depth, disciplined use of AI and an honest approach to solving unfamiliar problems.
We keep asking why and how until we reach the underlying behaviour. Candidates should understand what their framework, runtime, database, browser, cloud service or design tool is doing for them, how they work behind the scenes (and why), and how they would investigate a failure without relying on copying fixes from ChatGPT.
We expect candidates to use AI productively, but never as a substitute for judgement. They need to explain how they verify generated code, designs and tests, protect confidential data, catch unsafe assumptions and remain accountable for the result. We expect them to use MCPs, skills, and goals. So basically - we are looking for structured AI-assisted work, not vibe coding, vibe designing or vibe testing.
Strong candidates have a can-do mindset and will investigate, experiment and learn when the answer is not obvious. At the same time, they are fair and transparent about what they know, what they have not done before and when they need support.
Give us a few details about the role and your hiring plans. We'll assess your needs and get back to you with a practical next step.
We recruit for relational and NoSQL data platforms, batch and streaming pipelines, cloud warehouses, event-driven systems and advanced ingestion workloads. Relevant technologies have included BigQuery, Dataflow, Pub/Sub, SQL and Temporal.
Yes. The assessment can cover pipeline architecture, data modelling, query behaviour, performance and operational reliability.
Yes. We define the cloud platform, storage, processing, orchestration, networking, access controls and observability the role owns, then tailor sourcing and technical assessment to that environment.