Tại sao nhà sáng lập Rails tự động loại 80% ứng viên kỹ sư phần mềm

I. Giới thiệu

Gần đây tôi có ngồi lại với David Heinemeier Hansson để hỏi anh ta tại sao lại thuê những kỹ sư phần mềm này mà không phải là những kỹ sư phần mềm khác. Nếu bạn không biết anh ấy, David là nhà sáng lập của Ruby on Rails và CTO của Basecamp. Câu trả lời của anh ấy đã khiến tôi sốc toàn tập. Không phải bởi vì phương pháp anh ấy sử dụng, mà bởi vì sai lầm mà 80% ứng viên mắc phải khiến họ tự động bị loại khỏi cuộc chơi. 20% ứng viên bị loại còn lại bởi những lí do còn sốc hơn nữa. (Tôi biết 80 + 20 là 100%. Tôi làm tròn giả định một người trong số 150+ được chấp nhận)

Tin tốt là gì nhỉ? Những sai lầm này cực dễ tránh một khi bạn biết tới chúng. Điều này có nghĩa là bạn có thể dễ dàng bước qua 2 bước đầu tiên trong quy trình phỏng vấn của Basecamp (ít nhất là, cho vị trí kỹ sư phần mềm). Chắc chắn, bước thứ 3 và cũng là bước cuối cũng chính là bước thử thách hơn cả (như bạn sắp thấy), nhưng bạn đã tăng cơ hội vượt qua của mình một cách mạnh mẽ nếu như bạn vượt qua được 2 bước đầu tiên. Tôi phải viết bài này, bởi vì có cảm giác như tôi có thông tin nội bộ giúp bạn có lợi thế hơn hẳn đa số các ứng viên. Cùng bắt đầu nào.

II. ĐƠN XIN VIỆC VÀ THƯ GIỚI THIỆU - 80% HỎNG Ở ĐÂY

Tôi chắc chắn bạn đã thấy cả TẤN lời khuyên dành cho đơn xin việc và thư giới thiệu trên internet. Tuy thế, 80% số người bị loại trong quá trình tuyển chọn chỉ đơn giản là do đơn xin việc và thư giới thiệu của họ. Thế nên là hiển nhiên điều này vẫn cần được đề cập đến. Phần điên rồ nhất là tôi đã được nhiều “nhà tuyển dụng kĩ thuật” cho lời khuyên trong quá khứ để “cải thiện đơn xin việc”, và lời khuyên của họ thì trái ngược hoàn toàn với những gì David tìm kiếm. Những thứ như:

• Học vấn cần được để lên cao nhất
• Thêm GPA
• Liệt kê những nơi bạn đã làm việc theo thứ tự từ gần tới xa

Nếu bạn muốn có một công việc ở Basecamp, bạn sẽ vẫn bị loại khi có những điều trên. Trước hết, David không tìm thấy thứ gì đó có ích biểu thị học vấn khi tìm kiếm lập trình viên. Điều tương tự cũng xảy đến với những người làm việc ở các công ty lớn khác. Thứ 2 là không có gì trong những thứ trên cung cấp thông tin mang tính hành động cả. “Tôi sẽ làm gì với những thứ ấy? Tôi nghĩ đơn xin việc kiểu trên khá là vô giá trị khi đánh giá khả năng của một lập trình viên.” Trước khi bạn giơ nắm đấm về phía tôi và nói rằng tôi sai bởi vì công ty X muốn GPA được liệt kê, hoặc công ty Y muốn học vấn là trên hết, đọc đọan dưới đây đã. Với thư giới thiệu, lí do chính cho việc bị loại đến tới thực tế là người ta chỉ gửi đơn xin việc mang tính đại khái chung chung. Họ không thể hiện được sự quan tâm dành cho công ty. Điều này cũng xảy ra với đơn xin việc của bạn đấy. Nó cần được làm riêng cho công ty mà bạn ứng tuyển. Làm thế nào để những thứ bạn liệt kê trên đơn xin việc có liên quan đến công ty mà bạn ứng tuyển? Hãy nghiên cứu về công ty và tìm hiểu xem họ đang làm gì, sau đó làm nổi bật việc kinh nghiệm và sự quan tâm của bạn phù hợp với những điều đó.

III. CODE CỦA BẠN QUÁ LỞM! - 20% TRƯỢT Ở CHỖ NÀY

Bạn có thể thường đưa ra ý kiến về kĩ năng của ai đó sau khi nhìn khối lượng công việc thực tế của họ.

• Một người quan tâm bao nhiêu tới việc trình bày code?
• Một người siêng năng như thế nào đối với chất lượng code của họ?

