Phỏng vấn DevOps: Vì sao nhiều người trượt

Vấn Đề Thầm Kín Mà Ai Cũng Tránh Nhắc Đến Trong Giới DevOps

Dạo này tôi đọc được một đoạn tâm sự thẳng tưng của một bác quản lý tuyển dụng mà tôi phải dừng lại, suy nghĩ mãi. Bác ấy mở đầu bằng một câu phán xanh rờn thế này:

Cái tình hình tuyển DevOps dạo này nó loạn xạ hết cả lên các bác ạ. Cứ như là cứ dăm ba ứng viên thì lại có một ông kiểu tay ngang, thích mày mò linh tinh ấy. Họ không phải dân dev chuyên, cũng chẳng phải chuyên gia ops gì sất, chỉ là mấy anh chàng ôm rơm rặm bụng thôi, thấy DevOps đang hot nên nhảy vào, rồi bằng cách nào đó lại kiếm được việc hồi cái thời thị trường công nghệ sôi động 2020-2022.

Nghe đau điếng các bác nhỉ. Là người lăn lộn trong ngành tech bao năm, tôi thấy cái này nó đúng phóc luôn, vì tôi chứng kiến cả hai mặt của cái nỗi đau này rồi

Một bên là các bác quản lý tuyển dụng cứ than trời vì không tìm được ứng viên xịn dù hồ sơ chất đống. Một bên khác là mấy anh em kỹ sư kinh nghiệm đầy mình mà mãi chẳng kiếm được việc ngon, dù phỏng vấn tới chục vòng.

Rốt cuộc là chuyện gì đang xảy ra vậy? Và quan trọng hơn là, làm sao để mình không bị gắn mác thợ vọc trong buổi phỏng vấn DevOps sắp tới?

Cạm Bẫy Chứng Chỉ Có Chứng Chỉ Là Thơm? Xin Lỗi Đi Nha!

Thôi, mình nói thẳng ra cái vấn đề ai cũng biết mà ngại nói nhé: Mấy cái chứng chỉ không còn thần thánh như xưa nữa đâu.

Cái bác quản lý tuyển dụng kia kể, có mấy ứng viên ôm đống chứng chỉ AWS với Kubernetes mà hỏi mấy câu cơ bản về load balancer hay SSL termination là tịt ngóm. Đấy, nó chỉ ra một vấn đề ngày càng lớn trong ngành mình: cái khoảng cách giữa lý thuyết suông và kinh nghiệm thực chiến.

Thật lòng mà nói, học thuộc lòng để lấy chứng chỉ không biến các bác thành DevOps Engineer được đâu.

Một bác bình luận, có hơn 20 năm kinh nghiệm trong nghề, chốt hạ một câu mà tôi tâm đắc: Giờ tràn lan mấy cái kiểu thầy dạy, rồi ngân hàng đề thi, đáp án mẫu, với mấy lời hứa hẹn rằng DevOps dễ òm, chỉ cần học thuộc đề thi AWS với K8S cuối tuần là có chứng chỉ ngay.

Phỏng Vấn Thực Tế Phũ Phàng Thế Nào?

Vậy các bác quản lý tuyển dụng họ thực sự tìm kiếm điều gì? Theo dõi cái thread kia thì tôi rút ra mấy cái mấu chốt này:

  • Kiến thức nền tảng vững vàng hơn là mấy từ đao to búa lớn.
  • Kỹ năng xử lý sự cố thực tế.
  • Quan trọng nhất: Khả năng đọc… thông báo lỗi! Nghe vô lý nhưng mà đúng vậy

Một bác quản lý tuyển dụng chia sẻ một câu chuyện cười ra nước mắt: Cuối cùng, tụi tôi đành phải thuê một anh chàng vì không kiếm được ai ra hồn. Anh ta cứ loay hoay mấy ngày trời cố gắng kéo một cái container image rồi than là có gì đó bị hỏng. Đến khi tụi tôi phải bảo là ông ơi, không có key thì làm sao mà kéo được image từ repo riêng tư?, mà rõ ràng trong log của k8s nó cũng báo là thiếu secret mà không chịu đọc

Nghe thì thấy xấu hổ thật, nhưng nó lại nói lên một điều quan trọng: Kỹ năng xử lý sự cố cơ bản và khả năng đọc lỗi là những thứ không có cái chứng chỉ nào dạy được đâu các bác.

Sao Các Bác Kinh Nghiệm Lại Khó Kiếm Việc?

Điều thú vị là, trong cái thread bình luận đó, có rất nhiều anh em DevOps kỳ cựu lại than thở rằng họ đang chật vật tìm việc:

Kiểu gì ấy, tôi có 20 năm kinh nghiệm, 8 năm làm DevOps mà giờ đi kiếm việc ngon cứ chật vật. Mất thời gian vào mấy bài đánh giá kỹ thuật tào lao, rồi phỏng vấn vòng này vòng kia dài lê thê…

