Phỏng vấn thế nào để tuyển được lập trình viên Ruby có tay nghề?

Khi mà Ruby ngày càng trở nên phổ biến, thì số lượng các hồ sơ xin việc có Ruby ngày càng nhiều. Điều này khiến cho các công ty (kể cả bạn, tôi đoán) không biết một cách thức nào để chọn lựa các lập trình viên Ruby. Ít nhất là chưa.

Điều này đã có tiền lệ trong lịch sử. Nhớ lại rằng đã từng có thời kì, CGI thống trị, rồi CGI.pm, và đột nhiên công ty nào cũng muốn có người biết về Perl. Điều tương tự cũng xảy ra cho C++, Java và C#. Có vẻ một thước đo cho sự phổ biến ngôn ngữ lập trình là số lần chúng xuất hiện trên các hồ sơ xin việc. Kết quả là chẳng ai phân biệt được một thầy thuốc giỏi với gã lang băm.

Với Ruby, đây cũng là điểm mấu chốt. Khi mà các công ty bắt đầu thuê các lập trình viên với chữ Ruby đầy trên các bộ hồ sơ của họ, và các lập trình viên này tiếp tục làm ra các phần mềm tuyệt vời, Ruby trở nên thật vĩ đại. Trái lại, khi mà người ta bảo lập trình viên Ruby không khác gì một lũ ngốc, Ruby trở nên thật tệ hại. Những Rubyists đang đầy ở ngoài kia với các cuộc hẹn không ý thức lắm với các công ty, và những ấn tượng kiểu đó không chỉ tác động lớn tới họ, mà thật ra tới tất cả chúng ta.

Điều tệ hại nhất là gì? Một người bạn của tôi làm việc ở một công ty, ta tạm gọi là “FooCorp”, cho hay một chuyện có thật. Bộ phận nhân sự của “FooCorp” thuê một gã làm một công cụ đánh giá hiệu quả cho công ty. Gã này không cần liên hệ gì với toàn bộ bộ phận kĩ thuật còn lại, quyết định sử dụng Ruby. Thế là một sự lãng phí khủng khiếp về thời gian và tiền bạc được đổ ra để làm công cụ này, và thậm chí nhiều hơn thế cho các buổi xem xét lại chất lượng. Thế là với sự lãng phí thời gian kinh khủng ấy, cái công cụ mới hào nhoáng bằng Ruby ra đời một cách đầy tai tiếng và tiêu phí gần hết thời gian của mọi người.

Đó là lỗi của Ruby? Tất nhiên là không. Thật ra, tôi, à, ý tôi muốn nói là bạn tôi, gặp với gã lập trình viên cao bồi kia để xem thử vấn đề có thể tháo gỡ, hắn ta đã trả lời: “Anh biết đấy, khi mà vấn đề trở nên rắc rối thì hình như bất cứ cái gì cũng sẽ trở thành vấn đề”. Tôi cũng không nghĩ gã nói sai.

Dễ hiểu là Ruby bị thất sủng ở FooCorp trong một thời gian.

Tôi nghĩ cộng đồng Ruby nên suy nghĩ tích cực về vấn đề này. Tôi không nghĩ tôi sẽ giải quyết, hay gần giải quyết được nó trong một bài blog. Ruby dễ học một cách kì lạ, dễ hơn nhiều so với Perl, C++, Java, C#, hay thậm chí PHP. Và cũng dễ hơn nhiều so với Python. Đó cũng là vấn đề. Ý tôi muốn nói, Ruby trở nên một thứ cứu cánh cho những người không thể lập trình được các ngôn ngữ nào khác. Cần phải chỉ ra những cách nào phân biệt được một lập trình viên giỏi với một gã tồi.

Tôi sẽ chỉ ra một vài ý kiến theo quan điểm của mình dưới đây, tất nhiên là không thể nào đầy đủ trong khuôn khổ một bài blog. Tôi sẽ bắt đầu với một quy cách chung cho mọi ngôn ngữ lập trình, sau đó là Ruby.

Cách tiếp cận mang tính chất thống kê

Tất nhiên, đầu tiên bạn sẽ đánh giá qua bộ hồ sơ xin việc. Bằng cách này, có thể loại đi một số lượng lớn các lập trình viên có vẻ tồi bằng cách đánh giá các khuôn mẫu và phản khuôn mẫu trên bộ hồ sơ của họ.

