Câu hỏi Phỏng vấn DS

Q1. p-value là gì? p = 0.03 nghĩa là gì?

Là xác suất quan sát được kết quả (hoặc cực đoan hơn) nếu giả thuyết H0 đúng. p = 0.03 nghĩa là: giả sử H0 đúng, chỉ có 3% khả năng thu được dữ liệu cực đoan như vậy — thường ⇒ bác bỏ H0 ở mức α = 0.05. Lưu ý: p-value KHÔNG phải xác suất H0 đúng, và không đo độ lớn hiệu ứng.

Q2. Định lý giới hạn trung tâm (CLT)?

Khi cỡ mẫu đủ lớn (thường n ≥ 30), phân phối của trung bình mẫu tiệm cận phân phối chuẩn, bất kể phân phối gốc — với mean = mean tổng thể và độ lệch chuẩn = σ/√n. Đây là nền tảng cho hầu hết kiểm định & khoảng tin cậy.

Q3. Sai lầm loại I và loại II?

Type I (dương tính giả): bác bỏ H0 khi H0 đúng — xác suất = α. Type II (âm tính giả): không bác bỏ H0 khi H0 sai — xác suất = β; power = 1 − β. Giảm α thường làm tăng β; cân bằng tuỳ chi phí sai lầm nào tệ hơn (vd chẩn đoán ung thư sợ Type II).

Q4. Khoảng tin cậy 95% nghĩa là gì?

Nếu lặp lại thí nghiệm nhiều lần và tính CI mỗi lần, khoảng 95% số khoảng đó sẽ chứa giá trị thật của tham số. KHÔNG phải "có 95% xác suất giá trị thật nằm trong khoảng cụ thể này" (giải thích Bayesian, khác).

Q5. Định lý Bayes & ứng dụng?

P(A|B) = P(B|A)·P(A) / P(B). Cập nhật niềm tin (prior → posterior) khi có bằng chứng mới. Kinh điển: bài toán xét nghiệm — bệnh hiếm (prior thấp) khiến ngay cả xét nghiệm chính xác cao vẫn cho nhiều dương tính giả. Nền tảng của Naive Bayes classifier.

Q6. Thiết kế & đọc kết quả một A/B test?

Xác định metric & H0/H1 → tính cỡ mẫu (dựa trên MDE, power 80%, α 5%) → random assignment → chạy đủ thời gian (tránh peeking sớm, tính cả tính chu kỳ theo tuần) → kiểm định (t-test/z-test tỉ lệ) → xét cả ý nghĩa thống kê lẫn ý nghĩa thực tiễn. Coi chừng novelty effect và multiple testing.

Q7. Correlation vs Causation?

Tương quan chỉ nói hai biến biến thiên cùng nhau; không suy ra nhân quả vì có thể do biến gây nhiễu (confounder) hoặc trùng hợp. Muốn khẳng định nhân quả cần thí nghiệm ngẫu nhiên (RCT) hoặc phương pháp causal inference (IV, diff-in-diff, DAG).

Q8. Type I/II đánh đổi & các phân phối hay dùng?

Nắm được: Chuẩn (đối xứng, CLT), Nhị thức (số lần thành công), Poisson (số sự kiện/đơn vị thời gian), Mũ (thời gian giữa các sự kiện), Đều. Biết khi nào dùng t-test (n nhỏ, chưa biết σ) vs z-test (n lớn/biết σ), chi-square (biến phân loại), ANOVA (so >2 nhóm).

Q1. Tìm mức lương cao thứ nhì (second highest salary).

-- Cách dùng subquery: an toàn khi có trùng lặp
SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

-- Cách dùng window function (linh hoạt cho hạng N bất kỳ)
SELECT DISTINCT salary
FROM (
  SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
  FROM employees
) t
WHERE rnk = 2;

Q2. Top-N mỗi nhóm (top 3 sản phẩm bán chạy theo từng category).

SELECT category, product, revenue
FROM (
  SELECT category, product, revenue,
         ROW_NUMBER() OVER (
             PARTITION BY category
             ORDER BY revenue DESC) AS rn
  FROM sales
) t
WHERE rn <= 3;
-- ROW_NUMBER: hạng duy nhất | RANK: nhảy số khi bằng | DENSE_RANK: không nhảy

Q3. Khử trùng lặp (dedupe) — giữ 1 bản ghi mỗi email, mới nhất.

WITH ranked AS (
  SELECT *, ROW_NUMBER() OVER (
             PARTITION BY email
             ORDER BY created_at DESC) AS rn
  FROM users
)
SELECT * FROM ranked WHERE rn = 1;

Q4. Đếm số user hoạt động mỗi ngày & tỉ lệ giữ chân (retention) đơn giản.

-- DAU theo ngày
SELECT event_date, COUNT(DISTINCT user_id) AS dau
FROM events
GROUP BY event_date
ORDER BY event_date;

-- Self-join tìm user quay lại đúng ngày hôm sau
SELECT a.event_date,
       COUNT(DISTINCT b.user_id) * 1.0
         / COUNT(DISTINCT a.user_id) AS next_day_retention
FROM events a
LEFT JOIN events b
  ON a.user_id = b.user_id
 AND b.event_date = a.event_date + INTERVAL '1 day'
