Ngành phần mềm đang lớn và trưởng thành

Phần nào đó, điều này là tất yếu khi một ngành phát triển. Thời kỳ khởi đầu của mọi lĩnh vực giống như miền Viễn Tây hoang dã: rủi ro thấp, quy định không có, tiêu chuẩn còn non trẻ. Nhìn lịch sử các ngành như y khoa, điện ảnh, phát thanh, ta thấy nhiều điểm tương đồng.

Có một thời kỳ kỳ diệu khi biên giới giữa các vai trò mờ nhạt, và bất cứ ai có động lực, tò mò và chịu khó làm việc cũng có thể nắm bắt cơ hội.

Nhưng điều đó không kéo dài. Không thể; cũng không nên. Kiến thức và kinh nghiệm bắt buộc để vào ngành tăng vọt. Rủi ro cao hơn, sứ mệnh lớn hơn, sai lầm có thể rất đắt. Chúng ta phát triển chứng chỉ, đào tạo, tiêu chuẩn, quy trình pháp lý. Và còn tranh luận xem kỹ sư phần mềm có thực sự là kỹ sư không.

Phần mềm là một ngành học nghề

Ngày nay, bạn sẽ không muốn tuyển một học sinh bỏ học như tôi vào vị trí trực hệ thống cấp thấp. Kiến thức cần có để vào ngành đã tăng, tốc độ làm việc nhanh hơn, và rủi ro cao, nên bạn không thể học mọi thứ trên công việc như tôi ngày xưa.

Tuy nhiên, vào đại học không giúp bạn học hết mọi thứ. Bằng CS thiên về nghiên cứu hơn là làm kỹ sư phần mềm hàng ngày. Một con đường thực tế hơn là bootcamp lập trình, tập trung vào giải quyết vấn đề và học công cụ hiện đại. Bất kể bằng cấp thế nào, bạn học để hiểu và sử dụng công cụ để học trên công việc.

Phần mềm là ngành học nghề; bạn không thể học làm kỹ sư chỉ qua đọc sách. Bạn học bằng cách làm đi làm lại. Phần lớn học tập diễn ra trên công việc, và không bao giờ kết thúc. Học và dạy là việc cả đời; ngành thay đổi quá nhanh.

Thông thường, cần khoảng bảy năm kinh nghiệm để trở thành kỹ sư phần mềm có năng lực, hay "senior software engineer" theo thang lương nhiều nơi. Bảy năm code, review, triển khai mỗi ngày cùng nhóm kỹ sư giàu kinh nghiệm.

“Kỹ sư cấp cao” nghĩa là gì?

Để trưởng thành thành kỹ sư có thể đứng mũi chịu sào, bạn cần thời gian, kinh nghiệm và luyện tập. Chúng ta dùng “Senior Software Engineer” để mô tả kỹ sư tạo ra mã hiệu quả, nhưng đó là cách dùng sai lệch. Nó khiến một số người nghĩ kỹ sư cấp thấp là gánh nặng, điều này không đúng, và che lấp bản chất thật của công việc kỹ sư phần mềm, mà code chỉ là một phần nhỏ.

Kỹ sư cấp cao không chỉ là viết code tốt. Quan trọng hơn là khả năng hiểu, duy trì, giải thích và quản lý một hệ thống phần mềm lớn đang hoạt động theo thời gian, cũng như khả năng chuyển nhu cầu kinh doanh thành triển khai kỹ thuật. Làm kỹ thuật phần mềm nghĩa là xây dựng và chăm chút hệ thống xã-hội-kỹ thuật phức tạp, và code chỉ là một phần đại diện.

Kỹ sư cấp cao là người biết học và dạy; biết giữ và lý giải mô hình trong đầu; biết duy trì, mở rộng và vận hành hệ thống theo thời gian; có phán đoán tốt và trực giác đáng tin.

Đến phần về AI

Thật sự rất khó để bạn có vai trò kỹ sư đầu tiên. Năm qua, có rất nhiều bài báo nói job cấp đầu bị AI thay thế. Một số đúng. Bất cứ công việc lặp đi lặp lại như chuyển định dạng tài liệu, tóm tắt văn bản, thay đổi icon ... rất dễ bị tự động hóa. Điều này không cách mạng; chỉ là mở rộng tự động hóa sang văn bản.

