Archive for May, 2008

如果我是面試官…

Thursday, May 8th, 2008

面試
這禮拜公司開會,老闆說希望我們Leader可以安排一下,讓我帶一個人,也好讓我負責的東西有個Backup。聽到這我並不吃驚,因為我早就知道我們Leader年中就要出國讀書,然後就直接在國外當地工作不回來了。也該是時後開始安排「後事」了 XD。

不過老實說,在我們公司,我還找不到一個我真的覺得不錯想帶的年輕RD。也許是我們平常做的東西就不太一樣,沒什麼接觸的機會。之前跟一個同樣是寫軟體的朋友聊天,他跟我抱怨他們公司最近來了一個新RD。這個新RD的覆歷上寫會php。可是進了他們公司快一個多月,常常還會問一些很基本很基本的php程式問題,像是為何不能print out一個變數這種的。害他很想朝那個新RD的頭巴下去。他說他當初php、db連碰都沒碰過,進公司一個月就要全部學起來,還不是照樣做到了,也沒給他們Leader添麻煩。然後他問我們公司當初面試時有沒有考試。

我們公司是沒考試啦,那時我們Leader面試我時幾乎根本是「純聊天」。因為我覆歷上有寫我出國比賽過電玩的事,而我們Leader本身也很愛玩Game。所以就對我的比賽事蹟頗感興趣,問我是比什麼,平常都玩哪一類的遊戲。原本我以為面試都會考試,因為以前找第一份工作時,幾乎每一家都會考。很少「純聊天」過…。

像我上一份工作在仁寶,那時他們就考了一份簡單的英文測驗,然後人事部門的人來問我一些個人的問題,最後才是技術主管來口試一些技術的問題。我還記得當時人事部門的人問我:「你今天對這份工作有什麼期待嗎?」之類的問題,我那時剛畢業龜了一年成天打電動,頭腦不太清楚(也有可能是前幾次面試都失敗,挫折感有點大,秀逗了),就很順口的回答他說:「當然是要面試上啊!」。只見那位美麗的女人事官笑著說:「呵呵呵!! 除了這個呢?」。我在想,要是當時是個男的人事官,可能就謝謝再聯絡了。誰會用一個頭腦不太正常,亂講話,穿著很正正正正正式的襯衫,提著「公事包」來面試RD,只不過長的還有點帥的新人呢? ╮(╯_╰)╭ 不過還好後來事實證明,他們還是找到了一個還算不錯的人材就是(不是丁丁)。

經過了這麼多年,人事官這個角色有可能變成是我要扮演的了。我有時就會想,萬一哪一天我要面試一個新人時,我到底要怎麼面試? 想了想,下面列出我想做的事先記起來,以免以後忘記:

.簡單基本的英文測驗 -
我覺得這還是必要的,對於一個軟體工程師來說,英文如果不好會引響到很多事。例如要想一個DB的model object name時,或者某個Class的method name時。如果英文不好,可能會想出一個怪名字,或者想半天想不到用什麼名字比較適當。另外,在我們這種小公司,其實每個RD都會需要自己上網去找問題解決的方式。Leader就只有一個,他也不可能每樣都懂,最好也別太依賴他要學著自己獨立比較好。所以上Google搜尋是常有的事,如果英文不好,可能連要找的問題關聯的英文名詞都不知道,找到解法的機率當然就大大降低。

以前我面試仁寶時,是考英文文法的選擇題,大概只要有高中英文程度的人都沒問題。不過,如果我要考的話,我會選一小段有關新技術應用的英文文章讓他看。然後過一段時間再問他這段英文大概是在講什麼東西,順便讓他知道有這個新技術。因為我覺得考英文文法沒什麼意思,考單字更沒必要,他只要能看的懂網路上隨便一篇英文文章六七成的內容就夠了。我們公司是個小公司,名氣不大,所以不見得每個來面試的都是台清交研究所畢業,英文都很好。如果哪一天我們公司像聯發科一樣這麼賺,也許這一關就可以免了。另外,在英文筆試這段時間裡,也讓面試者一個人獨處。有機會觀察一下他所要上班的工作環境,舒緩一些緊張的情緒。

