Quần Cam

Chuyện làm bài test phỏng vấn

Khi phỏng vấn ở các công ty nước ngoài, các nhà tuyển dụng thường đề nghị bạn làm một bài “test-assignment”, để kiểm tra cách bạn giải quyết một vấn đề về kĩ thuật.

Đây là một vòng quan trọng, nhưng không khó, sau khi bạn đã trải qua những vòng “xương xẩu” như thuật toán trước đó. Mục tiêu của vòng này là để nhà tuyển dụng nắm được mindset và workstyle của bạn, để xem bạn có phù hợp với team của họ hay không?

Để không rớt vòng này, bạn nên chú ý một số điểm như sau.

Phần code

Phần code tất nhiên là quan trọng nhất. Bạn phải đảm bảo cho code sạch, đẹp, dễ hiểu và chạy. Bên cạnh đó những thứ dưới đây cũng nên được quan tâm.

1. Hướng dẫn sử dụng

Rất nhiểu bạn khi nộp bài chỉ nộp đúng code. Đây là thiếu sót, có bao giờ bạn giao dự án cho khách hàng mà chỉ giao source code không?

Hãy chạy nó để showcase là code của bạn có thể tự tin chạy tốt trên production. Nếu bài test của bạn là một web app, deploy nó lên Heroku. Nếu là một bài về thuật toán, gửi kèm benchmark.

Nếu không thể chạy, hãy ít nhất viết một hướng dẫn sử dụng, như README.md, đặt trong ngay repo, gợi ý về môi trường chạy, dependencies và các thứ liên quan để bật và chạy code.

Những việc này thể hiện bạn là một người chỉn chu và có trách nhiệm. Nếu bạn là nhà tuyển dụng, bạn thích làm việc với một người như vậy, hay là một người vô trách nhiệm để người khác bơ vơ không biết cách cài đặt?

2. Đặt câu hỏi

Đừng nghĩ đặt câu hỏi khi bạn bị bí là một thất bại. Bạn chỉ thất bại khi không hoàn thành công việc thôi.

Trao đổi là một việc cần thiết khi làm việc nhóm. Trao đổi giúp xoá tan vướng mắc và giúp mọi người nhìn cùng một mục tiêu. Vậy ngại gì mà không hỏi nếu nó giúp bạn làm xong việc?

Đặt câu hỏi cho nhà tuyển dụng nếu bạn không hiểu đề, hay cần thêm thông tin, mình tin là nhà tuyển dụng sẽ rất sẵn lòng giải đáp cho bạn. Ở một mức độ nào đó việc hỏi còn thể hiện bạn thực sự hứng thú và nghiêm túc với cơ hội làm việc tại công ty.

Tất nhiên là chỉ nên hỏi về đề và các business logic mà bạn không nắm chắc, không nên hỏi quá nhiều lần và quá nhiều câu. Đừng hỏi những câu như: “Tôi dùng Ruby on Rails có được không?” bởi vì “Dùng bất kì cái quần gì mà làm xong việc”. Nên đọc kĩ đề, gom nó thành một tập các câu hỏi rồi gửi cùng một lượt.

2. Chú ý code style

Cái đẹp đè bẹp cái nết.

Mình đảm bảo với các bạn điều này, mỗi công ty đều có ít nhất một tên “Syntax Nazi”. Đầu tiên tên này sẽ dạo một lượt cái codebase của bạn, một khi hắn đã ghét codestyle trong đó thì bạn có viết code như DHH () cũng bị ghét (con người yêu ghét rất chủ quan). Mà vậy thì bạn khó được đánh giá cao lắm.

Cái này hơi khó vì code style mỗi team khác nhau. Hãy cố gắng đi theo một code style của cộng đồng, ví dụ như Ruby thì có Ruby style guide, Javascript có Airbnb JS style guide, Python có PEP8.

Tránh phạm những lỗi như.

# thụt ra thụt vào có tâm.
def hello(name)
puts "Xin chào" + name;
  end

Thậm chí có lần phỏng vấn một công ty ở bên Úc, mình còn nhờ một anh từng làm việc tại công ty đó giúp xem qua code để biết code style và convention bên đấy là như thế nào. (đương nhiên là mình không có rớt)

3. Cây commit chỉnh chu

Phần này mình thấy khá quan trọng mà nhiều bạn hay bỏ qua.

Thông qua bài test, cái mà người tuyển dụng muốn biết là cách bạn giải quyết một vấn đề bằng code. Một trong những cách dễ nhất là lướt qua cây commit.

Một cây commit chỉnh chu sẽ mô tả rõ ràng mục đích của từng commit. Hãy đảm bảo cho cây commit của bạn gọn gàng, không có type, tránh những message như “Fixup a7584d” hay “asdfafd”. Mình có viết về good commit ở đây.

# see no evil
f12345 i promise
e12345 now this works
d12345 fix 2
c12345 fix
b12345 get it up and running
a12345 Init commit

4. Nhớ viết test

