Phỏng vấn lập trình viên qua điện thoại đúng cách

Bài viết được dịch từ blog Coding Horror

Thị trường việc làm cho các nhà phát triển phần mềm đang rất sôi động. Đây là tin tức tuyệt vời dành cho các lập trình viên, nhưng nó cũng khiến cho quy trình phỏng vấn trở thành một thách thức cho các nhà tuyển dụng. Một độc giả gần đây đã viết cho tôi để bày tỏ ý kiến về đôi điều anh ta quan tâm trong quy trình phỏng vấn tuyển dụng đó:

Anh có đề cập rằng quy trình tuyển dụng tại công ty Vertigo yêu cầu một ít code ví dụ, sau đó là phỏng vấn qua điện thoại, và tiếp đến là mời đến công ty gặp mặt để làm bài test trực tiếp. Chúng tôi có một quy trình y chang như vậy, nhưng không hiểu sao phần lớn những ứng viên lọt đến vòng làm bài test trực tiếp đều có chất lượng rất thấp và đáng lẽ nên bị loại trừ ngay từ vòng 1 hoặc vòng 2. Tỷ lệ những ứng viên tồi lọt đến vòng cuối là rất lớn. Chúng tôi đã mất rất nhiều thời gian để tiến hành phỏng vấn trực tiếp với những người mà thường thị họ không nên trở thành một lập trình viên ngay từ đầu. Tôi đang tò mò rằng anh đã đưa ra những câu hỏi xác định nào để yêu cầu những ứng viên của anh trả lời. Phần nào của quy trình đó là hiệu quả nhất để có thể loại trừ được những ứng viên không phù hợp, cách làm như thế nào và tại sao?

Làm thế nào để phỏng vấn lập trình viên qua điện thoại đúng cách?Làm thế nào để phỏng vấn lập trình viên qua điện thoại đúng cách?


Bạn sẽ phải trả giá đắt nếu tiến hành một cuộc phỏng vấn qua điện thoại sai cách— một sự lãng phí thời gian rất lớn cho tất cả các bên liên quan.

Bài viết hướng dẫn cách phỏng vấn qua điện thoại tốt nhất mà bạn chưa từng bao giờ tìm thấy là bài 5 Câu Hỏi Thiết Yếu Để Phỏng Vấn Qua Điện Thoại của tác giả Steve Yegge, đó là một món quà khác gửi đến chúng ta từ Steve trong quy trình tuyển dụng của Amazon.

Steve bắt đầu bằng việc lưu ý chúng ta về hai sai lầm nghiêm trọng mà những người tiến hành phỏng vấn qua điện thoại cần nên tránh:

  1. Đừng để cho ứng viên điều khiển cuộc phỏng vấn. Người phỏng vấn nên giữ thế chủ động, hướng dẫn suốt cuộc trò chuyện đó cho tới khi họ cảm thấy hài lòng rằng ứng viên đã biết các câu trả lời cho những câu hỏi (hoặc từ bỏ không trả lời được).
  2. Hãy cẩn thận với những “con ngựa chỉ biết có mỗi một trò”. Những ứng viên mà chỉ biết một ngôn ngữ hoặc môi trường lập trình riêng biệt nào đó, và xác nhận rằng hoàn toàn không biết gì về những thứ khác, là một dấu hiệu cảnh báo đỏ lớn.

Cuộc phỏng vấn qua điện thoại đó không nên để cho ứng viên thao thao bất tuyệt về những cái mà họ đã làm. Người phỏng vấn nên đẩy ứng viên ra khỏi vùng an toàn của họ một chút và hỏi họ những câu hỏi liên quan về những thứ mà họ chưa từng nhìn thấy hoặc làm trước đó. Về mặt lý tưởng, bạn muốn biết người này sẽ phản ứng như thế nào khi họ phải đối mặt với một cái gì đó mới, như là codebase của bạn chẳng hạn.

