Tại sao 80% các ứng viên kỹ sư phần mềm bị người sáng lập Rails từ chối?

Dạo gần đây, tôi đã có dịp ngồi xuống với David Heinemeier Hansson và hỏi anh ta lý do tại sao anh ta lại thuê những kỹ sư phần mềm này mà không phải là những khác.

Nếu bạn không biết anh ta, David là nhà sáng lập của Ruby on Rails đồng thời là CTO của Basecamp

Câu trả lời dưới đây của anh ấy đã làm tôi kinh ngạc.

Không phải vì những phương pháp hay câu hỏi mà anh ấy sử dụng khi phỏng vấn, mà bởi vì 80% sai lầm bắt nguồn từ ứng viên đã khiến họ tự đánh mất cơ hội của mình.

20% còn lại bị out còn vì những lý do thậm chí gây sốc hơn.

(Tôi biết 80+20 là 100%. Tôi đang làm tròn lên giả định chỉ có 1 người trên 150 được chấp nhận)

Tin tốt lành ở đây? Là những sai làm này dễ dàng tránh được khi bạn biết về chúng. Điều này có nghĩa là bạn có thể dễ dàng vượt qua được 2 vòng đầu tiên của quá trình tuyển dụng Basecamp cho vị trí kỹ sư phần mềm, ít nhất là như vậy. Chắc chắn, vòng thứ ba và vòng cuối cùng sẽ là nhiều thử thách hơn (dĩ nhiên là vậy rồi), nhưng bạn sẽ tăng tỷ lệ pass hơn khi vượt qua 2 vòng đầu. Tôi đã phải viết bài này, bởi vì tôi cảm thấy đây gần như là 1 thông tin nội bộ, điều mà có thể mang lại lợi thế cho đa số các ứng viên khi biết được. Chia sẻ thông tin đến ScaleYourCode đầu tiên là nhiệm vụ của tôi - nơi để cung cấp cho bạn những thông tin từ các chuyên gia, không cần biết bạn ở đâu và tài chính của bạn là gì.

Đi nào.

CV xin việc - 80% thất bại

Tôi chắc chắn bạn đã nhìn thấy 1 tấn lý lịch và lời khuyên về vấn đề này này trên internet. Tuy nhiên, 80% số người bị loại ngay từ đầu chỉ vì hồ sơ xin việc và thư giới thiệu của họ. Vì vậy, rõ ràng, điều này cần được đề cập ở đây. Thật điên rồ là tôi đã lắng nghe nhiều "nhà tuyển dụng kỹ thuật " những người đã đưa ra lời khuyên cho tôi trong quá khứ để "cải thiện hồ sơ của tôi", và những lời khuyên này của họ là hoàn toàn trái ngược với những gì David tìm kiếm. Những thứ như:

• Học vấn nên đưa lên trên cùng
• Thêm vào GPA của bạn
• Liệt kê các địa điểm bạn đã làm việc theo thứ tự thời gian đảo ngược

Nếu bạn muốn có một công việc tại Basecamp, những thứ trên sẽ làm giảm đi cơ hộ của bạn. Trước hết, David không thấy các chỉ số liên quan đến học vấn hữu ích khi tuyển dụng các lập trình viên. Cũng tương tự với những người đã có thời gian làm việc tại các công ty lớn. Thứ hai, không 1 điều gì trong những thứ đó cung cấp thông tin thực sự hữu ích. "Tôi sẽ viết cái gì? Tôi nghĩ rằng hồ sơ xin việc theo ý nghĩa tổng thể thì khá là vô giá trị khi dùng nó để đánh giá khả năng của một lập trình viên" Trước khi bạn xua tay và nói những điều này tôi nói trên là sai bới vì công ty X muốn GPA được liệt kê, công ty Y thì muốn ưu tiên giáo dục lên đầu, vậy xin mời đọc đoạn tiếp theo. Với những lá thư giới thiệu, lý do chính để từ chối là họ chỉ gửi duy nhất 1 hồ sơ theo cách chung chung. Nghĩa là, họ không tỏ ra quan tâm đến công ty. Tương tự, như vậy với hồ sơ của bạn. Nó cần phải được điều chỉnh theo công ty ứng tuyển. Vậy làm thế nào để liệt kê trong hồ sơ của bạn những điều liên quan đến công ty bạn đang ứng tuyển? Đó là những tìm hiểu của bạn về công ty đó và tìm ra những điều họ đang làm, sau đó làm nổi bất những kinh nghiệm và sở thích của bạn cho phù hợp với những điều đó.

Code của bạn trông thật khủng khiếp - 20% thất bại

Bạn thường có thể đưa ra ý kiến về kỹ năng của một ai đó sau khi nhìn thấy 1 số kỹ năng đáng kể trong công việc của họ

• Có bao nhiều người quan tâm đến việc trình bày các dòng code của mình?
• Họ thế hiện cái "tâm" như thế nào với chất lượng code của họ?

"Đến đây, rất nhiều người đã thất bại"

