顯示具有 面試 標籤的文章。 顯示所有文章
顯示具有 面試 標籤的文章。 顯示所有文章

8/29/2019

節省招募時間 - 電話面試的技巧 (軟體主管的31堂課)


在軟體「人才」的招募上,通常會花上比預期還要多時間,人才難尋是軟體產業其中最困難的問題。自招募流程上,各種審慎的過程當然不能省略,例如技術評估,面談等等。然而,整個過程可以透過各種方式,提前篩選適任或者不適任的人。其中,電話面試在台灣是最被忽視的一項。大概也是因為台灣交通十分方便,特別是大台北地區,面試者一般都不會因為「太遠」而放棄,但交通因素並不是電話面試最大的好處,電話面試最大的好處是可以低成本有效地去除偏誤,有效增加後續篩檢的正確率,並節省時間。


案例:在某次研討會中,軟體研發團隊主管K說,我從來不做電話面試,因為我想要看到應徵者的臉孔跟肢體反應,這樣我比較容易判斷個性。


電話面試有幾個好處:
(1) 去除偏誤:尤其是對外表的偏誤。已經有太多研究證實,沒有人能夠避免對外表的偏見,只是多或者少而已。也因此許多研究指出,履歷表不放照片才是最好的方法。當然也有人持反對意見,不過整體來說,雖然遲早會見到本人,但電話面試的確可以去除主管對外表的偏誤。案例中的主管K試圖去判斷個性,但容易流於自我偏誤。

(2) 節省彼此時間:一般面談起碼也要花2個小時,而電話面試至少可以先過濾掉10~15%的明顯不適合的應徵者。許多資深的軟體職位起碼要收20個履歷表才能找到1個人。換言之,電話面試,在表面上起碼可以少讓2個人來辦公室,但其實背後意義不僅於此,操作得當可以讓另外18個人對你的組織更有興趣更能在面試中努力表現,而非因為獵人頭介紹隨便來試看看。

(3) 其他:其實還有很多好處,例如再度驗證履歷表的真實性等等。

電話面試的技巧:

一:結構性問答而非開放性討論


電話面試必須要「固定詢問有意義的結構性問題」,而不是開放性討論。透過結構性問題收集了解事實。

結構性問題例如:
* 你為何想要離開現在的公司
* 是從什麼管道知道我們有在找軟體開發人才
* 你最近一次跟主管起衝突的時候,當時你做了什麼
* 最近三個月,你學了什麼新的資訊技術是跟工作無關的
* 你最近一次code review是什麼時候

這些問題回答不要評論好壞,只是記錄最為後續判斷。

不要問開放性的問題,除非你要找的是很會唬爛的人,開放性的問題通常都是假設性的問題,例如:

* 如果你跟老闆吵架了你會怎麼做
* 要是你加入一個有大流量的公司,你要怎麼做分散式系統設計

二:基本的事實查核


事實查核比想像中重要,倒不是因為履歷表造假的問題,而是在看履歷表的時候可能會有自已的假設,這些假設可能會有認知偏誤。

簡單的事實查核問題
* 請問你想要離開現在公司的原因
* 請問你當初加入這個公司的原因
* 在2013/3~2014/10年這段期間,你履歷表中似乎沒有在任何地方就業,請問是什麼原因呢
* 您在2012年某公司A的離職原因是什麼

進階的事實查核
* 在履歷表中,您有描述溝通是你的強項,請舉一個最近一次你解決非常困難溝通狀況的例子好嗎?
* 您剛才說在某公司A的離職原因是公司內部高層政治鬥爭很嚴重,可以舉一個政治鬥爭的然後影響到你的工作的實例嗎?

三:回答面試者對公司以及團隊所有問題


優秀的人才鐵定會想要再加入一個團隊時,了解一些事情。讓面試者詢問問題,不對問題做衍生性的回答,也不做假設,只是誠懇地回答問題。並且在最後再詢問「請問你還有任何想要了解的問題嗎?任何問題都可以現在詢問」

當面試者問了廣泛性的問題,請必定要他縮小範圍。否則,廣泛地回答對他也沒有好處。舉例來說:常遇到面試者問「呃 ...我很重視軟體工程文化,請問一下貴公司的文化是怎樣」這種問題太過空洞,可以直接告訴面試者「我們也很重視工程文化,但你的問題太過籠統廣泛,這樣我也會回答的籠統廣泛對你也不好,可否你縮小問題範圍,或者問實際的某件事情,透過實際上事情你就可以判對我們的文化對你來說好還是不好」。如果是容易溝通優秀的人才,很快能了解,因而他們就會問類似這樣的問題:「喔 我了解,那我想問,請問你會進行code review嗎」這樣彼此就可以針對事實討論。

更重要是這樣的事實討論,可以讓他了解優秀主管通常是實事求是,而主管也可以了解他能不能馬上抓到重點。



藉由這三個項目,一個好的主管可以初步篩檢適合或者不適合的人。另外一個值得一提的是:電話面試中間盡可能不要提早判斷面試者適不適合,盡可能是電話之後才根據筆記來判斷是否要邀請來面試。

3/17/2019

自我感覺良好的能力不足: 預防與解決之道



在軟體開發團隊的招募中,技術能力當然是不可或缺的一環。候選者如何自己評斷技術能力,也許和如何評估候選者的技術能力一樣重要!

換言之,謙虛的人比自我感覺良好的人,可能實質上的能力更好。這在「達克效應」中說明得十分清楚。

達克效應簡單的說:是指能力不足的人通常會高估自己的能力 無法正確判斷自己能力的不足。不過經過提高能力之後,是可以認知到過去能力不足的事實。
這個理論雖然廣為人知,但真正去證實的人很少,因為大家總是覺得很合理,

該論文研究分為四例,無論是哪個例子,結果都類似下圖(註1)
本圖取自論文:Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments
該圖是取自研究案例二,研究者讓所有受測者考一個邏輯考試,這邏輯考試取自於美國的法律學校入學考(LSAT),主要看一個人的邏輯思考是否完整,有興趣可以參看這個網站

當然考試不是重點,考完試之後,將結果分成四組人,最差的就是bottom,最好的是Top。所以在上圖中,很明顯bottom組的結果當然是在最下方。但有趣的是在於,最爛的一組,在預測自己的成績與能力,卻是和實際上差距很大!次佳組(3rd)其實實際成績和自我預測最接近。而成績最好的那組,反而感覺非常「謙虛」!?是唯一反而預測自己考得不好,同時也自覺的不好的一組。但實際上考的成績卻是最好的。

