Buổi nói chuyện với Engineering Director —
nơi họ kiểm tra bạn có dám gánh bài toán không.
Engineering Director (có nền product) không hỏi “framework là gì”. Họ soi: bạn define vấn đề rõ tới đâu, ra trade-off dưới ràng buộc kỹ thuật thế nào, và liệu họ có thể tin tưởng giao một mảng product cho bạn. Đúng tinh thần anh Đạt: CV đẹp chỉ qua HR — vòng trong người ta tìm người gánh được cái mớ bòng bong hằng ngày của sản phẩm, không phải thợ viết spec.
4 nguyên tắc cầm theo, không phải 140 câu thuộc lòng
Anh Đạt nói rõ: thuộc lòng đáp án thì interviewer chỉ twist một dữ kiện là đứng hình. Cầm theo cách nghĩ, không phải kịch bản.
1 · Đi thẳng trọng tâm
Đừng mở màn bằng 5 phút lý thuyết framework. Nói trong 2 câu: vấn đề thật là gì → hướng mình chọn → vì sao. Framework là cái xương ẩn bên dưới, không phải thứ đem ra khoe.
2 · Debug có cấu trúc
Mọi câu “metric tụt X%” → Confirm data → Segment → Check deploy → Tìm điểm drop → mới giả thuyết. Không nhảy thẳng vào solution.
3 · Dịch mọi con số ra business
CVR 15→26% không phải “tăng 11 điểm” — mà là “mỗi đồng acquisition đẻ ra gần gấp đôi paid user”. Eng Director nghe được điều đó là tin bạn hiểu tiền.
4 · Hỏi ngược là bắt buộc
Phỏng vấn là 2 chiều. Bạn đang lọc xem Spartan có để PM thật sự quyết định không — hay chỉ là order-taker. Cầm sẵn 3 câu (mục 05).
“Cho em xin 10 giây nghĩ cho có cấu trúc.” → Trả lời sai mà giải thích được vì sao mình nghĩ thế vẫn ăn điểm. Trả lời ẩu, thiếu logic mới kéo tụt mọi điểm tốt trước đó.
6 câu họ gần như chắc chắn soi
Mỗi câu: dẫn bằng một story Diaflow thật, đóng bằng trade-off và business. Đây là sân nhà của bạn.
Mình không cãi “được hay không”, mình hỏi cái gì làm nó khó. Ở Diaflow mình rút ra 4 non-negotiable khi handoff spec → cắt thời gian spec-to-dev đi một nửa. Vì khi engineer thấy mình đã nghĩ tới edge case và ràng buộc kỹ thuật trước, cuộc nói chuyện chuyển từ “từ chối” sang “cùng scope lại”.
Đóng bằng trade-offMình cắt scope, không cắt quality. Ship must-have trong sprint, ghi rõ cái gì hoãn và vì sao, để cả PM lẫn eng cùng đồng ý — không phải mình áp.
Mình define tiêu chí, engineer chọn cách implement. RAG cho THACO: mình set ngưỡng hallucination <5% và mục tiêu cắt ~70% thời gian tra cứu, rồi cùng team đánh giá LightRAG vs baseline về multi-hop retrieval và chi phí vector lookup. Mình không pretend mình code, nhưng mình hiểu đủ trade-off để cuộc trao đổi có chất.
Vì sao quan trọng với Spartan~70% portfolio Spartan là LLM. CTO kiểu Stanford-PhD (ResiQuant) sẽ probe RAG trade-off. Story này có độ sâu để đứng vững.
Không ai bảo mình động vào trial flow. Mình soi PostHog funnel, thấy CVR kẹt ~15% và time-to-convert ~23h. Mình tự giả thuyết reverse trial (cho dùng full rồi mới giới hạn), chạy, ra CVR 26% và TTC còn ~13h. Self-initiated — đó là tín hiệu founder DNA mà US founder ở Spartan tìm.
- Tách must-have khỏi nice-to-have → ship MVP 2 tuần đúng lõi giá trị
- Nói rõ trade-off với cả hai phía, lấy buy-in, không chọn phe
- Không im lặng tới deadline rồi mới báo; không âm thầm giảm chất lượng
Liên hệ RBAC PRD v4.1: 27 user story / 6 epic — mình quen việc cắt lát một mảng lớn thành các lát ship được mà vẫn unblock được pipeline enterprise.
Nghe trước → đưa góc nhìn bằng data, không bằng opinion → tìm điểm chung → đề xuất một experiment nhỏ, rẻ, dễ rollback để dữ liệu phân xử → document quyết định. Mình không override tech lead mà không giải thích vì sao.
Đồng ý là cost-of-building về gần 0 → bottleneck dời sang biết cái gì đáng build (đúng luận điểm Tommy Ng). AI làm prototype trong vài ngày, nhưng vẫn cần người chọn đúng user, đúng pain, đúng thứ tự horizon. Đó là lý do mình là Designer-Operator: đi từ Figma → discovery → brief eng → ship → đo, thường một mình. Mình là loại PM ít đi mà còn lại sau AI, không phải loại làm-theo-quy-trình.
“Thiết kế tính năng abc thế nào” — đi qua 7 phase, không nhảy thẳng vào feature
Đây là phần dễ rớt điểm nhất. Nguyên tắc Tommy Ng: đáp án Bottom 80% thay tên công ty nào cũng đúng; đáp án Top 10% có một insight mà chỉ sản phẩm/ user này mới có. Dưới đây là 2 walkthrough đầy đủ trên chính sản phẩm của Spartan.
Walkthrough A — “Tăng retention cho DietFit” (product improvement)
DietFit = AI đếm calo/macro qua ảnh, barcode, hoặc giọng nói trong 1.4s. Đây là sản phẩm Spartan tự build → trả lời câu này = bạn đã đọc product của họ.
Phase 1 · Clarify — câu hỏi nào thật sự đổi hướng?
Đừng hỏi cho có. Hỏi đúng cái mà câu trả lời khác sẽ đổi việc mình build: “Retention đang gãy ở đâu — tuần 1 (novelty hết) hay tuần 3 (khi user thấy con số thật của mình)?” và “Mình giữ người đã từng bỏ 3 app ăn kiêng khác, hay người mới hoàn toàn?”. Hai câu này phân nhánh sản phẩm.
Phase 2 · Strategic context — vì sao DietFit, vì sao bây giờ?
Cái mới của DietFit là tốc độ log 1.4s (ảnh/voice). Friction lớn nhất của mọi app dinh dưỡng là manual entry → bỏ trong tuần 1. AI ảnh vừa đủ rẻ và chính xác để giải khâu input. Window: trước khi app lớn nhúng AI photo-logging. Asset phòng thủ không phải “AI” (đang commoditize) mà là dữ liệu hành vi: framing nào khiến từng user quay lại.
Phase 3 · Choose user — segment theo động cơ, không theo demographic
Phase 4 · Real pain — xuống dưới triệu chứng
3 tầng: functional (không biết mình ăn gì) → emotional (thấy tệ khi biết) → identity (“tôi là đứa vô kỷ luật”). Mọi app giải tầng 1. Không ai chạm tầng 2–3. DietFit log nhanh 1.4s nghĩa là user log nhiều hơn → đối diện con số xấu thường xuyên hơn → nếu entry screen vẫn là “bạn vượt 600 calo” thì tốc độ log nhanh lại tăng tần suất tội lỗi.
→ Hướng đúng: màn hình đầu cho thấy một pattern tích cực có thật trước, rồi mới tới bức tranh đầy đủ.
Phase 5 · Design solutions — 3 horizon, mỗi cái nuôi cái sau
- H1 (4 tuần): “Check-in 60 giây” — tóm tắt tuần, dẫn bằng 1 điểm tích cực thật trước khi show toàn cảnh. Đồng thời test 3 kiểu framing (progress / goal / so-với-tuần-trước) và ghi lại user nào phản ứng với kiểu nào.
- H2 (sau 3 tháng data): Cá nhân hoá framing theo từng user — chỉ làm được nhờ data H1. App “biết cách nói chuyện” với từng người. New entrant copy được UI, không copy được data calibration.
- H3: Dự đoán & can thiệp đúng khoảnh khắc hành vi (gợi ý đổi món trước khi user vào chuỗi ăn-vô-độ). Đổi DietFit từ “tracker” thành “coach”.
Điểm Top 10%: H1 không phải feature lẻ — nó là training data cho H2. Đó là sequence, không phải list.
Phase 6 · Metrics
- NSM: tỉ lệ check-in tự nguyện/tuần (mở app không do notification)
- Leading: % user check-in lần 2 mà không cần nhắc
- Guardrail: điểm financial/diet-stress survey không được tăng — không đánh đổi lo âu lấy engagement
Phase 7 · Risks
- 2nd-order: engagement tăng 20% tuần 1–3 (team ăn mừng), nhưng tháng 3 nhóm chỉ xem bản tóm tắt curated lại có kết quả tệ hơn
- Mitigation: đo outcome thật vs control trước khi launch, khoá guardrail từ đầu
Walkthrough B — “Spartan build sản phẩm AI 0→1 cho US, nên build gì?” (new product)
Đây là câu Eng Director hay dùng để test 0→1 sense. Dùng LayerProof (doc lộn xộn → social post + slide) làm bàn đạp, hoặc đề xuất hướng mới. Trả lời gọn theo 4 nước cờ:
Cách đóng câu này
“Em sẽ không build ‘thêm một AI content tool’. Em build cái duy nhất biết giọng của bạn — và lợi thế đó dày lên theo thời gian dùng, không phải thứ một competitor có vốn lớn copy trong 6 tháng.” → đúng câu hỏi sống còn của Tommy Ng: “why will you win?”
Quy trình debug — học thuộc đúng thứ tự này
Câu kinh điển: “Metric X tụt 15% tuần này, bạn làm gì?”. Đừng bắn solution. Chạy đúng protocol của anh Đạt:
“Ở Diaflow em làm đúng vậy với trial flow: soi PostHog, segment cohort, xác nhận drop ở khâu activation chứ không phải acquisition → mới đặt giả thuyết reverse trial → CVR 15→26%, TTC 23h→13h.” Đây là bằng chứng bạn đã sống quy trình này, không chỉ biết nó.
Vài con số “distribution > average” cần nhớ
- Rating trung bình là artifact nén. 4.2 đồng đều khác hẳn 5-sao + 1-sao lưỡng cực — phân rã theo segment trước khi kết luận.
- D1/D7/D30: nhìn tỉ lệ giữa các mốc (đường cong có phẳng ra không) quan trọng hơn số tuyệt đối. DAU/MAU phụ thuộc category: social 50%+, utility ~20%, e-commerce 10–15% là bình thường.
- Support ticket tăng 30% chưa chắc xấu — normalize theo ticket/active user, phân loại bug vs câu hỏi vs request.
- NSM cho sản phẩm AI: chọn unit gắn với value và tiền. (Ở Diaflow bạn đã chốt
Credits Volume/week— nhắc được nếu họ hỏi về monetization-aligned metric.)
STAR, nhưng đóng bằng learning — không phải “em thắng”
Eng Director nghe behavioral để đoán bạn làm việc với team họ thế nào. Kể quan hệ, không kể chiến thắng.
Reverse Trial: business muốn giữ hard paywall sớm. Mình counter bằng data PostHog + đề xuất chạy thử có giới hạn, dễ rollback. Data prove giả thuyết → quyết định đổi. Đóng: “Điều em giữ được không chỉ là cái metric, mà là cách team tin vào việc để data phân xử thay vì cãi nhau bằng opinion.”
Chọn một case thật (vd. AppSumo: return rate ban đầu 70% — cao đau đớn). Own nó, giải thích cơ sở quyết định lúc đó, phát hiện sớm, can thiệp → kéo về 50% qua 180 ngày, $44K gross. Learning cụ thể: validate fit của LTD trước khi đổ acquisition. Tránh: “em chưa từng thất bại” hoặc đổ lỗi.
Hiểu áp lực của họ → build respect bằng việc hiểu tech đủ sâu (LightRAG, SSE streaming, WebSocket vs polling) → giải quyết 1-1 trước khi escalate. Tránh: escalate thẳng lên manager.
Điểm yếu thật: nền design-first khiến trước đây mình mạnh UX/storytelling hơn systems-thinking & business acumen. Đang đóng gap có chủ đích — chính vì vậy mình mới đào RAG architecture, NSM monetization-aligned, unit economics. Tránh điểm yếu giả (“em quá cầu toàn”).
Phần anh Đạt nhấn mạnh nhất — và Eng Director rất nể
Đây vừa là tín hiệu bạn nghiêm túc, vừa là cách bạn lọc xem Spartan có hợp mình không. Cầm sẵn 3–4 câu, chọn theo mạch nói chuyện.
Về autonomy (quan trọng nhất)
“Ở Spartan, khi embed vào một startup US, PM có quyền quyết định product tới đâu — hay phần lớn direction đến từ founder phía client?” → Lọc ngay văn hoá order-taker.
Về cách làm việc PM–Eng
“Ai define technical requirements khi embed — PM viết spec chi tiết rồi eng build, hay hai bên cùng shape từ đầu?” → Red flag nếu là cái đầu tiên.
Về client & chất lượng
“Với portfolio ~70% LLM, đâu là pattern thất bại hay gặp nhất khi embed product người vào một startup AI — và Spartan rút ra gì?” → Cho thấy bạn nghĩ ở tầng systems, và test xem họ có văn hoá growth hay đổ lỗi.
Về chính bạn sau khi vào
“Sau 6 tháng, một PM ở Spartan được đánh giá thành công dựa trên gì?” → Red flag nếu mơ hồ; tốt nếu có OKR/metric rõ.
VN-market drill — phòng khi họ test product sense generic
Giữ nguyên tinh thần bộ 140 câu của anh Đạt. Không học thuộc — chỉ chạy lại cho quen phản xạ. Mỗi câu: framework ẩn → 1 dòng hướng → bẫy.
CIRCLES. Clarify → user (ít data, feature phone) → need (gửi tiền/nhận lương) → cut → USSD fallback, QR offline, voice UI → evaluate. Bẫy: thiết kế phức tạp không hợp kết nối yếu.
Đo impact: crash ảnh hưởng bao nhiêu % user → nếu >10% thì fix trước. Bẫy: trả lời cảm tính, không gắn con số.
A/B khi: uncertainty cao, đủ traffic, feature isolatable, dễ rollback. Bẫy: luôn A/B mà không xét khi nào không cần.
“Monthly Active Transacting Users” hoặc “Transaction Value / MAU” — bắt được value đã giao + dẫn tới revenue. Bẫy: chọn MAU trần vì nó to nhất.
ARPU tăng / mix shift (giữ high-value) / đổi pricing → đào cohort revenue theo segment. Bẫy: assume ngay là vấn đề, bỏ lỡ upside.
Không nói “không” — hỏi “làm sao đạt mục tiêu của anh tốt nhất” → đề xuất giải pháp thay thế dựa trên data → nói rõ cái mình CÓ THỂ làm. Bẫy: luôn yes hoặc đối đầu.
~30M user → 20% transact = 6M → peak 1h = 6M/3600 ≈ 1.666 TPS → spike ×3 ≈ 5.000 TPS. Bẫy: không tách average vs peak. Luôn show workings.
Subsidy nặng không bền → unit economics không bao giờ chạy → đối thủ có multi-service moat. Bài học: subsidy không build loyalty, moat quan trọng hơn. Bẫy: chỉ đổ cho macro/COVID.