Không có cách nào đáng tin cậy để gắn một con số phần trăm cho công việc kỹ thuật chưa từng được đo lường, và việc bịa ra một con số chỉ để làm theo lời khuyên chung chung "hãy định lượng tác động của bạn" còn tệ hơn là để trống con số đó, bởi vì một số liệu bịa đặt hoặc là sai, hoặc là bạn không thể bảo vệ nó khi ai đó hỏi bạn lấy nó từ đâu. Điều có thể mô tả một cách trung thực, ngay cả khi không có số liệu được theo dõi, là phạm vi: hệ thống lớn đến đâu, bao nhiêu người hoặc dịch vụ phụ thuộc vào nó, nó chạy thường xuyên như thế nào, và điều gì thực sự thay đổi giữa trạng thái trước và sau. Đó là những sự thật bạn thường có thể tái hiện từ trí nhớ, lịch sử ticket hoặc một bản báo cáo sự cố, và chúng đáng tin hơn nhiều so với một con số xuất hiện từ hư không.
Vì sao lời khuyên "chỉ cần thêm một con số" thất bại khi không có số liệu
Hầu hết lời khuyên viết CV bảo kỹ sư định lượng mọi gạch đầu dòng, và lời khuyên đó không sai theo cách của nó: người đọc lướt qua hàng chục CV thực sự phản ứng tốt hơn với điều gì đó cụ thể thay vì một tuyên bố mơ hồ. Vấn đề là rất nhiều công việc kỹ thuật thực tế chưa bao giờ được theo dõi theo cách tạo ra một con số phần trăm sạch sẽ. Nhiều đội không chạy bảng theo dõi cho mọi thay đổi, nhiều tác động được cảm nhận chứ không được đo, và nhiều kỹ sư chuyển sang vai trò mới trước khi ai đó quay lại kiểm tra xem thay đổi của quý trước có thực sự giúp ích hay không. Đối mặt với khoảng trống đó, lối tắt hấp dẫn là viết một con số nghe có vẻ hợp lý và hy vọng không ai hỏi nó đến từ đâu. Đó chính là cái bẫy bài viết này muốn giúp bạn tránh, bởi một con số mà người phỏng vấn có thể vạch trần chỉ bằng một câu hỏi tiếp theo còn gây hại hơn là không có con số nào cả.
Những thước đo trung thực vẫn tồn tại ngay cả khi không có số liệu theo dõi
Một vài loại chi tiết cụ thể tồn tại cho gần như bất kỳ công việc kỹ thuật nào, dù có hay không có số liệu từng được ghi lại cho nó. Phạm vi mô tả quy mô của những gì bạn đã chạm vào: số lượng dịch vụ mà một thay đổi trải rộng, kích thước của codebase, số lượng endpoint hoặc bảng bị ảnh hưởng. Quy mô mô tả hệ thống mang tải bao nhiêu: bao nhiêu request nó phục vụ, bao nhiêu bản ghi nó lưu trữ, bao nhiêu đội xây dựng dựa trên nó, được diễn đạt bằng những từ ngữ bạn có thể nói một cách chắc chắn thay vì một con số bạn đang đoán. Tần suất mô tả điều gì đó chạy hoặc được sử dụng thường xuyên ra sao: một tác vụ batch chạy hằng đêm, một pipeline triển khai được mọi kỹ sư trong đội sử dụng, một báo cáo được tạo ra cho mỗi quý đã đóng. Trạng thái trước và sau mô tả điều gì đúng trước thay đổi của bạn và điều gì đúng sau đó, bằng ngôn ngữ đơn giản thay vì một phần trăm: điều gì từng thất bại, điều gì từng cần một bước thủ công, điều gì từng cần người trực, và điều gì không còn đúng nữa sau khi công việc được triển khai. Ai đã dựa vào nó nêu tên đối tượng thực sự: đội đã dùng công cụ bạn xây, dịch vụ đã gọi API bạn duy trì, ca trực không còn bị báo động vì sự cố bạn đã sửa. Mỗi điều trong số này là thứ bạn thực sự có mặt và có thể mô tả từ kiến thức trực tiếp, chính điều đó khiến nó đáng tin hơn nhiều so với một phần trăm được làm tròn lên.
Ví dụ minh họa: một gạch đầu dòng được viết lại xoay quanh phạm vi thay vì phần trăm
Trước, mơ hồ và không định lượng: "Chịu trách nhiệm về hiệu năng của dịch vụ thanh toán." Sau, được viết lại xoay quanh phạm vi và một trạng thái trước/sau được mô tả thay vì một con số bịa đặt: "Phụ trách lớp truy vấn cơ sở dữ liệu của dịch vụ thanh toán, con đường duy nhất mà mọi giao dịch mua trên trang web đi qua; trước khi viết lại, các truy vấn chậm là nguyên nhân phổ biến nhất khiến việc thanh toán bị treo mà đội hỗ trợ phải leo thang xử lý, và sau khi triển khai, loại khiếu nại đó không còn xuất hiện trong buổi rà soát hằng tuần nữa." Không có gì trong phiên bản viết lại là một số liệu đoán mò. Nó nêu rõ ứng viên phụ trách gì, phần đó quan trọng ra sao đối với hệ thống, vấn đề trông như thế nào trước đó, và điều gì thay đổi sau đó, tất cả đều từ điều mà ứng viên thực sự chứng kiến chứ không phải một con số được tái tạo sau này.
Điều nên bỏ qua khi viết lại
Ranh giới cần giữ là giữa một con số bạn hiện có thể chỉ ra, từ một bảng theo dõi, một báo cáo sự cố, hoặc một số liệu bạn thực sự đã theo dõi tại thời điểm đó, và một con số bạn đang tái hiện từ một ký ức mơ hồ kiểu "cảm giác như mọi thứ nhanh hơn nhiều." Loại đầu tiên thì được phép nêu trực tiếp. Loại thứ hai chính là loại đáng viết lại bằng ngôn ngữ phạm vi và trước/sau thay vào đó, bởi một cảm nhận được nhớ lại rồi làm tròn thành một con số nghe có vẻ chỉn chu chính là loại tuyên bố dễ sụp đổ trước một câu hỏi cụ thể trong buổi phỏng vấn. Phiên bản dựa trên phạm vi ở trên vượt qua được câu hỏi đó, vì mọi phần của nó là thứ bạn có thể diễn đạt bằng lời của chính mình mà không cần dựa vào một con số bạn chưa từng thực sự ghi lại.
Điều này khớp với khuôn mẫu chuyển nhiệm vụ thành thành tích rộng hơn ra sao
Viết lại xoay quanh phạm vi thay vì một số liệu bịa đặt là một ứng dụng cụ thể của một sự chuyển đổi rộng hơn, áp dụng vượt xa lĩnh vực kỹ thuật: chuyển từ mô tả những gì bạn chịu trách nhiệm sang mô tả điều gì thực sự thay đổi nhờ đó. Chuyển nhiệm vụ thành thành tích trên CV trình bày khuôn mẫu viết lại rộng hơn đó với các ví dụ từ những vai trò ngoài lĩnh vực kỹ thuật, dành cho bất kỳ ai có các gạch đầu dòng hiện đọc như một danh sách nhiệm vụ được giao thay vì kết quả.
Xây dựng mục này
Cách viết một bản CV trình bày các lựa chọn từ ngữ giúp kiểu viết lại này lan tỏa qua phần còn lại của CV, và mẫu developer của CVBuilderKit được xây dựng chính xác cho kiểu mục việc theo phạm vi, theo dự án như thế này. Bắt đầu từ một tài liệu có sẵn hoặc một tài liệu trống trong trình tạo CV và viết lại từng gạch đầu dòng bằng phạm vi và một trạng thái trước/sau được mô tả trước khi tìm đến một con số mà bạn thực sự không thể bảo vệ.