研究有四個案例,考試的範圍跟內容各有不同但結果很一致。

這篇論文,雖然很直觀,但寫得有點幽默,所以竟然還得了搞笑諾貝爾獎,細想其實很有啟發性。尤其在組織中,員工的自我感覺良好是績效評估產生問題的最大因素之一,那麼在組織中有什麼樣的解決方式呢?

預防的方式:招募時的預防


尤其是軟體開發團隊,招募一個謙虛的人,比招募一個很有自信的人更容易找到真正有能力的人。倒不是說有自信是不對的,但自信心往往容易落入低能力的範圍(請參見上圖)。

要判斷自信與能力最簡單的方式有兩種:一者,就是根據過去實際的產出內容來衡量,例如詢問他過去工作中,實際上做了什麼事情,導致於貢獻的產生,而不是只問了貢獻的結果。其二,設定簡單的測試環境,例如直接在白板上討論演算法問題。

解決的方式:衡量產出而非能力

絕大部分的企業組織都知道,衡量員工的績效乃是基於產出,並非能力。當然,能力好的人自然有機會有更高的產出。

在軟體開發團隊中,衡量產出極其困難。每個團隊幾乎都因人而異。有幾個方式倒是可以適用於大部分的狀況 
(1) 員工自評,並且加上3位以上的同僚互評。
(2) code review
(3) quality

由於最近比較忙,關於產出的衡量有機會再寫。:)



------
註一:本圖擷取自該論文本身:https://pdfs.semanticscholar.org/e320/9ca64cbed9a441e55568797cbd3683cf7f8c.pdf

12/23/2018

軟體工程師的職稱頭銜重要嗎?



軟體工程師根據所在的環境不同,通常有不同的職稱頭銜。例如:程式設計師,工程師,技術經理,架構師,策劃工程師,平台工程師等等。對應於英文可能會有:programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中,升遷可能是職稱上的轉換,例如在前面加個「資深」,大家就都知道你被升遷了。

對於轉換新的工作來說,職稱頭銜是否重要呢?

1.以工作的本質來說不重要


就技術為主的軟體工程師來說,(假設並沒有直接負責管理員工),職稱頭銜幾乎不重要,更重要的是做事情的內容和能力的展現。

假如在一個組織裡,一位新進員工的職稱是「sr architect資深架構師」,但他的工作內容實質上是對客戶提案,撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作,通常還是評估實際做的事情為主,並非職稱。

2.以團隊角度來說可能很重要


職稱是公開的,一個團隊組織裡如果有工程師,資深工程師,資深架構師這三種不同職稱的人:一般來說,大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟,職稱的功能有時候類似制服,當你在路上看到穿著警察制服的人,在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而,就軟體開發組織成長來說,職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係:團隊貢獻中,絕大部分的人會認為自己佔比重比較大,因而,在決定升遷或者其他公開獎勵時,一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中,大部分的人會認為自己佔比重比較大:許多實驗(參考這裡)都說明,假設一個團隊的總貢獻是100分,有10個人自己評估自己佔的比重,並且加總起來,很容易就超過150甚至250,但這實際上是不可能的。

也因為大部分的人都有這種偏誤,導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會,可以採用「無職稱」或者「自選職稱」的方式。


3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時,無論是中期還是短期發展,組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織,對團隊成員,甚至對組織外的人都有好處:

- 對組織的優勢


在組織內,成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」,而非「職稱頭銜」決定自己「做出的事情」。自然而言,團隊成員就會以提高自己的能力和對組織的影響力,並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密,再也不會影響其他人的心情。

當組織要招募人才時,組織會更專注於了解應徵者「過去做的事情」,而不是過去有的頭銜職稱。過去我們面試的時候,常常在履歷表中看到非常驚人的頭銜,但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高,錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時,在他對外面試的時候,很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明,團隊成員專注於工作的本身而非頭銜的表面公平性不足時,更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時,更容易專注於尋找人才得要件。換言之,本來評估能力和是不是適合,本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試,就更容易避免錯誤。









11/12/2017

中高階人才選用:成長心態鑒別的技巧



或許Carol Dweck這名字有點陌生,但是這位1946年出生的教授與她指導的學生(Lisa S. Blackwell, Kali H. Trzesniewski 這兩位才是研究作者,教授是列為共同作者) ,闡述的學習成長理論,卻經常的出現在教育界與職場上。

簡單的說,根據對美國小朋友的實驗,鼓勵「成長作為」比鼓勵「天賦能力」更能讓小朋友學習快,解決問題更有彈性,獲得更好學習效果。說的更直白一點,要多對小朋友說:「你做的很努力唷,好棒棒」「你做的方式很有創意耶,好棒棒」,千萬不要對小朋友說:「你好聰明唷,好棒棒」「你好厲害喔,好棒棒」。研究者把小朋友的內心,分成兩種心態(mindset):成長心態growth mindet,以及,固定心態fixed mindset。說的更直白一點,這些研究認為擁有成長心態的小朋友,未來的發展無限,人生就是彩色的。由於這個研究,引發了之後的更多類似相關研究,對於教育者而言,某些過去鼓勵方式,反而可能對小孩子有錯,而後,這些研究者,成立了 Mindset Works公司,開始賣服務與各類教材。

各企業巫醫們,自然能從中獲得啟發。比較好的像是lifehack,所做的此圖也還真的有啟發性。

對於企業組織要選用中高階人才,自然會希望找到「具有成長心態」的而且「很有能力」的人。換言之,就是要找在龜兔賽跑中,早就已經跑很快,而且也謙虛向學的兔子!對於已經具有十多年工作經驗的老江湖,確蠻有可能在面試過程中,不著痕跡的隱藏自己。那麼企業要如何找到具有「成長心態」的人才,而非找到「很會面試隱惡揚善」的人才?

當然企業不可能重複一次Dr Dweck的實驗,不過確可以用情境實例面試精神,找到簡單的三個「事實」來鑒別人才。

請緊記情境實例面試的原則:了解此人過去的經驗與能力,而非此人「對未來的憧憬與幻想」。換言之,企業組織雖然是為了未來,才需要雇用人才。但是,鑒別人才確必須要依賴了解這位候選人「過去的事實」。


1. 困難問題實例:最近2,3年來,解決最艱困的工作方面問題是什麼,自己如何解決?


