Recruits

遊戲程式面試之你在找甚麼樣的同僚?


遊戲程式面試之你在找甚麼樣的同僚?

縮網址: wp.me/pBAPd-xI

English version: http://www.gamasutra.com/blogs/NDarkTeng/20170413/296013/Ideas_in_Interviewing_Game_Programmers.php

各位好,我是NDark,一個視組織行為為聖杯的遊戲開發者。有在關注我的文章的朋友應該知道,我關心軟性議題-組織行為(團隊,管理及文化)多過於創意,技術,遊戲設計及遊戲行銷。我也在社群的聚會演講相關議題:"溝通的誤曲"以及"多包容不同思考模式的同僚"。我多年之前曾說過一句很嗆的話:“(台灣的)主管不懂怎麼管人,員工不懂怎麼被管。"多年之後我想把這句話再多加詮釋包裝一點:

“我們應該多關心一點管理,不只是公司管理層及負管理責任主管,也包含第一線工作的員工。管理不應只是主管的責任,作為基層員工,你也應該關心管理,關心團隊怎麼運作,關心團隊如何合作,關心你的同僚是誰,重點是以一個多元包容的視角。"

管理是實務科學,沒有一定怎麼作就對的方法,沒辦法照本宣科執行其他團隊的運作方式,只有適合自己團隊的方法。專案重點在於人,如何讓團隊成員能夠覺得放心,有支持,讓團隊成員覺得是他們控制專案,而不是專案控制了他們,團隊才會對決策有承諾,專案才能夠如期推進。關於團隊製程及文化的議題,我們在2014年底發表了團隊製程及文化對遊戲專案影響的文章,在此就不多論。

在任職不同團隊的過程中,我近幾年開始研究如何面試程式員(特別是遊戲產業),不管是大小公司,我認為技術人員的來去其實對專案都造成很大的傷害,有些直接讓專案結束,有些會讓專案時程爆增一倍。這對專案擁有者(團隊自己,出資人或老闆)都應該是個重要議題,但我們產業談這些卻談的太少。

另一個我覺得這個議題很重要的訊號是來自於我自己的部落格,我曾在八年前寫過一篇面試官入門的文章:面試官入門注意事項整理,四年前我描述我帶領的辦公室關於請假政策的文章:請假需不需要核可。很意外地,這兩篇文章是我部落格中各搜尋引擎導進來我部落格的排名一二的流量(自然流量)。這讓我驚覺:其實有很多人很需要這方面的知識。很多管理者是因為技術職能的優秀被公司拔擢為管理職,多半並不是因為他們已經具備了管理的知識與經驗。當這群小白兔誤入叢林,才會發覺他們需要這些知識,而多半公司沒有付出足夠的精力,來幫忙提升相關技巧,去勝任這些職位。而由於台灣職場的師徒制及政治問題,常常也讓這些管理新手無法在組織內學到這些技巧。

在本文開始之前我引述<面試官入門注意事項整理>:"面試官第一件要注意的事項,就是要了解這次面試的目的。"來強調管理學的一個重點:管理學沒有所謂標準答案,只有適合與否。也就是說一個應徵者可能很優秀,但是並不適合團隊及專案。因為專案有不同的進程,從開案,開發,到量產,上線可能需要不同的人才。職務職位不同,從玩法,系統,工具,到技術總監,技術長,也有可能需要不同的人才。有時不只是技術問題,更大一部分的是是否適合團隊文化。技術職的職涯發展並非單線式,有些人適合面對未知的挑戰,有些人適合維護舊產品,有些人適合研究第一線的技術嘗試導入,而有些人適合作知識的文件分享傳遞。新人有新人的優勢(像張白紙容易接受公司文化)及劣勢(沒辦法即戰力,需要說明及規範),反之老鳥則剛好相反,投靠時自帶武器馬上上工,但心靈上卻往往帶有過往戰鬥的傷痕。

不管你在團隊是擔任甚麼樣的職務,在開始後面的閱讀之前,請問問自己這個問題:甚麼樣的同僚適合作自己的同伴?團隊間對這個問題是否營造了互相討論的空間及共識?

破題

先講結論,我在這一輪的面試過程,總數大致面試了約二十五位前來應徵遊戲客戶端的程式,其中打槍率是百分之八十八。共有三位順利進入下一階段(製作人面試),有男有女,有資深也有新人。最後僅有一位是公司成功招募進團隊。該員進團隊後,三個月內就受到公司公開表揚。我想,這應該算是葛萊芬多得分的跡象。但由於該員不是我帶,所以我自認這個方法目前驗證上只能拿半分。只好請讀者作個參考,相互討論。