Tưởng tượng bạn muốn thuê một lập trình viên Java. Vậy là bạn đã phạm phải một sai lầm đầu tiên. Tại sao? Thông báo rằng bạn cần một lập trình viên biết ngôn ngữ X là đã đặt bạn vào một sự lựa chọn sai. Tôi dám cá với bạn rằng, bất cứ lập trình viên giỏi nào cũng biết ít nhất từ 3 tới 5 ngôn ngữ lập trình, và những người giỏi nhất, họ ghét mọi ngôn ngữ lập trình, chỉ có ghét cái nào ít hơn mà thôi. Ai mà từ cho rằng mình là một lập trình viên Java là một người mới học. Họ có thể thông minh, nhưng mà bạn sẽ phải đào tạo rất nhiều.

Đó là tín hiệu đầu tiên bạn phải lưu ý: nếu một người xin việc tự bảo: “Tôi là một lập trình viên Ruby”, nhiều khả năng bạn nên loại đi. Trừ phi tên họ là “Yukihiro”, “Dave”, hay “Why” gì đó, trong trường hợp này bạn muốn ai đó xem xét lại cho cẩn thận.

OK, tôi bảo là bạn sẽ không muốn thuê một lập trình viên chỉ biết mỗi một ngôn ngữ, bạn có thể tiếp tục sử dụng ví dụ Java. Giả sử bạn cần ai đó để tiếp tục phát triển một đoạn mã đã có sẵn, và rõ ràng bạn cần người giới thiệu trong hồ sơ là họ có biết về Java. Thế thì, dựa vào hồ sơ, làm sao biết được ai đó giỏi về Java?

Hãy nhớ lời khuyên của Dave Barry: “Một hồ sơ xin việc còn hơn là một mảnh giấy. Nó là một mảnh giấy với đầy lời nói dối. Một hồ sơ xin việc tốt, có thể chỉ ra sự khác biệt giữa không làm công việc ấy với thậm chí không đến gần”. Bạn phải đọc giữa các dòng (nguyên văn: read between the lines), khi mà bạn đọc hồ sơ của ai đó.

Đây là cách hiểu tần suất xuất hiện của chữ Java trong mẫu hồ sơ xin việc:

Ta tổng quát hóa lên được điều gì? Đây là bài học được rút ra:

• Biết Java đòi hỏi biết nhiều thứ không chỉ có Java.
• Làm việc trên Java dạy cho bạn nhiều hơn là làm việc trong nó.
• Những framework “enterprise” gây ra ảnh hưởng xấu tới tư duy.

Bạn có thể hình dung, điều này cũng đúng cho các ngôn ngữ khác, kể cả Ruby.

Hiện nay chúng ta đang ở giai đoạn mà hầu hết mọi resume nhắc tới Ruby 1 lần, có thể là 2 lần nếu bạn kể thêm Ruby on Rails. Nhưng cũng đã đến điểm mà chúng ta có thể bỏ từ Ruby ra khỏi bản resume hoàn toàn. Nếu bạn muốn tìm một ai đó giỏi về Ruby (hay tổng quát hơn là giỏi lập trình), bạn nên tìm bộ resume nhắc tới họ đã làm gì với Ruby.

Những từ cửa miệng của Ruby ngày nay là gì? Có gì tương đương ở Spring, Hibernate hay hàng trăm công nghệ Java khác hay không? Thật sự tôi không biết. Ruby ít có khuynh hướng lạm dụng framework (cũng có nghĩ là ít khuynh hướng gây ra sự cố) như Java. Những gói tốt nhất (thí dụ: REXML) có khuynh hướng được tích hợp sẵn vào Ruby hay Rails. Với vài IDE hay là những hệ thống sinh ra bộ phân tích (parsers), chưa có cái gì trở thành ngón nghề cả. Cho nên những từ “cửa miệng” cho Ruby không có, ít ra là chưa.

Có lẽ để xem resume, tốt hơn hết là bạn nên xem họ đã tạo được những gì với Ruby. Nếu có một thành tựu xuất sắc trong tất cả ngôn ngữ, đây là người bạn muốn tìm.