這個問題必須要問的簡單清晰。畢竟一個有10多年工作經驗者,必然會遇到困難問題,而既然是最艱難的問題,必然有下列幾種狀態,確實問出幾種客觀狀態,來鑒別此候選者的成長心態。

(a) 問題的艱難程度:不能太過簡單無聊的問題
(b) 此人對此問題的獨立貢獻程度:也就是是這個人「做」的,而不是他「叫別人做」。
(c) 問題解決方式的創意:這和下一題可能有關,但艱難的問題不見得要用創意的方式解決。

如果是資訊科技產業,這個問題要修改為「技術相關的艱困問題」。




2. 創意問題實例:最近5年內,對組織做出最有創意的貢獻是什麼?


此問題的基本精神在於,一個具有成長心態的人才,一定是會做出有創意的貢獻。當然也不可能每天都有創意,把時間放長為五年,應該已經很寬鬆。必然要透過這個問題,以及接下來的對話,確實問出以下客觀狀態:

(a) 這個創意,是此候選人「做」的,而不是他「叫」屬下做,或者是「建議」別人做的。
(b) 這個創意,範圍夠大,確實有所貢獻。
(c) 這個創意貢獻是否能有實質證明。


3. 失敗問題實例: 在工作上,做過最爛最失敗的事情是什麼。


雖然這是面試的老問題,但此問題必須按照事實,看出是否有「避重就輕」。特別是,許多工作十幾年的人,在職場都可以歷練出舌燦蓮花的本領。因此要檢查幾個事實狀態:

(a) 問題的嚴重性:確實有些人運氣特別好,工作十幾年都沒犯錯過。但這個機率實在太低,當一個候選人簡單的講一些根本不是失敗的例子,大概就只是避重就輕。面試時,可以簡單值說:說這些失敗其實根本不重要,能否在舉一個「嚴重犯錯失敗」的例子。另外也有可能是,其過去十幾年來工作內容太不重要,以至於沒有嚴重失敗的經驗。

(b) 失敗的歸咎責任:詢問問題時,一開始請讓候選人自行暢所欲言,許多固定心態(fixed mindset)的人,在能夠暢所欲言的時候,自然而然的會把責任轉移到非自我本身。例如:「那時候我們的QA根本沒找到問題,所以後來系統出錯的時候...」或者是「當時我們的人力不夠,所以就只能拖延...」

(c) 事後的影響:成長心態的人,對於重大失敗會有決定性的影響,因此,這個失敗事件,能否對他後來的「行為」「想法」有改變才是重點。

固定心態的人,很有可能會說「以後運氣還不錯 就沒發生同樣的事情了」或者「也就是因為如此 所以我才想離職」,更慘的是,規避了解失敗的真正原因,特別是曾經當過主管的失敗例子:「因為之前的屬下太過自由導致出問題,所以我現在就很嚴格管理所有細節」「那時候跑scrum有很多問題,所以現在都不用scrum了」。

成長心態的人,則比較傾向找到失敗的真正因素,改善真正因素:「那時候跑scrum有某某問題,所以我們現在scrum會做XX調整」。而重大失敗,更是會變成具有成長心態的人,隱含的內心記錄的一部分。


9/04/2017

面試的前晚準備 - 極簡計畫書



無論你是社會新鮮人,還是職場打滾了十幾年的老鳥。當你準備要去工作面試的前一天晚上,有計畫性的準備面試,絕對比沒有任何準備來的好。

職場新鮮人自然會從網路或其他地方,獲得許多面試準備的要領,試圖做到面面俱到。然而,已經到了前一天晚上的話,要抱佛腳也應該要有正確的方向。例如,努力準備英文自我介紹,大概就不是一個前一天晚上能做的好方向 (註1)。

職場老鳥,即使已經是工作N年以上,應徵的是資深技術相關職位,在前一天晚上「提升技術能力」當然是不可能的。不過,卻可以準備好自己的強項,來增加面試成功的可能性。

某些資深職場老鳥,通常有「知我者伯樂,不知我是你的問題」,「良禽擇木而棲,這塊木頭反正也不好」的想法。這些想法不見得是錯的,然而,這不應該是「不做面試準備」的藉口。因為無論該公司好或者不好,既然要前往面試,你的唯一目的應該就是「被錄取」,而錄取之後,再來考慮要不要答應還不遲。

而面試前一天的準備,對資深技術人員來說,其實更簡單,並且也很容易讓面試方看得出你的資深價值。舉例來說,準備「要問」的問題,對資深老鳥就非常重要,這些問題的重點不在於獲得「解答」,而是在於讓面試者知道你的資深程度和專業性。

「面試前一天的準備 - 極簡計畫書」


與其說是計畫書,不如說是一個檢核清單,任何人應該可以在一個半小時之內,完成清單上的項目。按此索取極簡計畫書

計畫書的目的是在面試前的晚上,約1.5小時之內,用合理的技術方式,盡可能提高自己既有能力的展現,藉此提高面試成功的可能性。 

使用步驟說明


(1):找到組織背景資料。  [15分鐘]


在組織相關資料區塊中,填入公司組織名稱,代表人,營業額,毛利率等等可以找到的資料。

如果是營利組織,幾乎一定能透過名字或者統編,找到基本資料。非營利組織或者剛起步的新創事業,可能缺乏某些資料,但是可以將難以取得的資料當作「要問的問題」。因為,專業人士,通常會問出真正關鍵性問題。


(2). 要問的問題:   [35分鐘]


要準備問對方的問題。現在的面試,幾乎都會讓被面試者發問,而這段時間難能可貴。因為,這些問題是100%可以由自己控制,也就是說自己可以決定要問什麼,也可以決定不問。因此,面試前一天,反而應該花多一點點時間在準備「要問的問題」。

要問的問題的「真正目的」是要讓面試者認定你的能力和潛力,而不是你真的想要知道問題的答案。因此,最最最愚蠢的問題,莫過於詢問公司福利,社團活動,上下班時間,哪邊可以蒸便當,之類的無聊問題,這些問題,應該是透過人資或上網搜尋取得答案,而非浪費在寶貴面試時間上。

要問的問題至少要準備7-10題,而可以視面試情況決定要不要問。

基本問題像是:
  • 如果我被錄取了,我在到職前3個月,要完成哪些具體工作內容?
  • 目前這個職位,是因為有人離職而要找取代者,還是一個新職缺?此職位已經懸缺多久?
  • 請問您如何評估一個人適不適合這個職位 
  • 面試到目前為止,你覺得我是否適合此職位

