FDE ở Notion: đọc tin tuyển dụng từng dòng và chuẩn bị một dự án để chứng minh

Bạn mở tin tuyển dụng Forward Deployed Engineer của Notion và gặp một đoạn dài: agent, integration, automation, data pipeline, migration, feedback loop. Đọc lướt thì nghe như một vai trò “làm tất cả”. Đọc kỹ thì thấy đó là ba việc riêng, mỗi việc cần một loại bằng chứng khác nhau.

Tách được ba việc đó quan trọng hơn bạn nghĩ. Một danh sách công nghệ trên CV khó trả lời được cả ba. Thứ nên có trong hồ sơ là bằng chứng rằng bạn đã từng nhận một hệ thống lộn xộn và đưa nó vào chạy thật mà không làm mất dữ liệu.

Ba việc nằm trong một chức danh

Notion tự mô tả mình là không gian làm việc AI, nơi các nhóm và agent cùng suy nghĩ. FDE là người đưa sản phẩm đó vào hệ thống thật của khách hàng.

Tin tuyển dụng cho thị trường DACH mô tả FDE trong khối Go-To-Market là người dẫn các dự án kỹ thuật phức tạp với khách hàng từ đầu đến cuối. Bản đăng tuyển cho AMER đặt vai trò này trong team Services và nhấn mạnh việc tự tay triển khai kỹ thuật.

Việc thứ nhất là xây dựng. Tin tuyển dụng yêu cầu thiết kế, xây và vận hành agent tùy biến, integration, automation và data pipeline nối Notion với hệ thống của khách hàng. Chữ “vận hành” là chi tiết đáng chú ý: viết xong rồi bàn giao là chưa đủ, bạn còn chịu trách nhiệm khi nó chạy.

Việc thứ hai là migration quy mô lớn, đi qua discovery, scoping và data modeling. Việc thứ ba dễ bị xem nhẹ nhất khi chuẩn bị: thiết kế và vận hành vòng phản hồi với Product, CX và Engineering, biến những khó khăn gặp phải khi triển khai thực tế thành việc mà các team đó có thể xử lý.

Mức yêu cầu thật sự nằm ở đâu?

Phần bắt buộc khá thực dụng. Bạn cần thành thạo ít nhất một ngôn ngữ trong số Java, JavaScript, Node.js, SQL hoặc Python. Kinh nghiệm thực tế với API và tích hợp dữ liệu lặp lại ở nhiều bản đăng tuyển theo khu vực. Kỹ năng debug được ghi rõ: tìm ra nguyên nhân gốc qua nhiều lớp, từ code đến API và quyền truy cập.

Về thâm niên, bản đăng tuyển AMER đòi 5+ năm ở vai trò làm việc với khách hàng, forward deployed hoặc một vai trò kỹ thuật trực tiếp làm tương tự; bản DACH đòi 4+ năm.

Có khu vực thêm yêu cầu ngôn ngữ: tin tuyển dụng cho Hàn Quốc cần tiếng Hàn như người bản xứ và tiếng Anh ở mức công việc, kể cả giao tiếp nói.

Notion cũng tuyển FDE Manager ở EMEA để huấn luyện một đội FDE, với yêu cầu 8+ năm.

Phần “nice-to-have” cho biết hướng đi của công ty. Bản AMER liệt kê ETL/ELT, chuyển đổi dữ liệu, schema mapping, validation script, cùng MCP, ứng dụng LLM, prompt engineering và RAG. Bản Hàn Quốc thêm kinh nghiệm triển khai AI agent tự vận hành trong quy trình code hoặc nghiệp vụ phức tạp.

Dòng trong tin tuyển dụng	Bằng chứng nên có trong hồ sơ
Migration: discovery, scoping, data modeling	Một tài liệu mapping schema nguồn sang đích, có ghi các trường bị mất hoặc phải biến đổi
Validation script, schema mapping	Script đối chiếu nguồn và đích, kèm báo cáo lỗi theo loại
Debug qua code, API, quyền truy cập	Một bản ghi sự cố: triệu chứng, các giả thuyết đã loại, nguyên nhân gốc
Vòng phản hồi với Product, CX, Engineering	Một bản đề xuất sản phẩm viết từ lỗi thực tế gặp khi migration
AI agent, MCP, RAG	Một agent nhỏ đọc dữ liệu đã migrate và trả lời câu hỏi, có ghi lại lúc nó sai

Ví dụ: một migration nhỏ, kiểm chứng đến từng bản ghi

Thử hình dung bạn tự đặt bài toán: một nhóm 30 người đang quản lý tài liệu và task trong một wiki cũ cộng một bảng tính, và cần chuyển sang một workspace mới. Đây là phiên bản thu nhỏ đúng loại việc trong tin tuyển dụng, và bạn làm được trên máy mình.

Bước discovery là liệt kê nguồn: wiki có trang, trang con, người tạo, ngày sửa; bảng tính có cột trạng thái với giá trị gõ tay không thống nhất như “Done”, “done”, “Xong”. Bước data modeling là quyết định đích: trạng thái thành một trường lựa chọn với ba giá trị cố định, quan hệ cha con giữ nguyên, người tạo map theo email.