Dùng Rails để làm web không phải là một điểm đáng khen ngợi, vì Rails làm cho những ứng dụng web bình thường trở nên nhỏ nhặt (đó là lí do tại sao nó tốt như vậy). Ở một phương diện khác, nếu người này là người bảo trì cho một phần mở rộng của Rails dùng cho hàng tá trang web, và đang được dự định thêm vào phần lõi của Rails, thì đó lại là vấn đề khác.

Đừng quên là những cái ngoài Ruby vẫn có giá trị. Giáo dục tốt, kinh nghiệm tốt, thích hoạt động ngoại khóa là một tín hiệu tốt của bản resume.

Phỏng vấn qua điện thoại

Nếu người bạn phỏng vấn đã qua vòng B.S và bạn đang tiến hành phỏng vấn qua điện thoại với anh ta, bạn sẽ hỏi những gì để tránh anh ta phải bật khóc?

Đùa thôi. Bạn đâu có muốn người bạn phỏng vấn phải bật khóc, vì như vậy anh ta sẽ là kẻ thù của công ty bạn. Hỏi Microsoft xem. Mãi đến giữa những năm 1990 họ mới nhận ra điều này và trở nên tử tế hơn. Ai đến phỏng vấn mà không qua cũng đều dành cụôc đời họ ( có thể cả bạn bè họ) chống lại Bill. Tôi đoán đó là một phần lí do tại sao mã nguồn mở phát triển đến thế.

Dù sao thì phỏng vấn qua điện thoại là một cơ hội tốt để kiểm tra khả năng sử dụng Ruby của một người. Nếu bạn không tận dụng, coi chừng ứng viên sẽ qua mặt bạn.

Sau đây là một số câu hỏi phỏng vấn đáng chú ý:

So sánh và phân tích sự đối lập giữa Ruby với ngôn ngữ sở trường thứ hai của bạn.

(Chú ý: Ruby phải là ngôn ngữ sở trường của họ, nếu không thì hiển nhiên họ không biết rõ về nó. Một vài ngoại lệ chấp nhận được nếu ngôn ngữ sở trường là: Scheme, Lisp, Haskell, OCaml, Python, Io, và Lua.)

Ứng viên giỏi sẽ thao thao bất tuyệt về câu hỏi này, và bạn phải ngăn nhiều lần anh ta mới dừng lại được.

Mô tả 2 đặc điểm bạn sẽ loại bỏ khỏi Ruby để cải tiến nó, và mô tả những thay đổi cần thiết cho bộ phân tích cú pháp, hệ thống parse từ vựng (bison parser), và trình thông dịch để tác động đến sự thay đổi này.

Có rất nhiều loại câu trả lời tốt cho câu hỏi kiểu này. “Ruby là hoàn hảo, mọi sự thay đổi chỉ làm xấu đi” là câu trả lời trung thành, nhưng không đúng. Và đừng để họ xoay đi bằng cách hỏi rằng có cần bỏ sung tính năng còn thiếu nào, thí dụ tối ưu lời gọi đuôi.

Mô tả chi tiết bộ phân giải tên cho hằng (nghĩa là nếu bạn khai báo một hằng và tham chiếu nó ở trong hàm, trình thông dịch làm sao để thực hiện đúng)?

Sẽ có điểm thưởng nếu anh ta nói thêm trong Ruby 1.9 mọi thứ thay đổi thế nào, và tại sao.

Giải sử bạn viết hướng dẫn về phong cách Ruby cho công ty bạn, bạn kể ra vài điều mà bạn sẽ viết? Bạn có quy định độ dài nhất của 1 dòng lệnh không? Nếu có, là bao nhiêu?

Ứng viên giỏi suy nghĩ về vấn đề này rất nhiều, và có thể hi vọng là anh ta xem phong cách lập trình và các đoạn chương trình có sẵn trước khi làm điều gì thật sự.

Lấy ra 5 “design patterns” trong C++ và Java và chỉ ra nó sẽ được áp dụng thế nào với một số lượng rất nhỏ đoạn mã Ruby.

(Tôi phỏng vấn có khó không nào :p ?)

Chốt lại: Ruby là một ngôn ngữ đòi hỏi suy nghĩ nhiều, và lập trình viên Ruby giỏi phải suy nghĩ thật sự sâu sắc về nó. Phỏng vấn qua điện thoại là cơ hội để ứng viên chứng tỏ họ suy tư nhiều vào cơ chế bên trong của Ruby, và ngôn ngữ cũng như cách hiện thực của nó khác các ngôn ngữ khác như thế nào.