至少必需要準備2-3個進階的技術性問題,技術問題並非指「特定的技術」,而是指「讓你側面了解更多」的問題。例如:

  • 請問您會在這裡工作最主要的原因是什麼?
  • 目前這個團隊,曾經遇到最大的障礙或困難是什麼?
  • 請問您擔任這個團隊的主管已經多久了?

當然,進階技術問題通常比較敏感,在開口之前應該要客客氣氣的說「如果不方便講也沒關係」。

請在表格中,挑選要問的問題,並且在備用欄位,填入你自己想到的問題。





(3). 被問的問題:   [30分鐘]


面試者在面試的時候,手上一定會有你的履歷表。無論你之前對你的履歷表有多熟悉,在前一天晚上,應該再次看一下當初你寄出去給該公司HR的履歷表。

因為,要從中找到「以面試者的角度,認為需要在確認」的問題。並針對這些可能被問的問題,簡單準備一下解答。

技術專業性的問題,對於職場新鮮人,需要再次確認「真實性」,以免被人認為誇大能力。因為,職場新鮮人通常的確會「誇大」自己已經有的能力,例如其實只是在學校學過c語言,寫過幾個作業,通常就會把c語言當做「自己會的程式語言」,但是這和職場上的「會」可能有些差距。

而對於職場老鳥,只需要注意一下「曾經做過的事情」和「曾經有的貢獻」即可。

例如參與的研發團隊人數,自己扮演的角色等等。履歷表上的明顯缺陷,才是一定會被詢問的地方,例如某個工作僅做了6個月,或者在前一份工作到今天有3個月個空閒時間。

請根據表格,檢視履歷表,並且填入自己的模擬問題和可能的回答。


(4). 面試的時間地點交通方式與服裝。  [5分鐘]

聽起來很不可思議,不過確實有一定比例的人會過於緊張,太早或者太晚抵達。
也甚至有人壓根就忘記面試時間或地點。

前一天晚上應該確認一下面試時間或地點。

某些職位(業務單位等)可能對服裝有一定的考量,當然也得花一點點時間準備。


(5). 面試之後?


無論面試的好與壞,其結果一定要誠實的記錄在計畫書中,因為它可以作為自己下一次面試的參考。

結果只有分成兩種:錄取或者不錄取 - 無論原因為何。有些組織會考慮資深人員的面子問題,可能會用「目前組織人事凍結」等等軟性理由,不過對面試者來說,就只有錄取和不錄取兩種結果。

難以回答的問題:在這欄中,盡可能就自己的記憶,記下自己覺得難以回答的問題。如果是技術性問題,表示自己有技術需要加強。如果是其他問題,也應該記錄起來作為參考。

這個計劃書,應該自行根據面試的公司不同,做不同的調整。極簡計劃書僅是在你沒有更好的主意時,提供參考而已。


按此索取極簡計畫書


註一:英文能力確實是許多工作的加分條件,但前一天晚上,臨時抱佛腳準備英文自我介紹,對英文本來就不好的人其實一點用都沒有,而對本來英文能力就已經很好的人,也幫助不大。




8/04/2017

不玩一樣的遊戲 - 準備面試的真正技術


程式設計師如何在面試中展現真正價值:最好的方式當然是不要跟其他人玩一樣的遊戲,也就是在面試中,找出幾個能突顯自己技術能力的要點。針對這些要點,做延伸性的準備。




不管什麼原因,當一個軟體工程師下定決心要換工作時(註1 ),面試通常是免不了的。

作為軟體工程師,鐵定會上網搜尋各種「面試技巧」文章。

例如:常見面試問題的最佳回答:這篇或者這篇。也有些人會說,面試除了回答問題,更重要的還是會問對問題,例如這篇

但是,人資與主管,通常比面試者更知道這些所謂「標準問題」。也很清楚面試者可能會去找的「標準答案」。這些面試技巧文章只是一再重複大家都知道的常識,多複習這些常識是有很大的好處,至少可以避免緊張或者不必要的誤解。

但常識不會是關鍵。


在面試的時候,除了回答標準問題之外,最重要的是「確實展示自己的價值」才是關鍵。

軟體工程師/程式設計師的價值展現,其實第一時間點是在「看履歷表」的時候。短暫的面試時間是在「檢查履歷的正確性」。假設面試者的履歷寫的中規中矩,沒有什麼誇大,也沒有過度謙虛(註2),會讓你進入面試階段,就表示在履歷表上展示的技術能力是公司願意接受的。

面試展示自己的價值,通常是在幾個關鍵點。而這些關鍵點,都是「面試之前」可以先做好準備的。

(1) 應答技術問題
(2) 解釋過去做的事跡
(3) 詢問技術相關的問題


(1)  應答技術問題


大部份的軟體工程師工作,通常都會有程式考試題目。只要你在Leetcode, topcoder之類的網站,用你本來就熟悉的程式語言,多練習幾次,應該就不會太離譜。事實上,技術問題不可能考得過於艱澀 - 因為公司組織通常沒這麼多閒功夫在一個面試者身上。

其他的技術問題應該要根據你在履歷表上的專長做「延伸性」的準備。延伸性準備,才是展現價值的最好方式。

例如,倘若履歷表上你的專長是WebUI,那麼你就得延伸準備到HTTP:至少了解一些重要的header。如果你的專長上有寫Linux,那麼就必須準備回答曾經使用linux做過什麼事情?

如果曾經在linux上架設web server (nginx, apache...),至少也得知道設定檔在哪裡,如何開始停止服務,如何列出執行的行程(process),如何在不得已的時候強迫結束服務。當然,如果你會回答kill -9,最好確實知道為什麼是-9。

應答技術問題的不僅只是「防禦性」告訴面試者你的能力。而透過簡要地回答,「順便」展示自己對技術能力掌握的額外價值。就以上述kill -9為例,以筆者過去15年,面試超過400個人經驗,在履歷表上寫「熟linux」的起碼也有150人。這些面試者,八成都知道kill指令。然而,僅有不到10個人,知道為什麼要用kill -9,並能說明kill預設single 15是比較好的選擇。

在回答簡要技術問題,只要能有正確延伸性的回答,就能展現與他人不同的價值。而這絕對事是先可以準備的。


(2) 解釋過去做的事蹟


只要有2-3年工作經驗,面試時,一定會被詢問過去做了什麼。

因為,要了解未來一個人在組織的貢獻,最好的方式是看他「過去貢獻了什麼」。以下是一些解釋過去事蹟的要點。

