De 25 belangrijkste Data Engineering sollicitatievragen in 2026

Sollicitatievragen over data engineering in 2026 gaan veel verder dan SQL-basiskennis. Wervingsteams toetsen tegenwoordig system design, realtime architecturen, kostenoptimalisatie en AI-gereedheid. Deze gids behandelt de 25 vragen die het vaakst voorkomen in data engineering sollicitatiegesprekken bij bedrijven van startups tot FAANG, met antwoorden geschreven voor professionals uit de praktijk.

SQL en query-optimalisatie

SQL blijft het fundament van elk data engineering sollicitatiegesprek. Zelfs senior kandidaten krijgen SQL-vragen, doorgaans gericht op prestaties in plaats van syntaxis.

1. Wat is het verschil tussen een window function en GROUP BY?

GROUP BY vouwt rijen samen tot geaggregeerde resultaten, waardoor het aantal rijen afneemt. Window functions berekenen waarden over een set rijen die gerelateerd zijn aan de huidige rij zonder ze samen te vouwen. De output behoudt elke originele rij.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

De window function-versie is essentieel wanneer de query zowel rijdetails als aggregatiecontext tegelijkertijd nodig heeft, een veelvoorkomende vereiste bij datakwaliteitscontroles en rapportagepipelines.

2. Hoe zou je een trage query op een feitentabel met 500 miljoen rijen optimaliseren?

Een gestructureerde aanpak werkt het best:

1. Controleer het execution plan (EXPLAIN ANALYZE) om volledige tabelscans, hash joins op niet-geindexeerde kolommen of overloop naar schijf te identificeren.
2. Partitioneer de tabel op datum of een andere kolom met hoge cardinaliteit die aansluit bij queryfilters.
3. Voeg gerichte indexen toe op vaak gefilterde kolommen, maar vermijd overmatig indexeren (elke index voegt schrijfoverhead toe).
4. Materialiseer tussenresultaten als dezelfde subquery herhaaldelijk wordt uitgevoerd voor meerdere dashboards.
5. Duw predicaten naar beneden om vroeg te filteren, waardoor de hoeveelheid verplaatste data tussen stappen afneemt.

Het belangrijkste signaal voor interviewers: het begrip dat optimalisatie iteratief en contextafhankelijk is, geen afvinklijst.

3. Leg CTEs, subqueries en tijdelijke tabellen uit. Wanneer gebruik je welke?

CTEs (Common Table Expressions) verbeteren de leesbaarheid en maken recursieve queries mogelijk. De meeste query-engines nemen ze inline op, waardoor de prestaties overeenkomen met subqueries. Tijdelijke tabellen materialiseren data fysiek, wat helpt wanneer hetzelfde tussenresultaat meerdere downstream queries in een sessie voedt. Subqueries werken goed voor eenvoudige, eenmalige transformaties.

Vuistregel: CTE voor duidelijkheid, tijdelijke tabel voor hergebruik, subquery voor triviale inline filters.

Zie voor een diepgaande uitleg van geavanceerde SQL-patronen SQL voor Data Analysts: Window Functions, CTEs en geavanceerde queries.

ETL vs ELT en data pipeline-architectuur

Vragen over pipeline-ontwerp toetsen architecturaal denkvermogen. Interviewers willen een afwegingsanalyse zien, geen pleidooi voor een specifiek tool.

4. ETL vs ELT: wanneer kies je voor welke aanpak?

| Criterium | ETL | ELT | |-----------|-----|-----| | Transformatielocatie | Voor het laden (externe compute) | Na het laden (warehouse compute) | | Geschikt voor | Legacysystemen, strikte schema's | Cloudwarehouses (BigQuery, Snowflake) | | Schemaflexibiliteit | Laag (transformatie legt schema vroeg vast) | Hoog (ruwe data beschikbaar voor hertransformatie) | | Kostenmodel | Compute buiten het warehouse | Warehouse compute-kosten schalen mee met transformaties | | Dataversheid | Hogere latentie (transformatiestap) | Lagere latentie (eerst laden, transformeren op aanvraag) |