Những câu hỏi phỏng vấn tổng quát

OK, đã xong phần resume và phỏng vấn qua điện thoại. Giờ tới phần Big Test. Anh ta đã sẵn sàng cho thử thách?

Quan trọng hơn là bạn có sẵn sảng không? Làm thế nào để phân biệt một ứng viên giỏi và dở? Điều đó thể hiện lúc phỏng vấn, có vẻ như anh ta giải quyết mọi vấn đề bạn đưa ra bằng một dòng code Ruby.

Thành thực mà nói, nếu không rành về Ruby, thì đây không phải lúc để bạn yêu cầu anh ta viết mã. Nếu bạn không giỏi về lập trình, hãy yêu cầu anh ta viết mã giả.

Thật ra bạn vẫn có thể phỏng vấn chọn một lập trình viên Ruby gỏi mà bản thân bạn chưa thật sự nắm vững Ruby. Nếu bạn có một công ty kĩ thuật, và ai đó thật sự yêu thích Ruby và nói về nó suốt trong resume, bạn vẫn có thể đánh giá anh ta tốt bằng cách hỏi những câu hỏi phỏng vấn căn bản.

Trong trường hợp bạn chưa biết, thì tôi xin nói là khoảng 1/3 câu hỏi phỏng vấn của các công ty kĩ thuật trên thế giới đại loại như “Làm thế nào cho 10 cân (cái gì đó – không tiện dịch (T_T)) vào một cái túi 5 cân”? Thí dụ: làm thế nào để đảo ngược 1 chuỗi, sắp xếp 1 tỉ số, viết một chương trình dịch cho một kiến trúc có 4 thanh ghi, làm thế nào để sắp lịch khi ai đó chạy chương trình mô phỏng bài toán tháp Hà Nội với 1000 đĩa, vân vân… 1/3 khác đại loại là làm thế nào tìm 1 cây kim trong 1 đống rơm cỡ núi Everest? Thí dụ: làm sao tìm kiếm trong một cây trò chơi của cờ vua cho bước đi tốt với thời gian nhỏ hơn thời gian của vũ trụ, làm thế nào tìm được bức hình IDMB bạn giống với nhất, và khả năng bạn bị đau tim nếu như đó là Marty Fedman, vân vân…

Không qua khó để nghĩ ra những câu hỏi phỏng vấn kiểm tra khả năng giải quyết vấn đề và nghĩ ra thuật toán của ứng viên mà không lệ thuộc ngôn ngữ. Cho nên đừng có sợ nếu bạn không thể kiểm tra bằng Ruby (và cũng đừng hỏi những câu tôi mới nói nhé, chúng khủng khiếp đấy).

Cần nói thêm là một phần các câu hỏi còn lại thường tập trung vào các điểm vụn vặt của cú pháp các ngôn ngữ khó nhớ như C++ hay Perl. Một cú pháp càng tệ khi càng nhiều ứng viên phải trả lời các câu hỏi phỏng vấn về nó. Đừng có để công ty bạn sa vào trường hợp đó.

Những chi tiết cú pháp vụn vặt không đánh giá được lập trình viên. Nếu trước đây công ty bạn đã làm thế, đừng làm vậy với Ruby. Thuê dựa vào cú pháp là sự lựa chọn cuối cùng vì chỉ có những nhân viên kém chất lượng. Chỉ nói KHÔNG.

Câu hỏi phỏng vấn Ruby

Thế nếu bạn biết Ruby, làm thế nào kiểm tra xem ứng viên cũng biết nó?

Bây giờ chúng ta có một vấn đề nhỏ, vì đây là một blog Ruby, và những câu hỏi thật sự ở đây đã được xem xét kĩ lưỡng bởi những nhà săn đầu người Ruby. Thật ra tôi phỏng vấn một ứng viên 2 tuần trước, sau khi tôi hỏi một câu hỏi từ blog cũ của tôi, anh ta cho biết đã đọc nó rồi. Blog thì ai cũng đọc được hết!

Bạn có thể thêm một chút bói toán. Nếu quẻ của bạn có “in bed” thì đó là quẻ tốt. Vậy bạn hãy thêm vào “in Ruby” để gây ấn tượng với ứng viên của bạn. Thí dụ:

