我最痛恨的是那種認為程式或電路只要"會動"就好的人。
做做小東西還可以，但是當專案越來越大時，就開始七拼
八湊。然後一些奇奇怪怪的問題就會慢慢浮現，有時候
run起來正常，有時候又有一些說不上來"怪怪"的問題。

設計者自己解決不了，同事想進去幫他，看到一堆雜亂
的程式碼，又不知從何找起。弄得無法收拾。

如果設計者不會想要去學習進一步的知識。那麼就只能
永遠停留在"會動就好"的程度。這樣的人滿街都是，自己
要如何跟別人競爭呢？

linux kernel source看不懂正常吧...
據傳，除了LT之外
能從頭到尾看懂100多萬行源始碼是在幹什麼的人
全世界應該不超過10個..

如果光是從硬體代工轉成軟體代工,就是一個很大的進步了
跟印度阿三搶搶生意也不錯

只可惜某x島上的老闆們腦中唯一的程式碼只有:
Begin:
10 代工代工代工代工代工代工代工代工代工代工代工代工
20 殺價殺價殺價殺價殺價殺價殺價殺價殺價殺價殺價殺價
30 搶單搶單搶單搶單搶單搶單搶單搶單搶單搶單搶單搶單
40 costdowncostdowncostdowncostdowncostdown
50 找奴工找奴工找奴工找奴工找奴工找奴工找奴工找奴工
60 call 政府(無薪假)
70 Ret
End

約耳談軟體裡有一篇：
--> 回歸原點

裡面有提到雖然我們現在都用高階語言寫程式，可是
跟底層有關的問題，有時還是會浮現上來。

裡面也順便提到C字串跟Pascal字串的不同。

你想太多了, 我說的是drivers,fs,...等,
不是整套OS, 更不用說這些東西變動太快, 沒幾個版本就又改api/structure, 寫個driver又要重看一次,
應該沒有人知道全部細節.

:think:

沒有順便考一下 startup code 跟 main 還有 function library 之間的關係嗎

C 真的是一個非常實戰派的語言，簡單優美效率高，

C++ 又把 C 語言跟軟體工程做了一個明快的結合，

讓軟體工程上一些想法可以清晰而有效率的實作出來，

個人認為在目前的電腦架構上，實作跟實用方面無人能出其右

我在業界二十一年，從 driver、firmware、tool chain 到 RTOS 都有做，

就缺 build OS 這塊沒有量產實作的經驗，不過我對軟體的看法跟前面幾位有些不同 ^^!!

我認為架構很重要，小東西還看不出來，做越久越大，要交給後人維護，有架構會比邊寫邊想好。

僅就目前個人工作經驗，我發現：

德國人：非常嚴謹、應學習其程式注解的習慣與架構組織。
美國人：異想天開、應學習其程式碼安排的巧思。
印度人：一目瞭然、應學習其簡單就是美，程式碼長短不是問題。
法國人：天女散花、了解函式呼叫的重要性，學習 call stack的重要性。
日本人：有頭沒尾、明白前後對照的重要性，解釋配置三個螢幕的原因。
俄國人：晦暗不明、隱藏技術的好方法。

我懷疑是不是隨母語的不同，而有不同的思考模式，進而使程式碼具有各種不同的習慣性寫法。

我想台灣軟體業，90%都是靠內需市場的軟體服務業，
這種產業幾乎是靠人脈和業務在賺錢，
而且跑起來2266的東西也敢出貨、上市

所以技術方面也都是靠SI (COPY-PASTE)，
工程師做的主要是前端UI和database的整合，
也就不太需要什麼高階技術了



回到樓主的問題，我覺得是可以考實作的題目啦，
至於要實作什麼，就看貴公司的徵人的內容了

例如『到某個網頁把圖片抓下來』小程式，
這中間網頁怎麼連(開socket、用http物件、呼叫外部程式...)、
怎麼找到網頁中的圖片(用regular expression、用迴圈硬幹、實作字串批配演算法...)、
找到的圖片URL怎麼下載、有沒有支援多工下載、防呆(斷線、逾時...)

從這些過程，應該就可以看出應徵者的基礎、經驗、實作能力了

我覺得挑重點來看就可以了，譬如行程管理、模組掛載...

不過在這之前最好先看過相關資料，像是作業系統、系統程式、編譯器...

都到業界了
還在用學校考試的方式過濾人材
考一堆名詞解釋
來個簡單程式碼
真得很難看出實力高低
好多東西在骨狗都很容易找到答案
而主考官要的是流程
只要流程符合邏輯就是好答案
像井字遊戲要怎麼寫
光是判斷三點如何連線就有很多東西可以問了
勵害的人只要一個變數
弱的人要設好多個變數
利害的人一個迴圈就解決了
弱的人就一堆變數if來if去的
說實在的
主考官只要把自己寫過的程式其中某一段功能拿出來問
這樣應該就很夠用了