Trừ khi nhà tuyển dụng đề nghị giấy trắng mực đen là “Bạn không cần viết test”, còn không thì cứ viết, không có chết thêm cái tế bào não nào đâu.

Viết test góp phần chứng tỏ với nhà tuyển dụng rằng code của bạn chạy, trước đó đảm bảo code của bạn pass hết test.

Đừng viết test kiểu viết cho có, trình bày rõ ràng mỗi cái test sẽ làm gì.

# bad
it "run the test" {} # WTF

# good
it "detects whether user has logged in" {}

5. Đừng viết dài dòng

Mình từng gặp nhiều bạn cấn thận quá mức khi viết comment cho từng đoạn code một cách dài dòng lê thê.

Bạn nên nhớ rằng quá nhiều comment sẽ tạo ra sự xao nhãng khi người phỏng vấn đọc code của bạn. Hơn nữa nếu code của bạn tốt, nó đã không cần comment để giải thích cho người đọc biết nó đang làm gì.

Cái đáng được comment là lý do bạn viết dòng code đó (nếu cần thiết).

Mình ví dụ.

# BAD
def add_product_to_order(order, product, amount)
  # Reload product from the database
  product.reload
end

# GOOD
def add_product_to_order(order, product, amount)
  # There is a chance that product data has been outdated during the checkout
  # process, to avoid race condition in adding product to cart, this code
  # ensures product data is always fresh and updated.
  product.reload
end

Phần Trình bày

Tuỳ công ty mà có khi họ sẽ yêu cầu bạn phải trình bày và bảo vệ giải pháp của bạn. Nếu có một vòng như thế, bạn nên chú ý những điều sau.

1. Trình bày trôi chảy

Hãy tập nói trôi chảy, luyện nói ở nhà, luyện nói trước gương sao cho lúc phỏng vấn bạn không có ấp úng.

Nếu bạn phỏng vấn các công ty nước ngoài bằng tiếng Anh, đảm bảo bạn phát âm rõ ràng, rành mạch. Không cần cố gắng luyến láy giọng Anh Mỹ Ấn, được thì rất tốt, còn không hãy cố gắng nói sao cho người nghe hiểu.

2. Đảm bảo bạn hiểu từng dòng code

Hãy chắc chắn khi người phỏng vấn hỏi bạn: “Tại sao phải có dòng code này?”, bạn biết cách trả lời. Thành thật chia sẻ những điều bạn nghĩ khi code dòng đó.

Đôi khi bạn copy paste một cái regex kiểm tra email hay một cái hàm tìm được trên StackOverflow. Không sao cả, ai cũng làm thế thôi. Cái quan trọng là bạn phải hiểu cái regex đó, cái hàm đó làm những gì.

Nhớ là code mà không biết mình code cái gì … rất là nguy hiểm.

3. Tranh luận xây dựng

Khi người phỏng vấn không đồng ý với giải pháp của bạn, hãy tranh luận mang tính xây dựng. Mục tiêu của buổi bảo vệ là để tìm ra giải pháp tối ưu, chứ không phải để chứng minh giải pháp của bạn là tối ưu.

Nó rất giống như khi bạn làm việc nhóm, nhờ tranh luận mà giải pháp cuối cùng trở nên tốt hơn. Hạ cái ego (cái tôi) của bạn xuống, cứng rắn bảo vệ luận điểm của bạn nhưng mở lòng với gợi ý của người khác. Điều này nghe có vẻ rất dễ nhưng làm được thì không dễ chút nào.

4. Nói cảm ơn

Người Việt chúng ta ít nói cảm ơn. Mình nói vậy có nghĩa là chúng ta không có thói quen nói chữ cảm ơn chứ không phải là chúng ta không biết ơn người đã giúp chúng ta.

Nhiều khi phỏng vấn hồi hộp quá bạn quên, nhưng nhớ nói cám ơn thời gian của người đã phỏng vấn. Lịch sự không bao giờ thừa cả.


Có một số điều nữa mà bài viết đã quá dài rồi. Chúc các bạn phỏng vấn thành công!

Shameless PR cái nữa là đọc xong nhớ like page, like một lần thôi.


NGUY HIỂM! KHU VỰC NHIỀU GIÓ!
Khuyến cáo giữ chặt bàn phím và lướt thật nhanh khi đi qua khu vực này.
Chức năng này hỗ trợ markdown và các thứ liên quan.

Bài viết cùng chủ đề

Vô chiêu thắng hữu chiêu

Giả định và Suy nghĩ khoa học

Trong cuộc sống hằng ngày, ta hay đưa ra những giả định và cho rằng nó mặc định đúng mà không kiểm chứng, nhưng chúng sẽ khiến bạn trông không thông minh lắm. Bài viết giới thiệu về cách suy nghĩ khoa học để tránh đưa ra các giả định.

Code Đức

Là một developer tất nhiên bạn phải chuyên nghiệp với nghề của mình. Thế nhưng chuyên nghiệp là như thế nào? Và bạn, một developer, sẽ phải hành xử ra sao mới được xem là chuyên nghiệp?