Project and Internship Experience Questions

Focused, personal narratives about internships, volunteer work, academic projects, or relevant personal projects that demonstrate applied skills, problem solving, and impact. Candidates should be prepared to describe two to three significant experiences using a structured format such as situation task action result, including the project scope, their specific contributions, technologies and tools used, challenges encountered, how they resolved them, and measurable outcomes or lessons learned. This includes domain specific examples such as compliance or audit related assignments, game development projects, and other role relevant work.

HardTechnical

84 practiced

You observe an unexpected large spike in a KPI. Outline an investigation plan: quick triage steps to identify if it is real or a tracking issue, data analysis techniques (segmentation, time-of-day, user cohorts), and next steps if the spike is real versus if it is a measurement error.

Sample Answer

Situation: Unexpected large KPI spike (e.g., daily conversion rate jumped 3x). Goal: quickly determine if spike is real or tracking-related, quantify drivers, and recommend actions.

Quick triage (first 30–60 minutes)- Confirm metric definition and time window (UTC vs local).- Check upstream data pipeline / ingestion errors, ETL logs, and last deployment/change log.- Validate against multiple sources: raw events, analytics db, dashboard aggregates, and third-party tags.- Run simple sanity SQL to compare counts and unique users:

sql

-- compare event counts and unique users today vs baseline
SELECT
  date(event_time) as day,
  COUNT(*) as events,
  COUNT(DISTINCT user_id) as uniques
FROM events
WHERE event_time >= current_date - interval '14' day
GROUP BY day
ORDER BY day;

Data analysis techniques (deeper, 1–4 hours)- Time series and changepoint: plot minute/hour granularity to find onset time; apply z-score or Bayesian changepoint to locate abrupt change.- Segmentation: by traffic source, country, device, app version, landing page, campaign id to isolate affected slices.- Cohorts and funnel: build user cohorts (first touch date, new vs returning) and examine funnel conversion steps to see where change originates.- Cross-metric validation: check upstream/downstream KPIs (sessions, click-throughs, revenue) for consistent signals.- Sampling and session-level inspection: pull random user sessions in the spike window and inspect events for anomalies (duplicate events, malformed payloads).

Tests and statistical checks- Compute relative lift with confidence intervals; run proportion test for conversion rates.- Check for bot/automation: sudden surge in single IPs, user agents, or unusually low session durations.

If spike is real (validated)- Identify top contributing segments and hypothesize causes (campaign, UX change, external event).- Notify stakeholders with early-findings dashboard and recommended immediate actions (monitor, scale infra if needed).- Run root-cause experiments: A/B rollback if tied to release, or attribution analysis for marketing.- Track persistence: categorize as transient vs sustained; if sustained, update forecasts and KPIs.

If measurement/tracking error- Pinpoint faulty instrument (tagging bug, duplicate processing, timezone bug).- Stop-gap: exclude affected data range from reports; add annotation to dashboards.- Fix code/ETL and reprocess/backfill clean data; validate with tests and peer review.- Implement monitoring/alerting for similar anomalies (data quality checks, cardinality checks, alerts on sudden unique count jumps).- Document incident and preventive actions.

Key outputs for stakeholders- Short executive summary (is it real? impact magnitude, top segments, recommended next steps)- Repro steps and technical root cause- Action plan with owners and timelines- Follow-up: postmortem and monitoring improvements.

HardTechnical

84 practiced

Given 30 minutes to build an executive-level dashboard for a subscription business, choose three metrics you would include and justify each choice. Explain visual format, time granularity, target audience concerns, and what alert thresholds you might set.

EasyBehavioral

62 practiced

Describe two to three significant projects or internships where you acted as a data analyst. For each, use the STAR structure (Situation, Task, Action, Result). Include: project scope, your specific contributions, tools and technologies used (SQL/Excel/Tableau/Power BI/Python/R), key challenges and how you resolved them, and measurable outcomes or lessons learned.

Sample Answer

Situation: At a mid-sized e‑commerce company I interned as a data analyst during peak season. Conversions were dipping but the product team wasn’t sure why.

Task: I needed to identify bottlenecks in the checkout funnel, quantify impact, and recommend fixes within 3 weeks so the growth team could act before holiday traffic.

Action:- Pulled event and order data from Redshift using SQL, joined with user/session tables.- Cleaned and aggregated data in Python (pandas) to compute conversion rates by step, device, and traffic source.- Built an interactive Tableau dashboard highlighting drop-off points and segmented by cohort.- Ran A/B style uplift analysis on historical experiments and used logistic regression (statsmodels) to control for confounders.- Presented findings to product and engineering with prioritized recommendations.

Result:- Identified a 12% higher drop-off on mobile payment page for users on older iOS versions.- Recommended two fixes: simplify payment form and enable alternate payment flow for that cohort.- After fixes, A/B test showed a 6.5% relative lift in conversions (projected +$150k monthly revenue).- Lesson: fast cross-team communication and focused segmentation turn data into rapid business impact.

Situation: As a data analyst on a subscription SaaS team, churn rose unexpectedly over two quarters.

Task: Diagnose drivers of churn, estimate revenue at risk, and propose retention actions within a month.

Action:- Extracted customer, usage, billing, and support ticket data with SQL; joined and modeled in Power BI for stakeholders.- Performed survival analysis in Python (lifelines) and feature importance via random forest to surface top churn predictors.- Conducted cohort analysis in Excel to validate retention trends and ran targeted segmentation for at-risk users.- Coordinated with customer success to design a targeted outreach pilot for high-risk cohorts.