Trong một nỗ lực để khiến cho cuộc sống trở nên đơn giản hơn đối với những người phải tiến hành phỏng vấn qua điện thoại, tôi đã sắp xếp lại danh sách 5 Câu Hỏi Thiết Yếu mà bạn cần hỏi trong suốt một buổi phỏng vấn qua điện thoại. Chúng không đảm bảo rằng bạn sẽ kiếm được những ứng viên tuyệt vời, nhưng chúng sẽ giúp loại trừ một số lượng lớn những ứng viên kém chất lượng mà có thể lọt qua được quy trình sàng lọc của chúng ta hiện nay.

  1. Khả năng lập trình. Ứng viên phải viết một số code đơn giản, với đúng cú pháp, trong C, C++, hoặc Java.
  2. Thiết kế hướng đối tượng (OO). Ứng viên phải định nghĩa những khái niệm OO cơ bản, và tiến đến xây dựng các class để mô hình hóa một vấn đề đơn giản.
  3. Scripting và regexes. Ứng viên phải mô tả cách làm thế nào để tìm thấy những số điện thoại trong 50,000 trang HTML.
  4. Cấu trúc dữ liệu. Ứng viên phải trình bày được những kiến thức cơ bản của hầu hết các dạng cấu trúc dữ liệu phổ biến.
  5. Bit và byte. Ứng viên phải trả lời các câu hỏi đơn giản về bit, byte và các số nhị phân.

Làm ơn hiểu rằng: cái mà tôi đang tìm kiếm ở đây là khi ứng viên không biết một chút gì về một trong những khái niệm nêu trên. Có thể chấp nhận được nếu họ phải khó khăn một chút và sau đó thì cũng có thể trả lời được. Nó thì OK nếu họ cần một vài gợi ý nhỏ hoặc lời nhắc. Tôi không quan tâm liệu họ có bực tức hoặc trả lời chậm hay không. Cái mà bạn đang tìm kiếm là các ứng viên mà hoàn toàn không có manh mối gì, hoặc bị nhầm lẫn tồi tệ, về những lĩnh vực trong các câu hỏi đó.

Dĩ nhiên, bạn sẽ muốn chỉnh sửa quy trình này để phù hợp với thực tế tại công ty của bạn– vì vậy tôi khuyến khích bạn hãy đọc toàn bộ bài viết đó. Nhưng Steve đã cung cấp một số ví dụ để bạn có thể bắt đầu:

Coding

  • Viết một function có chức năng đảo ngược một chuỗi.
  • Viết function để tính toán số fibonacci thứ N.
  • In ra bảng tính nhân lên tới 12×12.
  • Viết một function tính tổng các số integer từ một file text, mỗi số int nằm trên một dòng.
  • Viết function để in ra các số lẻ từ 1 đến 99.
  • Tìm giá trị int lớn nhất trong một mảng int.
  • Định dạng một giá trị RGB (3 số dạng 1-byte) thành một chuỗi 6-digit hexadecimal.

Những ứng viên tốt cho vấn đề coding thì có thể xác định khá dễ dàng, chỉ với một số vòng lặp cơ bản hoặc đệ quy và có lẽ thêm một chút định dạng output hoặc việc nhập xuất file. Tất cả bạn muốn biết đó là liệu họ có thực sự biết làm thế nào để viết chương trình hay không. Bài viết của Steve đã chỉ rõ điều đó, nhưng thật là thiếu sót nếu tôi không đề cập đến bài viết Tại sao nhiều lập trình viên lại không biết… code? ở đây. Vấn đề FizzBuzz cũng tương đối giống, và thật là sốc khi biết rằng rất nhiều ứng viên không thể làm được. Điều đó thật khó hiểu, nó giống như là một gã lái xe tải tương lai mà lại không có khả năng tìm thấy chân gas hoặc cần số vậy.

Lập trình hướng đối tượng

  • Thiết kế một cỗ bài mà có thể sử dụng cho nhiều ứng dụng đánh bài thể loại khác nhau.
  • Mô hình hóa một vương quốc Động Vật như là một hệ thống các class, để sử dụng trong một chương trình Vườn Bách Thú Ảo.
  • Tạo ra một class đại diện cho một hệ thống file.
  • Thiết kế một thực thể hướng đối tượng (OO) để mô hình hóa HTML.

Chúng ta không phải đang nói về những mặt thuận lợi và hạn chế của thiết kế hướng đối tượng (OO) ở đây, và chúng ta cũng không phải đang hỏi họ về một kiến thức thiết kế OO ở mức thấp và toàn diện. Những câu hỏi này được đặt ra ở đây để xác định xem liệu các ứng viên có thân thuộc với các nguyên tắc cơ bản của OO hay không, và điều quan trọng hơn là, liệu ứng viên đó có thể tạo ra một giải pháp OO ở dạng chấp nhận được hay không. Chúng ta đang tìm kiếm những người có sự hiểu biết về các nguyên tắc cơ bản nhất.