.新技術名詞,考驗自己解決問題的能力 -
除了上面講的,會給一張試卷上面有英文文章外。另外,試卷上還會列出5~10個技術專有名詞,有基本的,也有很新的。基本的專有名詞,是要考這位新人的基本技術常識。而很新的專有名詞,是故意考新人不知道的東西,讓他用電腦上網找。我覺得我到現在這家公司3年多,學到最多的,不是從零開始學會Java、SQL…etc.等等的程式語言。而是從我們Leader身上學到自己解決問題的能力。一開始,我還會問我們Leader一些比較常見的程式問題。到現在,我問的問題已經不是我們Leader 100%知道的東西了。因為我現在都會習慣自己先上Google搜尋、上程式討論區找答案。萬一真的找很久找不到,才會問我們Leader知不知道。

以前在仁寶時,寫手機UI,會用到的程式語言只有C而已,也僅僅只有C,還不是C++,nothing more。工作時會用到的Tool、Library都是很封閉的東西。有問題的話,也都有很多前輩可以問,也只有他們才知道,網路上還查不太到。所以很少上網找資料,每天就是重覆的解Issue,解Issue,解Issue。我曾經創下單月解了幾十條Issue的最高記錄,可是,So what!? 薪水又沒給比較多,工作量也沒變少,反而是大頭們知道你很行,所以派更多Issue給你解。

在那樣的環境中,一個RD是很難成長的,因為周遭的環境太封閉,能學的東西很有限。我很慶幸當時有早點離開那裡,不然如果再繼續待了3年,恐怕還是只會「解Issue」。又忍不住碎碎唸了一下…Orz。總而言之,我覺得對一個RD來說,一定要培養自己解決問題的能力,才有機會自我成長。對自己有幫助,對整個公司也有幫助。如果一個RD在一間公司待了3年,會的東西永遠只有公司會用到的,公司需要的。我覺得這不是一件好事,這代表這間公司沒有任何創新的東西可以做。而RD也有可能會因為枯橾無味,得不到成就感而想走人。一成不變,索然無味,這是RD可能會想走人的一個重要原因。

.程式經驗 -
身為一個RD,會被問到這類的問題,這也是很正常的。像我們公司本身主要是寫Java,所以當然會問一下有沒有寫過Java的經驗。如果沒有,那有沒有寫過其它的OO語言,像C++之類的。除了主要使用的語言外,我也會問一些當下熱門的程式或framework經驗,像Ruby, GWT, Silverlight, Flash…etc.。最後可能會再了解一下,他以前學校有修過哪些程式相關的課。

我不會考太細節的程式語法,也不會當場要他用筆寫一段code,沒什麼意思。以前我第一次找工作時,到高雄的友立去面試。當時是個女的技術主管面試我,感覺很硬。一開始就發了一張試卷,上面大概有10來題左右的C語言程式題目,例如考,這段code裡哪個地方有問題。當時我好久沒碰C語言了(自從大二修完資料結構後,幾乎就沒在碰了),所以考得非常爛,因為很多根本都忘光了。當下那位女主管還說:「你這樣可能不太行喔,最好加強一下C語言比較好」。聽得我是面目慘白,雙眼無神,低頭無語,活像一隻鬥敗的公雞般,完全不敢正視那位女主管。也導致我後來面試別家公司時,完全沒有信心,沒辦法把自己好的一面呈現出來。結果後來事實證明,我不但會寫C,Debug能力也比別人強,只不過當時記不得所有的細節,沒辦法寫出漂亮的答案。

我想問,這樣的一場面試,到底有什麼用? 公司找不到想要的人才,而面試者也因此自信大大受損。所以我認為實在沒有必要去考一位新人這種太細、看不出真正能力、毫無幫助的程式筆試。因為沒有人可以100%記得所有的細節。就算不記得,只要工作時查得到就好,用熟了自然就會記得。愛因思坦小時後功課也不好,可是長大後卻能發表相對論,你臨時去考他7!等於多少,搞不好他還答不出來勒。