Gần đây, nhiều lãnh đạo công nghệ tin rằng AI sinh sẽ thay thế toàn bộ công việc của kỹ sư mới ra. Có nhiều bài viết cho rằng công việc của junior engineer đang bị tự động hóa. Tất cả cho thấy hiểu lầm sâu sắc về công việc kỹ sư.

Viết code dễ, nhưng chất lượng mới khó

Mọi người nghĩ viết code là khó nhất trong kỹ thuật phần mềm. Thật ra, viết code dễ nhất, và ngày càng dễ hơn. Khó là việc sử dụng mã đó - vận hành, hiểu, mở rộng, điều khiển suốt vòng đời.

Kỹ sư mới học cách viết và debug. Dần lên cấp senior, bạn học cách ghép hệ thống từ phần mềm, dẫn dắt hệ thống qua nhiều thay đổi.

Hệ thống xã-hội-kỹ thuật gồm phần mềm, công cụ và con người; hiểu chúng nghĩa là am hiểu tương tác giữa phần mềm, người dùng, sản xuất, hạ tầng và thay đổi liên tục. Các hệ thống rất phức tạp, có thể hỗn loạn, không xác định và hành vi bất ngờ. Nếu ai tự tin hiểu hệ thống họ xây và vận hành, thì hệ thống đó rất nhỏ, hoặc họ chưa biết đủ để biết mình chưa biết gì.

Code thì dễ, hệ thống thì khó.

Công cụ AI sinh hiện nay giúp tạo nhiều mã nhanh. Phần dễ ngày càng dễ hơn với tốc độ đáng kinh ngạc. Nhưng chúng chẳng giúp gì trong việc quản lý, hiểu hay vận hành mã. Nếu có, chúng chỉ làm công việc khó thêm khó.

Dễ tạo code, khó tạo code tốt

Nếu bạn đọc nhiều bài hype, bạn sẽ tưởng kỹ sư chỉ ngồi prompt ChatGPT, dùng Copilot viết hàng code, rồi commit lên GitHub và bỏ đi. Thực tế không như vậy.

Cách nhìn đúng về Copilot như autocomplete cao cấp hoặc copy-paste từ Stack Overflow + Google. Bạn đánh cược mỗi lần.

Các công cụ này tốt nhất khi có đoạn tương tự trong file và bạn chỉ cần sửa chút. Hoặc khi viết test và bạn có khối YAML lặp đi lặp lại với tên cột/field. AI tạo template tốt.

Nhưng đừng tin mã generated. Mã AI sinh trông rất plausible, nhưng ngay cả khi chạy được, nó hiếm khi phù hợp với nhu cầu bạn. Nó sẽ tạo mã không parse hoặc compile; tự nghĩ ra biến, tên hàm; hallucinate field không có. Mã tạo ra sẽ không theo coding convention của bạn. Nó không tự refactor hoặc tạo abstraction thông minh. Đoạn mã càng quan trọng, việc tạo bằng AI càng khó đạt.

Bạn có thể tiết kiệm thời gian khi không phải viết từ đầu, nhưng bạn cần xem từng dòng, chỉnh từng phần trước khi commit, chưa nói đến production. Trong nhiều trường hợp, mất thời gian bằng việc tự viết. Autocomplete hiện rất thông minh rồi. Làm cho mã AI tích hợp vào codebase cần rất nhiều công sức.

Cách các kỹ sư thực tế sử dụng AI sinh tạo

Tóm lại: bạn có thể tạo rất nhiều mã rất nhanh, nhưng bạn không thể tin tưởng hoàn toàn vào kết quả đó. Tuy nhiên, có một số trường hợp sử dụng mà AI sinh tạo hoạt động rất hiệu quả.

Ví dụ, thường thì việc yêu cầu ChatGPT tạo mã mẫu sử dụng các API lạ sẽ dễ hơn rất nhiều so với việc đọc tài liệu API - bởi vì mô hình AI đã được huấn luyện trên kho mã thực tế chứa những API đó.

