Có một điều mình thấy rất thường xuyên khi trao đổi với các bạn theo hướng DV. Nhiều bạn thật ra học không tệ, thậm chí đã học qua lớp SystemVerilog & UVM, biết build UVM environment, VIP, functional coverage… Nhưng đến lúc đi phỏng vấn bị người ta hỏi những kiến thức đã học rồi thì lại bị khựng, trả lời ấp úng, và…fail.

Người phỏng vấn chỉ hỏi một câu rất cơ bản kiểu:

“Em giải thích giúp anh sự khác nhau giữa driver và monitor?”

Và thế là bắt đầu đứng hình vài giây. Trong đầu thì biết mình đã từng học qua, từng dùng rồi, nhưng không biết nên bắt đầu từ đâu. Lúc đó trong đầu bắt đầu xuất hiện 7749 câu hỏi:

“Giờ định nghĩa từng cái trước hay là so sánh luôn?”

“Giờ nói từ góc nhìn architecture hay implementation?”

…

Càng nghĩ thì càng rối, và cuối cùng câu trả lời trở nên vòng vo dù bản thân thật ra có hiểu.

Trong phỏng vấn kỹ thuật, nhiều bạn nghĩ fail interview là do thiếu kiến thức. Nhưng thực tế, với khá nhiều trường hợp, vấn đề không nằm ở việc không biết, mà là không biết cách tổ chức điều mình biết thành một câu trả lời rõ ràng và tự tin.

Kiểu như trong đầu bạn có rất nhiều mảnh thông tin rời rạc. Bạn biết driver dùng để drive stimulus vào DUT. Bạn biết monitor dùng để observe interface activity. Bạn cũng nhớ monitor là passive component, còn driver thì active và thường làm việc với sequencer. Tất cả đều đúng.

Nhưng vấn đề là khi phải gom những ý đó lại thành một flow logic trong khoảng 30 giây thì não bắt đầu loạn. Và đây mới là thứ khiến nhiều bạn mất điểm trong interview.

Thật ra chuyện này không chỉ riêng DV. RTL interview cũng có tình trạng tương tự. Nhưng với Verification thì hiện tượng này xảy ra thường xuyên hơn vì verification có rất nhiều khái niệm liên kết với nhau. Chỉ một câu hỏi nhỏ đôi khi có thể kéo theo sequence flow, TLM communication, phase mechanism, factory, config_db, objection… Nếu trong đầu không có structure rõ ràng thì rất dễ rơi vào trạng thái cái gì cũng biết một chút nhưng không diễn đạt được.

Đó là lý do mình luôn nghĩ rằng học kiến thức thôi chưa đủ. Một kỹ năng rất quan trọng khi học DV là khả năng đóng gói kiến thức thành những câu trả lời ngắn gọn, logic và có thứ tự.

Ví dụ với câu hỏi về driver và monitor, thay vì cố nghĩ quá nhiều, bạn chỉ cần trả lời theo một flow đơn giản: role của từng component là gì, chúng khác nhau ở đâu, data flow như thế nào và cuối cùng phục vụ mục đích gì. Lúc đó câu trả lời sẽ tự nhiên mạch lạc hơn rất nhiều.

Ví dụ:

“Driver là active component dùng để convert transaction thành pin-level signal và drive vào DUT. Còn monitor là passive component dùng để observe activity trên interface rồi convert ngược lại thành transaction để gửi sang scoreboard hoặc coverage collector. Nói ngắn gọn thì driver tạo stimulus, còn monitor quan sát behavior của DUT.”

Chỉ cần trả lời được như vậy thôi là interviewer đã cảm nhận được rằng bạn hiểu bản chất vấn đề và có khả năng organize ý khá tốt.

Thực tế thì trong interview, cách bạn trình bày đôi khi quan trọng không kém lượng kiến thức bạn có. Vì người phỏng vấn không đọc được suy nghĩ trong đầu bạn. Họ chỉ đánh giá dựa trên cách bạn diễn đạt kiến thức ra bên ngoài.

Có những bạn hiểu khá sâu nhưng trả lời quá rối khiến interviewer nghĩ là chưa nắm chắc. Ngược lại cũng có những bạn kiến thức chưa quá xuất sắc nhưng structure rất tốt nên overall impression lại khá ổn.

Thật ra sau một thời gian mình nhận ra, kỹ năng quan trọng không kém kiến thức trong ngành này chính là khả năng giải thích vấn đề.

Có những bạn kỹ thuật rất tốt, debug cũng ổn, nhưng khi trình bày lại issue thì người nghe vẫn không hiểu bug nằm ở đâu, testcase fail như thế nào, root cause là gì, hoặc tại sao fix này lại đúng. Trong khi ở môi trường làm việc thực tế, mỗi ngày gần như đều phải trao đổi kỹ thuật với rất nhiều người khác nhau: designer, DV, lead, architect, thậm chí đôi khi cả customer. Vậy nên khả năng organize ý và giải thích vấn đề rõ ràng thật ra là một kỹ năng rất đáng để luyện từ sớm. Kỹ năng này không chỉ giúp interview tốt hơn, mà còn giúp debug tốt hơn luôn. Vì khi bạn có thể giải thích một vấn đề một cách mạch lạc, thường cũng là lúc bạn đã thật sự hiểu vấn đề đó.

Vậy làm sao để improve khả năng này?

Theo mình, cách hiệu quả nhất là tập giải thích thật nhiều.

Nếu còn đang học đại học hoặc đang học gì đó, hãy thử chủ động xung phong giải thích bài cho bạn bè, support các bạn trong nhóm, hoặc thử trình bày lại lời giải theo cách của mình thay vì chỉ ngồi nghe.

Nhiều bạn nghĩ những việc đó chỉ là giúp người khác, nhưng thật ra người luyện được nhiều nhất lại chính là bản thân mình.

Vì lúc phải giải thích cho người khác hiểu, bạn sẽ bắt đầu nhận ra chỗ nào mình chưa hiểu kỹ, chỗ nào đang nói quá dài, chỗ nào logic chưa liền mạch, chỗ nào bản thân chỉ nhớ keyword chứ chưa thật sự hiểu bản chất…

Thậm chí nhiều anh em đi làm rồi thường nói vui rằng: một trong những cách học nhanh nhất là… đi dạy. Không nhất thiết phải dạy chuyên nghiệp. Chỉ cần là hướng dẫn junior, support teammate, hoặc chia sẻ lại kiến thức cho người khác thôi cũng đã giúp improve khả năng organize vấn đề rất nhiều rồi.

Ngoài ra, một cách khá hiệu quả mà nhiều bạn ít làm là tập trả lời thành tiếng. Đừng chỉ đọc slide rồi nghĩ rằng mình hiểu rồi. Hãy thử tự đặt câu hỏi cho bản thân kiểu như Factory là gì? Tại sao cần virtual interface? Scoreboard hoạt động như thế nào? rồi tự trả lời bằng miệng trong khoảng 30 giây đến 1 phút.

Lúc đó bạn sẽ phát hiện rất nhanh chỗ nào mình chưa thật sự hiểu, chỗ nào đang nói lan man, hoặc chỗ nào bản thân không biết nên mở đầu ra sao.

Nên nếu bạn đang nghĩ tech mình tốt, nhưng sao phỏng vấn fail hoài, thì rất có thể vấn đề không nằm ở việc bạn thiếu kiến thức. Mà là bạn chưa xây dựng được structure để biến kiến thức đó thành một câu trả lời rõ ràng và có flow thôi.