Phá Kén

Chào mọi người! Dưới đây là thông tin mình thu thập có được tổng hợp từ 1 anh techlead. Và đây là những nhận định, lời khuyên mà anh ấy muốn truyền đạt. Không dài dòng nữa, chúng ta hãy bắt đầu luôn thôi! (miêu tả dưới giọng văn của anh ấy)

Sau một thời gian vắng bóng trong việc viết lách, mình đã quay lại, cố gắng bắt kịp nhịp độ. Mình muốn nhấn mạnh rằng những trải nghiệm được chia sẻ ở đây dựa trên kinh nghiệm học tập và làm việc của chúng ta. Do đó, cần nhớ rằng những gì được mô tả tại đây có thể chỉ đại diện cho một phần nhỏ của thực tế và không nên được hiểu như một công thức dứt khoát cho các quy trình, thủ tục hay dịch vụ cụ thể.

Hiện tại, chúng ta đang rất hào hứng với giai đoạn mới trong sự nghiệp của mình. Chúng ta đã học được rất nhiều và muốn chia sẻ một phần của hành trình này với cộng đồng. Hy vọng rằng những thông tin được trình bày ở đây sẽ mang lại giá trị lớn cho người đọc.

Con Người Trước Tiên – Tầm Quan Trọng của Kỹ Năng Mềm

Khi tham gia vào quá trình tuyển dụng đầu tiên cách đây vài năm, chúng ta còn nhớ rất rõ các bước gần như nhàm chán mà mình phải trải qua: phỏng vấn với bộ phận nhân sự, bài kiểm tra thực hành, phỏng vấn với trưởng nhóm kỹ thuật và cuối cùng là phỏng vấn với quản lý. Trong suốt sự nghiệp làm developer của mình, chúng ta đã tham gia nhiều buổi phỏng vấn với các mô hình khác nhau. Lúc đó, chúng ta luôn cảm thấy không thoải mái khi phải phỏng vấn với nhân sự. Chúng ta không hiểu tại sao, nghĩ rằng: “Nếu mình có thể làm tốt những gì yêu cầu trong bài kiểm tra kỹ thuật, mình đã thể hiện đủ năng lực cho vị trí này rồi.”

Khi chúng ta đảm nhận vai trò lãnh đạo kỹ thuật, một trong những trách nhiệm là hợp tác với bộ phận nhân sự (đúng, là những người mà trước đây chúng ta không hiểu lý do tại sao lại phải tham gia vào quy trình tuyển dụng) để chuẩn bị bài kiểm tra kỹ thuật và xác định hình thức phỏng vấn cho hai ứng viên bắt đầu trong mảng backend. Chúng ta đã nghĩ rằng mình biết những gì một developer mới vào nghề trong mảng backend cần thể hiện và những gì sẽ được coi là điểm khác biệt trong bài kiểm tra. Tuy nhiên, điều chúng ta không ngờ đến là, ngoài tầm quan trọng của code, còn có các yêu cầu khác vượt ra ngoài việc hoàn thành dự án: làm thế nào để đánh giá ứng viên về mặt giao tiếp? Họ có quan tâm đến vị trí này không? Và bối cảnh mà họ trình bày có thể ảnh hưởng đến sự phù hợp của họ với vị trí được đề xuất như thế nào? Những câu hỏi này và nhiều câu hỏi khác đã trở nên quan trọng như code mà hai ứng viên trình bày, điều mà chúng ta chưa từng xem xét trước đây trong những năm đầu làm developer.

Chúng ta nhớ đã ngồi ở bàn họp để đưa ra quyết định cuối cùng và hơi ngạc nhiên khi nhận ra rằng rất ít điều được thảo luận về kỹ năng kỹ thuật của từng ứng viên. Một phần do họ là ứng viên mới vào nghề, nên việc kỹ năng kỹ thuật của họ chưa phát triển đầy đủ là điều dễ hiểu và không phải là trọng tâm chính của cuộc thảo luận.

Tuy nhiên, ngay cả đối với những vị trí cấp cao hơn, đặc biệt là vị trí senior, thì việc cân nhắc các kỹ năng như giao tiếp, viết tài liệu, khả năng thích ứng, sự chủ động và các kỹ năng mềm khác thường được nhắc đến là vô cùng quan trọng. Những kỹ năng mềm này là yếu tố cơ bản và có thể quyết định sự thành công trong vai trò này, bên cạnh các kỹ năng kỹ thuật. Thật vậy, đó là điểm tiếp theo chúng ta muốn nói đến.

Sự khác biệt giữa Junior và Senior (Không, không phải cấp trung).

Chúng ta biết có rất nhiều tranh luận về ý nghĩa và sự phân loại các thuật ngữ liên quan đến cấp độ kinh nghiệm, như “senior.” Một số người nói rằng “senior được xác định bởi số năm kinh nghiệm,” những người khác lại cho rằng “ở một số công ty, bạn có thể trở thành senior sau một năm.” Cũng có những người nói rằng “không có sự phân biệt rõ ràng giữa junior và senior” hoặc “senior chỉ review code và phê duyệt PRs.” Một số tuyên bố này thật hài hước, một số khác có một chút sự thật. Sự thật là khái niệm “senior” rất đa dạng và không phải là việc của chúng ta để định nghĩa một tiêu chuẩn chung, nhưng chúng ta có thể đưa ra một số hướng dẫn để hiểu phân loại này một cách cá nhân hơn.