Một kỹ sư kinh nghiệm khác lại than: Mới đây, một sếp cũ của tôi, người mà tôi từng làm việc cùng rất ăn ý, giới thiệu tôi vào vị trí DevOps ở công ty mới của anh ấy. Hai anh em hiểu nhau quá rồi còn gì. Tôi làm bài tập về nhà 3 tiếng đồng hồ về Terraform và Ansible ngon ơ, điểm cao chót vót. Thế mà rồi lại trượt buổi phỏng vấn với một ông DevOps bên đó. Ông ta cứ khăng khăng hỏi mấy câu cực kỳ chi tiết về sự khác biệt giữa các phiên bản TF, rồi sự khác nhau nhỏ nhặt giữa dịch vụ AWS và Azure, với mấy cái thứ trời ơi đất hỡi chỉ dựa vào mấy vấn đề ông ta vừa gặp phải gần đây.

Vấn Đề Thật Sự Quy Trình Phỏng Vấn Toang

Mấy cái bình luận kia cho thấy một hệ thống bị hỏng từ cả hai phía:

  • Ứng viên thì cứ qua mặt hệ thống bằng chứng chỉ ảo mà thiếu kỹ năng thật.
  • Công ty thì có quy trình phỏng vấn tệ hại, cứ lọc bay hết những ứng viên giỏi.
  • Mấy ông phỏng vấn kỹ thuật thì cứ hỏi mấy câu đố mẹo về mấy cái công nghệ cưng của họ.
  • Rồi thì phỏng vấn mấy vòng dài lê thê, tốn thời gian của cả đôi bên.

Một ứng viên bức xúc nói thẳng: Nếu mà họ không thể cử một trong những người giỏi nhất của họ ra để làm một buổi nói chuyện 30 phút, xem thử ứng viên có KINH NGHIỆM THỰC CHIẾN hay không, rồi chuyển sang vòng gặp gỡ team để quyết định cuối cùng, thì điều đó nói lên cái gì về công ty đang tuyển dụng đó?

Làm Thế Nào Để Chuẩn Bị Phỏng Vấn DevOps Thật Sự Hiệu Quả?

Dựa trên những kinh nghiệm xương máu của cả ứng viên thành công và các bác quản lý tuyển dụng, đây là cách để chuẩn bị thật tốt:

1. Nắm Vững Kiến Thức Nền Tảng Trước Đã!

Một bác quản lý tuyển dụng tiết lộ cách họ sàng lọc ứng viên:

Chúng tôi ưu tiên những ai có nền tảng Linux vững chắc kèm theo kiến thức về Dev, vì chúng tôi tin rằng những thứ còn lại có thể dạy được.

Đây là một điểm cực kỳ quan trọng đó các bác. Trước khi nhảy vào Kubernetes hay Terraform, hãy đảm bảo mình thật cứng mấy cái này:

  • Quản trị và xử lý sự cố Linux
  • Kiến thức nền tảng về mạng kể cả cách mấy cái load balancer hoạt động ra sao
  • Kiến thức cơ bản về bảo mật cả cách SSL/TLS hoạt động nữa
  • Kỹ năng lập trình/scripting cơ bản

2. Tìm Cách Có Kinh Nghiệm Giải Quyết Vấn Đề Thực Tế

DevOps rốt cuộc là để giải quyết vấn đề thôi mà. Hãy tìm cách để thể hiện kỹ năng này:

  • Đóng góp vào các dự án mã nguồn mở (nhớ là phải đóng góp có ý nghĩa, đừng chỉ sửa lỗi chính tả nhé).
  • Tự xây dựng một cái home lab để mày mò công nghệ.
  • Ghi lại quá trình xử lý sự cố và các giải pháp của mình.
  • Tập giải thích các khái niệm kỹ thuật phức tạp một cách rõ ràng.

3. Học Cách Đọc Logs Nghe Buồn Cười Nhưng Mà ĐÚNG!

Cái này được nhắc đi nhắc lại nhiều lắm trong thread kia. Khả năng xử lý sự cố bằng cách đọc kỹ thông báo lỗi có vẻ hiếm nhưng lại được đánh giá cực kỳ cao:

Nếu tôi có thể tính tiền theo giờ khi giúp mấy anh senior đọc mấy cái thông báo lỗi hay dòng log, chắc tôi đủ vốn để mở công ty tư vấn riêng rồi.

Hãy biến cái việc này thành thói quen hàng ngày của các bác. Khi có gì đó tạch, hãy bình tĩnh, đọc lỗi thật cẩn thận trước khi vội vàng nhảy vào sửa.

4. Thành Thật Về Những Gì Mình Không Biết

Nhiều bác quản lý tuyển dụng nói rằng họ tôn trọng những ứng viên dám thừa nhận điểm yếu hơn là cố gắng chém gió:

Cá nhân tôi thì dành nhiều thời gian đọc code hơn là viết code.

