14.11.26

How to Assess Real-World Medallion Architecture Experience During Technical Screening

Every hiring manager running a Databricks or Microsoft Fabric rebuild has interviewed the candidate who says "yes, I've done medallion architecture" and means "I once worked on a project where someone else had already built it." The term has become table stakes on a CV. The challenge for Heads of Data and Engineering Managers is that the phrase itself tells you nothing — what separates a genuine architect of bronze/silver/gold layers from someone who touched the gold layer in a reporting tool is entirely in how they answer the follow-up questions.

This guide sets out the screening sequence we use to find that line, and the specific answer patterns — both strong and weak — that reveal where a candidate actually sat in the build.

Prerequisites

Before you run this screening sequence, have ready:

• A clear picture of which platform the role centers on (Databricks, Fabric, or both), since the terminology and tooling differ even though the architecture pattern is the same

• Enough context on the candidate's CV to know whether they're coming in as a contractor who owned delivery end-to-end or as part of a larger team

• An understanding that "medallion architecture" is now a popular keyword — treat its mere appearance on a CV as a prompt for deeper questioning, not as evidence in itself

Step 1: Ask for the layer-by-layer walkthrough before anything else

Start by asking the candidate to describe bronze, silver, and gold in their own words, tied to a real project. This sounds basic, but it's the fastest filter available, because the quality of the explanation — not just its presence — tells you how deep the understanding goes.

A candidate with genuine ownership will describe the bronze layer as raw, untransformed data pulled from source systems, the silver layer as cleaned and conformed data with nulls handled and formats standardized, and the gold layer as curated, aggregated, business-ready data used for reporting. One candidate described it precisely this way: silver layer work means recognizing that "a user came 100 times and clicked 200 times" rather than tracking identifiable individuals, while gold layer work means producing aggregated metrics like "500 users clicked on this page" in a specific hour window.

Watch for candidates who can only describe the gold layer, or who describe the three layers in generic terms without reference to a specific data type or business problem they solved. Genuine builders tend to volunteer a worked example unprompted — raw clickstream data, HR records, banking transaction data — because they're describing something they actually touched.

Step 2: Probe for resilience and failure-handling design

Once you've confirmed they understand the three-layer concept, move past definitions and ask how they handled failure scenarios in the pipeline — this is where adjacent experience usually runs out of road.

A candidate with real design ownership will talk unprompted about what happens when a data source doesn't deliver on schedule, and how the architecture should degrade gracefully. One strong answer described exactly this: asking "if a file doesn't turn up today, what do I do? Do I just copy the previous day's from bronze and move it across?" as part of making the medallion approach robust and easy to troubleshoot.

This is a useful litmus test because it's not a question most training courses or tutorials cover — it only comes up when someone has actually run a pipeline in production and had to answer for a gap in the data. If a candidate can only describe the happy path, that's a signal they've worked with the pattern conceptually or in a controlled training environment, not against live, messy source systems.

Step 3: Separate platform fluency from architectural ownership

Next, test whether the candidate understands medallion architecture as a design pattern independent of any single platform, since the terminology shifts between Databricks and Fabric but the underlying logic doesn't.

In Fabric, this pattern lives inside lakehouses, and candidates should be able to speak to how Fabric's end-to-end ETL capability — connecting directly to source databases, mirroring them into the platform, and layering semantic models and reporting on top — changes how the bronze-to-gold flow gets implemented compared with a traditional ETL stack. In Databricks, candidates should be comfortable describing how they used PySpark to build and transform data moving through these layers, and should be able to speak to Unity Catalog as part of how governance and access control get layered onto that structure.

One candidate with genuine platform depth pointed out something useful for your own calibration: the underlying practice behind medallion architecture isn't new — "it's been like a good practice which we are using from long back itself" — but the formal bronze/silver/gold naming convention has only recently become widely recognized. A candidate who can make this distinction — separating the pattern from the branding — is usually speaking from genuine multi-year experience rather than repeating a training deck. One candidate described having used the pattern for four years prior to the naming convention becoming standard vocabulary.

Step 4: Ask who the end users were at each layer

This step moves the conversation from architecture to ownership, and it's one of the sharpest ways to separate design authority from implementation labor.

