※ 引述《Zoe519 (Zoe)》之銘言： : 面試公司: Facebook : 面試會是一個漫長的等待過程，我好像都沒有因為直接投履歷而 : 得到面試過。但是如果是經由內部推薦或是聯絡到recruiter就 通常來說，搶手的公司或職缺，內推的人就排隊到爆炸了 :D 其實這其中的「人性」道理很簡單，後面會詳述。 : Anyway, Facebook的理念就是move fast，從面試的過程中 ^^^^^^^^^^^^^^^^^ 羨慕... :D : 大概面試完過一兩個工作天recruiter就打電話給我了。（也 : 是一大早打來，接電話的時候我還在睡覺。）就是恭喜我得到 : onsite的機會，告訴我前一個面試的時候interviewer對我的評 : 價跟建議。被發現我寫code有點生疏了，叫我下個面試前多練習。 個人經驗，面試前練習寫程式最好是以「手寫」方式練習；若有機會 的話要練習在白版上解題，尤其是「解釋解題方法」的部分。 不過，我也看過有爆強者帶自己的筆電，接會議室的投影機; git init 起手式，開了 vim 就開始噴 code 出來, 解題同時還寫 unit test, 甘拜下風 orz : 於我的履歷經驗興趣的問題，就是很基本的behavioral questions， : 氣氛很像在閒聊。最後問了一題簡單的DFS的地圖題。最後也是 : 留很多時間給我我問題。我建議把想問的問題都留在這裡問。因 : 為這輪面試主要是在看你的個性跟職涯規劃，所以你問的問題如 : 果可以透露出你的求知慾跟上進心應該是有加分的。（我猜啦XD） 下面這些都是以前提過的，在這裡重新作個整理 * 正常的面試是雙向的。以北美的知識性工作來說，如果一場面試給 你一種「單向」的感覺，個人建議是: 塊陶。 * 資方這邊想知道的有三件事 1. Can you do the job? 你是否有勝任這工作的能力? (知識、經驗、技能、天賦) 2. Will you do the job? 你是否有執行這任務的意願? 3. Are you going to fit into this company's culture? 你是否能適應接受整個公司、團隊的文化? 通常 #1 是很直接的，以科技業來說，最常見的方式就是出題在白版 上給你解。 #2 與 #3 就很微妙；基本上沒有辦法在一般單天六小時左右的面試 行程裡得到精確、準確的答案. 是故，所謂「問『好問題』有加分」 ，通常就是加在 #2 與 #3 這背後的「人性」道理，就在於 一個年薪十萬鎂的職缺背後的真正成本在 15 至 30 萬鎂；在 corporate 環境裡最有價值的「資產」可說是 "head count"; 今天你是 hiring manager 的話，你會想怎麼使用你得來不易的 head count? 當然是用在「 看起來不會擺爛難管理，或在 18 個月內離職走人，以至於讓『我 』這個 hiring manager 看起來像個 idiot 的求職者」 是故，為什麼「內推」受重視? 最根本的理由在於 *spread of accountability* XD 「內推」進來的新人作得好，那自然是 hiring manager 識人有方 ( 同時，內推推薦人也能拿到筆獎金) ；若推進來的是個白爛，那可以 把責任倒一半到內推推薦人頭上 XD 易言之，就「資方想知道的三件事」而言 1. Can you do the job? 給所有的新人: 不要去擔心你「夠不夠資格」 不要去擔心你「夠不夠資格」 不要去擔心你「夠不夠資格」 剛畢業就是菜，大家都知道 :D 把你所學好好地用 "specifics, examples, results" 三原則展現出 來，資方要怎麼去評量，是他的事；事實上, 他比你更擔心。 :D 2. Will you do the job? 3. Are you going to fit into this company's culture? 以 #2 為例，問你自己: 「我需要哪些資料來幫助我回答 "Will *I* do this job?" 這個問題? 」，然後把這問題用 open-ended 的方向問出去 例如 (x) 貴公司是否有員工餐廳? (o) 通常你們怎麼解決三餐? 不一定要問些大題目，例如「請問貴公司在此產業裡的十五年 roadmap 為何? 」，這種題目通常太空泛 (除非你是應徵 director 以上的職 位) 但可問些管理制度的問題，例如這個問題是可以雙方通用的 你如何應對 / 調解 / 裁決在工作上的衝突? 以下 combo 技也是雙方通用的 * 能不能舉個例子? * 如果能重來，會不會在某些地方採取不同的作法? 能在 #2 與 #3 方面，雙方能交換愈多的 data points 愈好; 「讓 hiring manager 『覺得』他了解你、能掌握你、能管理你」, 那他 把 head count 花在你身上的機會也就大些 總結: hiring manager 也是個活生生的人，在 corporate 環境裡他也只 是領薪水的。把自己當商人，商品是自己的時間，「求職」也就只是 「出售自己的時間」而已，從買家的角度去推銷商品, business 101 :D : 我現在在忐忑等結果，想說發個心得，幫助需要的人，做好 : 事希望有好報 XD 祝好運 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 68.4.199.75 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Oversea_Job/M.1422726438.A.AEE.html 補述: 有些問題是需要拿捏的，例如，正式的福利(benefits)、薪資 、法律、簽證問題，大概就不適合在技術面試裡問，因為那些是 HR 才有被授權回答的問題；管理制度、文化、評量制度、風氣，通常都 可以問，因為管理與評量是 hiring manager 的工作內容。 有些問題很明顯是「白目」級的，例如，詢問對方未公開產品的八卦 流言這類的，除非你想申請的職缺稱謂就是「白目」，不然別問。 ※ 編輯: AmosYang (68.4.199.75), 02/01/2015 05:06:50 補述上面提到那位爆強者的作法: 先 O(scary) 暴力解，用這暴力解 來建構 unit test cases, 尤其是 edge cases, 然後再一步一步把 big-O 往下降, 同時繼續增加 unit test, 雖然最後不總是能找出最 佳解, 但在工程紀律上是十分讓人讚賞的 ※ 編輯: AmosYang (68.4.199.75), 02/01/2015 05:15:47 每家公司面試流程多少都有差異吧，無法一概而論 :) ^^^^^^^^^^^^^^^^ 這是一個很好的例子；以我自己來說，我觀察到我自己在 MVP 三原 則裡是先 mastery, 再 performance, 最後才是 visibility; 是故 我也對能展現 mastery 的求職者多少比較欣賞。相對地，我能理解 別的想法，例如「工具使用法可以再訓練，腦子裡有料才是最重要」 易言之，這就是為什麼這類「面試守則」總是只講大方向。因為面試 雙方都是活生生的人，無法有效窮舉所有的組合然後制定最佳戰術。 ※ 編輯: AmosYang (68.4.199.75), 02/01/2015 10:55:50 通常一「局」面試是 50~60 分鐘，他從 O(scary) 到 O(n log n) 花了大約 25 分鐘，但完全地以再實際不過的方式展現他的程式能力 ，包括使用 TDD + ALM 工具的能力；就 "Can you do the job?" 來說，我得到了 100% 精確(precise) 的答案。 又，個人覺得極細白板筆不見得適合；從面試者的位置 (離白版 5~10 呎) 通常無法看清楚極細白板筆寫出來的東西。 ※ 編輯: AmosYang (68.4.199.75), 02/01/2015 11:09:46 與其說「特別待遇」，我的看法是 1. 我希望與我共事的人收到的訊息是「只要合情合理合法(ethically, professionally, legally)，符合驗收條件，我不在乎你到底要 怎麼作」 2. 面試是雙向的；既然舞台已經交給了求職者，他要怎麼展現他的 能力及證明他的 business value, 我不在乎，只要能讓我看懂 就好 易言之，我崇尚的是 "absolute yet disciplined freedom"; 白板 或筆電都好, 以軟體業來說，工程紀律是必要的，但其他環節上我寧 願捨「制式流程的效率」，取「創意」 那你比我強太多了 orz git 的確是用熟就好，會了就是會了 但我沒有自信能在面試場合的壓力下還能走 TDD; 我玩 topcoder 或 ACM ICPC 題目寫出來的程式都是無可讀性的 hacky spaghetti clusterfuck black magic code... XD 我想，就這個話題，我們唯一能達成的共識就是「因為這類理念是建 構在更廣層面的『人生態度』上，並無好壞優劣之分，但也因為基本 價值觀的差異，所以無法達成共識」 XD ※ 編輯: AmosYang (68.4.199.75), 02/01/2015 11:55:38 如果「軟體測試」指的是有能力作 test automation, 從 functional, integration, performance, 到 stress testing; security vulnerability scanning & analysis; legal compliance; 領導 testing strategy, 這類事的話，雖說專門開給這方面的職缺不多(感覺上 contractor / consultant 居多), 但收入還不錯 如果「軟體測試」指的是手動測試後寫報告, 頂多走走 exploratory testing 的話，低。 ※ 編輯: AmosYang (68.4.199.75), 02/01/2015 14:21:51 *感覺上*, 公司規模大的才有資源去開 Test Engineer, Software Engineer in Test 這類職缺；規模小的必須把資源集中在開發。 雖說這種工作難找，但相對的，也因為工作難找，所以有實戰經驗的 人也少，競爭也少。近年吹起的 DevOps 風的確提昇了對這方面的需 求 有些公司是真正開始了解 DevOps 的意義，有些公司則是追著 buzzword 跑，把 DevOps 當成「一個 dev 抵三人用」的仙丹，就像之前什麼 東西都要來 cloud computing 一下… ※ 編輯: AmosYang (68.4.199.75), 02/02/2015 00:22:26