Senior Business Model Validation Analyst (BI)

Chất lượng dữ liệu cần được kiểm tra tự động ở từng lớp và có người chịu trách nhiệm, không chỉ phát hiện khi dashboard sai.

• Test trong pipeline: not null, unique, giá trị hợp lệ, quan hệ khoá ngoại (dbt tests, Great Expectations).
• Giám sát: độ tươi (dữ liệu có cập nhật đúng giờ), số dòng bất thường, phân phối giá trị thay đổi đột ngột.
• Data contract với team nguồn: schema và ý nghĩa cột, thay đổi phải báo trước.
• Lỗi nghiêm trọng thì dừng pipeline, không đẩy dữ liệu sai xuống báo cáo.
• Lineage để biết lỗi ở nguồn ảnh hưởng tới bảng và dashboard nào.

Người phỏng vấn muốn nghe: ví dụ cụ thể bạn từng phát hiện và xử lý một lỗi dữ liệu.

Chỉ chọn streaming khi nghiệp vụ thật sự cần độ trễ thấp (phát hiện gian lận, cảnh báo, cá nhân hoá tức thời); còn báo cáo theo giờ/ngày thì batch hoặc micro-batch rẻ và dễ vận hành hơn.

Lưu ý khi làm streaming (Kafka, Flink, Spark Structured Streaming):

• Ngữ nghĩa giao nhận: at-least-once phổ biến, cần sink idempotent để tránh trùng.
• Event time và watermark để xử lý sự kiện đến trễ, sai thứ tự.
• Quản lý state và checkpoint để khôi phục khi lỗi.
• Thay đổi schema có kiểm soát (schema registry).
• Giám sát consumer lag.

Người phỏng vấn muốn nghe: cân nhắc chi phí vận hành, không chọn streaming chỉ vì "hiện đại".

Không kết luận chỉ vì con số cao hơn; cần kiểm tra thiết kế thí nghiệm và ý nghĩa thống kê.

• Chỉ số chính và cỡ mẫu phải được định trước; không nhìn kết quả liên tục rồi dừng khi thấy đẹp (peeking).
• Kiểm tra sample ratio mismatch: tỷ lệ chia nhóm thực tế có khớp thiết kế không.
• Xem khoảng tin cậy và p-value, không chỉ chênh lệch trung bình.
• Chạy đủ chu kỳ (ít nhất trọn tuần) để tránh hiệu ứng ngày trong tuần, hiệu ứng mới lạ.
• Kiểm tra chỉ số bảo vệ (guardrail): doanh thu, tỷ lệ huỷ, tốc độ trang.
• Cẩn thận khi cắt quá nhiều phân khúc: dễ có kết quả "có ý nghĩa" do ngẫu nhiên.

Người phỏng vấn muốn nghe: phân biệt ý nghĩa thống kê với ý nghĩa kinh doanh.

Đo trước, tối ưu chỗ tốn nhất trước. Phần lớn trường hợp nút thắt là DB và gọi mạng, không phải tốc độ của Python.

1. Đo: APM hoặc tracing (OpenTelemetry) để biết thời gian nằm ở DB, API ngoài hay code. Profile bằng py-spy (gắn vào process đang chạy) hoặc cProfile.
2. DB: xử lý N+1, thêm index phù hợp, chỉ lấy cột cần (only, values), phân trang.
3. Cache: Redis cho dữ liệu đọc nhiều, ít đổi; nhớ chiến lược invalidate.
4. Việc nặng hoặc không cần trả ngay (gửi email, xuất file): đẩy sang Celery hoặc queue.
5. Gọi nhiều API ngoài: chạy song song, đặt timeout.
6. Cuối cùng mới tới tối ưu thuật toán, hoặc đưa đoạn nặng CPU sang thư viện C hay service khác.

Hay sai: viết lại sang async hoặc đổi ngôn ngữ trước khi biết thời gian thực sự bị tiêu ở đâu.

Python linh hoạt nên dự án lớn dễ rối; cần công cụ để bắt lỗi trước khi chạy.

• Type hints + type checker (mypy hoặc pyright) chạy trong CI. Dùng Protocol cho interface, TypedDict hoặc dataclass thay cho dict tự do.
• Validate dữ liệu ở biên (request, config, message) bằng Pydantic; bên trong tin vào kiểu đã kiểm.
• Dependency: môi trường ảo riêng, file lock để build tái lập được (uv, Poetry hoặc pip-tools). Tách dependency dev và production.
• Lint/format tự động: ruff thay cho nhiều công cụ cũ; chạy qua pre-commit và CI.
• Cấu trúc: chia theo domain, tách logic nghiệp vụ khỏi framework để test không cần DB hay HTTP.
• Test bằng pytest với fixture; test tích hợp cho các luồng chính.

