Xin phỏng vấn FDE khi không có người giới thiệu: nhắn ai, viết gì, gửi bằng chứng nào

Bạn không quen ai ở công ty mình muốn vào, và nút “Apply” thì cho cảm giác như ném CV vào một cái hố. Theo một khảo sát được ERE dẫn lại, kỹ sư dễ trả lời nhất khi người liên hệ với họ là chính hiring manager.

Đi hết bài này, bạn sẽ có đủ bốn thứ để gửi đi: tên một người nhận, một tin nhắn, một link bằng chứng và một tin follow-up.

Với vị trí FDE, việc này có ý nghĩa hơn bình thường. Viết cho một người bận rộn chưa từng biết mình rồi khiến họ đồng ý dành thời gian là việc bạn sẽ làm lại nhiều lần với khách hàng.

Bạn cần chuẩn bị trước ba thứ: một dự án bạn đã đưa lên chạy thật, một tài khoản GitHub, và một danh sách ngắn các vị trí FDE đang mở. Chưa có dự án nào như thế thì làm bước 2 trước, vì thiếu bằng chứng thì tin nhắn viết khéo đến đâu cũng chỉ là lời tự giới thiệu suông.

Bước 1: Viết cho ai, qua kênh nào?

Người cần tìm là hiring manager, tức người sẽ trực tiếp quản lý bạn, không chỉ recruiter. Dữ liệu ERE dẫn lại cho thấy kỹ sư trả lời tin nhắn từ hiring manager nhiều nhất.

Khảo sát ấy hỏi người được tuyển chứ không hỏi người đi xin việc, nên áp sang trường hợp của bạn thì chỉ là suy luận. Dù vậy, suy luận này đứng được: người chịu trách nhiệm về đội là người hiểu nhanh nhất bằng chứng của bạn giải quyết vấn đề gì của họ.

Về kênh, trong cùng khảo sát, 51% kỹ sư thích được liên hệ về việc làm qua email cá nhân, còn LinkedIn InMail đứng thứ hai. Khảo sát này nhỏ, nên chỉ nên dùng để tham khảo. Cách làm hợp lý là ưu tiên email nếu tìm được địa chỉ công khai, còn LinkedIn để làm phương án dự phòng.

Kiểm tra: với mỗi vị trí, bạn có tên một người cụ thể và một kênh liên lạc. Nếu cột người nhận chỉ ghi chung chung “Recruiting team” thì bạn chưa xong bước này.

Bước 2: Bằng chứng nào đủ để người lạ chịu mở ra xem?

Một bài hướng dẫn trên dev.to về con đường trở thành FDE viết rằng một dự án end-to-end làm tử tế hơn hẳn mười bản demo đồ chơi.

Tiêu chí cụ thể là dự án phải cho thấy bạn nhận một vấn đề còn mơ hồ và biến nó thành một hệ thống chạy được, có đánh giá (eval). Hướng dẫn của Scaler cũng đặt ra yêu cầu tương tự: dự án phải được tích hợp, được triển khai và có người dùng, không phải app làm theo tutorial.

Hãy đóng gói bằng chứng đó thành ba lớp, đi từ nhanh đến sâu. Lớp đầu là một video demo ngắn, chỉ cần quay màn hình kèm thuyết minh là đủ. Lớp thứ hai là case study hoặc README viết cho người không chuyên. Lớp thứ ba là repo có code sạch, lịch sử commit gọn và bản chạy thật.

Một khung README gợi ý, rút gọn cho dễ hình dung:

# [Tên dự án]: [vấn đề] cho [ai đang dùng]

## Vấn đề ban đầu (còn mơ hồ thế nào)
## Đã thu hẹp vấn đề ra sao
## Hệ thống đang chạy: [link bản deploy] · [link video demo]
## Đo chất lượng: eval gồm gì, kết quả ra sao
## Ai đang dùng và họ phản hồi gì
## Nếu có thêm thời gian, sẽ sửa gì

Phần “Đo chất lượng” là chỗ chứng minh hệ thống của bạn có eval, đúng tiêu chí ở trên, nên đừng để trống nó. Kiểm tra: gửi link cho một người bạn không làm kỹ thuật. Nếu xem xong video họ nói lại được hệ thống giải quyết vấn đề gì, phần bằng chứng đã dùng được.

Bước 3: Tin nhắn bốn phần

Trong khảo sát của ERE, 39% kỹ sư xếp cá nhân hóa là phần quan trọng nhất của một tin nhắn lạnh, nhiều hơn mọi yếu tố khác.