A candidate who owned the architecture decision will describe access control by layer without being prompted: raw bronze data is for developers only, used to preserve the untransformed source; silver is an intermediate transformation stage; and only gold-layer data is exposed to end users and business stakeholders. This detail matters because it reflects a deliberate design choice about governance and blast radius, not just a technical implementation detail. If a candidate can't tell you who was allowed to see which layer and why, they likely inherited an architecture someone else designed rather than making those calls themselves.

Compare this against a candidate who deployed Databricks "through the pipeline," handling configuration and troubleshooting and pipeline security end-to-end, but who explicitly says they don't "fully administer" the platform. That's not a disqualifying answer — pipeline deployment and security work is valuable — but it's a different role than the person who decided how the three layers should be structured and governed in the first place. Your screening should surface which one you're actually hiring for.

Step 5: Dig into the "who else was in the room" question

Having established the candidate's technical grasp of the architecture, the next step is understanding the scale and shape of the team that built it, because sole ownership and shared delivery require very different follow-up questions.

Ask directly how many people worked on the build and what the candidate's specific portion was. One candidate was transparent that a six-month Fabric data warehouse project was delivered by himself "along with three other data engineers," and that the team collectively handed the finished solution back to the business once delivery was complete. This kind of specificity — a named team size, a defined scope, a clear handover point — is a strong signal of genuine involvement, because candidates who were peripheral to the build tend to answer this question vaguely or inflate their role once pressed.

Similarly, ask what proportion of the work was genuinely hands-on architecture versus supporting tasks like pipeline deployment or reporting. A candidate who volunteers a breakdown — for example, estimating that a migration project was "75% on Azure and 25% SQL Server" — is demonstrating the kind of granular self-awareness about their own contribution that's hard to fake.

Step 6: Test their comfort explaining trade-offs to non-technical stakeholders

Architectural ownership isn't only about the build — it includes being able to justify design choices to the people funding or depending on the project, so this is where you test whether the candidate operated at a design level or an execution level.

Ask the candidate to describe a moment where they had to explain a medallion architecture decision — why data needed to pass through three stages rather than being reported on directly from source — to a stakeholder, analyst, or data scientist who wasn't a data engineer. Strong candidates describe this as a routine part of the job: sitting with stakeholders and analysts to gather requirements before constructing the pipelines, and translating those requirements into a layered pipeline design. A candidate at the architecture level should also be comfortable describing how they led the end-to-end creation of a pipeline, not just contributed to pieces of one.

Tips & Best Practices

A few principles make this screening sequence more effective across different candidates and seniority levels:

• Always ask for a named project, client, or sector — vague references to "a previous role" rather than a specific migration, platform, or data domain are a signal to dig further

• Treat platform-name-dropping (Databricks, Fabric, Snowflake) as a starting point, not a conclusion — candidates with genuine breadth will often note that these tools solve the same underlying problem in different ways

• Ask about certification where relevant, but don't let it substitute for the walkthrough — a Power BI or Databricks certification tells you about tooling knowledge, not architectural judgment

• Listen for whether the candidate differentiates between ETL and ELT approaches to the bronze-to-gold flow, since this distinction tends to surface naturally from people who've made the design choice themselves

Troubleshooting Common Screening Pitfalls

If a candidate's answers sound rehearsed or generic, it's usually because the question was too open-ended — tighten it by asking for the specific data type, the specific failure mode, or the specific stakeholder conversation rather than a general description of the pattern.

If you can't tell whether a candidate owned the design or inherited it, ask directly who made the decision to use three layers rather than two, or why the silver layer existed at all for that specific dataset — architects can answer this with a reason tied to the business problem, while peripheral team members tend to describe it as "how the project was already set up."

If a candidate pivots every answer back to the reporting or visualization layer, that's a sign their medallion architecture exposure came from the consumption side of the lakehouse, not the pipeline design side — useful to know, but a different hire than a data engineer or architect role requires.

Summary

Genuine medallion architecture experience shows up in specificity, not vocabulary: a candidate who can walk through failure handling, explain layer-based access control, name their exact role on a multi-person build, and describe translating the architecture to stakeholders has clearly designed and owned the pattern, not just worked near it. Build your screening around these follow-up layers rather than the initial definition question, and you'll separate candidates who've genuinely built bronze/silver/gold pipelines from those who've only reported on top of someone else's. At Dcoded, this kind of layered, pattern-specific questioning is how we vet every Databricks and Fabric candidate before they reach your shortlist.