Người phỏng vấn muốn nghe: bạn hiểu type hints không kiểm tra lúc runtime, nên vẫn cần validate dữ liệu đầu vào.

Star schema là mô hình dữ liệu cho phân tích: một bảng fact ở giữa nối với nhiều bảng dimension xung quanh, giúp truy vấn đơn giản và nhanh.

• Fact: ghi các sự kiện đo đếm được (đơn hàng, lượt xem), chứa số đo (số tiền, số lượng) và khoá ngoại tới dimension. Thường rất nhiều dòng.
• Dimension: mô tả ngữ cảnh (khách hàng, sản phẩm, ngày, cửa hàng), ít dòng, nhiều cột thuộc tính.
• Phải xác định rõ grain: mỗi dòng fact là gì (một đơn hay một dòng sản phẩm trong đơn).

Hay sai: trộn nhiều grain trong một bảng fact, dẫn đến cộng trùng khi tổng hợp.

SCD là cách xử lý khi thuộc tính của dimension thay đổi theo thời gian, ví dụ khách hàng chuyển thành phố hoặc đổi hạng thành viên.

• Type 1: ghi đè giá trị cũ. Đơn giản nhưng mất lịch sử; báo cáo quá khứ hiển thị theo giá trị mới.
• Type 2: thêm dòng mới cho mỗi thay đổi, kèm valid_from, valid_to, is_current và surrogate key. Giữ được lịch sử, fact trỏ đúng phiên bản tại thời điểm phát sinh.

Chọn Type 2 khi nghiệp vụ cần phân tích theo trạng thái lúc xảy ra (doanh thu theo hạng khách hàng lúc mua).

Hay sai: join fact với dimension Type 2 mà quên điều kiện thời gian hoặc is_current, làm nhân bản dòng.

Vài task chậm hơn hẳn phần còn lại thường là data skew: một khoá chiếm phần lớn dữ liệu, dồn vào một partition.

Chẩn đoán qua Spark UI: xem stage chậm, so sánh thời gian và dung lượng shuffle giữa các task, có spill ra đĩa không.

Cách xử lý:

• Bật Adaptive Query Execution (mặc định bật ở Spark 3.2+) để tự tách partition bị lệch.
• Broadcast bảng nhỏ khi join để tránh shuffle.
• Thêm salt vào khoá nóng rồi gộp lại.
• Lọc dữ liệu và chọn cột sớm, tránh collect() về driver.
• Điều chỉnh số partition; xử lý vấn đề quá nhiều file nhỏ.

Người phỏng vấn muốn nghe: đo bằng Spark UI trước, không tăng tài nguyên một cách mù quáng.

Decorator là hàm nhận một hàm và trả về hàm mới bọc quanh nó. @timer chỉ là cú pháp ngắn của func = timer(func).

import functools, time

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        try:
            return func(*args, **kwargs)
        finally:
            print(func.__name__, time.perf_counter() - start)
    return wrapper

• functools.wraps giữ lại __name__, docstring của hàm gốc, quan trọng cho log và debug.
• Decorator có tham số (ví dụ @retry(times=3)) cần thêm một lớp hàm bên ngoài.
• Ví dụ thực tế: @app.get của FastAPI, @login_required của Django, @functools.lru_cache.

Hay sai: decorator viết kiểu đồng bộ bọc hàm async def. Kết quả là đo thời gian tạo coroutine chứ không phải thời gian chạy.

Tìm hiểu trước mặt bằng lương cho vị trí và số năm kinh nghiệm (dữ liệu lương trên Drama Công Ty, bạn bè cùng ngành), rồi đưa ra một khoảng có căn cứ.

• Nói rõ gross hay net. Gross là lương trước khi trừ bảo hiểm bắt buộc và thuế thu nhập cá nhân; net là số thực nhận.
• Hỏi tổng thu nhập: lương tháng 13 (không bắt buộc theo luật), thưởng, chu kỳ review lương, bảo hiểm sức khoẻ.
• Lương thử việc theo luật tối thiểu bằng 85% lương chính thức; nhiều công ty trả 100%, cứ hỏi rõ.

Câu mẫu: "Dựa trên kinh nghiệm và mặt bằng thị trường, em mong muốn khoảng X đến Y triệu gross. Em cũng muốn hiểu thêm về thưởng và review lương bên mình."

Hay sai: nói "tuỳ công ty" (dễ bị trả thấp), hoặc khai khống lương hiện tại.