Delivery/Team Lead – Digitalization & Technology Enable

Tận dụng giờ làm trùng nhau cho việc cần trao đổi trực tiếp, phần còn lại làm bất đồng bộ có tài liệu.

• Thống nhất lịch họp cố định trong khung giờ trùng (daily hoặc vài buổi mỗi tuần), có agenda và biên bản.
• Câu hỏi gom lại, viết rõ ràng kèm ngữ cảnh và phương án đề xuất, để khách trả lời được ngay trong một lần.
• Báo cáo định kỳ: đã làm, sẽ làm, rủi ro, quyết định cần khách đưa ra.
• Demo cuối sprint để khách thấy sản phẩm thật; ghi hình nếu khách không tham gia được.
• Lưu ý khác biệt văn hoá: một số khách cần nói thẳng, một số cần trang trọng; chủ động báo tin xấu sớm.

Hay sai: để team chờ câu trả lời của khách cả ngày mà không có việc dự phòng.

Quản lý rủi ro là xác định sớm, đánh giá, có kế hoạch ứng phó và theo dõi liên tục.

• Lập danh sách rủi ro (risk register) ngay từ đầu: nhân sự, công nghệ mới, phụ thuộc bên thứ ba, yêu cầu chưa rõ, hạ tầng.
• Đánh giá khả năng xảy ra và mức ảnh hưởng, ưu tiên rủi ro cao.
• Chọn cách ứng phó: tránh, giảm thiểu, chuyển giao, chấp nhận; mỗi rủi ro có người chịu trách nhiệm theo dõi.
• Xem lại trong các buổi họp định kỳ, cập nhật khi tình hình thay đổi.

Ví dụ theo STAR: "API của đối tác chưa sẵn sàng (S), em cần giữ tiến độ tích hợp (T). Em đề xuất team làm mock theo tài liệu API, đồng thời hẹn mốc kiểm tra với đối tác hàng tuần (A). Khi API thật có, phần tích hợp chỉ mất vài ngày điều chỉnh (R)."

Đầu tiên là minh bạch: báo sớm, kèm nguyên nhân và phương án, không chỉ báo tin xấu.

• Đánh giá lại thực trạng: còn bao nhiêu việc, velocity thực tế, đường găng (critical path).
• Đưa các phương án với đánh đổi rõ ràng: cắt bớt phạm vi cho đợt đầu, dời mốc, bổ sung nguồn lực (lưu ý người mới cần thời gian làm quen), song song hoá một số việc.
• Đề xuất một phương án bạn khuyến nghị và lý do.
• Sau khi chốt: kế hoạch mới, mốc kiểm tra gần hơn, báo cáo thường xuyên hơn để lấy lại niềm tin.
• Tìm nguyên nhân gốc để không lặp lại.

Người phỏng vấn muốn nghe: bạn không giấu, không đổ lỗi cho team hay khách, và biết rằng thêm người vào dự án đang trễ thường không giúp kịp ngay.

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".

Tách lỗi theo từng khâu của pipeline, kiểm tra từ dưới lên.

1. Dữ liệu: tài liệu đã được nạp chưa, trích xuất từ PDF/bảng có bị vỡ không, có phiên bản cũ mâu thuẫn không.
2. Chunking: thông tin cần thiết có bị cắt đôi giữa hai chunk không.
3. Truy xuất: log các chunk lấy về cho câu hỏi đó; đúng chunk có nằm trong top-k không. Thử hybrid search, rerank, viết lại câu hỏi.
4. Sinh: chunk đúng đã có trong prompt mà vẫn sai thì xem prompt, thứ tự đặt ngữ cảnh, quá nhiều ngữ cảnh nhiễu.
5. Thêm ca này vào bộ eval để tránh tái diễn.

Người phỏng vấn muốn nghe: có tracing để xem từng bước, không đoán mò.

Không chỉ "đúng hạn, đúng ngân sách", mà còn giá trị mang lại và sức khoẻ của team.

• Dự án: tiến độ theo mốc, chi phí so với ngân sách, phạm vi bàn giao, chất lượng (bug sau release, số lần hotfix), mức hài lòng của khách hàng.
• Sản phẩm: chỉ số gắn với mục tiêu như người dùng hoạt động, tỷ lệ chuyển đổi, tỷ lệ giữ chân, doanh thu, chi phí vận hành giảm.
• Team: tốc độ ổn định, ít OT kéo dài, tỷ lệ nghỉ việc thấp, retrospective có cải tiến thật.

Ví dụ: "Dự án trước bàn giao trễ hai tuần so với kế hoạch ban đầu nhưng khách đã đồng ý từ sớm vì đổi phạm vi; sau go-live ít lỗi nghiêm trọng và khách ký tiếp giai đoạn 2. Em coi đó là thành công."

Hay sai: chỉ nói về output (số tính năng) mà không nói outcome.

Phát hiện sớm, nói thật sớm, và chọn phương án cùng team và PO.

• Tìm nguyên nhân: estimate sai, phát sinh việc ngoài kế hoạch, bị block bởi bên khác, có người nghỉ.
• Gỡ block trước: liên hệ team khác, khách hàng, xin môi trường, quyết định nhanh các điểm chờ.
• Cùng PO thương lượng phạm vi: giữ những gì quan trọng nhất cho sprint goal, đẩy phần còn lại sang sprint sau.
• Thông báo cho stakeholder kèm kế hoạch mới, không đợi tới ngày review.
• Retrospective: tìm nguyên nhân gốc để điều chỉnh planning lần sau.

Hay sai: bắt team OT để kịp mà không đổi gì về phạm vi. Làm một lần có thể được, nhưng lặp lại thì chất lượng giảm và người giỏi sẽ nghỉ.

"Yes, for the last two years I've worked with a client in Europe, so we only had about three overlapping hours a day. To make the most of that time, we kept a short daily call and I prepared questions in advance. For everything else, I wrote clear updates in Jira and Slack so they could reply when they started their day. This helped us avoid waiting a whole day for answers."

Mẹo: nhấn vào cách bạn giao tiếp chủ động và viết rõ ràng. Dùng "overlapping hours", "asynchronous communication", "I kept them updated". Tránh nói "I have worked with them since 2 years", đúng là "for two years".

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.