Result:- Found that decreasing weekly active usage and unresolved support tickets were top predictors; customers with >3 unresolved tickets had 3× churn risk.- Proposed a playbook: proactive outreach for high-risk users and SLA improvements for support.- Pilot reduced churn in targeted cohort by 18% over 8 weeks, saving ~$40k ARR in the first quarter.- Lesson: combining statistical models with simple operational fixes yields measurable retention gains.

HardTechnical

82 practiced

How would you conduct an audit to comply with a GDPR data erasure request that affects analytics pipelines? Describe steps to locate PII across raw and derived datasets, propagate deletions, communicate with legal, and verify successful erasure without breaking reports that rely on aggregated metrics.

Sample Answer

Situation: A user submitted a GDPR “right to erasure” request that may touch our analytics pipelines (raw logs, ETL outputs, event tables, and aggregated dashboards). As the data analyst responsible for reporting correctness and compliance, I led an audit and removal plan.

Approach / Steps:1. Scope & clarify with Legal- Confirm requester identity, scope (all systems vs specific datasets), and retention vs legal hold requirements.- Agree SLA, acceptance criteria, and audit evidence (logs, screenshots).

2. Discover PII and map lineage- Query the data catalog and schema registry for fields marked PII (email, user_id, device_id, IP).- Use SQL to search sample raw tables for the identifier values (exact and hashed variants).- Inspect derived datasets: materialized views, aggregates, user cohorts, ML feature stores, BI extracts and data exports.- Build a simple lineage map: source raw table → ETL transforms → intermediate tables → dashboards.

3. Plan deletion/obfuscation strategy- Prefer true deletion for raw records if allowed; otherwise pseudonymize (irreversible hash with salt) when deletion breaks downstream integrity.- For aggregates, decide between: recalculating aggregates excluding the user, adjusting counts/sums, or applying differential privacy/noise if repeated removals would skew metrics.- Prepare backfill scripts and test environments.

4. Execute with conservatism- Run deletion/pseudonymization in staging; run full ETL/backfill to rebuild affected aggregates.- Update incremental pipelines to drop or ignore identifiers going forward (filter, join logic).- Keep immutable audit logs of all actions (who, when, SQL run, snapshots before/after).

5. Verify and provide evidence- Automated checks: run queries to assert zero rows containing the identifier across all tables; validate hash variants and joins.- Recompute key aggregates and compare to production; explain delta to stakeholders if changes occur.- Sample dashboards and run unit tests to ensure visualizations handle missing users gracefully (no crashes, null-handling).- Provide Legal with logs, queries run, snapshots, and a short report confirming compliance.

Risk mitigation / preserving reports:- Recompute aggregates rather than deleting aggregated rows that would break totals; publish deltas and note the change in report footnotes.- Use cohort-level anonymized metrics where possible so single-user deletions minimally impact KPIs.- Schedule large backfills during off-peak and run parallel verification to avoid downtime.

Outcome / Learnings:- Deliver a reproducible playbook: an updated data catalog, lineage maps, deletion scripts, and an SLA template for future GDPR requests. This balances legal compliance with integrity of aggregated business reporting.

HardTechnical

67 practiced

Describe how you would build reproducible analytical notebooks and workflows from your internship projects so they can be code-reviewed and promoted to production. Cover folder structure, dependency management, parameterization, tests, CI, and documentation.

Sample Answer

I would treat an internship notebook as a software artifact and apply reproducibility, reviewability, and deployment practices used in engineering teams.

Folder structure- repo-root/ - README.md, CONTRIBUTING.md - data/ (only pointers or sample data; no PII) - notebooks/ (nbs for exploration; lightweight) - src/ - etl/ (data cleaning functions) - analysis/ (statistical functions, plots) - utils/ - tests/ - configs/ (YAML/JSON parameter files) - docs/ (rendered notebook reports, runbook) - ci/ (CI config)

Dependency management- Pin dependencies with poetry/conda environment.yml and requirements.txt for CI.- Use Binder/venv and provide Dockerfile for exact runtime.- Use pip-tools or poetry.lock to ensure deterministic installs.

Parameterization & modularization- Refactor notebook code into functions in src/ and keep notebooks as thin orchestration layers that call those functions.- Use papermill or nbparameterise to parameterize notebooks (date range, environment).- Store parameters in configs/ and override via CLI or CI.

Testing- Unit tests for src functions (pytest), using small synthetic fixtures in tests/fixtures.- Data quality tests (great_expectations or custom asserts) to check schema, nulls, ranges.- Notebook smoke tests: execute notebooks with papermill in a temporary env to ensure run-to-completion.- Snapshot tests for key tables/figures where appropriate.

CI/CD- Git workflow: feature branches + PRs. Require code review and passing CI.- CI (GitHub Actions/GitLab CI): install env, run linting (flake8/black), run pytest, run data quality checks, execute parameterized notebooks with sample params, build docs.- On merge to main, CI can: run full notebooks with production params in a controlled runner, build artifacts (HTML reports, CSV outputs), and publish to storage or trigger deployment to reporting platforms (Tableau/Power BI refresh or Airflow DAG).

Documentation & code review- README explains purpose, run instructions, and expected outputs.- Notebook README or top cells summarize question, data sources, assumptions, and key results.- Docstrings for all functions; use Sphinx or MkDocs to auto-generate docs from src/.- Provide a CHANGELOG and runbook describing how to re-run with production credentials, data access, and rollback steps.- In PRs include a short checklist: data access, tests passing, parameterization, performance considerations, and expected artifact locations.

Why this works- Separating logic from presentation enables testability and reuse.- Pinning dependencies and providing Docker ensures reproducible environments.- CI enforces quality gates so artifacts can be promoted safely to production dashboards or pipelines.

Unlock Full Question Bank

Get access to hundreds of Project and Internship Experience interview questions and detailed answers.

Join thousands of developers preparing for their dream job.