Tin vui đón Xuân (2)
Sau Tết, mình lại có thêm tin vui mừng Xuân. Hôm qua mình đã thi xong qualification exam, kết thúc bước đầu tiên của tiến trình PhD. Hai bước còn lại là: bảo vệ đề cương luận án (preliminary exam = dissertation proposal) và bảo vệ luận án (final exam = dissertation defendance).
Qualification exam là kì thi bắt buộc của nghiên cứu sinh ở đa số các trường ở Mỹ. (Một số khoa/trường – thường là rank thấp – không có kì thi này). Nhìn chung mục đích của qualification exam là để kiểm tra sinh viên PhD có “đủ kiến thức cơ sở để làm nghiên cứu” và “có biết cách suy nghĩ như một nhà nghiên cứu” không. Một số khoa/trường thì kết hợp cả qualification exam và preliminary exam nên yêu cầu sinh viên phải bảo vệ cả đề cương nghiên cứu của luận án. Khoa mình thì không như vậy.
Trước đây thi qual ở khoa mình khá đơn giản. Sinh viên chỉ cần làm một bài thi trong 2h, giải quyết một số bài toán kiểm tra kiến thức cơ sở (ví dụ như ngành software engineering của mình thì thi về nguyên lí hệ điều hành, thuật toán, phân tích hệ thống). Khi mình mới sang thì khoa chỉ có duy nhất hình thức thi này, vì thế nên mình chủ quan, không thi ngay vào kì Spring 2008.
Tuy nhiên, thi qual như vậy chỉ trả lời được câu hỏi “nghiên cứu sinh đủ kiến thức cơ sở để làm nghiên cứu” không? Và câu trả lời cũng khá phiếm diện, vì làm sao có thể kiểm tra kiến thức cơ sở trong nghiên cứu của lĩnh vực hẹp chỉ trong 2h và vài bài toán (thường phải khá đơn giản để làm được trong 2h). Một sinh viên ôn tập chăm chỉ các nội dung cần thiết trong một vài ngày và làm bài cẩn thận là có thể qua được qual dễ dàng. Vì thế nên hội đồng khoa họp và thảo luận với nhau thay đổi cách thi, nhấn mạnh vào việc kiểm tra sinh viên “có biết cách suy nghĩ và làm việc như một nhà nghiên cứu” không.
Trong cách thi mới, mỗi sinh viên sẽ phải thực hiện và viết report/paper về một original research, present và discuss về research đó trước một hội đồng. Như vậy, khi thi qual, nghiên cứu sinh phải thực sự tiến hành nghiên cứu một vấn đề cụ thể với đủ các bước: tìm bài toán (problem formulation) + đưa ra lời giải (solution design) + cài đặt thử nghiệm (implementation) + kiểm định (evaluation) + viết paper/report (verbal presentation) + trình bày (oral presentation) + bảo vệ (discussion). Tất nhiên hội đồng không yêu cầu cao về mức độ hoành tráng của problem hay solution. Họ chủ yếu muốn kiểm tra khả năng tư duy (thinking), khả năng trình bày (communicating) và các kiến thức cơ sở (background) liên quan đến research đó. Ví dụ, họ thường hỏi: Tại sao bạn giải bài toán A đó (tức là muốn hỏi motivation của research)? Có người đã giải bài toán B tương tự rồi, sao bạn còn giải A (tức là muốn hỏi novelty/originality của research). Sinh viên phải chỉ ra A khác với B như thế nào, ví dụ: challenging hơn, ở một domain khác nên có characteristics khác và sự khác biệt đó là đáng kể. Nếu sinh viên trả lời tốt những câu hỏi đó thì họ quay sang hỏi về kiến thức chi tiết. Ví dụ, nếu sinh viên bảo bài toán vốn là NP-hard thì hội đồng sẽ hỏi NP-hard là thế nào? Nhìn chung, qual exam kiểu này tương đương với một master thesis.
Cách thi thứ hai này thì phù hợp với mình hơn (vì mình vốn lười học, lười nhớ, thi kiểu đầu tiên dễ trượt lắm ;;). Hơn nữa, mình thực sự đã làm khá nhiều research, trải qua đủ các bước nên cũng có nhiều thứ để trình bày. Tuy nhiên do lười biếng nên mãi đến kì này mình mới đăng kí thi. Để đảm bảo chắc ăn, mình chọn công trình tốt nhất của mình, graph-based mining of usage patterns: được publish ở hội nghị top, được award và được luyện tập nhiều. (Mình đã trình bày bài này ít nhất 3 lần – ở FSE, ở VEF 2010 và ở student seminar).
Vậy mà bắt đầu cũng không suôn sẻ lắm. Nguyên nhân chủ yếu là mình chưa điều chỉnh tốt với các nhóm audience khác nhau. Ở 3 chỗ trên, đối tượng của mình chủ yếu là sinh viên với kiến thức và mối quan tâm khá phân tán, vì vậy nên mình thường nhấn mạnh vào motivation và dùng cách diễn đạt informal cho dễ hiểu. Tuy nhiên đối tượng lần này của mình lại là các giáo sư. Đặc biệt có Dr. Kothari là người có thói quen tư duy rất “toán”, yêu cầu mọi thứ cần phải được định nghĩa chính xác trước khi chuyển sang bước tiếp theo. Vì thế nên ngay trong motivation, khi mà mình trình bày với một số thuật ngữ informal (ví dụ usage scenario, object interaction), ông ấy đã hỏi mình tới tấp về định nghĩa cụ thể cho từng khái niệm đó. Mình và ông ấy mất một thời gian khá lâu để diễn giải từng khái niệm theo cách hiểu của mình và của ông ấy.
Trong chuyện này mình rút ra một kinh nghiệm như sau. Giả sử có hiện tượng X, mình gọi là A, ông ấy gọi là B. Ông ấy không hiểu A là X, mà hiểu A là Y khác X. Thay vì cố gắng giải thích A là X theo cách mình hiểu thì mình có thể dùng luôn B để gọi X theo cách của ông ấy trong các phần tiếp theo, không dùng A nữa. Mình nên làm thế vì bản chất của communication là truyền đạt ý tưởng: mục đích cuối cùng là để 2 cùng phải hiểu về X. Mọi chuyện sẽ trở nên bế tắc hoặc rối rắm hơn nếu cả 2 bên vẫn cứ tranh luận A là gì, B là gì, X là A hay B thì mới đúng. Trong khi nếu mình dùng B để gọi X thì ông ấy hiểu X dễ hơn, vì ông ấy có định kiến “B là X, A là Y” rồi. Phá vỡ một định kiến rất khó, hơn nữa chưa chắc cách mình gọi X là A đã chính xác. Tất nhiên, nếu mình vẫn muốn giữ quan điểm của mình là dùng A để gọi X, thì mình phải mô tả X trước, sau đó phát biểu là từ bây giờ X sẽ được gọi là A (chính là yêu cầu phải định nghĩa mọi thứ trước khi sử dụng của Dr. Kothari).
Nhìn chung sau khi vượt qua được cái “communication gap” do sự khác biệt về terminology này thì mọi chuyện suôn sẻ, tiến hành vui vẻ. Mình được cả hội đồng khen là good job và cho pass luôn. (So với mọi người trong lab thì mình may mắn hơn vì hai bạn khác không pass ngay trong lần thi đầu tiên – chủ yếu là do vấn đề communication với hội đồng). Mình đang tính xem không biết có nên tiếp tục đà may mắn này thi prelim trong kì Fall 2010 và final trong kì Spring 2011 để tốt nghiệp sớm không ;).
