Skip to content

Latest commit

 

History

History
126 lines (87 loc) · 8.18 KB

README.md

File metadata and controls

126 lines (87 loc) · 8.18 KB

求職求才指南-以持久合作為前提

動機

長久合作 為前提的求才/求職

原則

尊重透明誠實

Summary

  1. 尊重對方的時間
  2. 尊重對方這個人
  3. 需求的透明
  4. 清楚的溝通
  5. 知道所以然
  6. 尊重對方的提問
  7. 背景的透明
  8. 決策的一致性

##前言 面談常有談到最高package或招聘最強人才的迷思,似乎銷售技巧大於評估合適性。不論是求職方誇大自己的經驗得到很高package但無法勝任的職位,或求才方過度美化公司前景文化以低薪得到很強的人才,結果雙方一合作幾個月後發現根本不適合而分開 造成更大損失。如求才方訓練、交接、士氣等成本,求職方花時間重找工作的機會成本等。

求職/求才合作比較像相互訂閱制,其中一方不玩了可立馬解約,而非買斷制,沒必要硬拚第一次成交,而是看雙方是否有長期合作的可能性還比較有效益。


##尊重對方的時間

< 求職方 >

  • 遲到或早到最好都先告知,雙方的時間都是寶貴的,求才方可能在面試前後已安排許多重要會議,提早跟延後都會被打亂。
  • 可要求先電話面談,理由下面會說明。
  • 看情況準備介紹自身經歷的輔具如ipad、筆電,會比起用口述的更具體更有效率。
  • 自己的經歷最好有充分準備,面談時清楚有效率的表達很重要!

< 求才方 >

  • 先約30分鐘"電話面談"以快速了解雙方現況與期待,約50%情況可不用再排on-site以節省雙方時間。求職者on-site成本尤其大,如請假、舟車勞頓、2-3小時的筆試+多輪面談等。
  • 準時。

##尊重對方這個人

< 求職方 >

  • 語氣與態度很重要,自我意識過強會讓人覺得團隊合作能力不足,很多求職者能力很強但這點可惜了。語氣與態度也不是說有就有的,平常跟人合作時就要培養,同理心,用對方語言與對方溝通,異中求同,同中求異的切換時機都很重要。
  • 求才方通常比較資深但也非全能,表達訊息一定會有不完善之處,如要討論釐清的話,注意語氣是否變成批評或是令人不舒服的方式。工程師通常直腸子以邏輯為中心,但如顧慮到對方感受,循序漸進的表達不同看法通常對方比較容易接受。

< 求才方 >

  • 極度重要且在台灣經常有不健康的現象!
  • 台灣求才方常default站在資方這邊,好像覺得出錢比較大,而對求職方不時顯露出上對下的態度,這在心態健康的求職方感受起來會很不舒服,雙方一邊出錢,一邊出力,其實是合作共創更多利潤共享。另外求才方通常比較資深或是職位比較高,也較容易透露長輩對晚輩的態度,其實在網路世代每個人專業愈來愈專精且多元,過去的觀念與技術未必適合未來,保持虛心態度請教年輕輩尤其重要,對等尊重彼此才是長久之計。
  • 上對下語氣包括:"你應該xxx"、"你錯了..."、"你xxx能力不夠"。可考慮用以下語氣取代:"我有個不同想法跟你分享,你參考一下"、"抱歉就我認知你xxx能力可能跟我們期望不同,我們比較需要yyy"等。

##需求的透明

< 求職方 >

  • 期望待遇,文化偏好,團隊合作模式。不過在台灣通常會放後面講,或用"詢問"來確認。
  • 不用擔心問太多太細,求才方也希望你多問一點,畢竟求才方要找的求職方是認同他們的,值得多花時間。

< 求才方 >

  • 面談開始就說明職缺需求、部門/公司目前現況、未來短中長期目標與挑戰、讓求職者能針對該職缺需求挑重點經驗講、而不是求才方亂槍打鳥問看似相關的經驗或是求職方贅述很多低相關性的經驗。雙方一起合作找出與需求高度相關的經驗比單方面猜測有效率的多。
  • 徵才文就寫清楚更好。