Scripting và Regular Expressions

Năm ngoái nhóm của tôi đã phải xóa tất cả các số điện thoại từ 50,000 trang web template tại Amazon, vì có nhiều số trong đó không còn sử dụng nữa, và chúng tôi cũng muốn sắp xếp lại tất cả các thông tin liên hệ khách hàng chỉ thông qua một trang duy nhất.

Hãy giả sử rằng bạn ở trong nhóm của tôi, và chúng ta phải nhận diện những trang mà có thể chứa những số điện thoại kiểu Mỹ ở trong đó. Để đơn giản hóa vấn đề, giả sử chúng ta có 50,000 file HTML trong một cây thư mục Unix, dưới một thư mục gọi là “/website”. Chúng ta có 2 ngày để lấy ra danh sách các đường dẫn file đó để cung cấp cho các nhân viên của phòng biên tập. Bạn cần phải đưa cho tôi danh sách của các file .html trong cây thư mục đó mà có chứa các số điện thoại theo một trong hai định dạng sau đây: (xxx) xxx-xxxx và xxx-xxx-xxxx.

Bạn làm thế nào để giải quyết vấn đề này? Nên nhớ rằng nhóm của bạn chỉ có thời gian ngắn (2 ngày) để làm điều đó.

Đây là một câu hỏi thú vị. Steve nói rằng có từ 25% đến 35% trong tất cả các kỹ sư phát triển phần mềm ứng viên không thể giải quyết vấn đề này chút nào cả– thậm chí với rất nhiều lời gợi ý và cho phép sử dụng toàn bộ thời gian phỏng vấn cho vấn đề đó. Cái mà chúng ta đang tìm kiếm là một sự miễn cưỡng chung để phát minh lại cái bánh xe, và một số khác thì thân thuộc với các ngôn ngữ kịch bản và regular expressions. Đối với tôi, câu hỏi này cho biết liệu một lập trình viên sẽ dành nhiều ngày để làm công việc lập trình mà anh ta hoặc cô ta có thể dễ dàng tránh được, có lẽ chỉ với một chút tìm kiếm nhanh và một số code mẫu đã tồn tại ở ngoài kia.

Cấu trúc dữ liệu

  • Một số kiểu cấu trúc dữ liệu thực sự phổ biến, ví dụ trong java.util là gì?
  • Khi nào thì bạn nên sử dụng một danh sách liên kết và khi nào thì sử dụng một vector?
  • Bạn có thể biểu diễn một Map bằng một tree? Thế còn bằng một list thì sao?
  • Làm thế nào để bạn có thể in ra những node trong một tree ở những cấp khác nhau (ví dụ: cấp 1, sau đó cấp 2, sau đó cấp 3, v.v…)
  • Tốc độ insert tồi nhất là của một hashtable hay một cây nhị phân?
  • Có những tùy chọn nào cho việc thực thi một hàng đợi ưu tiên (priority queue)?

Một ứng viên nên có khả năng thể hiện một mức hiểu biết cơ bản trong hầu hết các loại cấu trúc dữ liệu. Chính xác hơn, những loại như mảng, vector, danh sách liên kết, hashtable, tree, và graph. Họ cũng nên biết về nền tảng độ phức tạp của thuật toán “big-O”: hằng, logarit, tuyến tính, đa thức, hàm mũ, và giai thừa. Nếu họ không thể, thì đó là một tín hiệu cảnh báo lớn.

Bit và Byte

  • Hãy nói cho tôi cách làm thế nào để kiểm tra xem liệu một bit có nằm ở vị trí cao trong một byte hay không.
  • Viết một function để đếm tất cả các bit trong một giá trị int; ví dụ: function đó có dạng là int countBits(int x)
  • Mô tả một function lấy đầu vào là một giá trị int, và trả về giá trị true nếu bit pattern của giá trị int đó thì giống hệt nếu bạn đảo ngược nó, ví dụ: boolean isPalindrome(int x)

Như Steve nói, “Máy tính không có 10 ngón tay, chúng chỉ có một. Vì vậy con người cần phải biết món này.” Bạn không nên bị đối xử bằng một sự im lặng không thoải mái sau khi hỏi một ứng viên về giá trị của 2^16; nó là một số đặc biệt. Họ nên biết nó. Tương tự như vậy, họ nên biết về nền tảng của AND, OR, NOT và XOR– và pháp AND theo bit khác phép AND logic như thế nào. Bạn có thể thậm chí hỏi về số signed vs. unsigned, và tại sao các phép dịch bit có thể quan trọng. Họ nên có khả năng giải thích tại sao câu chuyện của các lập trình viên đứng tuổi là, “tại sao các lập trình viên nghĩ rằng Oct 31 và Dec 25 là cùng một ngày?” là một câu chuyện cười.