• Đảo ngược một chuỗi bằng Ruby.
• Viết một hàm thêm nối chữ “Ruby" nếu chưa có bằng Ruby.
• Viết một hàm in ra tam giác Pascal cấp N bằng Ruby.
• Viết chương trình tự in ra mã nguồn của chính nó bằng Ruby.

Được rồi, không phải mọi câu hỏi đều tốt hơn nếu có đuôi “bằng Ruby”.

Một cách nghiêm túc, đây là cách tôi đánh giá khả năng viết Ruby của một người.

Đầu tiên, tôi quan tâm đến siêu lập trình. Đây là điểm tốt của Ruby, nó hỗ trợ siêu lập trình rất tốt. Các ngôn ngữ khác thường dẫn đến rắc rối khi hỗ trợ vấn đề này, thậm chí còn ngăn cản phong cách lập trình của công ty. Tôi gặp nhiều công ty thuê những lập trình viên giỏi nhất, và bắt họ phải viết trong những vòng lặp for.

Cho nên tôi nói về siêu lập trình trước khi nói về bất kì mọi vấn đề khác. Tôi có thể hỏi làm sao tạo ra một cầu nói cho các interface cũ của công ty với các chương trình mới. Hoặc viết một class có thể giải quyết mọi từ khóa {HTML | CSS | Starbucks | Bất cứ gì khác } trong một văn bản với không cần viết một hàm looking cho cho mỗi từ khóa. Câu hỏi nào mà câu trả lời đòi hỏi viết mã đều phải viết mã thật.

Tôi cũng hỏi các câu về mô hình siêu lớp, lớp ảo, lớp cha, và làm thế nào mà cách tìm ra một hàm trong cây thừa kế phức tạp đó. Và tôi muốn biết một số về cách sử dụng eval trong Ruby, và tại sao chúng ta cần nó. Làm thế nào để qua mặt một số trong chúng. Đây là các vấn đề điển hình về Ruby cho phép tách được những chuyên gia về Ruby với vô số lập trình viên Ruby.

Thực tế, tôi chú trọng tới khái niệm và không nghiêm khắc lắm tới các vấn đề chi tiết, ít nhất so với những người phỏng vấn khác. Chẳng hạn tôi hỏi về khả năng của Regular Expression trong Ruby, và khi nào sử dụng nó, nhưng tôi sẽ không hỏi cao hơn những gì căn bản của các siêu kí tự posix-ish. Tôi sẽ hỏi về method_missing, nhưng tôi sẽ không bắt bẻ về danh sách tham số (cũng không quá khó, nhưng mà bạn biết tôi muốn nói gì).

Giới hạn của Ruby

Những lập trình viên Ruby giỏi nhất, cũng như với mọi ngôn ngữ khác, là những người có thể nghĩ ra ngoài Ruby, biết cả sức mạnh lẫn giới hạn của nó. Hiếm khi một tay mơ nói về điểm yếu của ngôn ngữ sở trường, vì sách và bài hướng dẫn hiếm khi đề cập tới. Không thuận lợi để marketing.

Cách phổ biến nhất để biết một điểm yếu của một ngôn ngữ là so sánh xem nó được thực hiện tốt thế nào trong một ngôn ngữ khác. Khi phỏng vấn một lập trình viên Java, tôi sẽ hỏi xem câu lệnh return thực hiện thế nào (không có cách nào thực hiện tốt trong Java cả). Khi phỏng vấn một lập trình viên C++, tôi sẽ hỏi cách thực hiện cơ chế phản chiếu ( tạo ra một đối tượng từ tên lớp, gọi hàm bằng danh sách tham số).

Tốt hơn, tôi sẽ hỏi họ liệt kê ra một số điểm kém hiệu quả trong ngôn ngữ đó mà không gợi ý.

Với Ruby, bạn có thể dùng câu hỏi này để biết rất nhiều về một lập trình viên. Họ có nói đến sự thiếu tối ưu trong lời gọi đuôi, dẫn đến ảnh hưởng cách gọi đệ quy? Họ có phàn nàn rằng họ thiếu kiểu tĩnh như Java và C++? Có bực dọc về tốc độ thực thi (có thể sẽ không thuê!) Họ có nói về việc thiếu IntelliJ, và ghét sử dụng Emacs cho mỗi đoạn mã Ruby? (tuỵêt đối không thuê) (13 tiếng sau: Tôi chỉ đùa thôi. Bạn được nhận vào làm. Đừng gởi mail cho tôi về chuyện đó nữa)