** 妥善呈現事實而非感受。


當你已經離職時,過去的事蹟就已經成為「歷史」,而你可以準備的是「妥善呈現歷史的事實」,切勿扭曲或用「感受」呈現。

例如:「在那個專案裡面,幾乎事情都是我在做」。這其實是你的個人感受而非事實。事實必須要用無可扭曲的方式呈現。

又例如:「這個專案扣除html/css之外,前端javascript在git上大約有3萬行左右,其中兩萬五千行是我commit而且到專案結束也都是我負責維護」。這只是說明在程式碼上的「事實」,你並沒有貶低別人的貢獻,因為也許那其他5千行極端重要也說不定,但你也呈現了以code base而言,你的貢獻在事實上絕對不低。

**過去事蹟,絕對可以,而且也絕對需要在面試前妥善準備。


因為,你對過去自己真實貢獻越了解,就越能掌握過去事實。越能掌握過去的事實,就越能表示自己在技術上更有未來潛力。

例如,假設你是IT部門員工,過去都是協助內部系統上線,這些系統其實也是外包商提供。在面試時,被詢問做的內容,如果只是簡短回答「將公司委外開發的系統上線」當然也是可以。

但如果你在事實上,也會做「自動化檢測系統」「建構上線風險評估」「上線後的使用分析」「成本分析」以及「有沒有達到預期目的評估」,這些才是IT真正產生價值,並且與眾不同的地方。

最好的情況會是,公司之前並沒有此做法,而是你主動完成這些有價值的事,讓公司變得更好。可是,如果你已經離職,來不及產生事實 (當然也不可能去捏造說謊)。那麼,至少還是可以說「當時其實應做自動化檢測系統」,雖然那時候沒有完成,但你也可以在面試自己做一個小規模的自動化檢測系統,而在面試的時候就可以大大方方的說,當時雖然沒做,但是自己覺得應該要做,所以主動在事後做了。

當然這表示你需要在面試前付出時間準備。這樣的付出不會是沒有代價的。即便這次面試沒用到,你所做的事情是不會消失不見,只要是你做的「技術上正確」的事情,未來一定會對你的職業生涯有所助益。



(3) 詢問確實的問題


通常面試的最後,都會給面試者問問題的機會。

許多文章中,的確會說明問問題的重要,例如這篇。有上網查過的面試者,也了解不該問一些瑣碎小事,上下班時間,或者公司基本福利,因為這些問題只是等於打發時間。雖然沒有害處,但是也沒有價值。

軟體工程師最適合的就是詢問有價值的技術相關問題(註3) 。而這些問題也可以讓你稍微判斷此公司的狀況。

基本問題

一些很基本的問題,可以簡單展示你對軟體專案成熟度,也可以讓你了解這個公司的狀況:

* 請問目前是用什麼樣的版本控制系統,管理程式碼?

    該組織用什麼樣的版本控制系統不重要,無論是git, svn, cvs, p4...都可以。重點在於,的確還有些組織連版本控制系統都沒有。

* 請問目前組織是使用哪種專案管理方式?

    最近幾年是流行Agile/Scrum,

* 假如我有幸錄取,前三個月你希望我能完成哪些事情?

    這個問題代表自己的積極程度。主官如果對這個問題講得過於籠統抽象,很有可能該面試官(主管)並非實際的技術管理者。

* 團隊最近一次做code review是什麼時候?
* 團隊的bug追蹤流程目前大概是怎麼做的?
* 目前自動化測試的涵蓋率大約是多少?

    這些問題是展現自己對軟體開發的成熟度。特別注意的是,如果這些問題被籠統的回答,也不需要追根究底找別人麻煩。


進階問題

可能會引發進一步討論,也可能被反問,所以要事先準備被反問時的技術回答。

例如:

* 就現在的資料和面試的情況,您個人覺得會錄取我嗎?

* 最近一次在團隊裡面遇到最大的技術困難是什麼?

* 組織如何判斷成員的技術產出?




高級問題,


很有可能被認為是反過來刁難面試主管的問題。必須斟酌採用。例如: 

* 目前軟體專案程式碼的entropy有多高?

* 目前自動化建構和測試是採用哪些工具,涵蓋率有多高?

* 就您個人而言,最近在組織內學到新的技術是什麼樣的技術?新的程式語言或者新的工具?







面試是可以事先作準備地,軟體工程師的面試準備,應該花時間以事實展現價值作為準備方向,而非準備一些大家都知道的常識或者花時間準備外在行頭口語表達...等等。當成功地完成許多面試,就可以在工作機會上有所「選擇」。


參考文章:
(1) Scrum認證!不要再浪費你的時間了
(2) 如何充實自己
(3) 畢業前六個月 建構職業生涯
(4) 年底才績效評估或考慮轉職 已經太遲了
(5) 因為沒挑戰想轉換跑道,先檢討自己吧


註1:要轉職換工作區分成「主動」與「不得已」兩種。不得已:例如公司倒閉之類,當然就不用討論。但是如果是「主動」,就要先想清楚「真正的原因」。因為這個原因,可能不會因為你換工作而消失。

註2:剛畢業的學生可能是怕履歷表太空洞,通常都有誇大的傾向。而在業界打滾數十年的老鳥,有時候會有過度謙虛的可能。

註3:當然不應該「窺探機密」,因此可以在一開始的時候先說「如果這個問題不小心牽涉到公司機密,請告訴我,在這個時間點我無意探究貴公司的機密」



2/16/2017

建立軟體開發團隊 (1) 計畫 組成




... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作,不可能有完美的狀況。但是,妥善的計劃,能大幅降低軟體團隊的運作風險,並且讓團隊成員專注於發揮專長和創意,減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面,例如:

(1) 目標極端困難。例如:要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如:團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成,目標也還沒確認,就已經有時間壓力。例如:一個2-3個人合作的新創公司,剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如:在大企業中,因為高層要求,一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員,在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標,併購等等),讓某個團隊大幅流失人才,而需要重整補齊人力。

(7) 因為文化與跨國合作困難,導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人,最最基本的認知就是:

軟體團隊組成這件事情:本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊,其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考:

(1) 了解探索事實,盡可能將事實攤在陽光下


許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」,或者「假設在3個月後可以找到2個優秀的iOS開發人員」,或者「假設大部分的使用者都有fb的帳號」,或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下,很多事情的確有假設,才能進行下去。

但是,在建立團隊的時候,除了瞭解背景假設之外,先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景:

可參考下節「確切定義短期中期目標」。如果是非營利組織,團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業,營利組織,除了獲利之外,也可能會伴隨其他更遠大的目的。例如:「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體,也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的,如果只是單單純純想賺大錢的公司,例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的,就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知,才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊,自然不會將社會責任活動當作是團隊成員想要做的事(例如:到沙灘撿垃圾,協助獨居老人),當然「培育企業人才」也不太需要,甚至Scrum裡面的「自己選取task來做」也根本不用,採用由上而下的軍隊式管理,讓工作以最有效率的方式完成,才是這種團隊的最好方式。


(b) 資源現況:

目前的現況是不可否認的事實,但許多人一開始的時候,會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人。...這就是資源現況。

但也有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是:現在有1個專案經理,以及1個剛剛到職的工程師,未來可以找10個人,但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣,其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人,年預算只剩下600萬台幣,所以可以找10個人,但是平均年薪只能為60萬,或者找6個人,平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人,資源現況的瞭解和掌握,必須要越清楚越細節越好。實際上,絕大部分的情況下,只要稍微多花個幾個小時,就可以掌握到很多現況細節。


(c) 組成專長:

即使已經是軟體開發的專家,這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定,組合的專長可能大致確認。然而,某些專長不見得是「團隊成員需要有的」,這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段,需要清晰可見的專長分佈圖。

以上圖為例:簡單地列出做一個購物網站可能需要的專長,並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是,這樣的圖並不是要完全技術上正確,而是要做為未來計畫的參考。因此有可能一再修改,也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素:

哪件事情做好了,會讓這個團隊成功。成功關鍵因素應該只有1-3個,不應該太多。 這個關鍵成功因素必須要很「實際」,能夠被「衡量」,當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例,他的關鍵成功因素不只是火箭能發射,還要能「掉回地球後,能自己站立,以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而,建立組成的本身也有關鍵成功因素。例如,在2個月內吸引3個具有5年工作經驗,並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然,不可能花幾百天的時間,只是為了收集事實,只要在合理的時間內,盡量收集了解重要的事實。


(2) 確切定義短期中期目標



前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言,八九個短期目標完成後,差不多就等於一個中期目標完成。

任何軟體開發計畫,必定會有目標,而讓團隊朝向「同一個方向」前進。所謂團隊,當然是一群人往同一個方向前進,才能叫做團隊。一群在同一個組織架構的人,或者在同一個老闆底下工作的人,不見得是一個團隊,很有可能每個人在軟體開發



(3) 根據目標擬定計劃和備用計畫- Plan B



兵法有云「夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!吾以此觀之,勝負見矣。」

計劃本身並不重要,但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情!

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容:

(a) 團隊目的,短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是,哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示,根據分佈圖,來劃分團隊組成。

切勿用想像的方式。




以上圖為例:這是一個打算建立電商網站的技術分布圖,和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示,團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節,而且也把技術不相干的東西納入(例如裡面有個API doc,其實是還沒有去做的事情)。但整件事情的精神在於「視覺化」。透過視覺化,對團隊的變化才有整體性的考量和規劃,而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡


(d) 初始化工作項目

當團隊的成員是逐漸到職,最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節,但是是隱含的關鍵成功因素。

初始化工作項目,在新成員到職的前幾天,最好是鉅細彌遺。規劃了新成員第一天到第五天,「每天」要做的事情和達成的結果。並規劃前4週,要達到的大項目,以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短,對團隊的組成越有利。

規劃前五天的細目,絕對不會讓這個新成員變得沒有創意,也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內,先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項,如果在前一段時間沒有擺脫,之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目,同時也是檢閱清單:

Day-1  
    - Mentor介紹工作環境,取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限,確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件,Mentor協助了解文件內容
    - 參加Scrum會議,理解Scrum雞與豬的原則 
    - 在Mentor協助下,建立自己開發環境

Day-3
    - 在Mentor的協助下,在自己的開發環境確定能修改程式/簽入(commit)/建立branch,最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例,這些看似細節,但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡這裡

簡而言之,建立團隊的過程也需要被檢討。

例如:

新加入的成員,在當初面試的時候所呈現的能力,和實際上工作的產出,是否吻合。

新的成員對於非技術類型的雜事,是不是很快能找到資訊。例如git的位置,目前各個branch的狀況,自動化建構的方式,建立開發環境的方式等等。




註1:如果這個挑戰對負責組織團隊的人來說太過困難,最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天,或者品質降低一些;但是一個失職的領導者,會讓整件專案崩壞。


註2:例如xspace

註3:建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術,需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等






3/13/2016

如何組成團隊:三個步驟





分工合作,是人類社會進步的主要原因之一,也是幾乎所有人類活動的基礎(參見國富論:第一篇第一章論分工)

新創公司,資訊產業也不例外,建立一個好的團隊,是擴展未來的主要關鍵。雖然好的團隊沒辦法保證生意蒸蒸日上,一切順心如意。但是一個糟糕的團隊,卻是可以保證企業和組織的失敗指日可待。


市面上團隊合作的企管叢書,方法論,激勵理論,顧問大師...很多。但就和所有的事情一樣,越是很多人在談論的事情,越是困難。成功的團隊真實例子極為罕見。

萬事起頭難,「組織並成立團隊」是達到成功團隊的第一要務。許多人常依賴運氣,或者隨遇而安的隨意組成團隊,但其實組織團隊是一種可以學習的艱深技術能力。

資訊相關工作的人,如果有機會能扮演組成團隊的角色,並有意識的學習其中,將會是個人成長的重要關鍵。(無論未來是朝純技術領導方向前進,抑或管理方向前進)


有很多原因,會讓一個人扮演組織團隊的角色。也許是一個新的專案,讓你來領導專案,而恰巧專案開始的時候沒有既定的人。也許你是新創企業的創始人,你打算聚集一些人來開發創新事業。也許你是資訊相關科系的學生,因為課程需要必須組織團隊完成專案。

不管如何,如果你有「從頭開始找人選人,組織團隊,完成某件事情的機會」,請衷心的痛哭流涕的感謝上帝,這樣的經驗,在資訊科技領域裡是十分難得。

通常,由於各種背景壓力,組成團隊的方式通常就是先根據需要N個人,然後「儘速」透過各種管道,找到可能的人選,經過正式面試,或者非正式的聊天,就逐一邀入加入此團隊。這種方式沒有不妥,只是這樣的方式(如果算是一種方式的話)有很大的成分依賴運氣。如果不想依賴運氣,其實需要考慮的實務步驟也不多。