每位應聘者我都透過先前設計好的同一個方法,在實行之前建立了一個評分機制,方便我在事後評核結果。除去特殊情形需要特殊處理[註]之外就過關。評分是是理性的,但內容卻是主觀且軟性的。內容的部分我透過一個深度訪談,交互詰問的方法來了解每位應聘者是否適合?最後如約耳談軟體所說,最後結果就只有報請主管-核可及不核可兩個結論,核可後主管就會接著進入下一階段。機制分為三個部分,分別是心理測驗,經歷訪談,上機考。大致上每次進行都會花掉至少一個半小時的時間,所以常常早上十點開始的面試,極有可能進行到中午。這三個部分到底目的為何,分別說明如下:

上機考

上機考是技術能力的測驗方式。其實技術測驗並不是整個機制最重要的部分,但是卻是個必要的保險手段,透過技術測驗我們可以找出說謊者。也就是對於履歷經驗豐富,面試對答如流,但是實際上對程式碼掌握度卻異常的應徵者。一般軟體公司或是遊戲公司的技術測驗大多不外乎:考語法,資料結構,演算法,應用題,派作業,甚至我還有碰過考智力測驗的。有些是現場,線上,或是遠端限時。這些考試方式我都決定不採用,因為首先是跟實際執行的案子不一定接軌,講老實話我實在不了解會寫指標兩三層或是記憶體,背熟各種排序演算法優劣,甚至會背物件導向三要旨對實際執行專案的順利是否有正相關(除了證明教科書跟刷題刷很兇之外)。第二是作這些考試十分花費時間,尤其對每個應徵者來說求職可能是生死相關,為了確保答案正確,多半都會測試確認再三,考一個試一個小時,寫個作業兩到八個小時。對雙方都是一種消耗,事倍功半。

我嘗試從現實的角度來推演我們該怎麼設計這份技術測驗。也就是說我能否設計一個實際上在我們開發遊戲的模擬環境?來找出我想要找出的甚麼東西?也就是呼應到本文之前:"第一件要注意的事項,就是要了解這次面試的目的。"

各位遊戲程式開發者摸著自己的LP問問自己,那些演算法,物件導向,語法對我們每天的開發是否這麼重要?每一天的開發都用到這些東西?其實就算有,也只有極少的時間(我想也許一個月可能有一周我們有機會進行這樣的重點工程項目)會進行這樣的開發。摸摸自己的LP:其實我們大部分在處理的事情是甚麼?我想第一名我們話最多時間的是除臭蟲,有些是自己的蟲,有些是別人的蟲。所以其實大半時間我們不是設計演算法,也不是設計架構,有很多時間其實是在除蟲,特別是看別人的程式碼。

所以答案躍然而出,我設計的上機考就帶有這樣的特徵,我要設計一個環境讓應徵者跟我一起找出程式裡面的臭蟲或壞程式。同時更重要的是我要觀察這個程式員遇到問題是用甚麼樣的態度,思路來解決遇到的問題。心機更重的是我還會透過言語試探這個程式員能否在壓力及干擾的環境下,能跟他身旁的人作有條理的溝通,再進一步是否能夠接受別人的想法?

