來了之後我覺得收穫最大的，就是資格考的準備課程，一般 CS 學生大概不覺得考試有什麼困難，我在台大更是第一個學期就考完了資格考 (離散/線代/OS/Archi/Algo/DS)。但是因為我念的 Software Engineering program 隸屬 Informatics department 底下，這整個 department 都怪怪的…嗯我是說這是一個跨領域的學門，即使是軟體工程，也特別偏重 human factor, human computer interaction, social impact 等與社會科學較相關的因素，所以我們的資格考不考 CS 專業科目，相反的，你必須用六個小時回答四道情境或申論題，然後在答案裡展現出你在整個軟體工程領域的學術與實務知識，考試結果有 PhD Pass, Master Pass 與 Fail 三種，教授們對於 PhD Pass 的答案更是有高度的期待，你必須呈現出你的抽象思考與解題框架，只引用參考文獻裡面的知識是不夠的。這是什麼意思呢？假設你要回答以下問題：

你負責規劃開發一個醫療資訊系統，而在軟體開發實務中有所謂的 A 流程/技術與 B 流程/技術，你覺得以這個系統來說，採用 A 或 B 那個比較好？為什麼？

身為一個工程師，我們解決問題的流程通常如下：

1. 大概了解要解決什麼問題，需要什麼核心功能
2. 直接 google 網路上最常見的解法，找最多人使用/文件最齊全的技術或工具
3. 直接把找到的解法套下去用，看看效果如何
4. 問題不一定要完全解決，只要使用者/利害關係人沒意見，就可以結案。然後接著處理下一個問題，因為現實世界中要解決的問題不只這一個。

好了，套用工程師思維，我很可能會先描述一下我對這個系統的假設，再依我對 A/B 流程或技術的實務經驗或相關論文的理解，選擇其中一個，並說明選擇的理由，為什麼我的選擇比較好，大概幾百字或頂多一頁 A4 就可以答完了。

這個理所當然的回答，大概只能得個 Master Pass.

真正有病的…嗯我是說真正完整的回答，不能只回答問題本身，你要回答的，是問題背後的問題。比如說：

什麼叫做”好”？在你假設的系統需求下，好的定義是什麼？它有可能改變嗎？ A/B 流程或技術的步驟或核心是什麼？是它們的哪一個環節比較符合你對於好的定義？就算你選擇了其中一個，另外一個在什麼情況下會比較好？甚至，要符合你所定義的好，採用哪個流程/技術根本不是重點，重點在其他地方？

看出來了嗎？你必須小題大作，題目要你選邊站，但你不能真的只選一邊，你必須要兼顧到兩邊，甚至有可能選哪一邊根本不是重點。所以首先你要把題目不清楚的地方都做好假設，接著拆解問題中專有名詞的概念，架構你答題的框架，最後把問題放入你的框架中回答，過程中參考文獻不是拿來答題用的，你必須先有自己的論點，然後引用文獻支持你的論點。這沒有個兩千字是寫不完的。

如果是在公司或與人口頭溝通時搬出這套，大概就直接被轟出門了，工程師思維的我內心的 OS 也是：誰有空聽你在那邊嘴這麼多？我甚至覺得雖然這跟寫論文所需的 critical thinking 有關，但很多時候論文只是起源於一個待解的問題，把解法想出來，related work, motivation 跟 evaluation 補一補就寫好了，要嘴到這樣也太走火入魔了吧！但是，我從一開始的不以為然，慢慢地也學著接受這個考驗，除了考試就是這麼現實以外，同時它也是一種思考訓練，最重要的是，它是訓練我運用文字跟嘴砲的好機會，因為從古希臘以降的西方哲學告訴我們，這個世界就是嘴出來的，你雖然不屑，但你會發現：你想嘴的時候還嘴不出來，因為你念的書不夠多。

這對我來說比考數學或專業科目難多了，根本是知識累積跟英文寫作的雙重難題，但我很樂意接受這個挑戰，畢竟這就是我來的目的。