ELT domineert in moderne cloud-native stacks omdat opslag goedkoop is, compute elastisch schaalt en het bewaren van ruwe data schema-evolutie mogelijk maakt. ETL blijft relevant wanneer regelgeving vereist dat data wordt getransformeerd voordat het het warehouse binnenkomt (bijvoorbeeld het verwijderen van PII).

5. Ontwerp een idempotente datapipeline. Waarom is idempotentie belangrijk?

Idempotentie garandeert dat het meerdere keren uitvoeren van een pipeline met dezelfde input hetzelfde resultaat oplevert zonder data te dupliceren. Dit is belangrijk omdat pipelines falen en opnieuw worden uitgevoerd.

Implementatiestrategieen:

• Upsert-patronen (MERGE of INSERT ... ON CONFLICT) op basis van natuurlijke of samengestelde sleutels
• Partitie-overschrijving: vervang volledige datumspartities in plaats van toe te voegen
• Deduplicatie bij schrijven: wijs deterministische ID's toe (hash van bedrijfssleutel + event-tijdstempel)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Deze aanpak zorgt ervoor dat een heruitvoering van de run van 11 april de partitie van 11 april vervangt in plaats van dubbele rijen toe te voegen.

6. Wat is data lineage en waarom is het cruciaal in productiepipelines?

Data lineage volgt de herkomst, verplaatsing en transformatie van data door de gehele pipeline. Het beantwoordt: waar komt dit getal vandaan, welke transformaties zijn toegepast, en welke downstream systemen zijn ervan afhankelijk.

Praktische waarde: wanneer een dashboard onverwachte waarden toont, maakt lineage root-cause analyse in minuten mogelijk in plaats van uren. Tools zoals OpenLineage, dbt docs en cloud-native lineage (BigQuery kolom-level lineage) automatiseren dit.

Streaming en realtime dataverwerking

Streamingvragen zijn verschoven van "wat is Kafka" naar architecturale beslissingen over wanneer en hoe streaming ingezet wordt.

7. Batch vs streaming: hoe beslis je welke aanpak je gebruikt?

De beslissing hangt af van latentievereisten, niet van technologievoorkeur:

• Batch: acceptabel wanneer dataconsumenten een vertraging van minuten tot uren tolereren. Eenvoudiger om te bouwen, testen en debuggen. Lagere operationele kosten voor de meeste workloads.
• Streaming: vereist wanneer bedrijfslogica afhankelijk is van sub-minuut versheid: fraudedetectie, realtime pricing, live dashboards.
• Micro-batch: een pragmatisch compromis (bijvoorbeeld Spark Structured Streaming) dat near-realtime biedt met batch-achtige eenvoud.

Het sterkste antwoord erkent dat de meeste pipelines als batch moeten starten en alleen naar streaming verhuizen wanneer een concrete latentie-SLA dit vereist.

8. Leg de architectuur van Kafka uit: topics, partitions, consumer groups

Kafka organiseert data in topics (logische kanalen). Elk topic wordt opgesplitst in partitions (geordende, onveranderlijke logs) verdeeld over brokers. Producers schrijven records naar partitions (round-robin of op basis van sleutel). Consumer groups paralleliseren het lezen: elke partitie wordt toegewezen aan precies een consumer binnen een groep, wat horizontale schaling mogelijk maakt.

Belangrijke afweging: meer partities verhogen de parallelliteit maar voegen overhead toe aan de broker (file handles, replicatie). Een typisch startpunt is 6-12 partities per topic, opgeschaald op basis van doorvoervereisten.

9. Hoe ga je om met laat binnenkomende data in een streamingpipeline?

Laat binnenkomende data is onvermijdelijk in gedistribueerde systemen. Drie benaderingen:

1. Watermarks: definieer een drempelwaarde (bijv. 10 minuten) waarna late data wordt verworpen. Apache Flink en Spark Structured Streaming ondersteunen dit native.
2. Herverwerkingsvensters: voer periodiek aggregaties opnieuw uit voor recente tijdvensters om achterblijvers op te vangen.
3. Delta/upsert sinks: schrijf naar een muterbare opslag (Delta Lake, Apache Iceberg) die updates ondersteunt, waardoor late records eerdere resultaten kunnen corrigeren.

