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

[zanyking (遙遠的旅人)]

※ 引述《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
推 avhacker:沒有doc或有doc卻沒看完，實在不是啥光彩的事
推 swindler:軟體設計應該花40-50%時間 在前期設計與文件撰寫
推 xsion:給樓上，那是理論上，當規格寫到第163版時，你就會知道先寫
→ xsion:件的是白痴
推 finalcoffee:本篇說的很符合現實
推 poqwer:當你照著規格做完demo時還被幹個半天的時候，你就知道....
→ poqwer:你媽的規格到底是誰寫的，誰審的，誰說可以照著做的啊....
→ poqwer:大頭看規格的時候都不說話，看實品的時候才一堆這不好，那
→ poqwer:不好，這怎麼會這樣設計........到底是誰的錯啊....
推 avhacker:那是人跟制度的問，不是文件的錯
推 bobju:而人跟制度會醬子,又可歸究於環境所造成的..
→ bobju:我是指環境壓力太大,沒時間讓人家來慢工出細活.
推 swindler:當PRD的kick off會議開完 改規格的責任歸咎給ＰＭ
推 swindler:不過我看過有公司沒ＰＭ　大頭或說了算　讓ＲＤ狂作白工
→ swindler:但不要積非成是　還是要教育新人寫文件,ＡＰI,虛擬碼
→ swindler:不然老鳥ㄧ走　接手的人只能看到莫名奇妙的Ｃode幹繳
→ swindler:出來混　始終要還的
→ zanyking:沒有Doc很常見阿，我是寫Eclipse Plugin的。
→ zanyking:有的就是『萬行』為單位的原始程式碼。