Vấn đề là, mọi ngôn ngữ có sự chia sẻ của vấn đề trong thiết kế. Câu hỏi về điểm yếu của ngôn ngữ là một cơ hội bằng vàng để cho ứng viên thể hiện họ nghĩ thế nào về quy trình thiết kế ngôn ngữ lập trình, tổng quát là quy trình thiết kế phần mềm.

Nhưng phỏng vấn là một quy trình rất lạ. Mỗi người làm nó một cách khác biệt, mỗi lập trình viên có phong cách riêng, và những người đã biến phong cách thành cái mà theo họ là rất khoa học, không dễ dàng để chuyển đổi phong cách đó. Thật ra, cũng không phải vấn đề, vì trong ngành kỹ nghệ này, cuộc phỏng vấn 1 tiếng đồng hồ khá hú họa để chỉ ra ứng viên sẽ làm việc thế nào trong hàng tháng, hay hàng năm tiếp theo. Tôi không tin phong cách của ai đủ tốt để tránh khỏi những điểm sai.

Hãy cẩn trọng với những lời khuyên trên.

Gởi tất cả lập trình viên Ruby đang thất nghiệp

Ruby đang rất nóng. Truy cập vào monster.com hay bất cứ trang tuyển dụng nào bạn sẽ thấy số hồ sơ có Ruby nhiều hơn nhiều so với một năm trước đây.

Tôi muốn nói là: “Nếu đần, xin đừng để Ruby vào hồ sơ”. Tất nhiên là tôi cũng không thô thiển tới mức đó. Tôi muốn nói vậy, nhưng không nói.

Thay vào đó, tôi có một đề nghị nhỏ cho các lập trình viên Ruby đang tìm việc: đừng có thể hiện nó thô bạo quá. Ruby là công cụ tuyệt vời, có thể nó làm cho bạn thấy thế. Nhưng công ty thì mới chân ướt chân ráo tiếp cận Ruby. Nên nhớ rằng: công ty rất bảo thủ và chậm chạp, cho dù nó được tạo ra từ những con người thông minh và cấp tiến. Đó là cách nó họat động. Và điều này chưa bao giờ đúng hơn khi nó xem xét một ngôn ngữ lập trình mới.

Nếu bạn biết Ruby, thế thì hãy đề cập tới nó trong resume. Nhưng hãy cẩn trọng, không nên đề cao nó thái quá, vi sẽ gây tác dụng ngược. Hoặc công ty nghĩ là bạn quá phụ thuộc vào nó và không phỏng vấn bạn, hoặc họ sẽ phỏng vấn với những câu hỏi trên trời.

Gửi các công ty

Nếu bạn là công ty ( thừa nhận đi), bạn phải chấp nhận là Ruby ngày càng được chú ý, dù bạn thích hay không. Ruby xuất hiện trong 50% hồ sơ, và nó làm nhiều người thích thú khi sử dụng nó, bởi vì nó thật sự tốt: “làm project nhanh hơn, tốt hơn, với ít người hơn và ít chi phí bảo trì hơn”. Tóm lại là rất tốt.

Rất sớm, Ruby sẽ len lỗi vào các nền lập trình của bạn. Bạn nên chuẩn bị, ít nhất là lập kế họach tách đựơc lập trình viên Ruby giỏi với kẻ dở, và tổ chức các cuộc phỏng vấn. Bạn nên dành thời gian đi tìm những lập trình viên xuất sắc, chắt lọc lại những lập trình viên có tài năng về Ruby trong số những nhân viên đã có. Bạn sẽ ngạc nhiên.

Nếu bạn là lập trình viên, bạn sẽ theo được đến cuối bài viết. Nếu không thì – bạn đọc để làm gì? Dành nửa ngày ra học nó đi!

5h sáng. Tôi phải đi ngủ đây. Và tôi ghét bài này. Đừng có đề cập nó trong lần phỏng vấn tới nhé.

Nguồn: Interviewing Ruby Programmers