##清楚的溝通

< 求職方 >

  • (極度重要!很多人在這扣分。)
  • 介紹自己做過的專案一定要能把重點/差異化的地方凸顯出來,最好能用top-down方式介紹大架構,導引出最有價值的點,接著看求才方對那些細節有興趣再補充。
  • 求才方未必都很懂求職方過去用的技術,或懂但想探知求職方了解多少及表達的思路清不清楚。不論是哪種情況,也是需要有耐心的把求才方有興趣的事情講清楚。 例:為何選node.js寫backend? 可說明跟那些solution比較過,full stack統一語言的好處,event-driven I/O的好處,callback style的trade-off等。

< 求才方 >

  • 介紹職缺要求、公司現狀等最好能順過並有組織條理的表達,求職方也會觀察未來合作時溝通是否能順暢。
  • (很重要!) 無論結果如何都要禮貌且尊重的通知求職者,別發無聲卡,這反應公司對人的基本尊重的程度。

##知道所以然 雙方提供的價值都是解決問題,問題類型千奇百怪,隨時間演進,今天用的方法/技術,明天未必適用。所以,知道今天為何要這麼做,有哪些好處,有哪些潛在問題,怎麼權衡,一旦外在環境改變比較能知道何時該改變,為什麼要改變。

< 求職方 >

  • (也很重要!很多人在這被扣分)
  • 自己做過的東西一定要知道why? 每個決策的考量點有哪些?適用情境?如情境改變如何調整? 決策包含選擇語言,框架,演算法,系統架構等。
  • 情境題/程式題未必能在短時間寫出最佳解答,最起碼思路要講清楚,一般來說求才方會透過追問,提示的方式一起幫助找出適合的solution,主要還是看問題解決過程。
  • 了解自己在每份工作中對公司的價值。 如:擔任full stack developer時,主動幫助團隊建立許多common library,省下很多重刻類似功能的資源,且主動提出spec補強的建議,幫助公司設計出更適合市場的產品吸引更多user。

< 求才方 >

  • 可多問問求職方需要推導,整體思維,無法輕易google出答案的問題。
  • 另外,自己也必須準備為何目前系統採用這樣的架構,團隊採用這樣的流程。
  • 問求職方在某公司任職時的價值與定位為何?[2] (原PO還蠻喜歡的問題) 這問題可以問到的有求職方是否有以公司,團隊的角度思考自己的定位,以及如何根據自己的特性/技能提供公司/團隊更多價值。

##尊重對方的提問

< 求職方 >

  • 筆試要認真寫,先看過一遍題目再分配時間,有寫一些答案或解題過程比空白好,畢竟這些題目都是求才方努力設計過增加辨別度的工具。
  • 不要覺得求才方問太多或太細很麻煩,有時是求才方為了想用各種角度探索應徵者的專長,將優點全部榨出來,如此有機會更符合職缺需求,同時也有依據向HR爭取更高薪水。

< 求才方 >

  • 認真回答求職方的各種問題以彰顯透明度、態度,對公司評價影響很大。

##背景的透明 鼓勵對方去做reference check,多角度的資訊通常較能拼湊出真實面貌。

< 求職方 >

  • 提供linkedin讓求才方知道有哪些共事過的朋友/同事可供reference check。

< 求才方 >

  • 鼓勵求職方多問幾個內部員工、網路上的公司評價,也是展現自信的方式。

##決策的一致性

< 求職方 >

  • 雖然拿到offer後在任何期間(含onboard後)都可以反悔,但也希望別太反覆,除非有很正當理由,否則會給求才方留下扣分的印象。

< 求才方 >

  • 若要決定給offer,請與公司HR確定後再給求職方答覆,而不要一下給一下又不給,或是反過來。

##參考資料