Generative AI cũng rất giỏi tạo ra các đoạn mã tẻ nhạt hoặc chán ngán nhưng có phạm vi rõ ràng và dễ giải thích. Kịch bản càng dự đoán được, công cụ càng viết mã tốt. Nếu yêu cầu của bạn thực chất chỉ là sao chép-dán theo mẫu - bất cứ khi nào bạn có thể tạo mã dùng sed/awk hoặc macro vi - thì generative AI thật sự rất phù hợp.

Nó cũng rất tốt trong việc viết các hàm nhỏ giúp bạn làm việc với ngôn ngữ hoặc tình huống không quen thuộc. Ví dụ, nếu bạn có đoạn mã Python và muốn có phiên bản tương tự bằng Java nhưng không biết Java, generative AI sẽ hỗ trợ bạn.

Tuy nhiên, bạn phải nhớ rằng có đến 50/50 khả năng đầu ra là ảo giác (hallucinations) và không chính xác. Bạn luôn phải giả định rằng kết quả chưa chính xác cho đến khi bạn tự kiểm chứng. Nhưng những công cụ này chắc chắn có thể tăng tốc công việc của bạn theo vô số cách.

Generative AI giống một kỹ sư mới vào nghề

Generative AI giống như một kỹ sư mới làm việc ở chỗ bạn, chúng không thể triển khai ngay lập tức những dòng mã vào production. Bạn phải chịu trách nhiệm với mã đó - về mặt pháp lý, đạo đức và thực tế. Bạn vẫn phải bỏ thời gian để hiểu nó, kiểm thử nó, thêm instrumentation, chỉnh lại giao diện và logic để phù hợp với codebase còn lại của bạn, và đảm bảo đồng đội của bạn cũng có thể hiểu và duy trì nó.

So sánh này khá hợp lý, nhưng chỉ khi mã của bạn là disposable (dùng một lần rồi bỏ), tự biệt lập, tức không dùng chung với hệ thống lớn hoặc được người khác đọc, sửa sau này.

Trong ngành có những góc như vậy, nơi phần lớn mã chỉ được viết một lần, phục vụ một sự kiện hoặc chiến dịch, rồi bị bỏ lăn lóc. Nhưng đó không phải phần lớn phần mềm. Mã disposable là hiếm; phần mềm cần tồn tại lâu dài mới là tiêu chuẩn. Ngay cả khi chúng ta nghĩ mã của mình chỉ dùng một lần, chúng ta thường … sai lầm.

Nhưng generative AI không phải một thành viên trong đội của bạn

Theo nghĩa đó - tạo ra mã bạn biết là không đáng tin - GenAI giống kỹ sư mới. Nhưng trong mọi khía cạnh khác, tương tự phá sản. Bởi vì thêm một người biết viết code vào nhóm bạn là điều hoàn toàn khác với việc tự động sinh mã. Đoạn mã đó có thể đến từ bất cứ đâu - Stack Overflow, Copilot, bất kỳ nguồn nào. Bạn không biết, và nó chẳng quan trọng. Không có vòng phản hồi, không có người đằng sau để học và cải thiện, và cũng không ảnh hưởng đến tinh thần hay văn hóa nhóm bạn.

Rõ ràng: việc review code cho kỹ sư mới không giống soát mã tạo bởi AI. Dành thời gian phản hồi cho người khác mang lại giá trị nhiều hơn. Đó là cơ hội để truyền lại bài học từ sự nghiệp của bạn. Chỉ việc bạn cố gắng diễn giải vấn đề cũng buộc bạn phải tư duy nghiêm túc hơn, giúp bạn hiểu sâu sắc hơn về vấn đề.

Và việc thêm một kỹ sư mới vào nhóm sẽ ngay lập tức thay đổi động lực nhóm. Nó tạo ra môi trường nơi câu hỏi được khuyến khích, nơi việc dạy và học diễn ra liên tục. Chúng ta sẽ nói thêm về động lực nhóm sau.

Thời gian bạn đầu tư giúp kỹ sư mới tiến bộ có thể mang lại kết quả rất nhanh. Thời gian trôi rất nhanh 😊. Khi tuyển người, chúng ta thường đề cao kỹ sư cấp cao nhưng rất hay đánh giá thấp kỹ sư mới. Cả hai định kiến đều không tốt.

Chúng ta đánh giá thấp chi phí tuyển kỹ sư senior, và đánh giá quá cao chi phí tuyển junior

