Điểm khác biệt giữa một junior engineer và senior engineer

Khả năng viết code thô rất quan trọng, nhưng chúng ta thường bỏ lỡ một số lý do lớn khiến các công ty thường sẵn lòng trả cho senior engineer một lượng tiền lớn (khi các junior engineer sẵn sàng làm việc mới mức lương thấp) như:

  • Mức độ “có thể bảo trì” của code của bạn? Các lập trình viên khác có liên tục gọi bạn và yêu cầu bạn giải thích cách mọi thứ hoạt động không? Tên biến của bạn có mang tính mô tả không? Các phương pháp của bạn có rõ ràng không? Khi bạn sao chép và dán nhiều dòng code, bạn có trích xuất chức năng đó thành một dịch vụ có thể tái sử dụng không?
  • Mọi người có nhận được gì từ những nhận xét bạn để lại trên các pull request của họ không? Bạn đưa ra những lời chỉ trích mang tính xây dựng hay chỉ đơn thuần chỉ trích một cách cục súc? Khi bạn tìm thấy lỗ hổng trong kiến ​​thức của ai đó, bạn chỉ nói “thay đổi dòng này từ ABC thành XYZ” hay bạn có khả năng hướng dẫn họ xem tại sao cách tiếp cận của họ không tối ưu và để họ cảm thấy tốt hơn với tư cách một lập trình viên? Cốt cũng chỉ muốn họ học được một điều gì đó mới.
  • Nếu 100.000 người dùng tạo tài khoản ngay hôm nay, code của bạn có bắt đầu gặp phải hàng loạt sự cố khiến chương trình ngừng đột xuất và 500 lỗi đi kèm không? Bạn có chắc chắn rằng PR (pull request) của bạn sẽ khắc phục được vấn đề? Bạn có biết cách định chuẩn những thay đổi của mình và chứng minh điều đó không?
  • Bạn giỏi đến mức nào trong việc chuyển các vấn đề chuyên sâu về kỹ thuật thành ngôn ngữ đơn giản mà mọi bộ phận khác trong công ty có thể hiểu được? Liệu bạn có để tuôn ra một loạt các biệt ngữ kỹ thuật khi giải thích cho phòng marketing lý do tại sao một tính năng đó lại không thực sự khả thi?
  • Bạn có hiểu biết sâu sắc về lập trình hướng đối tượng? Kiến trúc hệ thống mà bạn nghĩ ra có “hợp lý” không?
  • Khả năng viết lách của bạn thế nào? Bạn có thể khiến mọi người hiểu ý của mình khi trả lời email hay mọi người thường đến bàn làm việc của bạn sau khi bạn nhấn Gửi để hỏi thêm về văn cảnh?
  • Bạn có chủ động chia sẻ với quản lý cấp cao những ý tưởng giúp nhóm của bạn hoạt động hiệu quả hơn không? Khi bạn muốn thấy một thay đổi trong quy trình được thực thi, bạn có khả năng giải thích lợi ích cho tất cả các bên liên quan không? Bạn có khiến mọi người hào hứng với sự thay đổi này không? Bạn có thể làm theo và đảm bảo quy trình mới thực sự được chấp nhận không?
  • Bạn có tôn trọng thời gian của người khác không? Khi bạn yêu cầu ai đó giúp bạn giải quyết một vấn đề, bạn có thể mô tả chính xác phần codebase mà bạn đang gặp sự cố (số dòng đang đưa ra các ngoại lệ, mô tả sáu cách tiếp cận bạn đã thực hiện trước khi họ mất thời gian thử lại, gửi cho họ các dấu vết ngăn xếp (stack traces) có liên quan) không? Họ có phải dò hỏi tất cả thông tin này của bạn không? Bạn đã chuẩn bị đầy đủ thông tin cần thiết trước khi đồng nghiệp đến giúp đỡ bạn chưa?
  • Khi xác định phạm vi các dự án lớn với những phòng ban khác, bạn có câu hỏi xoáy sâu về các tính năng mới mà bạn sẽ phát triển chưa? Bạn có thể thêm vào từng trường hợp cạnh (edge case) trước khi bắt đầu viết code không? Bạn có thể nhận ra rằng dự án đang vượt phạm vi và dừng nó trước khi toàn bộ nhóm bị mắc kẹt trong trong văn phòng nguyên buổi chiều thứ bảy?
  • Bạn có thể thực hiện đa nhiệm tốt đến mức nào? Bộ não của bạn có bị quá tải không? Tương tự như vậy, khi làm việc trên những tính năng lớn đó, những tính năng lên đến hơn 50 tệp tin… bạn có thể ghi nhớ tất cả chúng cùng một lúc không? Bạn đã phát triển thói quen ghi chú vững chắc chưa? Làm cách nào để bạn có kế hoạch theo dõi năm triệu thứ sẽ xuất hiện trước khi bạn rời đi hôm nay?
  • Bạn phản ứng như thế nào khi một đoạn code mà bạn đã viết khiến trang thanh toán bị lỗi và trưởng nhóm của bạn phải hủy kế hoạch ăn tối để họ có thể ở lại muộn và giúp bạn khắc phục sự cố? Bạn có xúc động không? Bạn vẫn có thể suy nghĩ duy lý? Bạn có thể tách rời khỏi tình huống và nhắc nhở bản thân rằng mọi lập trình viên trên hành tinh này đều gửi code lỗi vài ngày một lần không?
  • Bạn có hiểu cách kinh doanh hoạt động không? Bạn có hiểu tại sao các lập trình viên có thể đòi hỏi các mức lương điên rồ như vậy, ngay cả khi tỷ lệ thất nghiệp lên đến hai con số không? Tại sao lập trình lại là một bộ kỹ năng có giá trị như vậy? Tại sao khách hàng sẵn sàng trả cho công ty của bạn 50.000 đô/năm cho một số biểu mẫu web siêu cơ bản? Bạn có cảm thấy như họ đang bị chặt chém?
  • Những người cấp cao có thể tin tưởng khi bạn phỏng vấn các ứng viên không? Bạn có giỏi nhận định với lượng thông tin hạn chế và hình dung xem liệu họ có phù hợp với nhóm không? Bạn có thể nhận ra khi nào một ứng viên kỹ thuật xuất sắc không hòa hợp với văn hóa công ty không? Bạn có đề nghị rằng ta nên bỏ qua họ không? Tương tự như vậy, ngay cả khi bạn biết, sau 5 phút trao đổi qua Zoom, rằng họ không nhận được lời đề nghị làm việc, liệu bạn đảm bảo rằng họ vẫn có trải nghiệm tích cực khi trò chuyện với bạn không? Từ ngữ thực sự trôi qua nhanh chóng trên internet.
  • Vào những ngày cuối năm. Bạn đang bị mắc kẹt trong văn phòng. Bạn đã hơi điên rồ trong năm nay vì đã sử dụng hết tất cả ngày nghỉ phép của mình khi chỉ mới giữa tháng 9. Những người cấp trên được ra khỏi thành phố để nghỉ lễ. Bạn vẫn đi làm đúng giờ chứ? Bạn định làm đại cho xong khi sếp không có mặt để phạt bạn? Họ có nên giữ bạn khi bạn không làm việc chăm chỉ?
  • Chi phí cơ hội là một điều có thật. Bạn giỏi như thế nào trong việc cân bằng nợ kỹ thuật (technical debt) và đưa công việc kinh doanh tiến về phía trước? Bạn có cải tiến mọi vấn đề nhỏ về kiểu code mà bạn tìm thấy không? Có thể hơi đau đớn khi nói “đoạn code này thật khó chịu, nhưng nó hoạt động, sẽ mất bốn giờ để làm sạch, tốt hơn hết là tôi nên dành thời gian để xây dựng tính năng khác mà rất nhiều khách hàng đang mong mỏi”.
  • Bạn có biết cách góp ý cho người quản lý về hiệu suất của họ không? Bạn có mối quan hệ làm việc tốt với họ không? Bạn có xem họ là kẻ thù không? Bạn có đang chủ động cố gắng làm cho cuộc sống của họ dễ dàng hơn không? Giảm mức độ căng thẳng của họ? Bạn có bao giờ nói những từ "có thứ gì khó chịu mà tôi có thể gỡ rối giúp không?" Công ty thuê người đó là có lý do. Họ có thể có nhiều kinh nghiệm và trình độ hơn bạn nghĩ.
  • Bạn giỏi đến mức nào trong việc xử lý các vấn đề phát sinh? Bạn có hoảng hốt và đứng hình mỗi khi biết mọi thứ đã vỡ lẽ (AWS ngừng hoạt động khi trang web bị sập, vô tình làm mất các bảng hóa đơn khách hàng, một số lỗi gây rò rỉ dữ liệu giữa các tài khoản người dùng khác nhau) không? Bạn có suy sụp vì áp lực hay bạn có thể giữ được bình tĩnh và giao tiếp hiệu quả với các bộ phận khác trong lúc khắc phục sự cố không?