GROUP BY a.event_date;

Q5. INNER vs LEFT JOIN & bẫy với NULL/aggregate?

INNER chỉ giữ dòng khớp cả hai bảng; LEFT giữ toàn bộ bảng trái, phần không khớp bên phải là NULL. Bẫy hay gặp: COUNT(col) bỏ qua NULL (dùng COUNT(*) nếu muốn đếm cả dòng); lọc bảng phải trong WHERE sẽ vô hiệu hoá LEFT JOIN (phải đặt điều kiện trong ON). Nhớ WHERE lọc trước khi group, HAVING lọc sau aggregate.

Q6. Python/pandas: doanh thu trung bình theo nhóm & lọc.

import pandas as pd

# Doanh thu TB mỗi category, chỉ giữ category có > 100 đơn
g = (df.groupby("category")
       .agg(avg_rev=("revenue", "mean"),
            n_orders=("order_id", "count"))
       .reset_index())
g = g[g["n_orders"] > 100].sort_values("avg_rev", ascending=False)

# Đếm trùng & khử trùng lặp giữ bản ghi mới nhất
df = (df.sort_values("created_at")
        .drop_duplicates(subset="email", keep="last"))

# Fizzbuzz kiểu phỏng vấn nhanh
for i in range(1, 16):
    print("FizzBuzz" if i%15==0 else
          "Fizz" if i%3==0 else
          "Buzz" if i%5==0 else i)

Câu case study kiểm tra tư duy sản phẩm & hệ thống chứ không phải một đáp án đúng duy nhất. Luôn nghĩ thành tiếng theo khung dưới đây, và hỏi lại trước khi lao vào giải:

• Clarify: làm rõ mục tiêu nghiệp vụ, ràng buộc, ai dùng kết quả, định nghĩa chính xác (vd "churn" là gì).
• Metric: chọn metric nghiệp vụ & metric mô hình phù hợp; nghĩ tới đánh đổi precision/recall theo chi phí.
• Data: cần dữ liệu gì, lấy ở đâu, nhãn thế nào, rủi ro leakage & sẵn có lúc dự đoán không.
• Model: baseline đơn giản trước → mô hình phức tạp hơn; feature engineering; xử lý imbalance.
• Validate: chia dữ liệu đúng (theo thời gian nếu cần), offline metric, rồi A/B test online.
• Deploy: batch hay real-time? tích hợp vào quy trình nghiệp vụ (gửi cho team nào, hành động gì).
• Monitor: theo dõi drift & performance, kế hoạch retrain, vòng phản hồi.

Ví dụ 1 — Dự đoán khách hàng rời bỏ (Churn):

Clarify: churn = không hoạt động 30 ngày hay huỷ gói? Metric: recall cao để không bỏ sót khách sắp rời, nhưng cân với ngân sách chăm sóc ⇒ tối ưu theo lợi nhuận giữ chân. Data: hành vi sử dụng, tần suất, tickets hỗ trợ, thanh toán; nhãn từ lịch sử. Model: baseline logistic → gradient boosting; feature xu hướng giảm sử dụng. Validate: tách theo thời gian, sau đó thử nghiệm chiến dịch giữ chân trên nhóm nguy cơ cao vs nhóm đối chứng. Deploy: batch scoring hằng tuần, đẩy danh sách nguy cơ cao cho team CSKH. Monitor: theo dõi tỉ lệ churn thực tế của nhóm được can thiệp.

Ví dụ 2 — Phát hiện gian lận giao dịch (Fraud):

Clarify: chặn tức thời hay gắn cờ để review? Metric: cực mất cân bằng ⇒ PR-AUC, và cân recall (bắt gian lận) với precision (tránh phiền khách thật); tính chi phí mỗi loại lỗi. Data: đặc trưng giao dịch, hành vi lịch sử, thiết bị/vị trí; nhãn trễ (chargeback đến sau). Model: gradient boosting + rule engine; anomaly detection cho mẫu mới. Validate: đánh giá theo thời gian, chú ý feedback loop. Deploy: real-time API độ trễ mili-giây trong luồng thanh toán. Monitor: concept drift mạnh vì kẻ gian đổi chiêu ⇒ retrain thường xuyên, theo dõi tỉ lệ chặn nhầm.

Ví dụ 3 — Hệ gợi ý (Recommendation):

Clarify: tối ưu click, thời gian xem hay doanh thu? Metric: offline dùng Precision@K/NDCG, online dùng CTR/engagement qua A/B test. Data: tương tác user-item ngầm (view/click/mua), thuộc tính item; lưu ý cold-start. Model: baseline popularity → collaborative filtering/matrix factorization → mô hình lai (two-tower) kèm content. Validate: chia theo thời gian, chú ý bias phản hồi. Deploy: tính candidate offline + rerank online. Monitor: đa dạng & filter bubble, novelty, drift theo mùa.

Câu hành vi đánh giá cách bạn làm việc, xử lý xung đột & thất bại. Trả lời theo STAR: Situation (bối cảnh) → Task (nhiệm vụ/mục tiêu) → Action (bạn đã làm gì, cụ thể) → Result (kết quả, có số liệu). Tập trung vào "tôi" đã làm gì, kết thúc bằng bài học.