Mọi người thường nghĩ khi thuê kỹ sư senior thì họ sẽ làm việc ngay hiệu quả, còn junior thì mãi chậm chạp. Nhưng cả hai đều không đúng. Thật ra, phần lớn công việc của nhiều đội không quá khó, khi nó đã được chia nhỏ thành các phần cụ thể. Có rất nhiều cơ hội để kỹ sư cấp thấp thực hiện và thành công.

Góc nhìn đơn giản của kế toán chỉ nghĩ: “Tại sao lại trả 100.000 đô la cho kỹ sư mới khiến mọi thứ chậm lại, trong khi trả 200.000 đô cho senior thì mọi thứ nhanh hơn?” Điều đó hoàn toàn không hợp lý!

Nhưng bất cứ kỹ sư nào chú tâm đều biết, đó không phải cách kỹ thuật hoạt động. Đây là ngành học nghề, và năng suất được xác định bởi kết quả và khả năng chịu tải của cả nhóm, không phải của mỗi cá nhân.

Mỗi người đóng góp theo nhiều cách vào tốc độ của nhóm, cũng như có thể gây mỏi lực hoặc tạo ma sát cho cả nhóm. Điều này không luôn tương quan với cấp bậc, và việc viết code chỉ là một cách.

Hơn nữa, mỗi kỹ sư bạn thuê đều cần thời gian và đầu tư trước khi có thể đóng góp. Tuyển và đào tạo kỹ sư mới là việc tốn kém, bất kể cấp độ. Một kỹ sư senior cũng cần thời gian để xây dựng mô hình nhận thức về hệ thống, làm quen với công cụ và công nghệ, và đạt hiệu suất làm việc. Cần bao lâu? Tùy vào độ sạch và tổ chức của codebase, kinh nghiệm trước, khả năng onboard của bạn, v.v., nhưng có lẽ khoảng 6–9 tháng. Họ có thể sẽ chỉ “bay” ổn trong khoảng một năm.

Đúng, thời gian ramp lâu hơn cho junior và đúng là cần nhiều đầu tư hơn từ nhóm. Nhưng không phải vô thời hạn. Kỹ sư junior có thể tạo ra giá trị sau khoảng thời gian tương tự - sáu tháng đến một năm, và họ phát triển nhanh hơn rất nhiều so với đóng góp của senior. (Đừng quên, đóng góp của họ có thể vượt xa mã họ viết.)

Bạn không cần phải là một kỹ sư cấp cao để mang lại giá trị

Về việc viết và triển khai tính năng, một số kỹ sư năng suất nhất tôi từng biết là các kỹ sư trung cấp. Chưa bị vướng vào họp hành, mentoring, kiến trúc, lịch của họ ít bị gián đoạn, nên chỉ việc xây dựng sản phẩm. Họ bắt đầu ngày mới với tai nghe, viết code cả ngày, và ra về sau khi đã hoàn thành rất nhiều.

Kỹ sư trung cấp nằm trong trạng thái tuyệt vời, tạm thời: họ đã khá giỏi lập trình nên rất hiệu quả, nhưng vẫn đang học cách xây dựng và chăm sóc hệ thống. Họ chỉ việc viết code - rất nhiều code.

Và họ đầy năng lượng, nhiệt huyết. Họ vui khi viết một form web hoặc trang login lần thứ 1000. Mọi thứ vẫn mới, thú vị, và hào hứng, có nghĩa là họ sẽ làm tốt hơn, nhất là dưới sự chỉ dẫn nhẹ nhàng của người giàu kinh nghiệm. Có kỹ sư trung cấp trong nhóm thật tuyệt. Cách duy nhất có được họ là tuyển kỹ sư junior.

Việc có kỹ sư junior và trung cấp trong đội là biện pháp phòng ngừa tốt chống lại việc overengineering và phát triển phức tạp sớm. Họ chưa biết đủ về một vấn đề để tưởng tượng vô số edge case cần giải quyết. Họ giúp giữ mọi thứ đơn giản, và giữ đơn giản là việc khó nhất.

Lý do dài hạn để tuyển kỹ sư junior