Hầu hết mọi lập trình viên non trẻ thường gặp vấn đề trong giao tiếp với mọi người, không thể kìm được các cơn giận vô cớ khi tiếp nhận những lời chỉ trích mang tính xây dựng, tranh cãi nảy lửa vô nghĩa với sếp, lãng phí vô số giờ cho các vấn đề không quan trọng chút nào, luôn dè bỉu và than vãn về lý do mình xứng đáng nhận được mức lương tốt hơn.

Các senior engineer chỉ đơn giản là đánh bay các vấn đề

Danh sách những điều kể trên giúp bạn nhìn nhận lại vị trí của bản thân hiện tại nhưng không đánh đồng tất cả lập trình viên, có thể bạn đang ở vị trí Junior Engineer nhưng lại có cách hành xử đỉnh đạc của một Senior, hoặc ngược lại. 

Về cơ bản, một lập trình viên đã ở vị trí Senior sẽ như thế nào? Họ làm giảm căng thẳng. Họ đúng deadline. Họ biết cách viết code bảo trì, thứ mà sẽ chịu được thử thách của thời gian. Họ đáng giá hơn. Họ đưa ra (phần nào) các ước tính chính xác. Họ có thể phát hiện ra những sai sót trong quy trình hiện tại và kêu gọi mọi người tiếp thu ý tưởng của họ để cải thiện nó. Họ có thể hướng dẫn cho người mới tốt nghiệp. Họ sẽ không chửi thề trong cuộc gọi hội nghị với khách hàng lớn nhất của bạn.