以資訊相關工作為例,組成團隊必須要有以下三個步驟:


步驟一:定義目標

--- Your goal shouldn't be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs.   (MoneyBall)

定義目標,必須要在團隊開始組成之前,就先找到並且定義完成...最起碼是團隊差不多組成的時候就應該決定。

定義目標並不容易。

例如,以類似的資訊系統外包案而言,有些明顯的目標是「在成本內完成專案並驗收通過」或者「在期限內通過驗收」。但是,倘若一開始的合約是低價得標,而且還是業務亂搶合約,那麼一開始就已經知道不可能在時間成本內驗收通過。則團隊目標必須要轉換,例如「完成專案過程可順便完成重複利用的元件讓未來標案能大幅降低成本」。

大部分的資訊團隊真正的目標並非「技術達成」。例如,「完成iOS APP線上購物」這通常不是真正目標,真正目標通常是「在某移動通訊市場上,讓使用者可以線上購物」。

在營利企業裡,大部分的真正目標通常關聯到增加收入或者降低成本。而在非營利企業(例如研究單位)團隊的目標有可能非常模糊。例如,一個碩士班的實驗室團隊,他的目標可能是「培養人才」,也可能是「讓主持的教授獲得升遷的點數」。

定義目標雖然不容易,但掌握以下三點可以除去大部分的誤差:

(1) 定義目標後,審視檢查這個目標背後是否還有目標。例如,籃球比賽目標,某球員目標是得30分。但其背後還有個目標就是球隊要贏球。在球隊沒贏球的情況下得30分可能沒有意義。

(2) 定義目標後,檢視此目標是否只是某個大目標的一小部分。例如,某些NBA的球隊,會談論是進入季後賽的目標,然而背後的大目標其實應該是拿到總冠軍 - 無論有多艱難。

(3) 定義目標後,檢視此目標是否因為其他條件未達成就失去意義?這時候所謂「其他條件」或許可能是目標。例如,一個團隊負責營運線上購物網站,其目標是「網站每分鐘必須可以提供10萬個使用者同時進行交易,7x24服務不中斷不當機」。然而,若此線上交易網站平均上線交易人數每分鐘才1人,即便營運團隊達到技術目標,商業目標肯定無法達成,則此團隊目標也沒有太大意義。不如改成「與業務團隊合作線上行銷活動,讓每分鐘平均交易人數成長XX%」



步驟二:組合優勢


--- The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour. - (Adam Smith)

無論用什麼方式找到團隊成員,資訊相關的團隊必然有分工,而分工必須要能讓成員發揮相對優勢。而每個相對優勢,都可以達到步驟一的目標之一。

構成團隊過程可能很多,但無非是找到某人,詢問意見,在某時間此人加入。然而,「加入之後做什麼」著重於考慮組合優勢。

台灣經濟學的入門書通常會用蓋木屋與磚屋的例子(參見這裡)簡單的說,組織團隊時,把成員的時間投入在相對優勢的工作上,可以達到1+1>2的效果。

實務上,分工時請考慮一下三點:

(1) 根據相對優勢來分工:盡量只考慮優勢,而不是先考慮缺點。

(2) 分工的結果,還是必須朝「真正目標」前進

(3) 整個團隊需要了解分工與分派任務的原因 



步驟三:產生運轉動能

--- All things are difficult before they are easy.


團隊組織完成,要開始運作,不會像籃球比賽一樣,十個人在場上,裁判吹哨跳球就開始。

團隊前進需要累積動能。就像騎腳踏車一樣,從靜止到穩定前進,會花比較多力氣,然而一旦穩定前進,就很輕鬆。

產生動能指的是團隊成員已經彼此合作,彼此鏈結工作,發生問題也可以彼此協調解決。

以資訊科技為例:

最常見也是最糟糕的產生動能方法是由專案經理透過一連串的方式 - 通常就是開會 - 持續讓事情前進。團隊成員花在正式會議上的時間比例只要超過10%(也就是每週超過4小時)就屬於這種類型。


最佳,但是最罕見的產生動能的方式是由每個團隊成員,透過自身的判斷,做會讓事情前進的動作。類似足球或者美式足球的比賽。在資訊科技團隊中,這種組合需要時間磨合成員,而且也須一點點運氣,讓團隊的成員大部分的能力都可以足以某種程度的獨當一面。

如果你剛好是資訊科技/軟體開發的團隊領導者,至少要先避免最差方式,並且透過你的領導能力,讓團隊慢慢的朝向最佳的方式前進。

實務上有三個重點方式:

(1) 資訊透明:讓所有進行的事情透明的讓所有人取得。要注意,資訊透明指的是針對確定的事實透明。非確定的事實就是所謂謠言,要緊記:謠言止於智者,起於智障!

(2) Scrum中的豬雞原則:請參考這裡。在組織產生動能過程,豬負責的事情就由豬來決定,雞只是提供參考意見。

(3) 檢討 retrospective:需要團隊自我檢討任何不正確或可以強化的地方,檢討並非開批鬥大會,目的在於讓團隊能更有效率的,以及確保團隊真的朝向目標前進。




12/30/2015

大學或研究所玩太久.(三個解決方式)






























有幾次面試新鮮人,發現有些學生自覺得在大學研究所時代"玩得太久",而對於即將投入就業市場有些自覺能力不足。

首先,如果照著學校教育做好該做的事情,就算沒有「玩很多」,老實說能力一樣是不足。想要在還未就業之前,就達到一個好企業的標準是有點難。當然在學時期,有很多事情,對就業有極大的幫助(至少就軟體以及網路產業而言),但是大概都不是台灣學校教授能教的。

這些事情像是:加入open source的開發工作,找暑期工讀,到外包市場接專案等等,都對自己有幫助。

但如果你已經來不及這麼做,就面臨畢業了。那麼除了延畢,隨遇而安看命運安排,拒絕面對事實...之外,其實有三個實質的作法可供參考。

對了,要記得,任何時候都為時不晚 只有覺得太晚的時候才太晚。



三個解決方式:



(1) 解決方法一:快速學習技術能力

想要投入資訊產業,不管擔任什麼角色,擁有技術能力永遠是對的。

找一個喜歡的目標,全面性的學習相關能力。不見得一定要花大錢上課,網路上現有的免費資源一定可以讓你在2-4週之內(最遲不超過4週)學會某種東西到一定程度。不管是Java programming還是HTML5,不管是Big data analysis還是photoshop應用。

