Fairness, Bias Mitigation, and Responsible AI in Production Questions
Understand bias sources in ML systems and fairness metrics (demographic parity, equalized odds, calibration across groups). Design bias testing and monitoring. Discuss mitigation strategies: diverse data, algorithmic debiasing, and post-processing. For Staff-level, embed responsible AI practices into organizational processes.
MediumTechnical
52 practiced
Case study: You plan an online A/B experiment to evaluate a reweighing-based mitigation for loan approvals. Design the experiment: define primary and secondary metrics (utility and fairness), explain sample size and power calculations, specify stopping rules and rollback criteria, and describe how to detect heterogeneous treatment effects across subgroups.
Sample Answer
Framework: treat this as a randomized controlled A/B test where "treatment" applies reweighing to training/score inputs used by the loan-approval model. Pre-register hypotheses, analysis plan, subgroups, and metrics.Primary and secondary metrics- Primary (utility): approval-adjusted expected profit per applicant (or net revenue per application) — combines approval rate, funded amount, interest margin, and expected loss from defaults. Use a single summary metric to capture business impact.- Primary (fairness): difference in true positive rate (equal opportunity) or disparate impact ratio between protected group(s) (e.g., race, gender). Pick one fairness notion aligned with policy/regulatory constraints; state threshold (e.g., TPR gap < 0.03 or DI > 0.8).- Secondary: approval rate, default rate (30/60/90-day), loss given default, customer lifetime value, model calibration by group, complaint/appeal rate.Sample size & power- Choose significance α (0.05 two-sided) and power 1−β (0.8). Define minimal detectable effect (MDE) for primary utility and fairness metrics.- Example (approval rate MDE): baseline approval p0=0.30, want to detect Δ=0.02 (2 pp). n per arm ≈ 2*(z_{1−α/2}+z_{1−β})^2 * p*(1−p)/Δ^2. With z≈1.96+0.84=2.8 → n ≈ 8,200 per arm. - Note: rarer outcomes (defaults) require much larger n; if defaults are primary safety concern, compute MDE for proportions accordingly or use pooled long-run data and hierarchical models to borrow strength.Stopping rules and sequential testing- Pre-specify one primary analysis at fixed sample (no unplanned peeking). If interim looks necessary, use an alpha-spending approach (O’Brien–Fleming) or group-sequential design to control Type I error.- Alternatively use Bayesian decision rules with pre-specified posterior probability thresholds for benefit/harm (e.g., Pr(treatment utility > control | data) > 0.975 to stop for benefit; <0.025 to stop for harm).- Safety stop: immediate halt if monitoring shows statistically significant increase in default rate or large negative financial impact exceeding a pre-defined loss threshold.- Predefine maximum test duration, minimum exposure per subgroup, and no rollback until database lock and primary analysis complete.Rollback criteria- Rollback if treatment causes: - Expected profit decrease beyond business tolerance (e.g., >X% drop with p<0.05 or posterior prob >0.95 of harm). - Fairness violation: fairness metric moves in wrong direction or exceeds regulatory thresholds (e.g., TPR gap increases or DI falls below 0.8) with statistical significance or high posterior probability. - Safety signals: significant increase in default or charge-off rate monitored at pre-specified windows.- Consider guardrail rules: if utility improves but fairness worsens beyond threshold, require product + compliance sign-off before rollout.Detecting heterogeneous treatment effects (HTE)- Pre-specify key strata (race, gender, income bands, credit score buckets, geography). Power calculations should ensure minimal detectable subgroup effects or use stratified sampling to guarantee coverage.- Primary HTE methods: - Interaction tests in regression (treatment × subgroup) with multiplicity correction (Holm/Benjamini-Hochberg) for confirmatory claims. - Hierarchical (multilevel) models to estimate shrinkage-adjusted subgroup effects and uncertainty. - Uplift/causal forests for exploratory discovery — report out-of-sample performance and validate in holdout.- Always treat HTE findings as hypothesis-generating unless properly powered and pre-registered. For flagged subgroup harms, consider targeted follow-up experiments or localized rollbacks.Practical notes- Log all decisions; use blinded dashboards for rapid safety monitoring; include legal/compliance in design. - Report both absolute and relative changes, confidence intervals, and business impact simulations.
EasyBehavioral
56 practiced
Tell me about a time when you discovered that a model in production was producing biased outcomes. Use the STAR format (Situation, Task, Action, Result). Focus on (a) how you detected the bias, (b) steps you took to mitigate it, and (c) what process you put in place to prevent recurrence.
Sample Answer
Situation: As an AI Engineer at a fintech startup, I maintained a credit-default risk model deployed to production that drove pre-approval decisions. After a customer complaint and an internal audit request, I was asked to verify whether the model treated demographic groups fairly.Task: My responsibility was to detect if bias existed, remediate it quickly without disrupting service, and implement processes to prevent recurrence.Action:- Detected bias: I pulled a 6-month production prediction log, joined it with customer demographics, and computed group metrics: false positive rate (FPR), false negative rate (FNR), and selection rate by protected attributes (race, gender, ZIP). I found the FNR for a minority group was 2.8x higher than the majority (statistically significant, p < 0.01).- Mitigated: I paused automatic declines for borderline scores in that group and implemented a human-review queue for those cases (low-likelihood operational change). Concurrently I retrained the model using reweighted loss to penalize errors on the disadvantaged group and added demographic-aware calibration. I validated improvements on hold-out and simulated production data: FNR gap reduced from 2.8x to 1.1x, AUC stayed within 0.01 of baseline.- Prevention: I introduced a bias-monitoring dashboard (daily parity metrics, statistical tests, alerts), added mandatory fairness checks in the CI pipeline (unit tests that fail builds if disparity exceeds thresholds), and updated the model governance doc requiring quarterly bias audits and stakeholder sign-off for model updates.Result: Within two weeks the immediate risk was mitigated (no further complaints), model disparities were substantially reduced, and the new pipeline prevented a repeat — the next quarterly audit flagged no significant bias. Stakeholders (Legal, Compliance, Product) endorsed the governance changes. I learned that combining quick operational fixes with model-level corrections and automated monitoring is the most practical approach to address production bias.
HardTechnical
71 practiced
Describe attack vectors where an adversary deliberately poisons training data to manipulate fairness metrics (e.g., cause apparent parity while harming minority utility). Propose detection strategies, robust training techniques, and operational policies to reduce this risk in a production ML pipeline.
Sample Answer
Framework: treat this as an adversarial data-poisoning attack whose goal is to bias fairness metrics (e.g., equalized odds, demographic parity) while degrading utility for a protected minority. Address: (1) attack vectors, (2) detection, (3) robust training, (4) operational policies.Attack vectors:- Label flipping targeted by subgroup (flip positive → negative only for minority) to manufacture parity while lowering minority true positive rate.- Feature manipulation: subtly perturb features correlated with sensitive groups so model learns spurious correlations; e.g., add noise to minority embeddings to reduce predicted scores.- Example injection/backdoor: insert synthetic examples that push decision boundary to favor majority, or add a trigger that causes “fair-looking” outcomes when evaluated on clean validation.- Distribution shift via sampling bias: poison training sampling metadata so minority examples are underrepresented during retraining.Detection strategies:- Data provenance & lineage: log source, timestamps, collection method; flag sudden changes in source mix or volume.- Statistical monitors: track per-group distributions (features, label rates) and higher-order moments over time; use change-point detection (CUSUM, KS test) to flag abrupt shifts.- Model-centric monitors: compute per-group performance (TPR/FPR/precision/utility) on held-out, gold-standard validation and production slices. Look for divergence: fairness metric improves while per-group utility drops.- Influence and attribution: run influence functions or Shapley-value approximations on suspicious examples to find high-impact outliers.- Unsupervised anomaly detection on feature embeddings to find injected synthetic clusters.Robust training techniques:- Robust loss and reweighting: use sample weighting with adversarial validation—downweight examples with anomalous influence or provenance risk.- Certified defenses: data sanitization (RANSAC-like outlier removal), and median-of-means or trimmed loss to reduce effect of poisoned subsets.- Differentially-private SGD and gradient clipping limit single-example influence (helps poisoning resistance).- Adversarial training for fairness: train a model and an adversary that tries to manipulate fairness metrics; optimize for worst-case fairness gap across plausible perturbations.- Ensemble and cross-validation across disjoint shards (reduces impact of concentrated poisoning).Operational policies:- Strict ingestion controls: authenticated sources, quotas per source, schema validation, and cryptographic signing where possible.- Canary datasets: maintain immutable, gold-standard validation sets (representative of minority groups) kept offline for integrity checks before deploy.- Staged deployment: shadow testing, A/B testing with per-group metrics before full rollout.- Incident response playbook: rollback criteria (e.g., sudden per-group utility drop despite parity), forensics steps, and retraining from clean checkpoints.- Governance: periodic adversarial red-team exercises, access controls for data modification, and required fairness/security sign-off for model changes.Metrics and KPIs:- Monitor both fairness metrics (parity gaps) and per-group utility (TPR, precision) with alert thresholds; track provenance-risk score and influence concentration metrics (e.g., fraction of loss attributable to top-k examples).This layered approach—detect unusual data patterns, limit single-example influence, train for worst-case fairness, and enforce operational guards—reduces the risk that an attacker can manufacture apparent parity while degrading minority utility in production.
MediumSystem Design
66 practiced
Design a pre-deployment bias testing suite for classification models used in multiple countries. Describe test types (unit, integration, statistical), a small set of required fairness metrics to compute, minimum sample sizes and significance tests, synthetic or adversarial tests to include, and how you would gate a release based on the results.
Sample Answer
Requirements & constraints:- Multi-country models must meet accuracy and fairness per country and protected groups.- Fast pre-deploy checks integrated into CI/CD and a slower full-suite gating step.High-level architecture:- Test runner (unit & integration suites) triggered in CI- Metrics service (compute/store per-country, per-group)- Statistical engine (power analysis, bootstrap, permutation tests)- Synthetic/adversarial generator- Dashboard + gating policy enforcerTest types1. Unit tests:- Model I/O, feature schema, missing-value handling, deterministic preprocessing- Small synthetic checks: known inputs -> expected logits/probabilities2. Integration tests:- End-to-end inference on representative country slices; latencies; data-contract validation3. Statistical tests (pre-deploy):- Compute performance/fairness metrics per country/group- Significance testing vs. production baseline using bootstrapped CIs and permutation testsRequired fairness & performance metrics (per country & group):- Accuracy / Balanced Accuracy- AUC-ROC by group- Demographic parity difference (P(pred=1|group)-P(pred=1|baseline))- Equalized odds difference (difference in TPR and FPR)- Calibration-in-group (Brier score or calibration slope)Minimum sample sizes & tests- Use two-proportion power calculation for parity/TPR differences. Example: to detect delta=0.05 with alpha=0.05, power=0.8, p≈0.5 ⇒ ~1,600 examples per group. If base rates are lower/higher, compute formally: n ≈ (Z_{α/2}+Z_{β})^2 * (p1(1-p1)+p2(1-p2)) / delta^2- For continuous metrics (AUC), bootstrap CI with ≥1,000 resamples; require non-overlap with unacceptable thresholds or use permutation test to compare to baseline.- If a country/group lacks n_min, mark results as underpowered and require manual review or holdout larger validation.Synthetic & adversarial tests- Counterfactuals: flip sensitive attribute (where plausible) and check prediction changes (sensitivity).- Perturbation tests: realistic noise (OCR errors, accents, time-zone formats, currency formats) per country.- Adversarial inputs: small perturbations to numeric/text features to find instability.- Distribution shift simulation: sample covariate shifts matching historical worst-case country shifts.Gating policy (example)- Hard gates: - No critical unit/integration test failures. - For each country: performance >= baseline - guardrail_margin and fairness metrics within thresholds (e.g., demographic parity diff ≤ 0.05, TPR diff ≤ 0.05). - Minimum sample size satisfied or explicit waiver.- Soft gates: - Warnings when metrics degrade but within acceptable risk; require stakeholder sign-off (PM/Legal/Compliance) and canary rollout.- Release strategy: - If pass: deploy to canary 1-5% users in country for 24–72h; monitor live metrics and alert on drift. - If fail: block deployment, trigger automatic rollback and require remediation + re-test.Operational notes- Automate power calculations per-run and flag underpowered group results.- Store all metric distributions, test artifacts, and counterfactual traces for audit.- Periodically re-run tests with fresh data and retrain thresholds as populations and business tolerance change.This design balances automated, statistically rigorous pre-deploy checks with human oversight and staged release to manage multi-country fairness risk.
MediumTechnical
56 practiced
Write Python code that computes bootstrapped 95% confidence intervals for the difference in TPR between two groups. Inputs: y_true, y_pred, group labels, number of bootstrap samples. Your solution should return the empirical lower and upper percentiles for the TPR difference and handle class imbalance gracefully.
Sample Answer
Approach: compute TPR per group = TP / P (positives) and estimate distribution of TPR difference (groupA - groupB) via stratified bootstrap. To handle class imbalance, resample positives and negatives separately (preserves the number of positives so bootstraps have enough positive examples). Return empirical 2.5 and 97.5 percentiles.Key points:- Stratified resampling by label preserves positive count and mitigates imbalance issues.- Time complexity: O(B * n) where B = n_bootstrap and n = dataset size.- Edge cases: groups must be two-valued; if a group has zero positives, TPR is undefined; bootstrap samples with zero positives are filtered out.- Alternatives: balanced bootstrap per-group, paired bootstrap, or BCa adjustment for bias-correction.
python
import numpy as np
def bootstrap_tpr_diff(y_true, y_pred, groups, n_bootstrap=1000, seed=None, alpha=0.05):
"""
Compute bootstrapped (1-alpha) CI for difference in TPR between two groups.
Inputs:
y_true: array-like of 0/1 true labels
y_pred: array-like of 0/1 predicted labels
groups: array-like of two-group labels (e.g., "A"/"B" or 0/1)
n_bootstrap: number of bootstrap samples
seed: random seed
alpha: significance level (default 0.05 -> 95% CI)
Returns:
(lower_percentile, upper_percentile, diffs_array)
"""
rng = np.random.default_rng(seed)
y_true = np.asarray(y_true)
y_pred = np.asarray(y_pred)
groups = np.asarray(groups)
if not (len(y_true) == len(y_pred) == len(groups)):
raise ValueError("Inputs must have the same length")
unique_groups = np.unique(groups)
if unique_groups.size != 2:
raise ValueError("groups must contain exactly two unique values")
g0, g1 = unique_groups
# Indices by group and label for stratified resampling
pos_idx = np.where(y_true == 1)[0]
neg_idx = np.where(y_true == 0)[0]
pos_by_group = {g: np.where((y_true == 1) & (groups == g))[0] for g in unique_groups}
neg_by_group = {g: np.where((y_true == 0) & (groups == g))[0] for g in unique_groups}
# If any group has zero positives, TPR undefined -> handle by returning NaNs
if pos_by_group[g0].size == 0 or pos_by_group[g1].size == 0:
raise ValueError("At least one group has zero positive (label=1) examples; TPR undefined.")
diffs = np.empty(n_bootstrap)
n_pos = pos_idx.size
n_neg = neg_idx.size
for i in range(n_bootstrap):
# Stratified bootstrap: sample positives and negatives with replacement,
# preserving counts to avoid losing rare class.
sampled_pos = rng.choice(pos_idx, size=n_pos, replace=True)
sampled_neg = rng.choice(neg_idx, size=n_neg, replace=True)
sampled_idx = np.concatenate([sampled_pos, sampled_neg])
# Compute TPR per group on the bootstrap sample
def tpr_for_group(g):
idx = sampled_idx[groups[sampled_idx] == g]
if idx.size == 0:
return np.nan
positives = idx[y_true[idx] == 1]
# If no positives in this group's sampled indices, TPR undefined -> NaN
if positives.size == 0:
return np.nan
tp = np.sum(y_pred[positives] == 1)
return tp / positives.size
t0 = tpr_for_group(g0)
t1 = tpr_for_group(g1)
diffs[i] = t0 - t1
# Remove NaNs that may occur rarely if a bootstrap sample had zero positives for a group
diffs = diffs[~np.isnan(diffs)]
if diffs.size == 0:
raise RuntimeError("All bootstrap samples produced undefined TPRs; increase sample size or check labels.")
lower = np.percentile(diffs, 100 * (alpha / 2))
upper = np.percentile(diffs, 100 * (1 - alpha / 2))
return lower, upper, diffsUnlock Full Question Bank
Get access to hundreds of Fairness, Bias Mitigation, and Responsible AI in Production interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.