Underdog.io, một nền tảng tuyển dụng, khuyên rằng khi không có người giới thiệu, bạn cần tạo ra một mối liên hệ cụ thể với chính người nhận, với công việc của họ hoặc với công ty. Mối liên hệ đó thay cho lời giới thiệu bạn đang thiếu.

Từ đó tin nhắn có bốn phần. Tiêu đề phải ghi đúng tên vị trí, không dùng câu chung chung. Câu mở đầu là mối liên hệ cụ thể. Phần giữa là một link bằng chứng gắn với vấn đề của họ.

Câu cuối là một lời đề nghị nhỏ, ví dụ một cuộc trò chuyện 15 phút vào tuần sau. Mẫu tin bằng tiếng Anh:

Subject: Forward Deployed Engineer – [project] solving [problem close to their product]

Hi [Name],

Your [talk / post / release] on [specific topic] matched a problem I hit
while building [project]: [one sentence on the vague problem].

I shipped it end to end – deployed, used by [who], with an eval for
[what quality means]. 3-minute demo + write-up: [link]

Would a 15-minute chat next week be useful to see if this fits
the FDE role on your team?

[Name] · [GitHub] · [CV link]

Tin trên LinkedIn phải ngắn hơn email. Bản InMail chỉ nên giữ câu kết nối, link và câu đề nghị. Kiểm tra: xóa tên người nhận đi rồi đọc lại. Nếu tin vẫn gửi được cho bất kỳ công ty nào, phần cá nhân hóa chưa đủ.

Bước 4: Follow-up chỉ bằng một link

Không nhận được trả lời là chuyện bình thường. Tin follow-up phải thật ngắn, và thay vì đính kèm thêm tài liệu dài, hãy dẫn link tới một case study trong portfolio. Bạn có thể dùng chính phần “Đo chất lượng” ở bước 2 làm điểm mới, chẳng hạn một dòng nói hệ thống làm được gì sau lần cải tiến gần nhất.

Kiểm tra: tin follow-up không dài quá ba câu và không có file đính kèm nào.

Lỗi hay gặp

Lỗi đầu tiên là chỉ gửi cho recruiter rồi ngồi chờ. Lỗi thứ hai là gửi kèm năm repo. Người nhận sẽ không mở cái nào, vì không biết nên bắt đầu từ đâu; một dự án end-to-end đặt lên đầu thì hiệu quả hơn.

Lỗi thứ ba là đề nghị quá lớn kiểu “xin anh/chị xem giúp CV và giới thiệu em”, trong khi một cuộc gọi ngắn dễ được đồng ý hơn nhiều.

Họ trả lời rồi, chuẩn bị gì tiếp?

Mỗi công ty có quy trình riêng, nên hãy lấy Palantir làm ví dụ. Theo hướng dẫn phỏng vấn của Aced (trước đây là Exponent), quy trình FDE ở đây có một cuộc gọi 30 phút với recruiter, xoay quanh động lực của bạn. Câu chuyện vì sao bạn làm dự án ở bước 2 chính là phần chuẩn bị tốt nhất cho cuộc gọi đó.

Quy trình phỏng vấn FDE của Palantir còn có một vòng decomposition, trong đó bạn chia nhỏ một bài toán mở và gần như không phải code. Gần như ứng viên nào cũng gặp vòng này.

Phần README “thu hẹp vấn đề ra sao” bạn đã viết là bài luyện tập sát nhất, vì nó buộc bạn kể lại cách mình cắt một vấn đề mơ hồ thành từng bước.

Kỹ năng này dùng lại ở chỗ khách hàng thế nào?

Ở chỗ khách hàng, bạn sẽ thường xuyên phải viết cho một người bận rộn không nợ bạn điều gì: một trưởng phòng vận hành, một kỹ sư dữ liệu bên khách, một nhà tài trợ dự án.

Công thức vẫn giữ nguyên: đúng người có quyền quyết định, một điểm nối cụ thể với vấn đề của họ, một bằng chứng xem được trong vài phút và một lời đề nghị nhỏ.

Trong CV, bạn có thể ghi kỹ năng này dưới dạng một dòng mô tả dự án kèm link demo, thay vì liệt kê công nghệ. Người đọc tin nhắn của bạn chưa từng gặp bạn, nên chính tin nhắn đó là bài kiểm tra đầu tiên về việc bạn có làm việc được với khách hàng hay không.