A requisition that reads “Data Lake / Data Warehouse Engineer (Lakehouse experience a plus)” is not one role with flexible scope. It is three roles stacked into one title, priced at the midpoint of three different bands, advertised to three talent pools that barely overlap. Nobody matches it, so nobody good applies, and the req ages out at 90 days while the hiring manager concludes the market is tight. The market is tight. But the titling is what is killing this particular search.
The fix is unglamorous: decide which of the three jobs you are actually buying, title it that, and price it at that band. Below is how the three differ in practice, what each pool looks like, and the screening questions that tell them apart in twenty minutes.
The three jobs are not the same job
A data warehouse engineer optimises for contracts. The artefacts are dimensional or wide denormalised models, incremental builds, SCD handling, tests, and a semantic layer that finance will argue with. The work is Snowflake, BigQuery, Redshift or Synapse plus dbt, and the hard part is modelling judgement — grain, conformance, slowly changing history, and what happens when a late-arriving fact rewrites last quarter. Performance tuning here means clustering keys, pruning and warehouse sizing.
A data lake engineer optimises for ingestion and files. The artefacts are landing and curated zones, partition layouts, compaction jobs, schema-on-read contracts, and orchestration that survives a vendor API changing shape overnight. The work is object storage, Spark or Flink, Kafka, Airflow or Dagster, Parquet, and a lot of IAM. The hard part is operational: skew, small-file explosions, backfills that cost four figures in compute, and failure modes that only appear at 3am.
A lakehouse specialist optimises for the table layer that sits between those two worlds. The artefacts are Delta or Iceberg tables with managed metadata, catalog governance, time travel and branching, OPTIMIZE and VACUUM policy, streaming upserts, and a migration path off whatever came before. This person has to hold both the modelling discipline of the warehouse engineer and the file-level instincts of the lake engineer, which is exactly why there are so few of them.
If the same person could do all three equally well, they would not be applying to your req — they would be setting their own rate.
Side by side
| Data warehouse engineer | Data lake engineer | Lakehouse specialist | |
|---|---|---|---|
| Core artefact | Dimensional / semantic models | Ingestion pipelines, zoned storage | Managed table format + catalog |
| Typical stack | Snowflake, BigQuery, dbt, SQL | S3/ADLS, Spark, Kafka, Airflow | Delta or Iceberg, Unity Catalog or Glue, Spark SQL |
| Hard skill | Modelling judgement, grain, history | Distributed debugging, cost control | Table maintenance, migration, governance |
| Fails at | Streaming, file-level performance | Business semantics, stakeholder modelling | Nothing — which is why the pool is tiny |
| Common real title | Analytics engineer, DW developer | Platform / streaming data engineer | Data platform engineer, Databricks engineer |
| Pool size | Largest of the three | Moderate | Smallest by a wide margin |
The row that matters most is the last one. You can run a conventional, well-run search for the first column. The third column needs a different sourcing motion entirely — closer to how you would go after a Databricks specialist than how you would fill an analytics engineering seat.
The lakehouse pool is smaller than the job boards suggest
Open table formats dominate conference agendas and show up in almost every modern-data-stack diagram. Production reality is narrower. Only 9% of data teams report running Apache Iceberg in production, with 6% planning adoption and 12% in proof-of-concept. If you write “Iceberg required” into a req for work that is really dimensional modelling on Snowflake, you have voluntarily cut your addressable candidate pool by an order of magnitude to buy a keyword you do not need.
And the people who have done it did not learn it from a course. The most-cited barrier to open table format adoption is knowledge gaps at 27% — tied with unclear use cases, and ahead of anything to do with the technology itself. Teams are not rejecting the concept; they are stuck on implementation complexity, which means the experienced cohort is small because the number of completed implementations is small. We have written at more length on why lakehouse adoption stalls on skills rather than platform, and the hiring consequence is direct: this is a pool you source into, not a pool you post into.
Platform depth in general is rarer than requisitions assume. In the wider developer population, 4.5% report extensive work in Snowflake — and Snowflake is one of the most widely adopted platforms in the category. Any req that demands extensive hands-on depth in two platforms plus a table format plus streaming is asking for the intersection of several single-digit percentages.
One word in the title moves the band by about $35k
Titling is not cosmetic. It sets the compensation band, and the band is what determines whether anyone qualified clicks.
Federal wage data makes the point cleanly inside a single occupation family. Database architects carry a median annual wage of $139,500, while database administrators in the same family sit at $104,620. Roughly $35,000 of separation, same occupational family, different word in the title. Those aren’t the exact titles on your req, but the mechanism transfers exactly: design-and-own work prices above run-and-maintain work, and when you blend both into one posting, you almost always price it toward the lower of the two.
What that looks like in practice:
| Req as written | What it signals to candidates | Who actually applies |
|---|---|---|
| Blended lake/warehouse/lakehouse, mid band | “They don’t know what they need” | Generalists under-qualified for all three |
| Blended scope, architect band | “Three jobs, one salary” | Strong candidates read it as a trap and skip |
| Single scope, matched band | Clear ownership, clear level | The pool you intended to reach |
Senior data people screen requisitions for coherence before they screen for money. A posting that lists Kafka, Iceberg, dimensional modelling, Terraform and executive stakeholder management reads as an unresourced team hoping one hire fixes everything — and the strongest candidates have already worked somewhere like that once.
Migration is a programme, not a job description
The most common reason the three titles get blended is a migration. The team is moving from warehouse to lakehouse, so the req tries to describe both the old world and the new one and the bridge between them.
Scope that honestly and it stops being one hire. Databricks reports that IndusInd Bank migrated 1.5 PB across 44 business areas in 15 months. Whatever your volumes, the shape holds: a multi-quarter programme touching dozens of business areas is a different engagement from running the platform afterwards. The migration needs people who have done cutovers, reconciled row counts across engines, and negotiated with 44 sets of report owners. Steady-state needs people who will still be there in year three doing table maintenance and cost governance.
Hiring one person to do both means you either pay migration rates for someone who will be bored by month 18, or you pay steady-state rates for migration work and the cutover slips two quarters. Splitting the scope — specialist capacity for the migration window, permanent ownership for what comes after — is usually cheaper and always faster. That is the same capacity-versus-adoption distinction that decides whether a platform investment lands.
Why the bad title got approved
Nobody writes an incoherent req on purpose. They write it because the inputs were missing. Only 31% of recruiting functions use labour market data to shape talent strategy, per Gartner — so roughly two thirds of requisitions get approved without anyone checking whether the described person exists at the described price.
Title choice also decides how much competition you face, and adjacent data titles are not growing at the same rate. Data scientist employment is projected to grow 33.5% between 2024 and 2034, the fastest-growing mathematical science occupation and fourth-fastest overall. Lean your title toward the most contested label and you are bidding against every AI team in your city. Title it precisely for the work — “Delta Lake platform engineer, streaming ingestion” rather than “Senior Data Scientist / Engineer” — and you compete with far fewer employers for a candidate who actually wants that job.
A pre-approval checklist that takes an hour:
- Write the first 90 days as five deliverables. If they split cleanly into two columns of the table above, you have two reqs.
- Name the one platform where depth is non-negotiable. Everything else goes in “nice to have” and stays there.
- Price to the scope you kept, not the scope you wrote first.
- Check whether the keyword you are requiring reflects production reality on your stack or someone’s roadmap slide.
Screening that separates the three in twenty minutes
Resumés list all three vocabularies because candidates know you are searching for all three. Questions sort them faster:
| Ask | Warehouse engineer answers with | Lake engineer answers with | Lakehouse specialist answers with |
|---|---|---|---|
| “Last time a model got slow, what did you change?” | Grain, clustering keys, incremental strategy | Partition layout, file sizes, shuffle | Compaction policy, Z-order or sort order, statistics |
| “How do you handle a late-arriving fact?” | SCD design, restatement window | Backfill job and cost | MERGE semantics, time travel, idempotency |
| “Who owns the table after you ship it?” | Semantic layer and tests | Pipeline SLAs | Catalog permissions and maintenance schedule |
| “Describe a migration you ran” | Report parity and sign-off | Source onboarding | Dual-write, reconciliation, cutover sequencing |
Vague answers to the second row are the tell. Anyone who has genuinely operated Delta or Iceberg in production will go straight to upsert semantics and the maintenance jobs that keep them fast, because that is what pages them.
And on sourcing: the people with three to five years of production lakehouse work are currently employed, mostly at the small set of companies that finished a migration early. They are not browsing boards. Reaching them means going through a specialist data engineering network or a referral chain, with a scope description specific enough that they can tell in one read whether the job is worth a conversation.