如果對於快速學習技術能力有進入障礙,要記得這一定只是進入障礙而已。只要有興趣,願意專注,到目前為止還沒看過學不會的。真正問題在於有沒有專注的付出時間,如果確定資訊科技對你來說是完全沒興趣的,那也好,就此打住,改換跑道為時不晚。


(2) 解決方法二:尋找互蒙其利的機會,藉此重建履歷


很多時候,你需要的只是找到一個可讓你有學習機會的環境,這個環境可以促使你成長。如果不花錢,有什麼機會有這種環境呢?可以去看看upwork.com, guru.com, fiverr.com到上面以賠本的價格接專案來做,就會知道目前市場環境中缺乏什麼。


(3) 解決方法三: 打工與學習


這和解決方法二有什麼不同?打工是泛指先去做你不是很想做的事情,例如contractor。這除了可以讓你舒緩生活費用的問題,增加獨立性,也能獲取一些時間,讓你想一下自己有什麼選擇。

打工與學習,泛指各種範圍。在網路時代,只要知道怎麼找,資訊幾乎很容易取得。例如,如果你是26歲以下的女性,喜歡小孩想要學德文,au pair是一個看似誇張,但是合理的選項,參考這裡




創意沒有極限。不要只接受片面的資訊,即便是這裡也一樣:)




沈思:

1. 經濟學鼻祖書:國富論一開始就是在說明分工的重要。這也是就業市場上,各種職業產生的真正原因。能不能找到自己相對於別人的比較利益優勢?

2. 以長期而論,自己想要什麼很重要。但是短期來說,自己有什麼選擇才是關鍵。

3. 這三個解決方法,看起來都沒什麼創意,但是跟隨波逐流比起來,還有其他方法可選嗎?



12/14/2015

資訊系所學生就業 (三件值得注意的小事)


除了少部分往學術界持續邁進的人之外,畢業生遲早要就業。

但就過去數年面試新鮮人的情況來說,大部分的學生並沒有對就業有所準備。這似乎是理所當然,本來就不可能有充分準備,不然就不叫新鮮人。

而業界常常把問題放在學校並沒有充分"教育"學生該有的知識與技能,使得學界與軟體業界脫節。

這似乎也不是台灣單獨的問題,早在數年前有人在美國抱怨此事。而且類似的抱怨一直都沒停過,例如這裡。新鮮人面臨的困難,很多也都是像這些文章中一樣,是認知上的問題,例如:絕大部份的人,可能一開始只是會被要求做個小螺絲釘的工作。這和他幻想中,技術高超的程式設計師經過不眠不休的努力,就可以達成驚人的成就,然後改變這個世界有很大的不同。這裡有相關的認知現實描述。

因此一開始得先適應周圍環境,而大部份的學生畢業的時候(不管是哪個學校畢業)都須要先認知自己知識(或者常識)不足以適應環境。越有這種認知,適應的可能越快。

所以,以下是快要畢業,打算就業前,或者選擇公司的時候,建議學生先做好準備。

(1) 暫時不要看BBS,新聞,facebook一段時間。


PTT大概是台灣獨有的特殊環境,它很有趣,有時候資訊很快速。可是很遺憾的是隨著資訊量越來越多,他的正確性越來越差。如果你不是極端理性,意志堅定,很容易受到不良資訊的影響。如果可以的話,至少為期一個月。至於台製新聞跟facebook就更不用說了。


(2) 確實知道自己在搜尋什麼(當你打算google一下?)。


剛加入的新鮮人,特別是畢業於2008年之後的,在遇到困難的時候,一定習慣google。而google也很少讓人失望,通常都能找到某種答案。

但要注意的是,答案也許正確,但是資訊過於片面。日子一久,就很難獲得全面的視野。例如,查詢"android AsyncTask",如果你想要看中文資料,前幾個結果都會是某些人的blog,當然不是說這些人寫的一定不對,而是blog(特別是中文)常常是片面資訊,就算他好心貼上正確參考資料,可能也不會有人耐心查詢。對於中文閱讀者來說,最好是google之後自己找看看哪一個才是官方正確資訊。歹事,目前沒有中文的官方資料,api最好的參考是-> http://developer.android.com/intl/zh-tw/reference/android/os/AsyncTask.html

(3) 謹慎選擇工作 但更要謹慎選擇主管。


在台灣能夠選擇的工作實在太多,台灣優良的企業也很多。第一份工作,當你有難以決定的情況時,請謹慎擇一個好主管。

面試的時候,不只是面試者選擇你,而且你也必須要選擇面試者。當然如果面試你的人,不是你的主管,那這個公司等於是跟公家機關沒啥兩樣,不如乾脆去考公務員。


如何在面試的時候知道是不是好主管?

一個好主管能夠清楚地知道自己負責組織的真實情況,而夠培育員工,能夠掌握現實,並且能夠處理困難
。因此由詢問以下問題來判斷這個主管是不是個好主管:

  (a) 請主管描述自己未來1-3個月工作內容。


     如果講的比較含糊,可以單刀直入的問清楚。如果發現永遠都問不清楚,很有可能你進來這個公司的時候,發現這個主管無法控制組織前進的方向,做的工作和面試談的完全不同。要注意的是,工作的確一定要有彈性,以及隨時應變市場變化,但是市場的變化,不會讓一個新鮮人無法確定未來1-3個月的工作。而如果要靠一個到職不滿新鮮人來"負責"各類型的變化,那這個公司風險也太大了。

  (b) 請主管說明,上一次有新鮮人進來的時候,他是如何培育新人。

     同樣也是要清楚了解,是單純指派資深員工指導,還是有培育時程規劃,如果有規劃,可否讓你看一下,參考一下。當然也有可能上一次有新鮮人來的時候是10年前的往事,那就要考慮這個組織的老化性。

  (c) 請主管說明,當你來加入團隊的時候,他最有可能擔心哪件事情你做不好。


     這是要清楚了解,主管經過面試,對你有沒有清楚的認知,如果認知差距過大,那可能大有問題。舉例來說,如果你非常精熟java,但是並不熟悉Linux上的開發環境,在一個完全Linux的開發環境的團隊裡,如果主管認為你學習linux一定沒有困難,可以三天搞定,要不就是他不認清現實,要不就是你在面試中已經證明自己是天才。




沉思:


* 網路上的資訊很多,事實上無用的瑣碎的資訊,遠比切實的資訊來的多太多!短時間切斷資訊聯繫,對整理思緒有幫助嗎?