至於用筆寫code這種方式,有人說不是要考他能不能寫的出來,效能好不好,而是要考他有沒有創造力可以思考出一個解法。不過我認為用「筆」寫,實在太落伍,就算真的要考,也是要真的搬出一台電腦,讓他實際用IDE寫看看,速度上會快很多。有哪個寫軟體的RD,還在用「筆」的? 寫code用打的,寫文件用打的,玩MSN用打的,搞不好連寫情書也是用打的(拍謝!! 就是我…XD)。叫他用筆寫出來,搞不好比打字難上100倍 =.=。要是我,我倒覺得程式基本觀念比較重要,地基紮得不夠深,別想說大樓能蓋得多高。至於創造力與思考能力,我覺得可以用其它的方式去考,或用問問題的方式來判斷。因為創造力與思考能力,這兩個東西實在太抽象,影響的層面太廣,實在很難用一兩個試題就來決定這個人的創造力是高還低。如果我有想到的話,再補上來好了。

Model Object Relationship Map

Wednesday, May 7th, 2008

Model Relationship Picture
之前在學Ruby時,看到書上有像上面這種Model關係圖。在還沒開始進到我現在的這間公司前,其實我連什麼是MySQL、Oracle都不知道,也從沒下過SQL語法存取DB。大學時,修的課程裡,其實大多跟現在會用的東西都沒什麼關係。除了一門資料結構的課程和計概學的C語言比較有幫助外,其它像什麼組合語言、IC邏輯設計…etc.現在根本沒在碰。後來想想其實我的興趣應該是寫軟體的,應該去讀資工才對。Any way,這些都是題外話。我要說的是,由於以前從沒學過這方面有關資料模型的東西。所以在寫一個新的網頁程式時,都不會先去想資料模型彼此的關係,即使進公司已經寫了3年的Java。

這次學Ruby on Rails時,很認真的把這兩本書看完。
9789866840128 9867794923
而在Ruby on Rails建置與執行這本書中,作者為了要說明範例程式的設計概念,便使用了類似上面的資料模型圖。知道可以用資料模型圖去描述物件的關係後,我便試著在開發新網頁程式時使用看看,邊想邊畫。經過了一段時間的演練,發現透過模型圖,可以在程式開發初期就想好物件之間的關係結構。之後真正coding時,邊看圖邊寫,比邊想物件關係邊寫來的更清楚也更快。真是非常好的磨練。忽然間,感覺程式功力又增進了不少,彷彿像玩魔獸學到一個強力新技能般 XD。所以在這裡介紹一下這張圖的概念,希望有志成為一個死阿宅的工程師們,也可以學學 ^^

想像你要做一個討論區的Web Site。一個討論區有什麼? 使用者帳號是一定要的,right? 再來是討論區一定可以寫文章,可以回文。一篇文章中可能還可以夾圖片,還有下標籤。光看這樣的描述,有可能會想到5個模型。不過我打算將回文(Comment)也算成是文章(Post)的一種,Comment可以當成是有parent的Post物件。接下來,開始分析這4個model的關係:
一個帳號(Account)會有許多篇文章(Post)
一篇文章(Post)會有許多回文(Post)
一篇文章(Post)會有許多圖片(Image)
一篇文章(Post)會有許多標籤(Tag)
一個標籤(Tag)會有許多文章(Post)

首先,一個帳號會有許多文章,代表Post是「屬於」Account所有。所以會有個箭頭從Post指向Account。

再來,一篇文章會有許多回文,代表Post的不同instance間有關係串聯。所以圖中Post Model那裡,會有個箭頭指到自己。

一篇文章會有許多圖片,就像第一個描述類似,Post「擁有」Image。所以會有個箭頭從Image指向Post。

最後,一篇文章會有許多標籤,同時,一個標籤會有許多文章。所以這兩個Model互相擁有彼此,因此有個雙向箭頭在Post及Tag中間串聯。

短短幾分鐘內便把相關的Model關係想好並畫出來。之後真正開始寫code時,只要照著這張圖實作出來即可。這樣一來可以有效降低出錯的機率。當然如果中間想到一些idea,想要臨時加新的Model,也可以直接畫在關係圖裡,只要確保關係正確即可。其實像這種簡單的物件關係,還看不出來這圖好用的地方。說真的要邊做邊想,也不是什麼難事。但如果換成是一個有20種以上的物件、關係複雜的程式呢? 邊做邊想? 也可以啦,只要你的腦頭夠清楚、記憶力夠好也是沒問題的啦… XD