因此我透過我們實際使用的程式語言(C#,我甚至還寫了對應C++的版本),開發環境(Unity),設計了一連串有問題的壞程式。然後請應徵者來看程式,請他試著找出程式中我故意寫的臭蟲或壞程式。我會先針對這段程式碼的狀況進行戰情簡報(規格),然後應徵者嘗試看程式(讀程式碼),然後是以互相結問的方式(溝通),溝通順利的情形下,我會試著透露提示,引導玩家應徵者解題。試探應徵者是否能成功突破該關卡,是否能透過溝通暗示找到線索。不管成功過關與否,溝通順利的情形下,我都會說明這項目所想要找出的壞程式特徵是甚麼,進行術後的討論。(溝通順利的意思是我會看應徵者的溝通的狀況供給不一樣的情報,對於完全不溝通的應徵者就可能會結束該題目,甚至不公布答案。)

請各位面試官注意解題並不是唯一的重點,眼前的應徵者怎麼跟面試官互動就代表了將來應徵者進了團隊之後怎麼處理團隊給他的難題。

這邊進行的項目數目依照時間控制而決定,我平均會進行五題,程式語言一至四題,Unity一至二題。一般來講會花掉半個小時到一個小時,平均一題會需要十到二十分鐘。(老實講其實也沒比筆試省時)我這一輪面試多半沒有限時,因為不希望思考比較慢的應徵者因為時間因素而表現不好,但也許未來想辦法簡化題目,控制時間會更好。(因為整體還是花太多時間)

心理測驗

撇去其他兩個部分動輒都是一小時,心理測驗其實相對起來只有一題,耗時不到五分鐘,而且其實是不計分的,也就是核可與否跟心理測驗結果沒有關係。這份心理測驗有兩個目的第一個目的也是為了找出說謊者:如果應徵者訪談中理性回答的答案跟心理測驗有很明顯得出入,那麼就是一個警訊,必須要仔細再問詳細一點。第二,我希望知道對於應徵者來說,團隊或公司的甚麼要素對他而言是很重要的。將來我們在合作的時候要能盡量供給這個能量。

心理測驗的設計是改編自漫畫<女医レイカ>內的一個心理測驗,以職涯錨定的內容換皮而成。老實講我覺得還蠻準的。

經歷訪談

三個部分最重要的部分其實是經歷訪談,多半會持續一個小時,我會透過應徵者曾經作過的案子,了解他在團隊中負責的項目,然後詳細且深度地詢問應徵者怎麼作事情。與上機考相同,把這個訪談想像成我們試圖模擬未來的上班環境,以下有幾個訪談的原則:

  1. 狹義來講我的目的是找到一個能跟自己配合的開發者,所以依照我所設定的細節會比較容易找到跟我自己很像或是可以談得來的開發者。
  2. 我在訪談過程中也會說明自己的意見,所以會觀察對方能不能接受我的想法,這也是一個能否合作的訊號,如果在面試過程中兩人就很明顯地在意見上無法取得共識,那麼代表真正合作時也會有爭議,見微知著。
  3. 廣義來說目的是嘗試找出以下特質:經驗豐富,願意採用不同的方法,接受與團隊以非程式的方式溝通,具備其他選項思維的可能性,同時能夠在結問的過程中順利說明出來的開發者。
  4. 所以對於每個項目,我的問法會像是不只結問有沒有做過?而更重要的是為甚麼(Why)及怎麼(How)作?使用了甚麼樣的方法解決問題?使用了幾種方法?每個方法有甚麼優缺點?
  5. 額外地我還會問過往專案中遇到什麼問題?有沒有辨識到問題的成因,有沒有嘗試任何解法?嘗試了之後有沒有解決問題?環境因素造成無法解決問題時怎麼思考?從事後來看,有沒有更好的做法?
  6. 在不違逆特質的前題上,原則上照著這樣的邏輯,依照原先設定的標準給分。

接下來我列出我這邊會問的問題,同時我會說明我的思路,解釋我為甚麼要問這個問題。

  1. 面試前的準備:其實只要找得到,我是會先肉搜應徵者的,我也會先安裝對方履歷裡面作的遊戲。所以照這個邏輯,我也想知道應徵者有沒有先調查一下公司或團隊,有的話加分(這句話之後不提了,請自行依照自己的想法來決定)
  2. 在先前專案開發時(這句話之後不提了),程式寫作時有沒有甚麼合作規範?是哪一種規範?為什麼作?為甚麼不作?
  3. 使用過甚麼版本控制工具?上傳程式碼怎麼寫上傳紀錄?是否有用過Branch及Merge的功能?甚麼時候會發生問題?怎麼解決?
  4. 工作上是否需要寫程式之外的表單,如項目追蹤系統,工作日誌,結案報告,分享心得等?怎麼運作的?運作方式怎麼決定的?你覺得對工作有幫助嗎?
  5. 專案上有沒有遇到什麼困難?(如前述)
  6. 平均來說接到一項無法拆解的工作項目之後,大概多久作完是合理的時間?(這邊是在試探對方的工作節奏,藉此了解對方對於工作項目的規模認知,以及平時工作的節奏)為什麼需要這麼長?為什麼這麼快?(如果少於一天其實非常不合理,絕對是憑感覺不是基於事實,一定要問清楚)
  7. 接到企劃案之後你第一件事情是做甚麼?仔細的閱讀企劃案,跟企劃討論之後你還會做甚麼?在真正開始寫程式之前你會做甚麼?(其實企劃案完成是不是真正就開始寫程式呢?這又是一個理論及實務的差異,各位試著記錄一下自己的專案吧)
  8. 根據前述工作周期之後,工作完成時怎麼證明工作完成了?(這邊同時在問程式自己的證明,以及團隊怎麼運作品管兩件事)
  9. 有沒有遇過校能問題,優化時第一件事你覺得是甚麼?
  10. 前專案有加班過嗎?你覺得太多還是太少?如果被同事延誤到下班導致必須加班,甚至背了黑鍋,你覺得如何?有甚麼解法?(注意這裡我並沒有認為願意或不願意加班是好事或壞事,那是一種選擇,只要能說出自己的道理即可)
  11. 先前專案開會的長度及頻率是如何?你覺得合理嗎?你覺得太長還是太短?太頻繁還是間隔太久?需要每個成員都進去開會嗎?為什麼?有沒有更好的方法?

應徵者技術提問

在面試官問完問題上機考之後,我們就可以回覆應徵者對此職缺的疑問,這邊我們不多說,因為我這邊只面試技術,所以只回答關於團隊內軟體的部分,包含:技術團隊的組成,團隊使用的工具,目前工作分野,未來可能交付的開發項目等等。我這邊會建議,除了保密的項目之外,盡量客觀且誠實地對應徵者說明團隊的運作狀況,打比方說加班,團隊合作氣氛。因為應徵者既然會問這些問題,表示他們在意,就算不誠實說明,等到對方進來才發現真相,三個月內都是可以不用預告期離開,一進一出傷害的還是專案,團隊,及公司。寧可錯過,不要強迫。急件請使用外包。

結論:好相處

我必須再一次強調職涯錨定,我演講中曾說過光是程式員我都可以依照職涯錨定分成八種類型。不同的程式員對職涯的看法迥異,但他們可能都是技術合格的專家,我們如果是只用技術合格當作條件,那麼簡直就是把員工當機械,灌油就可以產程式碼。這世界也就不會有這麼多抓馬。也可能在賭未來團隊自己願不願意改變去適應這位哲學家皇帝。改編一句 Carly Fiorina 的名言:我看過不同的程式員,有些令人尊敬,有些人令我這輩子不會想與之再次共事。但我相信不同的程式員都有他適合的專案及公司,沒有絕對的優劣,只有適不適合。當然應徵者很難透過一兩個小時認識公司,公司其實也很難透過一兩個小時看透應徵者的前世今生。但我們既然要賭,也應該試用不同方法盡量提高勝率。人事是團隊或公司的重要課題,這流程中的每個人都應試著透過每次的面試真實認識自己公司的文化,同時找到能適應這個文化的員工,才是多贏的局面。

最後,每個人找夥伴的方式都不相同,我現在會建議試著把"好相處"(或稱之為符合團隊文化)這個特點比重加大。我是工程師,顯然地我用了科學化的方式來嘗試建立理性的評核機制。但如同我在經歷訪談中所提到的,我們都應該多包容不同的方法,我也認為對某些資深開發者來說,直覺或是氣味相投,其實就是在找相同文化的開發者。使用直覺並不是甚麼錯誤的事,但不管用哪一種方法,試著驗證及修正自己的目標及方法,嘗試不要被"每天變化的情感"或"專案及日常的壓力"影響了在選人方面的判斷依據。找進不適合的人,專案進度有可能不只是變慢,還有可能會倒退。慎之,戒之,共勉之。

[註]特殊處理:對於沒有作過遊戲或是應屆的應徵者,因為他們在此之前沒有遊戲案的經驗,我們很難透過深度訪談了解他們過往作專案的工作方式(連問問題都很難),如果遇到這種情況,我們會在面試時當面詢問是否願意接受作業的方式來進一步確認(來幫他們創造一次簡易的專案經驗),如果願意接受才在當天結束後發送題目。關於作業:是一個完整的工作交付流程,作業會有需求通常包含場景及運作,看應徵者是否能讀懂那些需求,可以來信討論,不限定時間(但其實這是陷阱),交付作業後會安排時間二面,我們會針對程式碼作一個有壓力的討論,模擬一個完整在公司工作的流程。藉此測試應徵者(通常是沒經驗的)能夠應付這些狀況,覺得這樣的環境跟他想像是一致的。曾經在遊戲公司或是作過遊戲專案的開發者即便前面的評分不及格,都不會有這個特殊待遇。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s