De juiste aanpak hangt af van of downstream consumenten exactly-once semantiek nodig hebben of eventuele consistentie kunnen tolereren.

Datamodellering en schema-ontwerp

Vragen over datamodellering onthullen of een kandidaat nadenkt over hoe data wordt geconsumeerd, niet alleen hoe het wordt opgeslagen.

10. Star schema vs snowflake schema: wat zijn de afwegingen?

Star schema denormaliseert dimensietabellen tot platte, brede tabellen die worden gekoppeld aan een centrale feitentabel. Snowflake schema normaliseert dimensies in subdimensies.

| Aspect | Star | Snowflake | |--------|------|-----------| | Queryprestaties | Sneller (minder joins) | Trager (meer joins) | | Opslag | Hoger (redundante data) | Lager (genormaliseerd) | | Complexiteit | Eenvoudig te begrijpen | Complexere relaties | | Onderhoud | Moeilijker om dimensies bij te werken | Eenvoudiger om subdimensies bij te werken | | Geschikt voor | BI/rapportage (lees-intensief) | Situaties die strikte normalisatie vereisen |

In de praktijk domineren star schema's in analytics warehouses (BigQuery, Snowflake, Redshift) omdat queryprestaties en eenvoud zwaarder wegen dan opslagbesparingen. Verdiep je verder via de data modeling interview-module.

11. Wat is een slowly changing dimension (SCD)? Leg Type 1, 2 en 3 uit.

SCD's houden bij hoe dimensie-attributen in de loop van de tijd veranderen:

• Type 1: Overschrijf de oude waarde. Geen historie. Eenvoudig maar verliesgevend.
• Type 2: Voeg een nieuwe rij toe met versiebeheer (valid_from, valid_to, is_current). Volledige historie bewaard. Meest gebruikelijk in productiewarehouses.
• Type 3: Voeg een kolom toe voor de vorige waarde (current_city, previous_city). Beperkte historie (slechts een wijziging bijgehouden).

Type 2 is de standaardkeuze voor de meeste bedrijfsdimensies (klantadres, productcategorie, afdeling medewerker) omdat audittrails en historische rapportages dit vereisen.

12. Hoe zou je eventdata modelleren voor zowel realtime analytics als langetermijnopslag?

Een tweelaagse aanpak:

1. Hot layer: stream events naar een realtime opslag (Apache Druid, ClickHouse of Materialized Views in een warehouse) geoptimaliseerd voor lage-latentie aggregaties op recente data.
2. Cold layer: land ruwe events in een lakehouse (Delta Lake, Iceberg) gepartitioneerd op datum, onbeperkt bewaard voor ad-hoc analyse en ML feature engineering.

De hot layer gebruikt voorgeaggregeerde of gedenormaliseerde schema's voor snelheid. De cold layer behoudt volledige granulariteit. Een reconciliatie-job valideert periodiek dat beide lagen overeenstemmen.

Apache Spark en gedistribueerde verwerking

Spark-vragen richten zich op het begrijpen van parallellisme en prestaties, niet alleen API-aanroepen.

13. Wat veroorzaakt data skew in Spark en hoe los je het op?

Data skew treedt op wanneer een partitie onevenredig meer data bevat dan andere, waardoor een enkele taak een bottleneck vormt voor de gehele stage.

Veelvoorkomende oorzaken: joinen op een sleutel met een paar dominante waarden (null-sleutels, een enkel populair product-ID), of partitioneren op een kolom met lage cardinaliteit.

Oplossingen:

• Salting: voeg een willekeurig achtervoegsel toe aan de scheefgetrokken sleutel, join op de gesalte sleutel en aggregeer vervolgens om het salt te verwijderen.
• Broadcast join: als een kant klein genoeg is (<200MB doorgaans), broadcast deze om shuffle volledig te vermijden.
• AQE (Adaptive Query Execution): Spark 3.x+ kan scheefgetrokken partities automatisch detecteren en splitsen tijdens runtime.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Dit verdeelt de werklast gelijkmatig over executors en elimineert de bottleneck.

