Browsing Category

未分類

未分類

招募與被招募

招募是一體兩面的,你在面試公司,公司也在面試你。

招募的核心是在有限時間內評估面試者是否適合加入團隊,也就是要先能認識面試者才能評估他是否合適。

首先我們必須認清一個事實,要在短短一兩個小時內了解一個人是不可能的,所以面試前的情報收集就格外重要。能收集到愈多關於面試者的資訊就能愈瞭解該面試者,反之收集資料愈少就是愈依賴面試者提供給你的資訊。關於面試許多人會只看到表面上的三個階段分別是準備履歷投履歷面試,但其實面試早在你投履歷之前就開始了,怎麼說呢?

我們是如何形容一個人呢?比如說我們形容 NBA 球星 Curry 是神射手,是如何歸納出來的呢? 是由他比賽中的表現來累積大家對他的印象,不科學的的三分投射距離,關鍵時刻的精準三分投籃,整體三分投籃數量及進球比例。

也就是說由過去做過的事情去定義他是怎麼樣的人。

那我們在認識(被認識)的過程中又展現了什麼呢?如果面試者自述對單元測試很有興趣,但卻說不出他讀過哪一篇文章,或是知道其中任一概念,也沒有在網路上發表任何關於單元測試的言論,那我們是否該取信於他呢?

人會說謊但是行為不會,所以我們不能只看他說了什麼,而是去觀察他做了什麼

這也就是為什麼面試是一門與設計相關的藝術,你必須透過問題設計與觀察去洞悉面試者背後的意圖,而不是直接問他你想知道的答案。

招募

你渴望與什麼樣特質的人工作?
自己是否具備這樣的特質?

必備

  • 誠實
  • 願意承認錯誤
  • 團隊合作的觀念
  • 軟體開發有熱情
  • 會主動學習且樂於分享

加分

  • 目前的程式能力
  • 對於軟體品質的要求

這些特質是我個人認為重要的特質,也是我反思自己是否具備這樣的特質,還有如何具備這樣的能力。

透過問題設計來洞察人心

  1. 誠實 與 願意承認錯誤 (知之為知之,不知為不知):
    1. 前一天晚上做了什麼? 最近下班時間都在做什麼? (避免已經準備好的答案,讓受測者放鬆)
    2. 問一個較艱深的 iOS 開發問題,觀察受試者的反應,當遇到不懂的事情是否會硬凹。
    3. 當不懂裝懂時被糾正的態度 (有無被動的學習能力)
  2. 團隊合作的觀念
    1. 過去的有無團隊合作經驗,你們如何合作?
    2. 與團隊成員持不同意見時,你會怎麼做? 有過這樣的經驗嗎?
  3. 軟體開發熱情 與 會主動學習且樂於分享:
    1. 覺得自己現在的程式能力如何?目前如何持續學習?
    2. 是否有分享經驗(blog, talk)?有或沒有的原因是什麼?
    3. 過去做過的專案中遇過的挑戰,你如何克服它?
  4. 目前的程式能力
    1. 設計模式(Design Pattern) 有印象的是哪些?
    2. 單元測試(Unit Testing) 有多少了解? 為什麼單元測試重要?
    3. 如何衡量自己的軟體品質好不好?
    4. 持續整合(Continuous Integration) 是什麼?重不重要,為什麼?
  5. 判斷是非及勇於堅持的問題
    1. 問一個不合理的問題,並看他面對不同答案時的表現。

情報收集

  1. 履歷: 面試者精選的資訊,但有可能造假
  2. 網路資料:Github, Blog, Slide share, Google, Facebook, Instagram, twitter。透過這些情報來了解受試者是否具備我們要的特質。
  3. 面試:事前設計題目

評估分析

  1. 綜合履歷 + 面試提問來給出一個客觀的分數
  2. 再依照面試官個人感覺給出一個主觀分數
  3. 綜合客觀與主觀分數為最後分數。

面試

思考過招募這端的目標後,準備面試的方向就很明確了。

你現在是否具備上述好的特質?你將如何準備這些特質?

  • 透過撰寫個人 Blog 分享所學技術,也練習思考與文筆
  • 與朋友組織課後讀書會,研讀技術相關的文章或書籍
  • 透過參加社群認識好的工程師,並向他們學習

如何了解一間公司的文化?

  • 有沒有認識的人在裡面工作,詢問他對公司文化的看法
  • 透過網路搜尋該公司相關資訊,看公司對技術的重視程度
  • 準備一些瞭解公司文化的問題面試時提問

心態

沒錄取也不用灰心,也許只是當下雙方沒達成一定的共識。 有時只是緣份未到剛好面試官跟你的氣味不相投,所以這次沒機會合作。

面試整體過程保持禮貌,這次沒談成不見得以後沒有合作機會,有可能是公司再度擴編所以多了職缺,留下好的印象最增加公司主動找你的機會。又或者你在短短時間內能力成長到符合公司的需求,都會再有合作機會。

持續關注好公司

自己對於好公司的定義是什麼? 薪資福利? 未來發展性?
現階段自己缺少什麼能力?
現階段已經具備什麼能力?

薪資談判

將自己的特質與能力攤在桌面上,看不同的公司願意用多少資源來招攬你。
心態保持健康,即使該公司的 Offer 不如你的預期,也可以試著請招募人員試著爭取更好的待遇,因為就招募人員的角度來說,總是希望好不容易招募到一個人才,希望能給他好的待遇讓他能專心的為公司做事,而不會分心在想著要不要下班接案,又或是再次尋覓下一個落腳處。所以,如果你有自信你帶來的價值符合更好的 Offer ,相信招募人員也會很願意幫你爭取看看,但無論爭取的結果如何都應該感謝對方的幫忙。

履歷