Nếu bạn hỏi, hầu hết mọi người sẽ hoàn toàn đồng ý rằng tuyển kỹ sư junior là việc tốt... nhưng lại nghĩ người khác nên làm việc đó. Bởi vì lợi ích lâu dài của việc tuyển junior rất rõ ràng và được hiểu rộng rãi:

• Ngành cần nhiều kỹ sư senior hơn
• Phải có người đào tạo họ
• Kỹ sư junior rẻ hơn
• Có thể tăng tính đa dạng
• Họ thường trung thành với công ty đầu tư cho họ và không nhảy việc
• Và đã có nói rồi ai đó phải làm việc đó

Nhưng suy nghĩ dài hạn không phải điều mà các công ty hay chủ nghĩa tư bản nói chung thường làm tốt. Khi nhìn dưới góc độ này, bạn sẽ nghĩ tuyển junior là một hành động hi sinh vì công ích với chi phí lớn. Các công ty thường muốn đẩy chi phí đó ra ngoài, và đó là lý do chúng ta đang ở tình trạng hiện tại.

Những lý do ngắn hạn để tuyển kỹ sư mới vào nghề

Tuy nhiên, cũng có ít nhất từng ấy lý do để tuyển kỹ sư junior trong ngắn hạn - những lý do mang tính ích kỷ, thực tế, và sinh lợi, chứng minh vì sao điều đó lại có lợi cho đội ngũ và công ty. Bạn chỉ cần thay đổi góc nhìn một chút, từ cá nhân sang đội nhóm, để thấy rõ điều đó.

Hãy bắt đầu từ đây: việc tuyển kỹ sư không phải là quá trình "chọn người giỏi nhất cho công việc". Tuyển kỹ sư là quá trình xây dựng đội ngũ. Đơn vị nhỏ nhất sở hữu phần mềm không phải là cá nhân, mà là tập thể. Chỉ có đội ngũ mới có thể sở hữu, xây dựng và duy trì một kho phần mềm. Đây vốn dĩ là một hoạt động mang tính hợp tác và cộng tác.

Nếu việc tuyển dụng kỹ sư là để chọn “người giỏi nhất”, thì việc thuê người có kinh nghiệm cao nhất, cấp bậc cao nhất bạn có thể trả được sẽ là lựa chọn hợp lý - vì chúng ta đang dùng “senior” và “giàu kinh nghiệm” làm chỉ báo cho “năng suất”. (Điều này đáng bàn, nhưng ta sẽ tạm bỏ qua.) Nhưng năng suất của mỗi cá nhân không phải thứ ta cần tối ưu hóa. Điều duy nhất đáng quan tâm là năng suất của cả đội.

Và những đội ngũ tốt nhất luôn là những đội có sự đa dạng về điểm mạnh, góc nhìn và trình độ chuyên môn. Một đội đồng nhất có thể hoạt động rất hiệu quả trong ngắn hạn - thậm chí có thể vượt trội so với một đội đa dạng. Nhưng những đội như vậy không mở rộng tốt, và không thích nghi linh hoạt với các thách thức lạ. Bạn càng trì hoãn việc đa dạng hóa, thì việc đó sẽ càng khó khăn hơn sau này.

Chúng ta cần tuyển kỹ sư mới vào nghề, và không chỉ một lần, mà là thường xuyên. Chúng ta cần nuôi dưỡng phễu từ dưới lên. Kỹ sư junior chỉ ở cấp junior trong một vài năm, và kỹ sư trung cấp sẽ trở thành senior. Những kỹ sư cực kỳ kỳ cựu thực ra không phải là người phù hợp nhất để dẫn dắt kỹ sư mới; người hướng dẫn hiệu quả nhất thường là người chỉ ở trên bạn một bậc, người vẫn còn nhớ rõ cảm giác khi bước vào nghề.

Một đội ngũ khỏe mạnh, hiệu suất cao luôn có đủ các cấp độ

Một đội ngũ khỏe mạnh giống như một hệ sinh thái. Bạn sẽ không tổ chức một nhóm kỹ sư sản phẩm với sáu chuyên gia cơ sở dữ liệu và một người làm mobile. Tương tự, bạn cũng không nên có sáu kỹ sư cấp staff+ và một kỹ sư mới toanh. Một đội tốt bao gồm nhiều cấp độ kỹ năng khác nhau.

