※ 引述《Arminius (奇怪的歐吉桑)》之銘言： : 恕小弟不客氣的問一句話: 實際工作上會寫出這種程式碼的機率會有多少? 也可以換個角度：『這種東西都不會的，那能用的機會有多高？』 我相信，很低。 我自從大學畢業後再也沒碰C C++(寫數值分析作業)，都在寫Java。 (某號稱強者的同學嗆我，『搞那種沒有指標，軟啪啪的語言』) 但是那些題目根據網友的答案我居然都猜對了。 我只能說，這種題目對有寫Code的人來說，應該是瞄一眼花個一分鐘答完， 二郎腿換隻腳，然後開始跟面試官聊點其他的。 這就跟去外商應徵法務部門職缺，人家老外叫你用英文自我介紹一樣。 應該就是很流暢的花個兩分鐘結束然後弄點別的。 : 這種程式碼應該只會在學校考試才會出現的, 如果面試問這些問題, 不如時 : 間省下來, 叫面試者成績單拿出來直接看成績就好了. 至於有幾年經驗的人, : 早就脫離 "考試模式" 了, 一下子答不出來更是正常. 小弟曾經被用這種題 : 目面試, 心裡都會暗罵兩句: 哇幹, 要找剛畢業的新肝, 需求就別寫資深工 : 程師呀～ 說老實話，我是覺得他出的太簡單了。 是我的話，我是不會出什麼演算法之類的、也不會考SCJP。 我會把Tomcat還是甚麼Opensource的Code剪貼個一大段，然後問他你覺得這是 作啥的、可能的功能、你要如何印證你的猜測之類的問題。 就算不懂亂猜也好，會努力亂猜找方向的就是未來會有機會的。 畢竟小公司找人就是找『有機會上手』的人，看到Code會放棄的應該就不用 考慮了。 沒有Document比Code更可靠的，Document確實要看，但是真正做的時候， 不會有時間把Doc K完才來寫的，更多時候是Code先看才用Doc確認。 往往都是跑一跑，找到個進入點鑽進去，觀察一下行為給個模型假設，然後 憑變數名稱、方法名稱猜特性就來檢查一下Doc那邊大概念上講了些啥，沒差 太遠，就要可以開始動工寫測試Code了。 可能真的有照本宣科、看完API作事的人吧？ 不過至少在我做的領域裡，在別人的架構上加東西改東西，都是只有Code、 沒有Doc的。 : 小弟以前面試人, 如果是剛畢業的, 問做過的專題; 有經驗的就問他最得意 : 的作品. 在他的作品中, 面試者負責哪些部份? 你們團隊怎麼協調工作的? : 遇過最大的瓶頸是什麼? 如何解決? 如果有自己的程式碼更好...程式寫得 : 越簡潔的越好, 程式寫得盤根錯節, 光要我看懂面試者的程式在寫啥就得報 : 表前後翻好幾翻的就算了吧, 您不適合團隊作戰.... : 專案規模不大只需要一兩個獨強的工程師的話, 就當小弟沒說過 這種的當然也要，不過，這種東西大家也都會問，我覺得面試者基本上 都準備的太充足了。 -- 我所信仰的科學是一種謙卑的理性，承認自身的無知與渺小才能觀察到世界在我們貧 弱的知覺上留下來的痕跡。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.194.181.12