14. Leg het verschil uit tussen transformations en actions in Spark.

Transformations (map, filter, select, join) zijn lazy: ze bouwen een logisch plan op maar voeren niets uit. Actions (count, collect, write) triggeren de daadwerkelijke berekening door het plan naar het cluster te sturen.

Deze lazy evaluation stelt de Catalyst optimizer van Spark in staat om bewerkingen te herordenen, predicaten naar beneden te duwen en onnodige shuffles te elimineren voordat er data wordt verplaatst. Het begrijpen van dit onderscheid is essentieel voor debugging: een transformatie die traag lijkt, is eigenlijk prima; de bottleneck zit in de action die deze triggert.

15. Wat is het verschil tussen repartition() en coalesce()?

repartition(n) voert een volledige shuffle uit om precies n partities te creeren, waarbij data gelijkmatig wordt verdeeld. Gebruik het om parallellisme te verhogen of scheefgetrokken partities te herbalanceren.

coalesce(n) vermindert partities zonder shuffle door aangrenzende partities samen te voegen. Gebruik het om het aantal partities te verminderen voor het schrijven (ter voorkoming van veel kleine bestanden).

Vuistregel: coalesce voor verminderen, repartition voor verhogen of herbalanceren.

Orchestratie en pipelinebeheer

Orchestratievragen toetsen operationele volwassenheid: hoe pipelines draaien, falen en herstellen in productie.

16. Vergelijk Airflow, Dagster en Prefect. Wanneer kies je voor welke?

| Kenmerk | Airflow | Dagster | Prefect | |---------|---------|---------|---------| | Volwassenheid | Meest volwassen, grootste community | Groeiend, sterk in ML/data-teams | Cloud-first, sterke DX | | Kernabstractie | DAGs van taken | Assets (datacentrisch) | Flows en taken | | Testen | Moeilijker (DAG-niveau) | Ingebouwde asset-testing | Goede testing op taakniveau | | Lokale ontwikkeling | Vereist Docker/containers | Native lokale uitvoering | Native lokale uitvoering | | Geschikt voor | Complexe, langlopende ETL | Data mesh / asset-georienteerde teams | Teams die minimale infrastructuur willen |

Airflow blijft de industriestandaard voor volwassen dataplatforms. Dagster past bij teams die denken in termen van data-assets in plaats van taaksequenties. Prefect spreekt teams aan die Airflow-achtige orchestratie willen met minder operationele overhead. Zie voor Airflow-specifieke interviewvoorbereiding de Airflow-basismodule.

17. Hoe ga je om met pipelinefouten en alerting in productie?

Een productieklare foutafhandelingsstrategie omvat:

1. Retry met backoff: tijdelijke fouten (netwerk-timeouts, API rate limits) lossen op met exponentieel toenemende wachttijden.
2. Dead-letter queues: foutieve berichten worden naar een aparte wachtrij gerouteerd voor handmatige inspectie, zonder de pipeline te blokkeren.
3. Circuit breakers: na N opeenvolgende fouten wordt de pipeline gepauzeerd en een alert verzonden, in plaats van downstream systemen te overspoelen met slechte data.
4. Observability: gestructureerde logs, metrics (taakduur, rijaantallen, foutenpercentages) en datakwaliteitscontroles (Great Expectations, dbt tests) bij elke pipelinefase.
5. Alertniveaus: P1 (pipeline down, ontbrekende data) belt de dienstdoende engineer. P2 (datakwaliteitsdrift) stuurt een Slack-notificatie voor de volgende werkdag.

18. Wat maakt een pipeline "productierijp" versus een prototype?

Productierijpheid betekent: idempotente runs, geautomatiseerde retries, monitoring en alerting, datavalidatie bij inname- en transformatiefasen, documentatie van datacontracten, versiebeheerde pipelinedefinities en een getest terugdraaipad. Een prototype heeft niets van dit alles. De kloof tussen beide is waar de meeste technische schuld in pipelines zich ophoopt.

Cloud-dataplatforms en lakehouse-architectuur

Vragen over cloudplatforms beoordelen of kandidaten kosten, schaalbaarheid en architectuurafwegingen begrijpen, los van leverancierspecifieke syntaxis.