Việc trở thành senior không chỉ liên quan đến kiến thức kỹ thuật, mặc dù điều này chắc chắn rất quan trọng. Một senior thực thụ, hoặc ít nhất là một senior giỏi, là người có khả năng giải quyết các vấn đề phức tạp cả về code và kiến trúc hệ thống. Duy trì chất lượng code, tuân thủ các thực hành phát triển tốt và có kiến thức về quản lý dự án là những khía cạnh then chốt.

Sự khác biệt chính là một senior phải có khả năng thực hiện tất cả điều này một cách độc lập và, quan trọng hơn, hợp tác với các nhóm ở các cấp độ và lĩnh vực khác nhau để hoàn thành dự án tốt nhất có thể. Hơn nữa, một senior thực thụ (hoặc ít nhất là những người giỏi nhất) không chỉ dẫn dắt và hướng dẫn nhóm, mà còn phát triển và chuẩn bị các developer khác để đảm nhận các vị trí và trách nhiệm mới.

Trải nghiệm đầu tiên khi lãnh đạo một dự án

Khi chúng ta đảm nhận dự án đầu tiên, sếp của chúng ta biết rằng chúng ta chưa từng lãnh đạo bất kỳ dự án nào trước đó. Chúng ta chỉ tham gia phát triển và làm một số việc để dễ dàng hóa quá trình giao tiếp với quản lý. Câu hỏi đầu tiên mà sếp hỏi chúng ta là: “Có bao nhiêu người và loại người nào sẽ đủ để hoàn thành dự án?” Chúng ta không biết câu trả lời ngay lập tức, đó là một câu hỏi rất phức tạp. Vì dự án chỉ mới trong giai đoạn phác thảo, chúng ta không có ý tưởng gì về stack, mất bao lâu để hoàn thành từng nhiệm vụ và các chỉ số khác mà những người trên muốn biết. Chúng ta đã thực hiện một nghiên cứu toàn diện để có thể đưa ra câu trả lời vào ngày hôm sau về nhiều phương pháp quản lý dự án: Pert, Planning Poker. Chúng ta đã cùng nhau chọn lựa phương pháp phù hợp nhất và thử thách bắt đầu. Cho mỗi thành viên trong nhóm, đâu là nền tảng phát triển tốt nhất, đâu là stack tốt nhất để sử dụng, hệ thống kiến trúc sẽ hoạt động như thế nào, nghiên cứu các giải pháp khác trên thị trường, theo dõi trình độ của từng developer, các cuộc họp, cuộc họp và thêm các cuộc họp với ban quản lý.

Miêu tả hình ảnh

Khi chúng ta nhận ra, chúng ta ngày càng xa rời code hơn. Vai trò của chúng ta trở thành gợi ý cải tiến và sửa chữa một số lỗi nghiêm trọng để dự án có thể hoạt động, hoặc ít nhất cung cấp một nền tảng vững chắc cho các developer bắt đầu. Phần còn lại của công việc liên quan đến giao tiếp với các developer, phân chia nhiệm vụ, theo dõi chỉ số và, cơ bản, một mắt nhìn vào Asana (để ước tính thời gian hoàn thành dự án) và một mắt nhìn vào Meet để đảm bảo micro của mình không bị bật và không có gì ngoài ý muốn “vô tình” bị lộ ra.

Kết luận và nhìn lại quá khứ – đến thầy với tình cảm

Chúng ta bắt đầu sự nghiệp như một thực tập sinh phát triển và điều thú vị là — và bạn có thể thấy điều này hơi mâu thuẫn — chúng ta không có bất kỳ kinh nghiệm cụ thể nào (ít nhất là không được ghi chép chính thức trong hồ sơ việc làm) mà sẽ phân loại chúng ta là developer junior, full hay senior. Phần lớn kinh nghiệm mà chúng ta tích lũy được đến từ các dự án cá nhân và nghiên cứu tại trường. Đó là một quá trình dần dần cho đến khi chúng ta nhận ra rằng kỹ năng của mình đã phát triển kể từ những ngày đầu.

Nhưng đúng vậy, chúng ta đã làm việc rất nhiều như một developer ở các cấp độ khác nhau và có cơ hội gặp gỡ các kiểu senior khác nhau trong suốt sự nghiệp:

Senior rất giỏi và hiệu quả, nhưng ít giao tiếp, người giải quyết vấn đề mà không đưa ra giải thích về cách tiếp cận của mình.
Senior xuất sắc trong giao tiếp và giảng dạy, nhưng thường bị quá tải với các nhiệm vụ khẩn cấp và không có thời gian để giảng dạy.
Senior đam mê việc thiết kế phức tạp và tập trung công nghệ, nhưng luôn hoàn thành đúng hạn và giao những gì họ hứa.
Điều quan trọng nhất là, mặc dù có những khuyết điểm chính đáng (mặc dù có thể, rất khó để cân bằng các yêu cầu), tất cả những chuyên gia này đều có điều gì đó quý giá để dạy. Những trải nghiệm này đã giúp định hình sự nghiệp của chúng ta và mang lại cho

chúng ta cái nhìn rõ ràng về những gì hiệu quả và không hiệu quả trong việc phát triển hệ thống.