最近參加了工作後的第一次面試，雖然最終沒談成，但是收獲還是不少，不管是技術還是面試經驗還是得多多積累呀。
這一次面試與在學校時候參加過的面試區別還是挺大的。
校園招聘的面試問的問題似乎都比較具體，直接針對技術點，這樣的問題如果知道就是知道，不知道嘛就是不知道。。。
而這一次面試問的問題大多都非常粗犷，似乎是面試官想讓自由發揮的空間更大，也就是盡量把自己理解的內容說出來就好。。。
然而我有好幾個問題都是能說而沒說。。估計給面試官留下了不好的印象。以下記錄幾個回答得非常糟糕的技術問題，各位面試者以我為戒。。。
問題一：談一談內存優化
這個問題的前一問是“談一談C#的內存管理”，我回答得非常簡潔“CLR通過GC來回收內存”。。。
聽到這一問我就有點懵B了，這是在問我怎麼優化GC算法嗎?!我真是對GC的算法實現一竅不通啊，於是草率地做出了回答：
不知道。。。。。(然後倆人沉默數秒)
事後分析：
首先不管面試官問的是不是GC的算法優化，我當時的回答肯定是讓面試官無語了，不光是讓人覺得技術上深度不夠，而且可能讓人覺得面試態度不端正。
而且就算是對“優化”說不出什麼內容，也可以說說“渣化”嘛，從反面來說一說自己的理解總還是比啥都說不出來好得多的。
所以更好的回答應該是這樣的：
1）不要構造一個體積很大的struct。
因為值類型是可能被分配在棧上的，它占用的空間是沒有辦法被GC來管理的，何時釋放內存就得靠自己了。
2）如果實在要構造一個大體積的struct，那麼針對這個類型的方法參數應該考慮使用ref。
因為按值傳參的時候值類型會被完完全全的復制一遍，不僅費空間而且也費時間，不需要保留副本的時候直接傳址就會提高效率了。
3）釋放非托管資源用IDisposable而不是析構函數。
因為析構函數被調用的時機是極度不確定的，即使運行過析構函數的對象也得等到下一次GC才會被回收。而IDisposable就沒有這倆缺點了。
4）WeakReference。
對於一個占空間很大，構造起來不麻煩的對象，使用弱引用是個不錯的選擇。
問題二：C#能不能寫非托管代碼
接到這個問題我也是非常沒底，因為自己沒拿C#寫過什麼非托管代碼啊，而秉著“寧可信其有不可信其無”的原則，又覺得可能會存在實現非托管代碼的方法。。。
支吾了一陣後，想到了會不會問的是指針呢？然後就說了這麼一嘴。。。
事後分析：
嚴格來說C#是個編程語言，托不托管的全靠編譯器。然而面試官顯然不是問這個。。。
再說unsafe代碼吧，它仍然是依賴於CLR，接受類型檢查，所以我覺著應該是托管的。NGen也離不了CLR，還是托管。。。
.NET Native這種就不知道該咋算了，我理解的是它把CLR精簡以後一起給編譯成本地代碼了，貌似也還是沒有完全脫離CLR。
後來百度到了一個神奇的東西，C#寫的操作系統。。。神人所為
http://en.wikipedia.org/wiki/SharpOS_%28operating_system%29
更好的回答：
把自己的理解給說出來就好了，比啥都不說強。。。
問題三：談一談綁定和依賴屬性
這個問題問到了我的技術盲區。。。雖然以前看過WPF的書，可是長久不用又不回頭溫故，早就忘得差不多了。早知今日，當初就不把這書的事往簡歷上頭寫了。。。
面試的時候只是隱約記得有個INotifyPropertyChanged，就回答了依賴屬性的set方法裡頭觸發個了事件實現了綁定。。。
事後分析：
把源碼一翻就發現不管是DependencyProperty還是DependencyObject都和INotifyPropertyChanged沒有半毛錢關系。。。
那麼這綁定是通過什麼來實現的呢，於是繼續翻源碼。。。
從FrameworkElement.SetBinding入手，一直翻到了BindingExpressionBase。看到這個類裡頭有個ValueChanged事件，頓時覺得真相離我不遠了。。。
然而繼續往下翻，死活沒找到DependencyObject.SetValue和這個事件的關聯。。。
最後實在沒招了只能Debug跟源碼，每個看上去可疑的方法都F11進去一探究竟，費老大功夫了真是。。。
然後跟到了這個方法DependencyObject.NotifyPropertyChange這名字怎麼這麼眼熟呢。。。ORZ
更好的回答：
這個真沒法答。。。只能怪平時沒溫故了
最後想說的是，應屆生找工作其實還是有優勢的，校招的時候企業會更看重學生的未來增量，當前存量不會奢求。
同時大型企業會比中小企業更看重增量，因為中小企業擔不起那個風險嘛，要讓他們拿成本去賭應聘者的成長性太難了。