Bạn đã bao giờ ở trong một đội chỉ toàn kỹ sư staff hoặc principal chưa? Không vui chút nào. Đó không phải là một đội hiệu quả. Lượng công việc ở tầm kiến trúc cao hoặc hoạch định chiến lược là có giới hạn, chỉ có vài quyết định lớn cần đưa ra. Những kỹ sư này dành phần lớn thời gian làm những việc nhàm chán và lặp lại, nên họ thường rơi vào hai thái cực: hoặc là thiết kế quá mức cần thiết, hoặc là làm qua loa - đôi khi làm cả hai. Họ tranh giành phần việc "thú vị" và thường xuyên xảy ra tranh cãi kỹ thuật. Họ ít khi viết tài liệu và hiếm khi đầu tư vào những thứ giúp hệ thống đơn giản và dễ tiếp cận hơn.

Những đội chỉ có kỹ sư trung cấp (hoặc mới vào nghề, hoặc toàn senior) sẽ mắc các vấn đề khác, nhưng cũng có vấn đề tương tự về va chạm và mù mờ. Bản thân công việc có rất nhiều mức độ phức tạp - từ những hàm nhỏ rõ ràng đến các quyết định kiến trúc hệ trọng. Vậy nên, việc đội ngũ cũng có sự phân tầng tương ứng là điều hợp lý.

Những đội tuyệt nhất là nơi không ai cảm thấy nhàm chán, vì ai cũng đang làm điều gì đó thử thách và đẩy họ vượt khỏi vùng an toàn. Cách duy nhất để đạt được điều này là có đội ngũ với đủ mọi trình độ.

Nút thắt hiện tại không nằm ở đào tạo, mà ở tuyển dụng

Vấn đề hiện tại không nằm ở việc ta có thể đào tạo kỹ sư junior tốt đến đâu. Cũng không phải là họ cần chăm chỉ hơn - tôi thấy có nhiều lời khuyên chân thành về điều này, nhưng chúng không giải quyết được gốc rễ. Vấn đề nằm ở chỗ ai sẽ cho họ công việc đầu tiên. Nút thắt nằm ở các công ty xem họ như một chi phí cần đẩy ra ngoài, chứ không phải là khoản đầu tư cho tương lai của chính công ty.

Sau công việc đầu tiên, kỹ sư thường có thể tìm việc tiếp. Nhưng để có được việc đầu tiên, theo tôi thấy, là cực kỳ khó khăn. Gần như không thể - nếu bạn không học từ trường top, và không vào được chuỗi cung ứng của Big Tech, thì việc tìm được công việc đầu tiên gần như là hên xui hoặc dựa vào các mối quan hệ. Trước khi xuất hiện cái bóng của "AI sinh tạo có thể thay thế kỹ sư junior", việc đó đã khó rồi. Bạn sẽ ở đâu, nếu bạn không vào ngành công nghệ đúng thời điểm?

Không ai nghĩ rằng chúng ta cần ít kỹ sư senior hơn

Rất nhiều người nghĩ rằng chúng ta không cần kỹ sư junior, nhưng không ai nói rằng chúng ta cần ít kỹ sư senior hơn - hoặc sẽ cần ít hơn trong tương lai gần.

Tôi nghĩ có thể giả định rằng bất cứ điều gì có thể xác định được và tự động hóa thì cuối cùng sẽ được tự động hóa. Kỹ thuật phần mềm cũng không ngoại lệ - chúng ta là nơi tiên phong! Tất nhiên chúng ta luôn tìm cách để tự động hóa và tăng hiệu quả, như chúng ta nên làm.

Nhưng các hệ thống phần mềm lớn thì khó đoán và phi tuyến tính, với các hành vi phát sinh ngoài dự đoán. Chỉ riêng việc có người dùng đã khiến hệ thống trở nên hỗn loạn. Các thành phần có thể tự động hóa, nhưng độ phức tạp thì chỉ có thể quản lý.