Rất nhiều code sai indent, tên hoặc phạm vị quá tệ Thậm chí, có những người đã đẩy lên những dòng code đi kèm với 1 loạt comment đi theo 1 cách lung tung! 1 ví dụ về đặt tên không tốt, sai indent và comment sai chỗ Ví dụ về đặt tên tốt, đúng ident và comment đúng chỗ

"Ứng viên gửi lên 1 đoạn mã mà không cần làm sạch chúng. Điều đó giống như mời nhà tuyển dụng của bạn đến nhà chơi và không dọn dẹp lại nhà cửa"

Code của bạn trông khá ổn, nhưng chưa tốt

"Ý bạn là gì, code của tôi không tuyêt vời ư?" Không đủ trả lời câu hỏi này trong email. Hãy suy nghĩ về vấn đề này như 1 câu chuyện ngắn, và tác giả hỏi tại sao bạn nghĩ nó như vậy. Bạn thực sư không thể chỉ vào 1 đoạn , bởi vì có toàn bộ câu chuyện mới là không chính xác. Cải thiện code của bạn. Nhận biết code chưa tốt có 1 vài điểm cơ bản như:

• Tồn tại phương thức dài 15 dòng và làm 5 việc khác nhau
• Hàng "tấn" biến toàn cục
• Đặt tên biến quá nghèo nàn
• Comment code hạn chế

Vậy làm thế nào để bạn học hỏi và cải thiện code của bạn?

Đó là luyện tập, luyện tập luyện tập và đọc. Đề xuất cá nhân của David Smalltalk: Best Practices Patterns. Còn tôi đề xuất Clean Code của Robert C. Martin. Một quyển sách khác là: Refactoring: Improving the Design of Existing Code. Một đọc giả cũng đề xuất cho quyển Practical Object-Oriented Design in Ruby của Sandi Metz.

Những cuốn sách kể trên giống như những cuốn sách dạy bạn làm thế nào để viết code tốt hơn. Họ nói về việc đặt tên thích hợp, thành phần phù hợp, và các ví dụ. Điều này được thể hiện qua rất nhiều ví dụ code mẫu, không chỉ đơn thuần là lý thuyết.

Điểm cộng từ việc đóng góp vào các mã nguồn mở

Trong quá trình phỏng vấn các ứng viên của mình, David nhấn mạnh rằng bạn sẽ không cần thiết phải đóng góp cho các dự án mã nguồn mở. Tuy nhiên việc bạn có đóng góp ở đây lại có rất nhiều lợi ích. Nó không chỉ cung cấp cho bạn 1 nơi thực hành bổ sung để cải thiện code mà còn có thể tạo thêm cho bạn các mối liên kết với mọi người. Ví dụ: Thực tế, đối với các vòng cuối cùng trong quá trình tuyển dụng của mình, Basecamp sẽ yêu cầu bạn viết code cho họ. Họ trả tiền cho bạn để làm việc trên 1 dự án thực luôn để họ có thể đánh giá về kỹ năng của bạn. Ở vị trí nhà tuyển dung thì một khi bạn đã trải qua quá trình kể trên cùng với 1 số ứng viên, thì nó khá rõ ràng để thấy là họ biết mình cần phải thuê ai rồi, bạn sẽ được nhận dựa trên cách bạn làm việc, suy nghĩ và giải quyết vấn đề. Tuy nhiên, cũng có một số người được thuê trực tiếp từ việc họ đã đóng góp trực tiếp vào nhóm cốt lõi của Rails (Rails core). Điều này này cũng đúng thôi, bởi vì David có thể dễ dàng đánh giá kỹ năng của 1 ai đó nếu họ đã có những đóng góp trực tiếp cho Rails.

Vậy các hành động cần thực hiện ngay lúc này

Trước khi bạn gửi hồ sơ xin việc và thư giới thiệu của bạn, hãy tự hỏi bản thân điều này: đã có các thông tin liên kết giữa bản thân đến công ty/đến vị trí ứng tuyển chưa? Trước khi bạn đưa những file code của bạn cho nhà tuyển dụng, hãy đọc qua từng dòng và cố gắng làm "sạch" chúng: có nhiều tên có ý nghĩa hơn, xóa bớt các dòng nhận xét thừa thãi trong code, để lại những dòng thực sự có ý nghĩa nhưng đừng quá lạm dụng nó. Để cải thiện code: trình bày rõ ràng, tách ra nhiều hàm nhỏ nhưng đừng mù quáng và lạm dụng điều này ... làm theo tiêu chuẩn ngay cả khi phải mất nhiều thời gian và làm bạn chậm xuống 1 chút. Đọc vài đầu sách kể phía trên khi có thời gian rảnh

Nếu bạn có bất kỳ đề xuất nào về các đầu sách khác, hãy thêm chúng dưới comment, tôi muốn lắng nghe những điều này!

Dịch từ nguồn: https://medium.com/@christophelimpalair/why-the-founder-of-rails-automatically-rejects-80-of-software-engineer-applicants-4e2a4d255f58