Cứ thành thật về những gì mình chưa biết, nhưng hãy thể hiện quá trình mình sẽ học hỏi nó như thế nào. Một câu trả lời hay không phải là Tôi không biết mà là Tôi chưa làm việc với công nghệ cụ thể này, nhưng đây là cách tôi sẽ tiếp cận để học nó…

5. Xây Dựng Một Portfolio Gồm Các Giải Pháp Thực Tế

Một kỹ sư DevOps dày dạn kinh nghiệm chia sẻ:

Cách phỏng vấn mà tôi thích nhất cho đến giờ là một kỹ sư ngồi trên Zoom kéo lên một đống code Terraform và Python rồi yêu cầu tôi đi qua từng khối code và mô tả nó làm gì, cuối cùng là nó đạt được mục đích gì. Cách này cho phép tôi thể hiện rằng tôi có thể đọc code và hiểu chuyện gì đang xảy ra, thay vì trả lời mấy câu hỏi linh tinh vô định.

Hãy chuẩn bị cho điều này bằng cách có sẵn các đoạn code mẫu của mình để thảo luận. Ghi lại các dự án của mình, bao gồm:

  • Vấn đề mà bác đang giải quyết là gì.
  • Cách tiếp cận của bác và lý do chọn nó.
  • Những thách thức đã gặp phải và cách vượt qua.
  • Những gì đã học được trong quá trình đó.

Sự Thật Về Vai Trò DevOps Vắt Chanh Bỏ Vỏ?

Một bình luận rất sâu sắc đã chỉ ra cái cốt lõi của vấn đề:

DevOps đứng giữa hai lĩnh vực chính. Một vấn đề tương tự cũng xảy ra trong phát triển firmware. Rất dễ tìm được một dev giỏi và dễ tìm được một kỹ sư phần cứng giỏi, nhưng tìm được một người chuyên cả hai thì gần như là không thể.

Điều này phản ánh sự căng thẳng cơ bản trong các vai trò DevOps. Bác được kỳ vọng sẽ hiểu cả phát triển (Development)vận hành (Operations), mà theo truyền thống thì hai cái này đòi hỏi tư duy và kỹ năng khác nhau.

Một kỹ sư khác mô tả thực tế khi làm DevOps:

Tôi đã dùng terraform, python, aws, eks, helm, làm việc với dns các thứ… nhưng vấn đề là tôi chỉ động vào một trong những công cụ đó sau 2-3 tháng rồi lại nhảy sang cái khác. Cuối cùng thì tôi cũng học được cái này cái kia, nhưng mà cứ quay lại viết một cái lambda bằng Python rồi tạo nó trong Terraform sau 6 tháng không làm thì tôi chịu, không nhớ chi tiết đâu

Đây chính là thế giới thực của DevOps: liên tục chuyển đổi ngữ cảnh và học hỏi. Những ứng viên tốt nhất là những người thể hiện được khả năng thích nghi và có nền tảng vững chắc, chứ không phải là nhớ vanh vách mọi câu lệnh

Lối Đi Nào Cho Tương Lai?

Nếu các bác đang muốn nhảy vào ngành DevOps hoặc muốn phỏng vấn thành công hơn, thì hãy tập trung vào việc xây dựng một nền tảng kỹ năng thực tế thật vững chắc, thay vì cứ chạy theo mấy cái chứng chỉ nhé.

Hãy nhớ rằng DevOps rốt cuộc là để lấp đầy những khoảng trống: giữa phát triển và vận hành, giữa lý thuyết và thực hành, giữa nhu cầu kinh doanh và khả năng kỹ thuật.

Và nếu các bác đang ở bên phía tuyển dụng, hãy thử nghĩ xem, liệu quy trình phỏng vấn của mình có đang vô tình loại bỏ những kỹ sư kinh nghiệm mà mình đang tìm kiếm không?

Như một bác quản lý tuyển dụng đã thành công trong việc xây dựng team chia sẻ: Sau khi phỏng vấn 3 ứng viên hơi tệ, tôi phát ngấy và viết lại cái mô tả công việc, loại ứng viên mà chúng tôi đang tìm kiếm, rồi ngồi lại với HR để họ biết chính xác chúng tôi cần gì. Từ đó trở đi, mọi người tôi phỏng vấn đều rất hợp với những gì chúng tôi tìm. Dùng quy trình đó, chúng tôi đã xây dựng được một team cực kỳ mạnh

Có lẽ đã đến lúc tất cả chúng ta, cả ứng viên và công ty, cùng ngồi lại để suy nghĩ lại cách tiếp cận việc tuyển dụng DevOps. Bởi vì rõ ràng, hiện tại có gì đó đang… toang thật rồi.

Article Thumbnail
Datadog Webinar: Modernize AWS Logs at Scale
Chia sẻ bài viết:
Theo dõi
Thông báo của
0 Góp ý
Được bỏ phiếu nhiều nhất
Mới nhất Cũ nhất
Phản hồi nội tuyến
Xem tất cả bình luận