Nhiều người quyết định ngừng leo lên bậc thang vào thời điểm này. Lập trình là một trong những nghề nghiệp kích thích tinh thần nhất hiện nay, và rất nhiều doanh nghiệp sẵn sàng chi rất nhiều tiền cho những người kỳ cựu có thể giữ cho mọi thứ hoạt động trơn tru.

Sẽ luôn có một nhóm nhỏ các lập trình viên cuối cùng sẽ quyết định treo IDE vào một ngày nào đó, và bắt đầu chuyển hướng sang quản lý. 

Nếu bạn có kỹ năng giao tiếp vững chắc và thực sự muốn dành cả ngày cho các cuộc họp (để bạn có thể loại bỏ phiền nhiễu và giúp đồng đội tìm thêm thời gian để hoàn thành công việc hiệu quả), đó có thể là một công việc đáng làm.

Tất cả bắt đầu với việc những senior engineer cố gắng dành ra vài giờ mỗi tuần (giữa các phiên viết code nặng) để tập trung vào:

  • Làm sạch và rõ cách họ thực hiện các cuộc phỏng vấn kỹ thuật, để họ có thể có tỷ số tín hiệu cực đại trên nhiễu (signal-to-noise ratio) tốt hơn với các ứng viên (cải thiện các câu hỏi họ đặt ra, xem xét lại các mẫu email của họ, họ có nên yêu cầu làm bài test không, mô tả công việc có còn chính xác không, ở đâu họ đăng quảng cáo, họ sẽ trả lời bài đăng tuyển này như thế nào nếu họ đang tìm việc, làm cách nào để họ cung cấp cho các ứng viên hiểu biết sâu hơn về văn hóa công ty và chu trình phát triển trước khi họ đưa ra quyết định).
  • Làm việc với nhóm sản phẩm để xác định phạm vi công việc sắp tới một cách kỹ lưỡng, để giảm thiểu yêu cầu qua lại giữa họ và lập trình viên xử lý vấn đề đó trên JIRA.
  • Tổ chức các hoạt động xây dựng nhóm và các buổi ăn trưa với nhóm.
  • Góp ý với CEO/CTO khi các mục tiêu hàng quý sắp tới mà họ đang xem xét nghe có vẻ hơi lạc quan và rất có thể sẽ khiến những người còn lại trong nhóm kiệt sức và bắt đầu rải hồ sơ xin việc của họ khắp nơi.
  • Thực hiện các cuộc gọi xác nhận hàng tuần với một số khách hàng lớn nhất (để tự mình trả lời tất cả các câu hỏi liên quan đến kỹ thuật và đảm bảo mối quan hệ luôn tốt đẹp).
  • Tìm ra các lỗ hổng trong kiến ​​thức của các lập trình viên khác và cho họ tiếp cận với các kỹ thuật mà họ đang bỏ lỡ (theo cách khiến họ hào hứng mở rộng bộ kỹ năng của mình): thao tác các tệp CSV với vim macro, sử dụng triệt để 2–3 chương trình chữ cái để trong chương trình giao diện cửa sổ dòng lệnh linux (linux terminal), các lệnh SQL nâng cao, cách làm cho mô tả PR mang tính mô tả hơn, giải thích cách hoạt động của bộ cân bằng tải (balancer), trò chuyện về sự khác biệt giữa merging và rebasing,…
  • Giúp nhóm thiết kế bổ sung các tính năng dễ phát triển trước khi họ dành hàng giờ để chuyển đổi wireframe thành một mô hình có độ trung thực cao (high-fidelity mockup).
  • Cải thiện quy trình để cho các bộ phận khác biết khi nào các tính năng mới bị giảm (viết ghi chú phát hành tốt hơn, trả lời bất kỳ câu hỏi nào họ có trong buổi giới thiệu sản phẩm nội bộ hàng tuần, giúp họ viết tài liệu đối ngoại mà khách hàng sẽ hiểu), vì với một tính năng mà không ai biết thì sẽ không giải quyết được bất kỳ vấn đề thực tế nào.

Danh sách vẫn tiếp tục, và hầu hết trong số đó không yêu cầu Visual Studio. Rất nhiều senior engineer sẽ đi theo con đường như thế này sau một vài năm, và cứ tin đi, trước khi bạn nhận ra điều đó thì bạn đã có sáu nhân viên báo cáo cho bạn rồi.

 

Tổng hợp việc làm IT - Software trên VietnamWorks
VietnamWorks InTECH
Theo Jacob Comer