19. Wat is een lakehouse en waarom is het de dominante architectuur geworden?

Een lakehouse combineert de flexibiliteit van een data lake (schema-on-read, opslag van ruwe data, meerdere bestandsformaten) met de betrouwbaarheid van een datawarehouse (ACID-transacties, schema-afdwinging, queryoptimalisatie). Technologieen zoals Delta Lake, Apache Iceberg en Apache Hudi maken dit mogelijk door een metadata-/transactielaag toe te voegen bovenop objectopslag (S3, GCS, ADLS).

Het lakehouse wint omdat het de kostbare ETL-laag tussen lake en warehouse elimineert, zowel BI-queries als ML-workloads op dezelfde data ondersteunt en goedkope objectopslag benut.

20. Hoe optimaliseer je de kosten van een cloudwarehouse (BigQuery, Snowflake, Redshift)?

Strategieen voor kostenoptimalisatie:

• Partitioneer en cluster tabellen om het aantal gescande bytes per query te verminderen
• Stel passende warehouse-groottes in (Snowflake) of slotreserveringen (BigQuery) op basis van workloadpatronen
• Automatisch opschorten van inactieve resources: Snowflake warehouses moeten automatisch opschorten na 1-5 minuten inactiviteit
• Monitor kosten per query: de INFORMATION_SCHEMA.JOBS-view van BigQuery onthult dure queries
• Gebruik materialized views voor herhaaldelijk berekende aggregaties
• Archiveer koude data naar goedkopere opslagtiers met lifecycle policies

Het interviewsignaal: kandidaten die kosten beschouwen als een eersteklas engineeringbeperking, niet als een bijzaak.

Datakwaliteit en governance

Datakwaliteitsvragen onderscheiden engineers die pipelines opleveren van degenen die betrouwbare dataplatforms onderhouden.

21. Hoe implementeer je datakwaliteitscontroles in een pipeline?

Datakwaliteitscontroles horen in drie fasen:

1. Inname: valideer schema-conformiteit, controleer op null-waarden in primaire sleutels, verifieer rijaantallen ten opzichte van drempelwaarden uit de bron.
2. Transformatie: bevestig bedrijfsregels (bijv. omzet > 0, datums binnen geldig bereik), controleer referentiele integriteit tussen tabellen.
3. Serveren: monitor metricdrift (een plotselinge daling van 50% in dagelijks actieve gebruikers duidt waarschijnlijk op een pipelineprobleem, niet op een bedrijfswijziging).

Tools: dbt tests (schema en custom), Great Expectations, Soda Core, Monte Carlo (data-observability). De beste aanpak integreert controles direct in de pipeline-DAG zodat fouten downstream verwerking blokkeren.

22. Wat is een datacontract en hoe voorkomt het pipelinebreuken?

Een datacontract is een formele overeenkomst tussen een dataproducent en zijn consumenten die het volgende specificeert: schema (kolomnamen, typen, nullability), versheids-SLA (data beschikbaar voor 6:00 UTC), volumeverwachtingen (tussen 1M en 10M rijen dagelijks) en semantische regels (statusveld bevat alleen ACTIVE, INACTIVE, SUSPENDED).

Wanneer producenten hun schema wijzigen zonder het contract bij te werken, detecteert geautomatiseerde validatie de mismatch voordat deze downstream doorsijpelt. Dit verschuift pipelinefouten van stille datacorruptie naar expliciete, actiegerichte fouten.

System design en architectuur

System design-rondes zijn standaard voor mid-tot-senior data engineering functies. Deze toetsen end-to-end denkvermogen.

23. Ontwerp een realtime analytics pipeline voor een e-commerceplatform.

Een solide ontwerp behandelt:

Inname: clickstream-events en transactie-events stromen naar Kafka-topics, gepartitioneerd op user_id voor volgordegaranties binnen een gebruikerssessie.

Verwerking: een Flink- of Spark Structured Streaming-job consumeert van Kafka, verrijkt events met productcatalogusdata (broadcast join vanuit een dimensietabel), berekent sessieniveau- en 5-minuut-aggregaties.