是面試官對你的第一印象,盡可能精選出最有價值的部分。 精選的要領就在於少,即時。
盡可能以 問題→ 行動 → 結果 的方式敘述來幫助面試官了解你的故事。

未分類

奇怪的價值觀

小明努力很久準備國家考試,終於第3年後如願考上公務員,從此之後小明就每天坐在辦公室裡,過著每天滑手機看FB,準時下午茶衝團購的幸福美滿生活。

很多人眼中的理想生活

因為國家考試(簡稱國考)很難,所以要成為公務員很辛苦,所以薪資福利好是應該的。即便是每天工作任務都隨便應付,因為之前考試很辛苦,所以這些都是應得的。

為什麼我們會這樣想?

小明做一件跟「工作不相干的事情很辛苦」,所以就算沒把工作做好,一樣能領很好的薪資福利也是沒關係的?

這例子或許有點極端,因為現實是目前公務員的體制跟法律給予其的保障就是如此。

另一個例子

小華因為工作的關係,每天天沒亮就起床開始掃地,不知道的人以為每天地就是會自動變乾淨,她卻只能領基本薪資。

每天天沒亮就起來工作不辛苦嗎?

為什麼我們對小明如此寬容?

對「工作」有貢獻的人卻沒辦法有更好待遇,而我們卻花大把鈔票在養一些對「工作」沒貢獻的人卻拿他沒辦法?

為什麼我們的價值觀如此扭曲? (包含我自己在內)

我們很容易被「名目、標籤」來說服,只要是「XX」大學畢業就是會比「OO」大學畢業多5k,只要A工作5年就比B工作2年資深,所以薪資比較高是正常的。

我們習慣偷懶的用一些「標籤」來定義一個人的「價值」,而不是這個人到底做了什麼「貢獻」來給賦予其價值。

哈佛大學畢業、澳洲打工度假經驗、某某大學肄業、業界10年經驗、美商公司創意總監、資深軟體工程師…等等。

這問題我還找不到答案,我們都還活在自己的傲慢與偏見

延伸閱讀

未分類

告別KKTOWN

離開 KKTOWN 一段時間,紀錄一下在 KKTWON 的一些小事。

機緣

因為 Zonble (楊維中) 在社群分享技術的關係,在我剛開始接觸 iOS 開發就嚮往著加入高手如林的 KKBOX ,當時還在 Hiiir 時間軸科技剛開始學習著 iOS ,每月也勤於參加社群補充新知,認識業界的高手們。

終於在 CocoaHeads Taipei 做了兩次 Share 後鼓起勇氣向 Zonble 毛遂自薦,但當時 iOS Team 剛好沒有缺,所以轉而面試新產品開發部門的 iOS 工程師一職。
記得當時面試主管問說:「我看你還很年輕,你怎麼證明你能把 iOS 做好?」 而我的回答是:「我確實很年輕,但面對開發的問題我會以這樣的策略進行。首先,我會嘗試在網路上找解答,如果卡關太久,我會去請教 Zonble 他們,如果這些問題他們沒解決方法,或許我們該討論有沒有其他的方式達到一樣效果,讓產品保持持續前進。」能夠從無到有打造產品是我有興趣,也一直在做的事情。

加入不久之後我們就開始做 KKTOWN。

KKTOWN 是一個 C2C 電子商務服務,最重要的是確保交易安全與正確性,不容許有些微差錯,無論是交易狀態以及訊息通知都很重要,為此必須透過一些開發方法提升軟體品質,才不至於惹出交易糾紛。

Shared mock data

單元測試要執行的穩定,要快的話就必須不穩定因素隔絕在外,而「網路」就是時常不穩的的因素之一,可能是辦公室網路斷線,抑或是伺服器後端正在部署造成某些 API 暫時無法使用,都會影響單元測試的結果。

為了將網路的不穩定因素排除,我們建立了一個 repo 把 API mock 資料集中管理,並由前後端共同維護,如此一來即使再斷網的情況下,iOS 的單元測試依然可以順利執行,並給出正確的結果。即使 API 格式有任何的修改單元測試都會替我們把關,幫助我們快速的修正程式碼去符合新的 API 格式。

但很不幸的,這個 repo 大多數的時間只有 iOS 的團隊成員,也就是我跟 Jefferey 在維護。

API 整合測試

簡單來說,透過 API Client 模擬兩個 User 的交易行為。

其中的步驟大致如下:
1. 賣家建立商品
2. 買家購買商品
3. 賣家必須收到商品售出的通知,並且商品狀態要是已出售
4. 賣家出貨確認,商品運送狀態要為運送中
5. 買家要收到出貨通知
6. 買家確認收到貨並給評價
7. 賣家給評價
8. 交易完成

上面的步驟再乘上 7-11 金物流,全家金物流,貨到付款等等不同情境,加起來有十幾種不同的流程。

在 KKTOWN iOS 這邊不止測單隻 API 是否正常運作,也測了所有情境整合測試。做這樣的事情雖然辛苦,但是能在開發 UI 前就確保交易流程正確,除了後續保證 API 功能的正確以外,還可以減少整體開發時間,也算是一石多鳥。

KKTOWN 後期

在 2016 年底萌生去意,一部分是因為公司發展方向與我期望的不一樣,但也因為我只是個 iOS 工程師無法改變什麼。仔細想想也與我當初加入 KKBOX 的目的不太一樣,還沒有一探 KKBOX iOS team 的開發方式,沒有在 Zonble 底下學習過,於是在 2017 年 1 月申請內部轉調回 KKBOX 。

雖然不捨自己一手打造的 KKTOWN iOS,但也渴望能夠在更強的團隊內學習,能夠讓真強者檢視自己的實力,在 KKBOX iOS team 裡修練,成為更獨當一面的工程師。