20 veelgestelde interviewvragen voor Data Scientist. Data science is een veelgevraagd vakgebied dat product-, klant- en bedrijfsdata omzet in beslissingen, experimenten, modellen en meetbare inzichten. De vragen behandelen verschillende niveaus, en je kunt hardop oefenen met antwoorden in onze interviewtrainer.
1How do you explain foundational metrics like conversion rates or statistical significance to non-technical business stakeholders without using technical jargon?
When communicating foundational metrics to non-technical stakeholders, the key is to translate abstract formulas and statistical mechanics into intuitive user stories, decision confidence, and business risk. For conversion rate, rather than presenting a bare ratio or abstract percentage, frame it around concrete user counts: 'Out of every 100 people who landed on the checkout page, 5 completed a purchase.' This grounds the metric directly in observable customer behavior. For statistical significance, avoid formal null hypothesis terminology like alpha levels or rejection regions. Instead, explain it as confidence that an observed uplift is real rather than random noise or lucky timing. For instance: 'A statistically significant result means we are 95% confident this improvement reflects a genuine change in user behavior rather than random fluke. Rolling this out gives us high confidence of a positive outcome instead of reacting to random noise.'
## Experiment Results: New Checkout Flow
- Baseline Conversion: 5.0% (5 out of 100 visitors buy)
- Variant Conversion: 5.8% (5.8 out of 100 visitors buy, a +16% relative lift)
- Decision Confidence: 96% confidence (p = 0.04)
- Business Takeaway: The risk that this lift was just random chance is under 4%. Rolling this out is estimated to bring +$45k in monthly revenue.
2Wat is het conceptuele verschil tussen inner, left, right en full outer joins, en hoe beïnvloedt elke keuze de analytische populatie en de verwerking van null-waarden bij downstream metriekberekeningen?
Inner, left, right en full outer joins bepalen welke records behouden blijven bij het combineren van tabellen op basis van overeenkomende sleutels:
- Inner Join: Behoudt alleen records waarbij de join-sleutel in beide tabellen overeenkomt.
- Left (Outer) Join: Behoudt alle records uit de linkertabel en vult kolommen uit de rechtertabel met NULL wanneer er geen overeenkomst is.
- Right (Outer) Join: Behoudt alle records uit de rechtertabel en vult niet-overeenkomende kolommen aan de linkerkant met NULL.
- Full Outer Join: Behoudt alle records uit beide tabellen en plaatst NULL-waarden aan weerszijden wanneer een overeenkomst ontbreekt.
Analytische populatie en impact op downstream metrieken:
De keuze van de join bepaalt rechtstreeks het analytische cohort en de noemers die worden gebruikt bij het berekenen van metrieken. Een onbedoelde inner join tussen een gebruikersbestand en een activiteits- of transactietabel verwijdert inactieve gebruikers, waardoor de noemer krimpt tot alleen actieve gebruikers en conversie- of retentiepercentages kunstmatig hoog uitvallen. Daarentegen behouden outer joins de volledige basispopulatie, maar introduceren ze NULL-waarden voor niet-overeenkomende rijen. Downstream berekeningen moeten rekening houden met deze NULL-waarden: standaard SQL-aggregaties zoals SUM() of AVG() negeren NULL-waarden, COUNT(kolom) telt niet-NULL-waarden terwijl COUNT(*) alle rijen telt, en rekenkundige bewerkingen op niet-gecoalescete NULL-waarden resulteren in NULL.
-- Inner join silently shrinks denominator to purchasers only
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS inner_conv_rate
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
-- Left join preserves full user base for accurate metric computation
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS true_conv_rate
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id;
3In product experimentation, what does randomization achieve that simple before-after comparison usually cannot, and how would you explain the core causal claim an A/B test is designed to support?
In product experimentation, a simple before-after comparison compares metrics across different time periods, which confounds the effect of a feature change with external temporal factors such as seasonality, day-of-week patterns, concurrent marketing campaigns, macro trends, and natural user maturation. Randomization assigns eligible units simultaneously to treatment and control groups, balancing both observed and unobserved confounding variables across groups in expectation. This establishes internal validity. The core causal claim supported by an A/B test relies on counterfactual reasoning: because the control group is subjected to the exact same external conditions over the exact same time window, it serves as an empirical estimate of the counterfactual—what would have happened to the treatment group had they not received the feature. Therefore, any statistically significant difference in outcomes can be causally attributed to the treatment intervention.
# Naive Before-After Comparison:
# Effect_estimate = Metric_t1 (Holiday Launch) - Metric_t0 (Pre-Holiday Baseline)
# Problem: Lift is confounded by holiday shopping surge and marketing spend.
# Randomized A/B Test:
# Effect_estimate = E[Metric_Holiday | Treatment] - E[Metric_Holiday | Control]
# Solution: Both arms experience the exact same external shocks simultaneously.
4Wat probeert exploratieve data-analyse doorgaans te bereiken voorafgaand aan formele modellering of experimenten, en hoe onderscheid je EDA (Exploratory Data Analysis) van confirmerende analyse?
Exploratory Data Analysis (EDA) is een open proces gericht op het begrijpen van de onderliggende structuur van een dataset, het ontdekken van patronen, het identificeren van anomalieën of problemen met gegevenskwaliteit, het beoordelen van aannames over verdelingen en het genereren van hypothesen voordat formele statistische modellen worden gebouwd of experimenten worden uitgevoerd. Het belangrijkste onderscheid tussen EDA en confirmerende analyse ligt in hun doel en methodologie: EDA is hypothesegenererend, flexibel en verkennend — waarbij beschrijvende samenvattingen, correlaties en visualisaties worden gebruikt om te onderzoeken wat de data suggereert zonder strikte vooraf vastgelegde aannames. Confirmerende analyse daarentegen (zoals het toetsen van hypothesen of A/B-testevaluaties) is hypothesetoetsend, gestructureerd en inferentieel — ontworpen om vooraf gespecificeerde, falsifieerbare hypothesen rigoureus te toetsen terwijl statistische foutmarges (zoals Type I-fouten) worden beheerst. Het behandelen van bevindingen uit EDA als bevestigde conclusies op dezelfde dataset kan leiden tot datadredging (p-hacking) en overfitting.
import numpy as np
import pandas as pd
# 1. EDA Phase: Open-ended discovery and hypothesis generation
df = pd.DataFrame({'engagement_score': np.random.normal(50, 10, 1000)})
summary = df['engagement_score'].describe()
# 2. Confirmatory Phase: Testing pre-registered hypothesis on fresh test/experiment data
# (e.g., two-sample t-test with fixed significance level alpha = 0.05)
5Wat is target leakage bij supervised learning, en hoe verschilt dit van een legitieme sterke correlatie tussen een feature en het label?
Target leakage treedt op wanneer een feature die wordt gebruikt bij het trainen van een model informatie bevat over het doellabel die op het moment van inferentie, wanneer het model voorspellingen doet in de praktijk, redelijkerwijs niet beschikbaar zou zijn. Dit gebeurt vaak wanneer een feature chronologisch wordt verzameld na de gebeurtenis in kwestie of een direct gevolg is van de uiteindelijke doeluitkomst (zoals het gebruik van een tijdstempel voor accountopzegging of een terugbetalings-ID om klantverloop te voorspellen). Een legitieme sterke correlatie weerspiegelt daarentegen een werkelijke, vooraf bestaande voorspellende of causale relatie die volledig bekend en beschikbaar is vóór het voorspellingsmoment (zoals de inlogfrequentie van een klant over de afgelopen 30 dagen). Hoewel beide leiden tot een hoge feature-belangrijkheid of sterke evaluatiescores, behaalt een model met target leakage onrealistisch hoge offline validatiescores, maar faalt het in productie omdat de gelekte feature tijdens inferentie niet bekend kan zijn.
# Scenario: Predicting whether a user will cancel their subscription (is_churned)
# LEAKY FEATURE:
# 'cancellation_survey_submitted' -> Occurs after the decision to churn has executed.
# LEGITIMATE FEATURE:
# 'login_count_last_30_days' -> Observed strictly before the prediction cut-off date.
6Wat is het doel van het opdelen van data in trainings-, validatie- en testsets, en hoe moet elke partitie richting geven aan iteratieve modelontwikkeling?
Het opdelen van data in trainings-, validatie- en testsets scheidt het trainen van modellen, het afstellen van hyperparameters en de uiteindelijke evaluatie, zodat het model goed generaliseert naar niet-eerder-geziene data.
- Trainingsset: Wordt gebruikt om de interne parameters van het model te fitten (zoals gewichten en biases in neurale netwerken, of splitsingsdrempels in beslissingsbomen).
- Validatieset: Wordt tijdens de iteratieve ontwikkeling gebruikt voor modelselectie, hyperparameterafstelling, featureselectie en het detecteren van overfitting. Deze set stuurt beslissingen over welke modelarchitectuur of configuratie het beste presteert, zonder de uiteindelijke evaluatiedata te beïnvloeden.
- Testset: Dient als een strikt apart gehouden proxy voor ongeziene productiedata. Deze wordt pas helemaal aan het einde van het project eenmalig geëvalueerd om een zuivere schatting te geven van de generalisatiefout. Het opnieuw afstellen van modellen op basis van testsetresultaten doet afbreuk aan de objectiviteit en introduceert een te optimistische vertekening.
from sklearn.model_selection import train_test_split
from sklearn.datasets import make_classification
X, y = make_classification(n_samples=1000, n_features=10, random_state=42)
# Step 1: Split off final test set (20%)
X_dev, X_test, y_dev, y_test = train_test_split(
X, y, test_size=0.20, random_state=42, stratify=y
)
# Step 2: Split remaining development data into train (75% of dev = 60% total) and validation (25% of dev = 20% total)
X_train, X_val, y_train, y_val = train_test_split(
X_dev, y_dev, test_size=0.25, random_state=42, stratify=y_dev
)
print(f"Train size: {len(X_train)}, Val size: {len(X_val)}, Test size: {len(X_test)}")
7Wat is het verschil tussen gesuperviseerd en ongesuperviseerd leren, en hoe bepalen de beschikbaarheid van labels en bedrijfsdoelen welk paradigma je kiest?
Algoritmen voor gesuperviseerd leren (supervised learning) leren een wiskundige afbeelding van invoerkenmerken (X) naar bekende doellabels (y) op basis van gelabelde historische gegevens om uitkomsten op nieuwe waarnemingen te voorspellen. Ongesuperviseerd leren (unsupervised learning) analyseert datasets die uitsluitend kenmerken (X) bevatten om intrinsieke structuren, natuurlijke groeperingen (clustering) of gereduceerde representaties te ontdekken zonder vooraf gedefinieerde doellabels. De keuze tussen deze paradigma's wordt bepaald door de beschikbaarheid van labels en de bedrijfsdoelen: als er referentielabels (ground-truth labels) bestaan of als deze haalbaar zijn om te verzamelen, en het doel gerichte voorspelling is (zoals fraudedetectie, churnvoorspelling of prijsvoorspelling), dan is gesuperviseerd leren passend. Als er geen referentielabels zijn, deze te duur zijn om te verkrijgen, of als het doel verkennend van aard is (zoals klantsegmentatie of anomaliedetectie zonder bekende labels), dan wordt gekozen voor ongesuperviseerd leren.
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.cluster import KMeans
X = np.array([[10, 2], [12, 3], [1, 8], [2, 9]])
y = np.array([0, 0, 1, 1])
# Supervised: Learns mapping X -> y
clf = LogisticRegression().fit(X, y)
# Unsupervised: Discovers clusters directly from X
kmeans = KMeans(n_clusters=2, random_state=42, n_init=10).fit(X)
8Wat is een North Star Metric en hoe onderscheid je een effectieve North Star van een vanity metric bij het evalueren van de gezondheid van een product?
Een North Star Metric (NSM) is de primaire metriek die het best de kernwaarde weergeeft die een product aan zijn klanten levert, terwijl deze tegelijkertijd duurzame bedrijfsresultaten stimuleert (zoals 'Geboekte overnachtingen' voor Airbnb of 'Wekelijkse actieve streaminguren' voor een muziekplatform). Het brengt productteams op één lijn rond langetermijnwaarde voor de klant in plaats van oppervlakkige groei. Om een effectieve North Star te onderscheiden van een vanity metric:
1. Afstemming op waarde: Een effectieve North Star weerspiegelt daadwerkelijk nut voor de gebruiker en actieve betrokkenheid, terwijl een vanity metric oppervlakkig volume meet (zoals het totale aantal geregistreerde gebruikers, cumulatieve app-downloads of ruwe paginaweergaven) dat kan groeien zelfs wanneer gebruikers direct afhaken.
2. Bruikbaarheid en correlatie: Een effectieve North Star correleert met gebruikersbehoud, productgezondheid en het genereren van inkomsten, en reageert direct op verbeteringen in de productkwaliteit. Vanity metrics kunnen vaak niet worden gekoppeld aan daadwerkelijk behoud of de gezondheid van het bedrijf en zijn gevoelig voor kunstmatige opblazing.
Platform: Vacation Rental App
Vanity Metric: Cumulative app downloads (increases continuously even if 95% of users uninstall immediately).
North Star Metric: Nights booked per active user (reflects actual value exchange between guests and hosts).
9Wat is het praktische onderscheid tussen datadrift en conceptdrift, en waarom is het correct categoriseren hiervan essentieel voor het onderhoud van modellen na ingebruikname?
Datadrift (vaak aangeduid als covariate shift) treedt op wanneer de statistische verdeling van invoerkenmerken P(X) in de loop van de tijd verandert, terwijl de voorwaardelijke relatie tussen de invoer en het doel P(Y|X) ongewijzigd blijft. Conceptdrift daarentegen treedt op wanneer de onderliggende relatie tussen de invoer en het doel P(Y|X) verandert, wat betekent dat identieke kenmerkwaarden nu overeenkomen met ander doelgedrag of andere uitkomsten. Het correct categoriseren van beide is essentieel voor het onderhoud na ingebruikname, omdat de oplossingsrichtingen fundamenteel verschillen. Bij datadrift blijven historische patronen geldig; het onderhoud richt zich op het uitbreiden van de trainingsdekking over nieuwe kenmerkgebieden, het bijwerken van de voorbewerking of het opnieuw wegen van steekproeven. Bij conceptdrift weerspiegelen historische labels de actuele werkelijkheid niet meer; het onderhoud vereist dan het verzamelen van nieuwe gelabelde data, het uitfaseren van verouderde historische voorbeelden en het opnieuw trainen of herontwerpen van het model.
# Data Drift (Covariate Shift):
# User demographics or devices change (P(X) shifts),
# but genuine vs fraudulent transaction patterns remain identical (P(Y|X) unchanged).
# Concept Drift:
# Fraudsters adapt tactics to mimic normal shopping patterns;
# identical feature inputs now have a higher probability of fraud (P(Y|X) shifts).
10Wat is het verschil tussen een populatieparameter en een steekproefgrootheid, en welke invloed heeft steekproefvariabiliteit op de interpretatie van metrieken?
Een populatieparameter is een vast, doorgaans onbekend numeriek kenmerk van een gehele populatie (zoals het werkelijke populatiegemiddelde μ of de proportie p). Een steekproefgrootheid is een numerieke samenvatting berekend op basis van waargenomen steekproefgegevens (zoals het steekproefgemiddelde x̄ of de steekproefproportie p̂), die wordt gebruikt om de onbekende parameter te schatten. Steekproefvariabiliteit verwijst naar de natuurlijke variatie tussen steekproefgrootheden over verschillende willekeurige steekproeven uit dezelfde populatie. Door deze steekproefvariabiliteit is elke afzonderlijke steekproefmetriek onderhevig aan toevallige fouten en komt deze zelden exact overeen met de werkelijke populatieparameter. Als er bij de interpretatie van metrieken geen rekening wordt gehouden met deze variabiliteit, wordt ruis al snel aangezien voor een daadwerkelijke verandering. Analisten moeten de onzekerheid van schattingen kwantificeren met behulp van standaardfouten, betrouwbaarheidsintervallen of hypothesetoetsen voordat ze kunnen concluderen dat een waargenomen verschil reëel is.
import numpy as np
# True population parameter (mean = 50, standard deviation = 10)
pop_mean = 50.0
pop_std = 10.0
# Draw multiple independent samples of size n=30
np.random.seed(42)
sample_means = [np.mean(np.random.normal(pop_mean, pop_std, size=30)) for _ in range(5)]
for i, sm in enumerate(sample_means, 1):
print(f"Sample {i} Mean (Statistic): {sm:.2f} | Error: {sm - pop_mean:+.2f}")
11Een stakeholder stelt een dubbelzinnige vraag zoals 'Werkt feature Y?'. Hoe herformuleer je die vraag naar een meetbaar analysekader waarmee besluiten genomen kunnen worden?
Wanneer een stakeholder vraagt 'Werkt feature Y?', begin ik met het ontleden van de vraag naar de achterliggende intentie: Welk probleem moest feature Y oplossen, voor wie is het bedoeld en welke beslissing wordt er genomen op basis van het antwoord (bijvoorbeeld itereren, opschalen of uitfaseren)? Vervolgens stel ik een gelaagd meetkader op dat bestaat uit: 1. Adoptie en betrokkenheid: Ontdekken en gebruiken doelgroepgebruikers de feature zoals verwacht? 2. Directe waarde / succesvolle taakafronding: Rondt de gebruiker de kernworkflow die door de feature mogelijk wordt gemaakt succesvol af? 3. Afgeleide bedrijfsimpact: Corroleert de feature-adoptie met of stuurt het belangrijke top-line metrieken aan (zoals retentie, conversie, omzet)? 4. Vangrails (guardrails): Heeft de feature onbedoelde negatieve neveneffecten veroorzaakt (zoals verhoogde latency, extra supporttickets, kannibalisatie)? Tot slot leg ik vooraf beslissingsdrempels en evaluatiecriteria vast met de stakeholder voordat de analyse wordt uitgevoerd. Dit zorgt voor afstemming over wat succes inhoudt en voorkomt dat de doelpalen achteraf worden verschoven.
Feature: Quick Checkout Button
1. Primary Decision: Keep & expand vs. Redesign vs. Deprecate
2. Evaluation Metrics:
- Adoption: % of checkout sessions clicking the quick button (Target: >= 15%)
- Funnel Completion: Checkout completion rate given button click (Target: >= 75%)
- Business Metric: Overall cart conversion lift (Target: +1.5% in A/B test)
- Guardrail: Support tickets for accidental purchases (Threshold: < 0.2% increase)
3. Pre-agreed Action Plan:
- If Target Met: Roll out to 100% and promote to mobile app.
- If Adoption Low but Completion High: Retain, optimize UI discovery.
- If Guardrail Exceeded: Halt rollout, add confirmation step.
12Hoe maak je bij het opschonen en voorbereiden van een dataset met aanzienlijke ontbrekende waarden de afweging tussen complete-case analysis, eenvoudige imputatie, ontbrekendheid-indicatoren (missingness indicators) en modelgebaseerde imputatie?
Het kiezen van een strategie voor ontbrekende gegevens hangt primair af van het mechanisme achter het ontbreken (MCAR, MAR, MNAR), het aandeel ontbrekende waarden, het uiteindelijke gebruiksdoel (statistische inferentie versus voorspellende modellering) en het risico op vertekening (bias):
1. **Complete-Case Analysis (rijen verwijderen):** Alleen geschikt wanneer gegevens Missing Completely at Random (MCAR) zijn en het ontbrekende percentage klein is (bijv. < 5%). Als gegevens Missing at Random (MAR) of Missing Not at Random (MNAR) zijn, leidt het verwijderen van rijen tot ernstige selectievertekening en verlies van statistisch onderscheidend vermogen.
2. **Eenvoudige imputatie (gemiddelde/mediaan/modus):** Snel en praktisch voor basale voorspellende modellen, maar riskant voor statistische analyses omdat het de variantie van variabelen kunstmatig verlaagt, toetsingsgrootheden opblaast en covariantiestructuren verstoort.
3. **Ontbrekendheid-indicatoren (imputatie + binaire vlag):** Ideaal voor voorspellende modellering (met name boomgebaseerde algoritmen) en situaties waarin het ontbreken zelf informatief is (MNAR, zoals weggelaten optionele velden). Dit behoudt het signaal van de ontbrekende waarde zonder geldige numerieke verdelingen te vervuilen.
4. **Modelgebaseerde imputatie (KNN, MICE, Iterative Imputer):** De voorkeursoptie wanneer gegevens MAR zijn, er sterke correlaties tussen variabelen bestaan en het behoud van multivariate relaties of standaardfouten van parameters cruciaal is (bijv. bij regressie-inferentie). De afwegingen hierbij zijn computationele complexiteit, overhead bij implementatie in productie-pipelines en het risico op data leakage als er niet strikt op trainingsfolds wordt gefit.
from sklearn.impute import SimpleImputer
import pandas as pd
df = pd.DataFrame({'income': [50000, None, 75000, None, 120000]})
# Impute median while tracking missingness pattern
imputer = SimpleImputer(strategy='median', add_indicator=True)
imputed_data = imputer.fit_transform(df)
# Returns: [income_imputed, income_is_missing]
13Een productteam vergelijkt gebruikers die zich actief hebben aangemeld voor een nieuwe functionaliteit met gebruikers die dat niet deden, en vindt een 20% hogere retentie. Hoe zou je selectiebias en confounding diagnosticeren, en hoe zou je de evaluatie opnieuw opzetten?
Het vergelijken van opt-in-gebruikers met niet-opt-in-gebruikers heeft te lijden onder zelfselectiebias en confounding. Gebruikers die er actief voor kiezen om een nieuwe functionaliteit te gebruiken, hebben doorgaans een hogere baseline-intentie, betrokkenheid of technische vaardigheid. Daardoor verwart het waargenomen retentieverschil van 20% het werkelijke causale effect van de functionaliteit met reeds bestaande motivatie van de gebruiker. De bias diagnosticeren: 1. Vergelijking van covariabelen vóór de interventie: Vergelijk basiskenmerken tussen de opt-in- en niet-opt-in-cohorten voorafgaand aan de introductie van de functionaliteit (bijv. historische activiteit, eerdere retentie, klantduur, transactiefrequentie, apparaatmix). Significante verschillen bevestigen confounding. 2. Pre-trend- / placebocontroles: Evalueer of opt-in-gebruikers al een hogere retentie of betrokkenheid vertoonden in perioden vóór de lancering van de functionaliteit. De evaluatie herontwerpen: - Gerandomiseerd experiment (de gouden standaard): Implementeer een Randomized Encouragement Design (of een gerandomiseerde uitrol van de functionaliteit). Alle in aanmerking komende gebruikers worden willekeurig ingedeeld in Behandeling (krijgen de functionaliteit / prompt aangeboden) en Controle (krijgen dit niet aangeboden). Analyseer met behulp van Intention-to-Treat (ITT) voor het totale aanbiedingseffect, en Instrumentele Variabelen / Two-Stage Least Squares (2SLS) met toewijzing als instrument om het Local Average Treatment Effect (LATE) op actieve gebruikers te schatten. - Quasi-experimentele benaderingen (als randomisatie onmogelijk is): Gebruik Propensity Score Matching (PSM), Difference-in-Differences (DiD) of Synthetische Controle om te corrigeren voor observeerbare baseline-confounders en parallelle reeds bestaande trends.
import statsmodels.formula.api as smf
import pandas as pd
# df columns: ['user_id', 'post_period', 'opted_in', 'retained']
# Interaction term captures causal lift above baseline group differences
model = smf.ols('retained ~ opted_in + post_period + opted_in:post_period', data=df).fit()
print(model.summary().tables[1])
14Hoe zou je cohortafbakeningen ontwerpen voor een activatie- of retentieonderzoek om ervoor te zorgen dat vergelijkingen niet worden vertekend door mixverschuivingen of afkapping door looptijd (maturity truncation)?
Om cohortafbakeningen te ontwerpen die mixverschuivingen en afkapping door looptijd voorkomen: 1. **Standaardiseer tijdsvensters (tenure windows)**: Lijn cohorten uit op basis van relatieve verstreken tijd (bijvoorbeeld dag 0, dag 7, dag 30 na registratie/activatie) in plaats van kalenderdata om eerlijke vergelijkingen over de levenscyclus te garanderen. 2. **Ga om met afkapping door looptijd (rechts-censurering)**: Evalueer alleen cohorten die het volledige observatievenster hebben doorlopen. Sluit recente cohorten die nog niet de volledige tijdsduur hebben gehad om de mijlpaal te bereiken uit of markeer ze expliciet. 3. **Beperk mixverschuivingen**: Segmenteer cohorten over invloedrijke verstorende variabelen (zoals acquisitiekanaal, platform, land of gebruikersintentie). Als je een geaggregeerd cijfer rapporteert, gebruik dan standaardisatie- of post-stratificatieweging zodat verschuivingen in de mix van acquisitiebronnen de waargenomen retentietrend niet vertekenen.
WITH user_cohorts AS (
SELECT
user_id,
DATE_TRUNC('week', signup_time) AS cohort_week,
signup_time,
acquisition_channel
FROM users
-- Exclude cohorts that have not reached 7 full days of maturity
WHERE signup_time <= CURRENT_DATE - INTERVAL '7 days'
),
user_activity AS (
SELECT DISTINCT
c.user_id,
c.cohort_week,
c.acquisition_channel,
1 AS retained_d7
FROM user_cohorts c
JOIN events e ON c.user_id = e.user_id
WHERE e.event_time >= c.signup_time + INTERVAL '7 days'
AND e.event_time < c.signup_time + INTERVAL '8 days'
)
SELECT
c.cohort_week,
c.acquisition_channel,
COUNT(c.user_id) AS cohort_size,
COUNT(a.user_id) AS d7_active_users,
ROUND(100.0 * COUNT(a.user_id) / COUNT(c.user_id), 2) AS d7_retention_pct
FROM user_cohorts c
LEFT JOIN user_activity a ON c.user_id = a.user_id
GROUP BY 1, 2
ORDER BY 1 DESC, 2;
15Tijdens de evaluatie behaalt je model een ongebruikelijk hoge metriek zoals een AUC (Area Under the Curve) van 0,99, maar tijdens shadow testing keldert de performance. Hoe isoleer en verifieer je target leakage op een systematische manier?
Wanneer een model een onrealistisch hoge offline metriek behaalt (zoals een AUC van 0,99) die in live shadow testing instort, is target leakage de hoofdverdachte. Een systematische workflow voor isolatie en verificatie omvat: 1. Feature Importance & Attributie: Bereken SHAP-waarden, gain-importances of permutation importance om kandidaat-features met dominante voorspellende kracht te identificeren. 2. Modellen met één feature & Ablatiestudies: Train eenvoudige modellen met 1 feature (zoals ondiepe beslissingsbomen of logistische regressie) op afzonderlijke verdachte features. Als een enkele feature een nagenoeg perfecte classificatie behaalt, lekt deze waarschijnlijk de target. Verwijder verdachte features stapsgewijs en meet de daling in offline performance. 3. Tijd- en timestamp-lineage-audit: Controleer de exacte aanmaak- en bijwerktimestamps van kandidaat-features ten opzichte van de voorspellingsafkaptimestamp (cutoff timestamp). Controleer of de featurewaarde pas bekend kon zijn nadat de doelgebeurtenis plaatsvond (bijvoorbeeld `cancellation_reason` of `refund_status` die pas wordt ingevuld bij churn of terugboeking). 4. Datalineage en verificatie van data-engineering: Controleer de upstream datapipeline en de tabelsynchronisatielogica (bijvoorbeeld veranderlijke tabellen die ter plekke worden bijgewerkt versus append-only onveranderlijke logs) om te controleren wanneer velden precies worden gevuld.
from sklearn.metrics import roc_auc_score
from sklearn.tree import DecisionTreeClassifier
leakage_candidates = {}
for col in X_train.columns:
clf = DecisionTreeClassifier(max_depth=2)
clf.fit(X_train[[col]], y_train)
preds = clf.predict_proba(X_test[[col]])[:, 1]
auc = roc_auc_score(y_test, preds)
if auc > 0.85:
leakage_candidates[col] = auc
print("Candidate Leaky Features:", leakage_candidates)
16Hoe maak je de keuze tussen standaard K-Fold, Stratified K-Fold en Group K-Fold kruisvalidatie (cross-validation) bij het evalueren van gestructureerde data uit de praktijk?
De keuze tussen standaard K-Fold, Stratified K-Fold en Group K-Fold hangt af van de verdeling van de doelvariabele en de onderlinge onafhankelijkheid van rijen:
1. **Standaard K-Fold**: Splitst data willekeurig in K gelijke folds. Dit veronderstelt dat observaties onafhankelijk en identiek verdeeld zijn (IID) en wordt doorgaans gebruikt voor continue regressiedoelen of goed gebalanceerde datasets.
2. **Stratified K-Fold**: Zorgt ervoor dat elke fold dezelfde verhouding van klasselabels behoudt als de volledige dataset. Dit is essentieel voor classificatietaken, vooral bij ongebalanceerde klassen, om te voorkomen dat folds te weinig of geen voorbeelden van de minderheidsklasse bevatten.
3. **Group K-Fold**: Garandeert dat afzonderlijke groepen of entiteiten (bijvoorbeeld `user_id`, `patient_id`, `device_id`) niet tegelijkertijd in zowel trainings- als validatiefolds voorkomen. Wanneer meerdere observaties afkomstig zijn van dezelfde entiteit, veroorzaakt een standaard splitsing ernstige datalekken (data leakage) doordat het model entiteitsspecifieke kenmerken memoriseert in plaats van generaliseerbare patronen te leren. Group K-Fold toetst hoe goed het model generaliseert naar volledig ongeziene entiteiten.
17Hoe kies je tussen logistieke regressie, Gradient Boosted Decision Trees en niet-lineaire neurale architecturen voor tabulaire classificatie onder beperkingen qua latentie en datadrift?
Het kiezen tussen logistieke regressie (LR), Gradient Boosted Decision Trees (GBDT's) en neurale netwerken (NN's) voor tabulaire classificatie vraagt om een afweging tussen voorspellende kracht, budgetten voor inferentielatentie, uitlegbaarheid en bestendigheid tegen datadrift. 1. Logistieke regressie blinkt uit in omgevingen met een extreem lage latentie (<1-5 ms p99) en zeer beperkte rekenkracht. Omdat de scoring een eenvoudig inwendig product (dot product) is, is het extreem snel en robuust. Bij covariatenverschuiving (covariate drift) of featurewaarden buiten de trainingsverdeling extrapoleren lineaire modellen monotoon; dit kan voorspelbaar of juist gevaarlijk zijn afhankelijk van de geregulariseerde hellingen, maar leidt zelden tot grillig stapfunctiegedrag. Wel vereist LR uitgebreide handmatige feature engineering (interacties, niet-lineaire binning) om de prestaties van niet-lineaire architecturen te evenaren. 2. GBDT's (zoals XGBoost, LightGBM, CatBoost) vormen de standaard benchmark in de industrie voor tabulaire data. Ze leggen complexe niet-lineaire interacties van nature vast en gaan naadloos om met gemengde datatypen en ontbrekende waarden. Qua latentie halen geoptimaliseerde GBDT's (of gecompileerd via Treelite/ONNX) gemakkelijk SLA's van onder de 10 ms. Bij drift kunnen GBDT's niet extrapoleren buiten de waargenomen trainingsgrenzen (ze klemmen voorspellingen af op de buitenste bladeren), wat een ingebouwde veiligheidsbuffer biedt tegen wilde extrapolaties, maar wel het risico met zich meebrengt van statische stapvoorspellingen als de featureverdelingen aanzienlijk verschuiven. 3. Neurale architecturen (zoals FT-Transformer, TabNet, MLP) verdienen de voorkeur wanneer tabulaire data multimodaal is (gecombineerd met tekst, embeddings of afbeeldingen) of in continue online leerscenario's. Zuiver tabulaire NN's hebben echter doorgaans hogere inferentielatenties (ze vereisen matrixvermenigvuldigingen over meerdere lagen of GPU-versnelling), vergen meer rekenkracht bij de training en zijn zeer gevoelig voor niet-geschaalde invoer en covariatenverschuiving. In de praktijk: begin met een GBDT als sterke prestatiebasis; implementeer LR als een strikte latentie in microseconden of eenvoudige uitlegbaarheid vereist is; en gebruik NN's primair voor multimodale architecturen of de overdracht van embeddings.
decision_matrix = {
"Logistic Regression": {"Latency": "<1ms (Ultra-low)", "Drift Behavior": "Linear extrapolation", "Tabular Baseline": "Moderate (needs feature engineering)"},
"GBDT (XGB/LightGBM)": {"Latency": "1-15ms (Fast)", "Drift Behavior": "Leaf clamping (no extrapolation)", "Tabular Baseline": "State of the Art"},
"Tabular Neural Net": {"Latency": "10-50ms+ (Higher)", "Drift Behavior": "Nonlinear extrapolation", "Tabular Baseline": "Competitive / High tuning cost"}
}
for model, traits in decision_matrix.items():
print(f"{model}: Latency={traits['Latency']}, Tabular Perf={traits['Tabular Baseline']}")
18De directie moet beslissen over een grote landelijke uitrol van een functionaliteit onder ambigue omstandigheden, waaronder wisselende regionale experimentresultaten en vaste lanceringsmomenten. Hoe zet je het raamwerk voor de strategische aanbeveling op?
Om een strategische aanbeveling op te stellen bij dubbelzinnige regionale experimentresultaten en vaste lanceringsdeadlines, moet je de beslissing loskoppelen van een binaire go/no-go-keuze. Splits eerst de geaggregeerde resultaten uit in heterogene behandelingseffecten over marktsegmenten, klantcohorten en operationele omgevingen om te isoleren waar de functionaliteit slaagt, stagneert of juist schade berokkent. Ontwerp vervolgens een risicomijdende gefaseerde uitrolstrategie (zoals regionale fasering of canary-implementaties) die prioriteit geeft aan segmenten met een hoge mate van zekerheid en tegelijkertijd extreme neerwaartse risico's isoleert. Stel expliciete, vooraf vastgelegde vangnetstatistieken en geautomatiseerde noodstoppen of rollback-drempelwaarden in om het neerwaartse risico in het slechtste geval te begrenzen. Structureer tot slot de communicatie naar het leiderschap rond de verwachte waarde, het asymmetrische neerwaartse risico versus de commerciële kosten van het missen van het vaste tijdvenster, en operationele draaiboeken om tussentijds bij te sturen.
| Rollout Tier | Target Markets | Launch Exposure | Guardrail Circuit-Breaker | Expected Value / Risk Profile |
|---|---|---|---|---|
| Tier 1: Immediate Launch | Cohorts with stat-sig positive lift (e.g., Regions A, C) | 100% | Rollback if 48h conversion drops > 1.5% | High upside; verified market fit |
| Tier 2: Phased Staging | High-variance / neutral cohorts (e.g., Region B) | 10% -> 25% -> 50% over 14 days | Hold expansion if CSAT drops > 2.0% | Moderate upside; bounded downside |
| Tier 3: Hold & Re-test | Stat-sig negative cohorts (e.g., Region D) | 0% (Holdout / internal testing) | Launch blocked until root-cause resolution | Eliminates primary churn risk |
19Hoe zou je een gecentraliseerde semantische laag ontwerpen over een enterprise datawarehouse om consistente definities van bedrijfsstatistieken te waarborgen tussen verschillende analyticsteams?
Het ontwerpen van een gecentraliseerde semantische laag over een enterprise datawarehouse vereist het opzetten van een declaratieve, op code gebaseerde definitielaag voor metrieken (zoals MetricFlow/dbt Semantic Layer, Cube of LookML) die bedrijfslogica ontkoppelt van fysieke opslag en downstream-consumptietools (BI-platforms, Python/R-notebooks, API's). De kernarchitectuur definieert entiteiten, dimensies, meetwaarden en afgeleide metrieken in versiebeheerde repositories (Git) om één betrouwbare bron van de waarheid te bieden en metriekconsistentie tussen teams af te dwingen. Om multi-tenancy en governance over afzonderlijke bedrijfsonderdelen te ondersteunen, moet een gefedereerd governancemodel worden toegepast: centrale enterprise-KPI's (Key Performance Indicators, zoals ARR of actieve gebruikers) vallen onder het beheer van een centraal data-governanceteam, terwijl domeinspecifieke metrieken worden beheerd door gedecentraliseerde domeinteams via geïsoleerde semantische modellen met CI/CD-validatie. De semantische laag biedt vervolgens gestandaardiseerde query-interfaces (SQL, GraphQL, REST) met uniforme rolgebaseerde toegangscontrole en caching/pre-aggregatie om prestaties en consistentie te behouden.
semantic_model:
name: orders
node_relation:
alias: fct_orders
dimensions:
- name: order_date
type: time
type_params:
time_granularity: day
- name: country
type: categorical
measures:
- name: total_revenue
expr: revenue_usd
agg: sum
- name: distinct_buyers
expr: user_id
agg: count_distinct
metrics:
- name: average_order_value
description: "Governed metric for AOV across all BI tools"
type: ratio
type_params:
numerator: total_revenue
denominator: distinct_buyers
20Hoe zou je in een tweezijdige marktplaats (zoals een ritdeeldienst of e-commerce) een experiment ontwerpen om een wijziging in het matchingalgoritme te evalueren, rekening houdend met kannibalisatie van vraag en aanbod en ruimtelijk-temporele interferentie?
In tweezijdige marktplaatsen schendt het evalueren van matchingalgoritmen via standaard A/B-testen op gebruikersniveau de Stable Unit Treatment Value Assumption (SUTVA). Wanneer behandelde eenheden schaarse gedeelde middelen consumeren (zoals chauffeurs of voorraad), kannibaliseren ze controle-eenheden, wat leidt tot kunstmatige degradatie van de controlegroep en opgeblazen behandelingseffecten door verschuivingen in het marktevenwicht. Om ruimtelijke en temporele interferentie aan te pakken, hanteren we twee primaire experimentele architecturen: clustergebaseerde randomisatie en switchback-experimenten. Bij ruimtelijke clusterrandomisatie worden geografische markten of geïsoleerde subregio's (bijv. afzonderlijke stedelijke gebieden of hexagonale ruimtelijke cellen via graafpartitionering) gerandomiseerd toegewezen aan behandeling of controle. Dit isoleert directe interacties tussen vraag en aanbod, al zijn methoden zoals synthetische controlegroepen of difference-in-differences nodig om heterogeniteit tussen markten op te vangen. Bij switchback-experimenten wisselen volledige geïsoleerde markten af tussen behandelings- en controle-algoritmen over afzonderlijke tijdvensters (bijv. elke 1 tot 2 uur). Switchbacks handhaven een gemeenschappelijke balans tussen vraag en aanbod binnen elk venster, maar introduceren temporele overloopeffecten. Om dit overloopeffect te beperken, introduceren we overgangsbuffer- of uitwasperioden tussen vensters (waarbij bestellingen tijdens statusovergangen worden genegeerd) en kiezen we vensterlengtes die lang genoeg zijn om herpositionering van het aanbod op te vangen, maar kort genoeg om statistische power te behouden. De analyse moet rekening houden met serieel gecorreleerde tijdreeksfouten door standaardfouten te clusteren op het niveau van het tijdsblok of de markt, of door Generalized Estimating Equations (GEE) / Newey-West-variantieschatters te gebruiken.
import pandas as pd
import numpy as np
def generate_switchback_schedule(n_days=14, window_minutes=60, washout_minutes=15):
total_windows = int((n_days * 24 * 60) / window_minutes)
np.random.seed(42)
treatments = np.random.binomial(1, 0.5, size=total_windows)
schedule = []
for i, trt in enumerate(treatments):
start_min = i * window_minutes
eval_start_min = start_min + washout_minutes
end_min = (i + 1) * window_minutes
schedule.append({
'window_id': i,
'treatment': trt,
'start_min': start_min,
'eval_start_min': eval_start_min,
'end_min': end_min
})
return pd.DataFrame(schedule)