Serveren: geaggregeerde metrics landen in een realtime OLAP-store (ClickHouse of Apache Druid) voor dashboardqueries met sub-seconde latentie. Ruwe events landen in Delta Lake/Iceberg voor historische analyse.

Datakwaliteit: een schema registry (Confluent of AWS Glue) valideert eventschema's bij inname. Streaming datakwaliteitscontroles signaleren anomalieen (plotselinge daling in eventvolume) en routeren naar een dead-letter topic.

Foutafhandeling: Kafka's consumer offsets maken exactly-once verwerking mogelijk met checkpointing. De streaming-job herstart automatisch vanaf het laatste checkpoint bij een fout.

24. Hoe zou je een legacy ETL-pipeline migreren naar een moderne stack?

Migratie volgt het strangler fig-patroon:

1. Audit: catalogiseer alle bestaande pipelines, hun bronnen, transformaties en consumenten. Identificeer afhankelijkheden en SLA's.
2. Parallelle run: bouw de nieuwe pipeline naast de oude. Beide consumeren dezelfde bronnen en schrijven naar aparte doelen.
3. Validatie: vergelijk outputs tussen oude en nieuwe pipelines. Geautomatiseerde reconciliatiequeries signaleren discrepanties.
4. Cutover: zodra outputs overeenkomen binnen de tolerantie gedurende 2+ weken, schakel consumenten over naar het nieuwe doel. Houd de oude pipeline in read-only modus voor rollback.
5. Decommissioning: sluit na een stabiliteitsperiode de legacy pipeline af.

De kerninzicht: voer nooit een big-bang migratie uit. Laat beide systemen parallel draaien totdat vertrouwen is opgebouwd.

25. Een kritiek dashboard toont onjuiste cijfers. Doorloop het debugproces.

Een systematische aanpak:

1. Baken het probleem af: welke metrics zijn onjuist? Sinds wanneer? Alle dimensies of specifieke filters?
2. Controleer de serveerlaag: query het warehouse direct om te bevestigen of het probleem in de dashboardtool zit (caching, filterlogica) of in de data zelf.
3. Volg de lineage upstream: volg de data van de dashboardtabel terug door elke transformatiestap. Controleer rijaantallen en kernmetrics bij elke fase.
4. Identificeer het breekpunt: de fase waar verwachte waarden afwijken van werkelijke waarden is de locatie van de oorzaak.
5. Controleer veelvoorkomende boosdoeners: schemawijzigingen in bronsystemen, mislukte pipelineruns die niet gesignaleerd werden, laat binnenkomende data die het verwerkingsvenster miste, of een deployment die transformatielogica wijzigde.
6. Herstel en voorkom: patch het directe probleem, voeg een datakwaliteitscontrole toe die het zou hebben opgemerkt, en werk het runbook bij.

Deze vraag toetst de volwassenheid van incidentrespons. Interviewers willen gestructureerd denken zien, geen willekeurig gissen.

Voorbereiding op het data engineering sollicitatiegesprek

Het Data Engineering voorbereidingstraject op SharpSkill behandelt deze onderwerpen met interactieve oefeningen voor ETL/ELT-patronen, datamodellering, Airflow, BigQuery en meer.

Conclusie

• SQL window functions, CTEs en query-optimalisatie blijven fundamenteel, ongeacht het ervaringsniveau
• ETL vs ELT-beslissingen moeten worden gestuurd door latentievereisten, datagovernancebehoeften en infrastructuurkosten in plaats van trends te volgen
• Idempotentie, datacontracten en datakwaliteitscontroles onderscheiden productieklare pipelines van prototypes
• Vragen over streamingarchitectuur richten zich op afwegingen (batch vs streaming vs micro-batch) in plaats van toolspecifieke kennis
• Datamodelleringskeuzes (star vs snowflake, SCD-typen) moeten aansluiten bij consumptiepatronen, niet bij theoretische best practices
• System design-antwoorden moeten foutafhandeling, kostenoptimalisatie en observability behandelen naast het happy path
• De sterkste kandidaten tonen gestructureerde probleemoplossing en eerlijke redenering over afwegingen