Phần ghi điểm nằm ở kiểm chứng. Giả sử nguồn có 1.200 bản ghi. Script migration báo “thành công” nhưng đó chỉ là lời của chính script. Bạn cần một script độc lập đối chiếu hai đầu:

import csv
from collections import Counter

ALLOWED_STATUS = {"Not started", "In progress", "Done"}

def load(path, key="source_id"):
    with open(path, newline="", encoding="utf-8") as f:
        return {row[key]: row for row in csv.DictReader(f)}

def validate(source_path, target_path):
    src, dst = load(source_path), load(target_path)
    errors = Counter()
    for sid, row in src.items():
        t = dst.get(sid)
        if t is None:
            errors["missing_in_target"] += 1
            continue
        if t["status"] not in ALLOWED_STATUS:
            errors["unmapped_status"] += 1
        if row["parent_id"] and t["parent_id"] != row["parent_id"]:
            errors["broken_hierarchy"] += 1
        if not t["owner_email"]:
            errors["owner_not_mapped"] += 1
    extra = len(set(dst) - set(src))
    print(f"source={len(src)} target={len(dst)} extra={extra}")
    for kind, n in errors.most_common():
        print(f"{kind}: {n}")

validate("source_export.csv", "target_export.csv")

Giả sử kết quả là 1.200 nguồn, 1.188 đích, 12 bản ghi thiếu, 25 trạng thái không map được. Con số đó mới là bắt đầu.

Debug 12 bản ghi thiếu, bạn có thể thấy chúng nằm trong một thư mục mà token tích hợp không có quyền đọc, đúng loại lỗi “quyền truy cập” mà tin tuyển dụng nhắc tới. 25 trạng thái lỗi thì đến từ giá trị gõ tay mà bảng mapping chưa tính.

Rồi bạn viết một đoạn ngắn cho “team sản phẩm”: nếu công cụ import cảnh báo sớm về các trang không có quyền truy cập, người triển khai sẽ không phải đếm tay. Đó là một vòng phản hồi phiên bản thu nhỏ.

Tự làm theo thứ tự nào?

Bắt đầu bằng việc chọn một nguồn dữ liệu thật, dù nhỏ: issue tracker, wiki cá nhân, bảng tính quản lý dự án. Viết tài liệu mapping trước khi viết code, vì đó chính là phần discovery, scoping và data modeling mà tin tuyển dụng nêu tên. Sau đó mới viết script migration bằng ngôn ngữ bạn mạnh nhất, Python hoặc Node.js đều nằm trong danh sách.

Tiếp theo là validation script và một báo cáo lỗi theo loại, có nguyên nhân gốc cho từng loại. Nếu muốn chạm vào phần nice-to-have, thêm một agent nhỏ trả lời câu hỏi trên dữ liệu đã migrate, và ghi lại các câu nó trả lời sai cùng lý do. Cuối cùng, viết bản phản hồi sản phẩm dài một trang.

Trên CV, mỗi dòng nên có bốn thành phần: hệ thống nguồn, hệ thống đích, khối lượng, và cách bạn kiểm chứng. “Migrate 1.200 bản ghi từ wiki sang workspace mới, validation script phát hiện và xử lý 37 lỗi thuộc 2 loại” nói nhiều hơn hẳn “Thành thạo Python, REST API”.

Những lỗi khiến hồ sơ trượt

Lỗi đầu tiên cần tránh là chỉ chứng minh việc xây dựng. Một demo agent đẹp mà không có migration hay kiểm chứng dữ liệu chỉ phủ một phần ba vai trò. Lỗi thứ hai là kể chuyện debug như một may mắn (“cuối cùng nó chạy”), thay vì trình bày các giả thuyết đã loại qua từng lớp code, API, quyền truy cập.

Lỗi thứ ba là bỏ qua yêu cầu thâm niên làm việc với khách hàng. Nếu bạn là SWE thuần backend, hãy tìm trong quá khứ những lần bạn làm việc trực tiếp với người dùng nội bộ hoặc đối tác tích hợp và viết rõ chúng ra.

Lỗi cuối cùng là không đọc kỹ bản đăng tuyển của đúng khu vực mình nộp. Tin tuyển dụng cho Hàn Quốc, chẳng hạn, ghi rõ yêu cầu tiếng Hàn như người bản xứ và tiếng Anh giao tiếp được trong công việc.

Hồ sơ của bạn phủ được mấy dòng?

Bài tự kiểm tra cho tuần này: chép năm dòng ở cột trái của bảng phía trên ra một trang giấy. Cạnh mỗi dòng, dán một đường link hoặc ghi tên một dự án cụ thể mà người phỏng vấn có thể mở ra xem ngay: tài liệu mapping, validation script, bản ghi sự cố, bản đề xuất sản phẩm, agent nhỏ.

Dòng nào còn trống chính là việc cần làm trước tiên. Nếu trống nhiều dòng, chọn dòng validation script, vì một script đối chiếu tốt sẽ để lại sẵn nguyên liệu cho bản ghi sự cố và bản đề xuất sản phẩm.

Một migration 1.200 bản ghi trên laptop không bằng một dự án doanh nghiệp. Nhưng nó cho người phỏng vấn thấy bạn nghĩ như người phải chịu trách nhiệm khi dữ liệu của khách hàng bị mất, và đó là câu hỏi thật sự đằng sau mọi dòng trong tin tuyển dụng này.