Articles · Microsoft
Microsoft Fabric Data Engineer Interview Questions: Lakehouse Choices, Pipelines, and Capacity
Practice Microsoft Fabric interview questions with an orders case covering lakehouse choices, incremental pipelines, safe reruns, and capacity troubleshooting.
Strong Microsoft Fabric data engineer interview answers connect three decisions: where the data belongs, how changes become trustworthy outputs, and what evidence explains a slow or failed workload. Naming Lakehouse, pipelines, and capacity units is only the start. You need to explain why a choice fits the current constraints and what would make you change it.
This is a cross-employer technical preparation guide, not a description of Microsoft’s hiring process. Start by practicing how to choose components for a data warehouse, then apply the Fabric-specific boundaries below. Official documentation supports platform facts; candidate experience is labeled separately; the orders and capacity exercises are original simulations, not tenant measurements.
Start with an Orders Case, Not a Product List
Imagine a retailer delivering order analytics to finance and operations. Order changes arrive hourly. Some events are repeated, some arrive late, and product attributes change independently. Analysts want daily revenue by region. Engineers also need access to raw event payloads when a reconciliation fails.
Before choosing a Fabric item, ask four questions. Who writes transformations, and in which language? Which records must become visible together? How fresh must reports be? What is the authoritative version of an order? Those answers constrain the architecture more usefully than saying that a lakehouse is modern or a warehouse is familiar.
For this original practice case, assume engineers already use Spark for raw event cleanup, finance primarily uses SQL, and corrected orders must replace earlier versions without adding revenue twice. There is no requirement to run checkout transactions in the analytical platform. That last boundary matters: an analytics serving layer and an operational order-processing database solve different problems.
Candidate report: One Reddit author discussing a Fabric developer interview mentioned questions about smoothing, throttling, capacity, and upsert terminology. This is an anonymous account of one interview, not a universal syllabus or evidence about Microsoft’s own interview loop. The useful preparation signal is to connect terms with behavior you can explain. Candidate discussion
How Would You Choose Between Lakehouse and Warehouse?
Official facts: Microsoft’s decision guide associates Lakehouse with Spark and mixed structured/unstructured data, and Warehouse with T-SQL and multi-table transactional requirements. Both use open Delta storage. Its recommendation is a starting point for evaluating a workload, not a claim that structured data can only live in a warehouse. Microsoft’s decision guide
For the retailer, an initial answer could place retained source payloads and Spark transformations in a Lakehouse. If a SQL-focused serving team needs coordinated changes across several analytical tables, evaluate Warehouse for that responsibility. Using both creates an additional contract: define which layer owns each transformation and how downstream consumers learn that a new version is ready.
The following choices are editorial reasoning for the hypothetical case, not performance results or Microsoft’s prescribed reference architecture.
| Changed requirement | Defensible choice and condition |
|---|---|
| Engineers need Spark cleanup and retained raw payloads. | Start with Lakehouse; define how curated tables are produced. |
| Finance owns SQL transformations across several related tables. | Evaluate Warehouse; verify the required transaction and SQL behavior. |
| Analysts only need to query existing curated lake tables. | Evaluate the Lakehouse SQL endpoint before adding another serving copy. |
| One team wants SQL serving and another needs raw-event exploration. | Consider both, with explicit ownership and freshness boundaries. |
| Reporting must reflect a coordinated release of several outputs. | Define the publication contract first; a successful individual write is insufficient. |
A weak answer selects every Fabric feature and leaves synchronization unexplained. A stronger answer identifies one initial design, its extra moving parts, and a reason to simplify. For example, if the SQL consumers only read one curated table, a second serving layer may add operational work without satisfying a new requirement.
Can the Lakehouse SQL Endpoint Perform Your Upsert?
Official boundary: The Lakehouse SQL analytics endpoint offers a read-only T-SQL surface over lakehouse Delta tables. It supports SQL objects such as views, but is not a general DML write path into those tables. Do not propose an UPDATE or MERGE there simply because the endpoint accepts SQL queries. SQL analytics endpoint documentation
In an interview, identify the executing engine before naming syntax. “Use a merge” is incomplete until you say whether a supported Spark/Delta operation, Warehouse statement, or another supported write mechanism performs it. Then identify the match key, how source duplicates are resolved, and what prevents an older update from overwriting a newer value.
Also distinguish the storage format from the access surface. Two items using Delta does not make their write permissions, SQL support, or operational responsibilities interchangeable. If a follow-up changes the interface, revisit the proposal instead of assuming the same code will work everywhere.
For the retailer, keep the cleanup operation close to the layer that owns source interpretation. Do not implement two slightly different definitions of a valid order merely because both teams have a convenient place to write transformations. The interview answer should make the business rule discoverable and assign responsibility for changing it.
Design Incremental Loads That Survive a Rerun
Here is an original locally checked state example. The current destination contains order 101 at version 1 for 100 units of revenue, and order 102 at version 1 for 40. A new batch contains order 101 version 2 for 120, new order 103 version 1 for 30, a duplicate of order 101 version 2, and a late copy of order 101 version 1.
After applying a strictly newer-version rule, the destination should contain three orders totaling 190, not the sum of every incoming event. Applying the same batch again should leave that state unchanged. Our small Python model produced those results; it does not validate Fabric SQL syntax, concurrent execution, or transaction durability.
The design needs more than this happy-path result. If two records have the same order ID and version but different amounts, input order must not decide the winner silently. Reject or quarantine the conflict according to an explicit source contract. If the source cannot provide a reliable version, explain the alternative ordering rule and its limitations.
Track the ingestion boundary separately from the business result. A watermark or source cursor records how far extraction has progressed; it does not prove that every downstream output is complete. Advance it only after the required writes and validation have succeeded, or design a reconciliation path for a failed state transition.
Suppose extraction succeeds, the destination write commits, and the pipeline fails before recording completion. On retry, the same batch may arrive again. The destination’s deduplication and version policy should tolerate that replay. Conversely, advancing the cursor before the write can create a gap that an ordinary retry never revisits.
Deletes need their own rule. A missing order in an incremental batch does not necessarily mean it was deleted. Ask whether the source supplies tombstones, cancellation events, or periodic reconciliation snapshots. For financial reporting, deleting a record and preserving an auditable cancellation can have very different meanings.
When Should a Pipeline Retry, and When Should It Stop?
Official capability: Fabric Data Factory supports configurable retries for most activities, including per-activity counts and intervals. Current documentation describes fixed and increasing-delay intervals, with conditional retries marked preview. Do not assume a preview option is enabled or supported for every activity in an interviewer’s environment. Activity retry documentation
For the orders chain, classify the failure before choosing recovery. A transient upstream failure can justify a bounded retry. A malformed schema, invalid business key, or conflicting source version usually needs diagnosis. Repeating an unchanged invalid input faster will not improve correctness.
Prepare a concise failure narrative: the copy completed, validation detected two conflicting versions, the curated publication did not occur, and the old reporting version remains available. That is a more useful status update than “the pipeline is red.” It tells the operator which work is reusable and which downstream data should remain unchanged.
If only a late aggregation failed, ask whether rerunning that step can safely consume the already validated batch. Persist a batch identifier and validation outcome so recovery does not depend on someone remembering which notebook ran. Any reuse decision should be grounded in persisted evidence, not the color of a single activity tile.
Explain Smoothing Without Confusing It with Execution Time
Official facts: Fabric distinguishes bursting, which permits temporary compute use beyond the provisioned level, from smoothing, which spreads usage accounting across time. The general policy smooths interactive work over at least five minutes and background work over 24 hours. Workload exceptions exist, and Spark Autoscale Billing changes the applicability of these concepts. Fabric throttling policy
Smoothing does not mean the engine intentionally stretches your query across the accounting window. Microsoft’s Warehouse documentation also warns that most Warehouse operations are classified as background; a query manually submitted by a person is not automatically an interactive-classified operation. Check the actual workload and operation classification. Warehouse smoothing and throttling
Use units carefully. In a simplified arithmetic exercise, a notional capacity providing 32 CUs has 115,200 CU-seconds across one hour: 32 multiplied by 3,600. This calculation was checked locally. It is not a forecast of query latency, an actual consumption measurement, or a reconstruction of Fabric’s throttling decision.
A good interview explanation connects the concepts without claiming certainty from the wrong chart. A utilization spike can motivate investigation; it does not, by itself, identify which requests were delayed or rejected. Separate resource accounting from the elapsed time a particular user experienced.
Diagnose This Simulated Capacity Incident
The following is invented practice telemetry. No Fabric tenant was used to produce these observations. Treat each timestamp as a new piece of evidence rather than a complete causal story.
| Observation in the exercise | Next check before a conclusion |
|---|---|
| 09:00: one query slows; no throttle event is recorded. | Compare its plan, input size, and competing work with a normal run. |
| 09:10: an interactive-delay event appears. | Correlate operation classification, time, and capacity usage. |
| 09:20: new interactive requests are rejected. | Check affected requests and pause optional retry traffic. |
| A background operation remains in progress. | Distinguish already-running work from new submissions. |
Official diagnostic guidance: Microsoft says utilization above 100% does not automatically mean throttling. Use the Capacity Metrics app’s throttling charts and system events to confirm it; slow performance can also come from item design. Capacity monitoring guidance
At 09:00, calling the incident “capacity exhaustion” would outrun the evidence. Perhaps the query scans more data after a missing filter, or an upstream change produces many more rows. Investigate that item first while preserving the possibility of a shared resource issue.
At 09:10 and 09:20, the exercise supplies explicit throttling events. Now connect them to the affected operation IDs and windows. Do not assume that every slow job shares the same cause merely because it belongs to the same workspace. Establish which capacity serves the workload and whether the observed request is a new submission.
For recovery, prioritize actions that match the confirmed cause. Reduce optional repeat submissions, investigate the largest changed workloads, and involve the capacity owner when a sizing or isolation decision is needed. Simply rerunning everything may create more work while preserving the original defect.
After recovery, verify both service and data: requests can start again, order totals reconcile, and no partial batch was published during retries. A green capacity chart cannot establish that financial outputs are correct. Conversely, correct totals do not prove that report latency has returned to its target.
Practice Answers That Survive Follow-Up Questions
| Practice question | What to explain using the orders case |
|---|---|
| Choose Components for a Data Warehouse | Select one initial design and name a requirement that changes it. |
| Design an Incremental Rolling-Metrics Data Pipeline | Separate source progress, late updates, and publication. |
| Diagnose data quality and pipeline performance issues | Distinguish incorrect totals from slow execution. |
| Explain ETL schema changes and ensure integrity | Decide when a change should stop the pipeline. |
| Design an e-commerce analytics warehouse | Define order grain and auditable revenue semantics. |
Use the data-quality and performance question to rehearse a short incident explanation. State the observation, give your leading hypothesis, and name the next check that could disprove it. That structure keeps an answer useful even when the interviewer changes the workload or withholds a metric.