“Rất nhiều người trượt bài kiểm tra này.” Rất nhiều code lùi đầu dòng một cách tệ hại, đặt tên một cách kém cỏi hay scope tệ lậu. Thậm chí có những người còn submit file với code nằm trong comment! “Họ submit một đống code mà không thèm dọn dẹp. Nó như kiểu thích mời người trao công việc tiềm năng trong tương lai của bạn tới nhà và bạn đếch thèm quan tâm tới việc dọn dẹp. Bạn có vài người ngủ lại từ đêm qua và tất thảy các thứ loại hầm bà lằng bừa bộn trên sàn.” Điều này thực sự làm não tôi muốn nổ tung. Tôi thậm chí cố tìm lí do biện minh bằng cách hỏi là nếu như đó là code anh ấy vừa kéo từ tài khoản Github khác về thì sao, nhưng anh ấy chắc chắn với tôi rằng đó không phải là code kéo về mà là code bạn submit lên.

IV. CODE CỦA BẠN SẠCH, NHƯNG KHÔNG XỊN

“Ý anh là gì khi nói là code của tôi không xịn?” Thật bất khả thi để trả lời câu hỏi này trong một email. Nghĩ về nó như thể là một truyện ngắn, và tác giả hỏi tại sao bạn nghĩ truyện dở. Bạn không thể thực sự chỉ ra một đoạn nào cả, đơn giản là cả câu truyện không hay, vậy thôi. Cải thiện code của bạn. Tôi sẽ tệ đến mức nào nếu tôi cứ để như thế ? Tôi sẽ không bao giờ làm vậy… Tôi sẽ tính phí 100$ nếu bạn muốn biết ý của tôi là gì bằng code thối. Được rồi, được rồi, đùa đủ rồi đấy… ‘Code thối’ hầu hết lại chỉ là ở mấy thứ cơ bản, kiểu như:

• Có những method dài 15 dòng và làm 5 việc khác nhau
• Hàng tấn biến toàn cục
• Biến được đặt tên một cách tệ hại
• Comment tệ

Vậy làm thế nào để bạn học và cải thiện code của mình? Luyện tập, luyện tập, luyện tập. Và đọc nữa. David đích thân khuyên đọc cuốn Smalltalk: Best Practice Patterns. Tôi khuyên đọc Clean Code của Robert C.Martin. Một cuốn khác là: Refactoring: Improving the Desgin of Existing Code. Một bạn đọc khác thì khuyên đọc cuốn Practical Object-Oriented Desgin in Ruby của Sandi Metz. Những cuốn sách này kiểu như những cuốn dạy bạn cách viết code xịn. Chúng nói về cách đặt tên đúng, bố cục đúng, đại loại thế. Điều này có nghĩa là thông qua rất nhiều code ví dụ, chứ không phải chỉ có lý thuyết suông.

V. THÊM NỮA: ĐÓNG GÓP MÃ NGUỒN MỞ

Trong khi David nhấn mạnh rằng bạn không cần có đóng góp vào các dự án mã nguồn mở, nhưng nếu có thì sẽ là lợi thế rất lớn. Nó không chỉ giúp bạn có thêm kinh nghiệm thực tế trong việc làm cho code của bạn tốt hơn, mà còn giúp bạn kết nối nữa. Ví dụ: Trong bài kiểm tra cuối cùng trong quá trình tuyển dụng, Basecamp bắt buộc bạn phải viết code cho họ. Họ trả tiền cho bạn làm dự án ngoài lề để họ có thể đánh giá bộ kĩ năng của bạn. Một khi bạn đã trải qua quy trình đó với một số lượng ứng viên, sẽ rất rõ ràng tìm ra người công ty cần tuyển dụng. Bạn được nhìn cách họ làm việc, suy nghĩ và giải quyết vấn đề. Vài người, nhờ đó, được tuyển thẳng vào đội ngũ đóng góp cho lõi của Rails. Điều này là hợp lý, bởi David có thể dễ dàng đánh giá kĩ năng của ai đó nếu họ đã từng đóng góp cho Rails.

VI. HÀNH ĐỘNG CẦN LÀM NGAY

Trước khi bạn gửi đơn xin việc và thư giới thiệu, hãy tự hỏi bản thân điều này: Những thông tin này liên quan như thế nào tới công ty/ công việc mà mình định ứng tuyển. Trước khi khoe code với một nhà tuyển dụng, kiểm tra kĩ từng dòng và dọn dẹp chúng: Có nhiều tên có ý nghĩa hơn, xoá code nằm trong comment, bỏ comment vô nghĩa nhưng đừng lạm dụng quá. Để cải thiện code của bạn: Hiển nhiên, tiếp tục code. Nhưng đừng chỉ tiếp tục code trong mù quáng, hãy tuân thủ các chuẩn chung kể cả khi điều đó khiến bạn tốn nhiều thời gian hơn và làm chậm tiến độ của bạn. Đọc những cuốn như Smalltalk: Best Practice Patterns, Clean Code của Robert C.Martin, Practical Object-Oriented Desgin in Ruby của Sandi Metz. Nếu bạn có lời khuyên về cuốn sách nào, tôi vô cùng mong muốn được nghe những lời khuyên đó. Đừng ngần ngại chia sẻ ở phần bình luận nhé!

Cảm ơn đã theo dõi

Nguồn: Sưu tầm

Người dịch: Bùi Mạnh Cường