Re: [心得] 程式設計師應該懂多少？

看板Soft_Job (軟體人)作者zanyking (遙遠的旅人)時間16年前 (2009/06/03 02:17)推噓9(9推 0噓 10→)

留言19則, 7人參與討論串15/23 (看更多)

※ 引述《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