Việc tiến hành một cuộc phỏng vấn qua điện thoại chi tiết và tỉ mỉ thì cần rất nhiều việc phải làm. Nhưng đó là điều đáng giá. Mỗi ứng viên bị loại ra thông qua buổi phỏng vấn qua điện thoại đã tiết kiệm ít nhất 8 giờ làm việc quý giá mà bạn đã phí phạm bởi một ai đó lọt vào đến vòng kiểm tra trực tiếp. Mỗi lần một ứng viên kém chất lượng lọt qua được đến vòng kiểm tra trực tiếp, thì bạn nên hỏi bản thân mình rằng– làm thế nào để chúng ta có thể loại bỏ ứng viên này ngay trong buổi phỏng vấn qua điện thoại nhỉ?

Các bài viết liên quan:

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Advertisements

20 comments on “Phỏng vấn lập trình viên qua điện thoại đúng cách

  1. Bài viết hay thật, mình trả lời được có mấy câu. Mấy cái đoạn OOP câu hỏi có vẻ không rõ lắm nhi, nếu không hiểu cấu trúc đối tươngj sao mô hình hoá được, ví dụ không biết các loại bài có những cách chơi nào sao mô hình hoá cho phù hợp được nhỉ ?

  2. Chào Anh! Lúc phỏng vấn người ta thường kiểm tra sinh viên có biết lập trình hay không từ những vấn đề như cú pháp c++, tìm lỗi, hay viết thuật toán tìm kiếm, hoặc một cấu trúc dữ liệu; những vấn đề cơ bản nhưng yêu cầu lập trình viên phải hiểu thật rõ và vững chắc. Vậy khi đi làm thì có yêu cầu chúng ta phải hiểu thật sâu như vậy không? Em làm đồ án ở đại học, sau mỗi kì, tụi em có thể làm xong khoảng vài đồ án và biết thêm một số vấn đề. Nhưng kiến thức học được từ việc làm đồ án cũng rất vụn vặt, mỗi phần một chút, rất không có hệ thống và cũng không nắm vững lắm về những gì đã làm. Anh có thể nói rõ hơn giúp em về phần kiến thức mình chuẩn bị cho phỏng vấn và phần kiến thức chuẩn bị để làm việc khác nhau như thế nào không?

    • Minh Thạch Phạm, câu hỏi của em hơi khó trả lời, vì nó còn tùy vào đặc thù dự án và văn hóa công việc của từng công ty nữa.

      Một số công ty lớn khi tuyển dụng thì họ nhắm đến việc tìm kiếm những ứng viên thông minh và có tố chất tốt, thông qua những kiến thức cơ bản chứ ko yêu cầu phải rành một framework cụ thể nào cả (sau khi tuyển dụng thì họ sẽ có một khóa training về framework và công nghệ đang sử dụng). Còn một số công ty khác lại muốn tuyển được những người có kinh nghiệm trên một số framework nào đó, khi tuyển về là có thể làm ra sản phẩm ngay.

      Bởi vậy anh nghĩ về kiến thức cơ bản thì mình cần phải nắm vững (một số kiến thức sâu quá thì cũng chưa cần tìm hiểu, vì người ta cũng ít khi hỏi đến), và cũng nên tìm hiểu thêm một vài framework nữa để có nhiều lựa chọn khi đi phỏng vấn sau này.

  3. Giả sử các bạn tìm được 1 ứng viên đáp ứng đầy đủ yêu cầu của bài viết này ở Việt Nam. Vậy thì các bạn có thể cho biết mức lương các bạn sẽ trả cho người này khoảng bao nhiêu không ?

    • scvn80, thực ra theo Jeff Atwood và Steve Yegge thì đây chỉ là tiêu chí để sơ loại một lập trình viên qua điện thoại. Ứng viên sau khi qua vòng này mới được xem là có kiến thức “cơ bản” và được mời đến công ty làm bài test và trả lời phỏng vấn trực tiếp, lúc đó mới bàn đến chuyện lương bổng. 🙂

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s