Ngay cả khi hệ thống có thể hoàn toàn tự động và điều hành bởi AI, thì việc ta không hiểu cách AI đưa ra quyết định là một vấn đề khổng lồ - có thể không thể vượt qua. Điều hành doanh nghiệp trên một hệ thống mà con người không thể debug hay hiểu rõ là một rủi ro quá lớn đến mức không bộ phận an ninh, pháp lý hay tài chính nào dám phê duyệt. Có thể một phiên bản nào đó của tương lai này sẽ xảy ra, nhưng hiện tại rất khó tưởng tượng ra. Tôi sẽ không đặt cược cả sự nghiệp hay công ty của mình vào điều đó.

Trong thời gian chờ đợi, chúng ta vẫn cần thêm kỹ sư senior. Và cách duy nhất để có họ là sửa lại quy trình tuyển dụng.

Có phải công ty nào cũng nên tuyển kỹ sư junior?

Không. Bạn cần có khả năng để đảm bảo họ thành công. Một số yếu tố khiến bạn không nên tuyển kỹ sư junior:

• Bạn chỉ còn dưới 2 năm ngân sách hoạt động
• Nhóm của bạn luôn trong chế độ “chữa cháy”, không có thời gian rảnh
• Bạn không có quản lý kinh nghiệm, hoặc có quản lý tệ, hoặc không có quản lý
• Bạn không có roadmap sản phẩm
• Không ai trong nhóm bạn muốn làm mentor hoặc đầu mối cho họ

Điều duy nhất tệ hơn việc không bao giờ tuyển kỹ sư junior là tuyển họ vào một trải nghiệm tệ hại, nơi họ không học được gì.

Việc công ty hoạt động hoàn toàn từ xa không phải là rào cản tuyệt đối, nhưng nó khiến mọi thứ khó hơn nhiều. Kỹ sư mới nên tìm việc có văn phòng, nếu có thể. Bạn học nhanh hơn rất nhiều khi được nghe các cuộc nói chuyện ngẫu nhiên và thảo luận kỹ thuật hàng ngày - điều bạn đánh mất khi làm ở nhà. Nếu bạn là nhà tuyển dụng từ xa, bạn cần làm nhiều hơn để bù lại điều đó, nên kết nối với những người đã làm việc này thành công để xin lời khuyên.

Các công ty cũng không nên chỉ tuyển một kỹ sư junior. Nếu bạn tuyển, hãy tuyển hai hoặc ba người. Họ sẽ có đồng đội, đỡ cảm thấy cô lập và ngại ngùng.

Sẽ không có ai đến giải quyết vấn đề thay chúng ta

Điều này chỉ có thể thay đổi nếu các kỹ sư và quản lý kỹ thuật trong ngành chúng ta đứng lên và coi đó là vấn đề của chính mình.

Các chương trình tuyển kỹ sư mới vào nghề đều bắt nguồn từ một kỹ sư nào đó đã chiến đấu để có được nó. Các kỹ sư - đôi khi là các quản lý kỹ thuật - là người đã nêu ra vấn đề, đấu tranh xin nguồn lực, thiết kế chương trình, phỏng vấn và tuyển dụng kỹ sư junior, rồi kết nối họ với mentor. Đây không phải là một dự án quá tầm, mà hoàn toàn nằm trong khả năng của đa số kỹ sư có động lực và kinh nghiệm (và cũng rất có ích cho sự nghiệp của bạn).

Bộ phận tài chính sẽ không đấu tranh cho điều này. Lãnh đạo cấp cao thì càng khó. Người càng dễ coi kỹ sư như nguồn lực thay thế được thì càng khó hiểu vì sao điều này lại quan trọng.

AI sẽ không đến để giải quyết hết vấn đề của ta hay viết hết mã cho ta - mà ngay cả nếu nó làm được, điều đó cũng không quan trọng. Viết mã chỉ là một phần rất nhỏ của công việc kỹ sư phần mềm, và có thể là phần dễ nhất. Chỉ chúng ta mới có đủ bối cảnh và uy tín để thúc đẩy những thay đổi mà chúng ta biết là nền tảng cho đội ngũ tuyệt vời và năng lực kỹ thuật xuất sắc.

Những đội ngũ tuyệt vời chính là nơi tạo nên những kỹ sư tuyệt vời. Không ai hiểu điều đó rõ hơn kỹ sư và quản lý kỹ thuật. Đã đến lúc chúng ta lên tiếng và bắt tay vào hành động.

Nguồn: StackOverFlow