2020 年度回顧 - 矽谷輕鬆談 Podcast 推薦單集
感謝各位 JK 粉的一路陪伴,總算到了今年的最後一天了,無論你是從第一集就開始聽的鐵粉抑或是最近才加入的朋友,我們真心感謝你的每一次收聽 ❤️ 宅在家跨年的朋友,快來回顧柯柯與肯吉私心推薦的 2020 單集,沒聽過的集數趕快聽起來,同時手刀分享給你的朋友,讓我們一起告別 2020 邁向更好的 2021 吧!
#面試心得
EP10 從應徵者到面試官 - 美國矽谷軟體工程師 Kenji 的求職筆記
https://pod.fo/e/aed34
EP38 矽谷資深軟體工程師後疫情時代面試心得 Facebook/Robinhood/Coinbase/DoorDash
https://pod.fo/e/aeadb
EP39 為何我拒絕了 Facebook 資深工程師的 Offer
https://pod.fo/e/aeada
#科技社會議題
EP12 你以為你很有同理心?所有男生都該知道的矽谷科技業女性困境
https://pod.fo/e/aed32
EP13 Airbnb Uber Lyft 相繼裁員 矽谷共享經濟獨角獸的困境
https://pod.fo/e/aed31
EP17 矽谷創業教父彼得堤爾的創業聖經《從0到1》
https://pod.fo/e/aed2d
EP30 從惡血和 Fyre 音樂節看失控的造夢者 Netflix 和 Zillow 對遠距工作一個唾棄一個擁抱
https://pod.fo/e/aed26
EP31 我們才是科技公司的產品!矽谷科技專家敲響了警鐘 The Social Dilemma
https://pod.fo/e/aed25
EP33 Coinbase 矽谷逆風而行禁止員工討論政治議題 不認同的員工可以領遣散費離開
https://pod.fo/e/aed23
EP35 美國總統大選拜登醜聞事件 Facebook 和 Twitter 如何做事實查核
https://pod.fo/e/aeade
#人物訪談
EP15 矽谷資深女工程師 X 資料科學家柯柯 Jessica Ko
https://pod.fo/e/aed2f
JK Show EP1 Amazon 軟體工程師華麗地轉身離開 - 王文昱
https://pod.fo/e/aed37
JK Show EP2&3 Square 首席工業設計師 Ben 談 Square 產品從0到1的起源故事
https://pod.fo/e/aed29
https://pod.fo/e/aed27
#深入技術
EP18 打開 Apple Podcasts 排行榜演算法黑盒子 feat. 拉麵的叫聲
https://pod.fo/e/aed40
EP20 當你在瀏覽器輸入 google.com 並且按下 Enter 的時候發生了什麼事?
https://pod.fo/e/aed3e
EP24 人工智慧大突破!最新最強通用語言模型 GPT-3 問世
https://pod.fo/e/aed3a
EP27 工程師竟然要寫驗屍報告!?服務大當機時工程師在幹嘛?
https://pod.fo/e/aed2b
EP36 揭秘 Uber 司機乘客配對演算法 最佳化計算供需市場動態平衡
https://pod.fo/e/aeadd
#鬼故事系列
EP23 Amazon 和 Microsoft 如何「致敬」新創公司和個人開發者
https://pod.fo/e/aed3b
EP25 前 Google 工程師竊取自駕車專案 Waymo 的商業機密到 Uber 被判刑 越挫越勇繼續告 Uber
https://pod.fo/e/aed38
EP26 換了位置就換了腦袋 30%的蘋果稅讓 Apple 從《1984》的革命者變身為極權大魔王
https://pod.fo/e/aed2c
#公司介紹
EP29 最神秘的獨角獸 Palantir 與矽谷文化格格不入的矽谷科技公司
https://pod.fo/e/aed28
EP32 Stripe 估值 360 億美元的金融科技獨角獸會是下一個科技巨頭嗎?
https://pod.fo/e/aed24
EP41 Airbnb 展現韌性 從 2007 設計大會最初的房客到 2020 谷底反彈風光上市
https://pod.fo/e/aead8
EP42 不只是餐飲外送平台 DoorDash 立志成為 on-demand 物流公司
https://pod.fo/e/aead7
還沒填 Podcast 年末問卷的朋友,請你們花一分鐘的時間給我們回饋,幫助我們 2021 年繼續製作你們喜歡的內容 ❤️
https://www.surveycake.com/s/vgG7N
同時也有2部Youtube影片,追蹤數超過2萬的網紅Untyped 對啊我是工程師,也在其Youtube影片中提到,拖了三個月的軟體工程師面試SOP在此獻上!把面試當作刷題的我,把面試經驗技巧,努力濃縮再濃縮,還是有15分鐘的精華,只要五步驟,面試照著做,保證你 ace the coding interview like a PRO (most of the time). 這集會聊到... 💬 Overvie...
「軟體 工程師 面試心得 分享」的推薦目錄:
- 關於軟體 工程師 面試心得 分享 在 矽谷輕鬆談 Just Kidding Tech Facebook 的最佳解答
- 關於軟體 工程師 面試心得 分享 在 矽谷輕鬆談 Just Kidding Tech Facebook 的最佳解答
- 關於軟體 工程師 面試心得 分享 在 矽谷輕鬆談 Just Kidding Tech Facebook 的最佳解答
- 關於軟體 工程師 面試心得 分享 在 Untyped 對啊我是工程師 Youtube 的最佳解答
- 關於軟體 工程師 面試心得 分享 在 在地上滾的工程師 Nic Youtube 的精選貼文
- 關於軟體 工程師 面試心得 分享 在 [心得] 2023 軟體工程師(後端)面試分享- 看板Soft_Job 的評價
- 關於軟體 工程師 面試心得 分享 在 0到100的軟體工程師面試之路- 科技業板 - Dcard 的評價
- 關於軟體 工程師 面試心得 分享 在 軟體工程師面試20家公司的心得(2)準備篇 - YouTube 的評價
- 關於軟體 工程師 面試心得 分享 在 半路出家軟體工程師在矽谷- 面試技巧及心得 - Facebook 的評價
- 關於軟體 工程師 面試心得 分享 在 Facebook 總部軟體工程師面試心得分享與免費冰淇淋 的評價
- 關於軟體 工程師 面試心得 分享 在 40歲軟體工程師面試心得 - Mobile01 的評價
- 關於軟體 工程師 面試心得 分享 在 [心得] 碩士應屆面試心得-軟體工程師- 看板Soft_Job | PTT職涯區 的評價
- 關於軟體 工程師 面試心得 分享 在 Re: [心得] 在日本工作受不了,想回台灣 - PTT評價 的評價
軟體 工程師 面試心得 分享 在 矽谷輕鬆談 Just Kidding Tech Facebook 的最佳解答
S1E39 為何我拒絕了 Facebook 資深工程師的 Offer Q&A
#最近發現拉麵粉好像有點多
感謝大家對於 Kenji 面試心得分享的支持和反饋!本集延續上集的討論,我們一起更深入談談求職該有的正向心態和背後的人生哲學,雖然是從工程師的角度出發,但也適用於非工程師領域的求職者喔!本集還會聊到:為什麼這次的面試名單沒有 Google?拒絕科技公司的 job offer 會不會以後就沒機會進這家公司了?在目前的一線大公司(FAANG + Microsoft)中我們會如何排志願?我們也深入的探討在 Facebook 工作的優缺點,但不論如何討論,主旨就是那麼一句話:不要放棄思考,盡量找到真正適合自己的公司,而不是用別人的看法來選公司。
由於這次 Q&A 聽眾反應熱烈,本集 Q&A 先回答一半的問題,另一半問題下集待續!
#心態 #SiliconValley #Interview #SoftwareEngineer #資深軟體工程師 #矽谷 #Facebook #FAANG #Microsoft #JustKiddingTech #矽谷輕鬆談
---
#Podcast傳送門
Apple Podcasts ➡️ https://apple.co/2wizvzO
Spotify ➡️ https://spoti.fi/3aeP9KY
Google Podcasts ➡️ https://bit.ly/2vureZq
其他平台 ➡️ https://anchor.fm/jktech
軟體 工程師 面試心得 分享 在 矽谷輕鬆談 Just Kidding Tech Facebook 的最佳解答
S1E38 矽谷資深軟體工程師後疫情時代面試心得 Facebook/Robinhood/Coinbase/DoorDash
2020 年是個動蕩不安的一年,因為疫情的關係,很多公司都在年中進行了規模不小的裁員,包含大家耳熟能詳的 Airbnb、Uber、Lyft、Yelp、LinkedIn、Mozilla、Intuit、Salesforce 以及 WeWork 等等族繁不及備載。根據 layoffs.fyi 的統計,這波裁員潮集中在今年的 3 月到 7 月,8 月以後逐漸趨緩。
這對於在這段期間要找工作的絕對不是件好事,因為很多人被裁員,意味著同樣的職缺會有更多競爭者,也因為景氣不好以及疫情不確定性的關係,很多公司開始減緩招人的腳步。不過 7、8 月以後情況逐漸好轉,隨著美國各大城市解除封城,人們意識到必須跟疫情共存好一陣子,於是實體經濟活動恢復了,美國人畢竟是擁有自由的靈魂不能隨便被囚禁的呀!最近是美國各公司的財報季,各大科技公司紛紛發布第 3 季的財報,表現都非常好,也應證了在疫情下經濟轉好的事實。
我在 8 月下旬的時候開始投遞履歷,9 月初開始電話面試,10 月中結束 Onsite 面試 (都是線上進行),面試了四間公司:Facebook、Robinhood、Coinbase 以及 DoorDash,最後拿了前三間公司的 Offer,級別都是資深工程師。在這篇文章我會分享各公司的面試流程以及體驗、我做了什麼準備、怎麼談薪水以及我最後的決定,希望可以對在美國求職的人有幫助!由於有簽保密協定的關係,我只會提到面試的流程,不會提到具體的題目以及 Offer 數字。
Medium 文章好讀版 https://bit.ly/2Ii9vLc
Apple Podcasts https://apple.co/36fLCMh
Spotify https://spoti.fi/2IcyJdv
#面試的動機
蛤!?面試不就是為了換工作嗎?對大部分的人或許是如此,但對我而言這次並沒有非換工作不可的理由。我在 Square 待了三年多,整體的滿意度一直都很好,公司的股票從我加入以後基本上都是一個上漲的趨勢,最近也來到歷史新高。一年多前從 Android 開發換到後端的 Traffic Infrastructure 組以後,更是一直處在學習的狀態,了解怎麼規模化公司的後端架構,支援更多的應用場景,工作上也需要一直動腦,思考各種方法的優缺點、我們為什麼要這樣做並且撰寫許多技術文件,負責的專案也很有影響力,最近的成果是把公司很重要的 reverse proxy 升級成 Envoy,讓系統的效能更好並且支援更多新的功能。或許因為疫情一直在家工作的關係讓我有點工作倦怠,但這個倦怠並不是源自於工作的不開心,而是真的在家太久了,很需要好好放個長假讓腦袋放空充電一下。
言歸正傳,這次面試的主要目的是測試自己的市場價值,看看自己能否適應資深工程師面試的強度,畢竟上次面試已經是四年前了 (當時的面試心得),很多當時對於面試的理解也需要進行修正,我的心態是保持開放的態度,如果遇到很好的機會,當然可以考慮換工作,沒有的話待在現在的公司也很好!另外我自己過去的主要經驗都是 Android 行動開發,在後端只有一年多的經驗,也很好奇這些公司會不會讓我面資深後端的缺,還是會將我過去經驗打折?事實證明是我多慮了,我面的這幾間公司都有把我在 Android 的年資完整算進去,最後也給了我資深軟體工程師的 Offer,Facebook 甚至幫我安排 E6 (Staff Level) 的面試,只是因為系統設計表現得不夠好,最後給我的是 E5 (Senior Level) 的 Offer。
我還蠻建議大家即便沒有特別想換工作,也可以定期去外面面試看看,在沒有非換不可的情況下,習慣面試的緊張感跟壓力,這樣會讓你以後的面試更自在,跟面試官可以像是在平常工作時一樣互動,發揮自己的實力。一開始會有這個觀念是在幾年前讀 hello, startup 這本書時看到,作者建議大家每一年定期去外面面試,審視自己的能力,進而補足自己不夠好的地方,當然我覺得每一年對一般人來說可能有點難,畢竟邊工作邊準備面試不是易事,而且還得跟公司請假去面試,但至少每兩三年可以去外面看看,避免自己的能力跟求職市場脫勾太久。在矽谷以專門招收資深工程師聞名的 Neflix 甚至在他們的文化守則裡提到:「員工的薪水取決於他們個人最高的市場價值,我們鼓勵員工去外面面試並且跟他們的主管討論,我們認為這是健康的行為。」
#資深工程師的優勢
在一般情況下,5 年以上工作經驗可以面資深工程師 (L5) 的職位,10 年以上工作經驗可以面 Staff level (L6) 以上的職位,我有約 6.5 年的工作經驗 (3 年台灣 + 3.5 年美國),所有公司都是讓我面資深工程師以上的職缺。
這次找工作我感受最深刻的事情就是:我再也不用海投一大堆公司了!四年前當我還是求職市場裡的菜雞的時候,投了超過 150 間公司,只有 1x 間公司回應我,轉換率不到 10%。這次 Facebook 跟 Robinhood 都是 recruiter 主動從 LinkedIn 聯繫我進行面試邀請,Facebook 的 recruiter 更是從 2019 年初就開始定期聯絡我,到後面我真的不好意思持續拒絕她,於是接受了面試的邀請,真的還蠻感謝她不斷地嘗試,讓我定期思考一下要不要面試。Coinbase 跟 DoorDash 我都是從官網直接投履歷,沒有透過內推,一個禮拜內就收到了 recruiter 的來信,而這也是我唯二主動申請的公司,真的從以前我找工作,到現在變成是工作機會找上我了。
另一個很大的改變是:刷題不再是最重要的一環。隨著你越來越資深,系統設計跟行為面試所佔的比例也會越來越高,而且除了年資以外,這兩種面試的表現基本上就決定了你的職等,Facebook 的 recruiter 也在電話中跟我說,針對比較資深的應徵者,Coding 的要求會比較寬容 (lenient),所以建議大家不要對刷題過度著迷,一昧的追求題數不是好事,而是應該重質不重量,題目是無限但觀念是有限的。
最後一個體悟是在拿到 Offer 之後,談判的空間變得很大。美國科技業的求職市場一直是呈現一個兩極化的狀態,對於剛畢業的人來說,競爭者多而且職缺少,公司有較高的話語權。但是當你是資深工程師以上的時候,情況就反過來了,大多數公司不管景氣如何,任何時候都在招有經驗的工程師,職缺一直開在那但總是招不滿。上次找工作的時候,能夠讓公司提高年薪 1 ~ 2 萬美金就歡天喜地了,但是這次有兩家公司給我的初始 Offer 跟最終 Offer 都差了好幾萬美金。
#準備過程
軟體工程師的面試主要分成三種:Coding、系統設計以及行為面試。我自己是花比較多時間在系統設計上面,再來是 Coding,最後是行為面試。
關於系統設計的準備,我在軟體工程師系統設計面試準備指南有比較完整的介紹,這邊補充說明一下,準備系統設計最好的方法是來自於工作,最好你工作上就是要去思考怎麼設計系統,各種方法的優缺點以及思考各種 edge case 以及解法,這樣子學到的深度跟廣度都遠多於看那些準備素材。如果工作上沒有碰到也沒關係,可以先從 system design primer 看起,理解系統設計的各種面向。另外我推薦看一些公司的 Tech talk 來了解他們實際上怎麼設計系統,為什麼要這樣做以及不同方法的 Trade-off 又是什麼,理解為什麼要做這個決定是最重要的。如果已經接近面試了,建議可以看 InterviewBit 的系統設計篇,總共有八題,我認為寫的還蠻好的,比 Grokking the System Design Interview 還深入,看個兩次完整理解以後對面試很有幫助。
Coding 的部分我還是要再強調一次,不要過度迷信刷題的數量,應該要重質不重量,重點放在在訓練你的解題思維以及邏輯思考,練習使用常見的資料結構並且把想法轉成可以執行的程式碼。剛開始寫題目的朋友,我會建議相同的題型一起刷,培養對同類型題目的敏銳度,題目難度主要以 Medium 為主,搭配少量的 Hard 題。
很多題目一開始寫不出來,或是寫不出最佳解是很正常的,如果一題你卡超過一個小時,建議可以參考討論區的最佳解,但是切忌直接照抄別人的解答,因為那可能不是最適合你的方式,比較推薦的方式是你去理解背後的演算法,清楚地知道每一個步驟,再用你自己方式寫出來,這樣即使換了一個程式語言,你應該也可以寫得出來。當你開始發現沒看過的題目你也可以自己想出最佳解,並且實作出來,程式碼也很精簡,那代表你已經成功培養出解題的思維了。
我自己還會做一件事,就是想辦法分辨好的題目跟壞的題目,有一些題目的答案很明顯就只適用於這一題,用一些很特殊且不好理解的方法、實際上工作也不可能用到,這類型的題目我就不會花太多心思在上面,如果真的被考到,我會認為這是面試官的不用心。相反地,有一些好的題目:在觀念上很實用、有好幾種解法、工作上有機會用到或是系列題,這種就很值得練習,比方說 Graph 或是 Design 題就是我很喜歡的類型。
雖然說題數不重要,還是提供我的數據給大家參考,我在寫了 50 題的時候開始安排電話面試,最後一個 Onsite 結束時寫了約 120 題,我是以比較新的題目以及高頻題為主。
最後是行為面試,要再細分的話可以分成兩種,一種是 Project Deep Dive,你選一個你最近做過的專案,解釋一下專案內容、解決了什麼樣的問題、你的角色是什麼、最後的成果以及中間遇到的困難,另一種面試是來判斷你是否符合公司的文化以及價值,衡量你過去解決衝突跟溝通的能力。不管是哪一種面試,只要你好好回顧你過去做過的事情,能夠完整講述前因後果,把自己的故事清楚地講給面試官聽,輔佐一些例子,基本上就不會有太大的問題。
#遠距面試 #VirtualOnsite
因為疫情的關係,大家都在家工作,所以所有的面試包含電話面試都改成線上視訊進行,這個情況至少要到 2021 年的夏天。遠端面試的好處就是你不需要舟車勞頓,時間安排上也比較彈性,但是壞處是跟面試官的溝通比較沒那麼順暢,線上的交流絕對是沒有實體見面來得好,而且有的面試官網路很差,我甚至有遇到差到面試官需要把影像關掉的情況。
另一個要注意的點是,系統設計的面試會需要用到線上白板來畫圖,我自己覺得沒有實體的白板順暢,主要有兩種方法,你可以使用 iPad 搭配 Apple pen,或是用鍵盤滑鼠直接拉,選一個自己習慣的方式,面試前稍微熟悉一下白板軟體的使用,面試也會比較順利。
#DoorDash
第一輪是一個小時的電話面試,前 20 分鐘聊過去的工作經驗以及這個組在做的事,後 40 分鐘 Coding。題目是一道經典的 Hard 題,我對於該題印象很模糊,於是在面試中慢慢想,最後是有跌跌撞撞的寫出來,當時自我感覺良好,面試官給我的感覺也蠻算滿意的,但是隔天還是收到了拒信。事後回想應該是因為這是經典題,所以標準相對高,我並不是一次就寫對,而是慢慢修正,所以相對於其他應徵者表現不算太突出。
#Robinhood
他們家固定有兩輪各一個小時的電話面試,第一輪前 15 分鐘給你一段程式碼,要找到潛在的 bug 並且問你要怎麼修正,後面 45 分鐘 coding,題目比較偏向 Robinhood 工作上會遇到的演算法題。第二輪是系統設計,這是我第一個系統設計面試,微緊張,原本以為表現不夠好,但從 recruiter 那得到的反饋是還蠻好的。
Onsite 出乎我意料只有三輪,一輪 45 分鐘 coding,一輪一小時的系統設計,以及 45 分鐘的 Project Deep Dive,Coding 也比較偏向實作工作上會遇到的問題,面試官提到不用特別在意效能,以實作出來並且跑過測資為主,最後 10 個測資我只過了 9 個,不算完美。接下來兩輪跟面試官都聊得蠻開心的,並且有蠻不錯的討論,最後順利拿到 Offer!面 Project Deep Dive 有個小插曲,面試官到一半網路突然掛了,他後半段只能打電話加入簡直尷尬。
#Coinbase
Coinbase 的面試體驗是所有公司裡最讚的!從面試的流程跟題目都可以感受到他們的用心,面試官的平均素質也很好,你可以感受到他們是真心想要認識你這個人,面試過程中對於很多問題都有深入地討論,對於我問的問題他們往往也能給出很好很真誠的答案。
不過他們的面試過程也是最累的,電面是一小時的 Coding,Onsite 總共有五輪,其中居然有兩輪各 90 分鐘的 Coding!你可以在自己的電腦使用平常的開發環境,並且分享螢幕,題目不是傳統的演算法題,而是要你實作一個小型專案,其中一輪是實作一個小遊戲,另一輪則是實作一個系統,最後要 call Coinbase 的 API,所以對於送出網路請求並且處理 JSON 要有一定的熟悉度才行。整體的面試過程還蠻好玩的,面試官也會幫你,但一輪 90 分鐘真的有點太久。另外有一輪一小時的系統設計,以及各 30 分鐘的行為面試跟 Hiring Manager 面試。總共五輪五小時,中間休息一小時,面完真的氣力放盡了。我對整體的表現還算滿意,沒有一輪有感覺明顯不好,最後順利拿到了 Offer。
#Facebook
雖然 Facebook 都是進去以後再經過 Bootcamp 新生訓練選組,但是應徵的時候就要分不同的 Track,主要的分類有 Product、Infrastructure、Android、iOS 以及 Machine learning,Coding 的部分應該都差不多,而系統設計會根據你選的 Track 而有所不同。recruiter 一直建議我選 Android ,畢竟我的履歷上 Android 還是佔了一大部分,她提到 Facebook 現階段非常缺 Android 的人,不過她也補充說明這不代表面試的標準會比較低就是了。我最後還是堅持選擇面 Infrastructure,這樣對我來說準備起來比較方便,不用再額外花心思準備 Android。
我的 recruiter 覺得我可能也適合面另一個職缺 Production Engineer,於是就介紹了另一個 recruiter 給我,我可以選擇同時面兩個缺,最後如果拿到兩個 Offer 可以到時候再決定。實際聊過以後我還是婉拒了,因為不想花時間準備 Linux System 面試。
我們也聊到了預期的級別,她說以我的經驗我可以選擇面 E5 或 E6,這讓我感到蠻意外的啦,平心而論我認為不管是年資和能力我都還沒有到 Staff Engineer 的水準,不過既然 E6 只比 E5 多一輪系統設計面試,我就大膽地挑戰 E6 了!
Facebook 除了系統設計是一小時以外,其餘的面試都是 45 分鐘,電話面試是一輪 coding,Onsite 總共有五輪,兩輪 coding、兩輪系統設計以及一輪的行為面試。最後 Facebook 給了我 E5 的 Offer,原因是兩輪系統設計一輪還不錯另外一輪普普,沒有達到 E6 的標準。
雖然我最後有拿到 Offer,但我還是必須說 Facebook 的面試體驗蠻差的,面試官給我的感覺是他們不在乎我這個人,只想趕快在有限的時間內盡可能地蒐集一些訊號來判斷我有沒有通過,我並不反對有效率地蒐集一些訊號,但是面試是雙向的,作為應徵者的我們同樣也在面試這間公司,面試時我也在看未來我會不會想要跟這個面試官一起工作?而 Facebook 在我的標準裡顯然是不及格的。當然也有可能是我運氣不好,剛好遇到這樣子的面試官,但這也代表 Facebook 對於面試官的訓練不夠嚴謹,導致素質參差不齊,又或者是面試體驗並不在 Facebook 優先考慮的事情,不管是什麼原因,這都是一個警訊。
這個現象在 Coding 面試尤其明顯,面試官就是在看你能不能在有限的時間快速寫出最佳解。不過我倒是沒想到在行為面試也會遇到一樣的問題,我的面試官就按著他預先準備好的問題一個一個問,大部分的時間他的眼睛都盯著螢幕在做筆記,我實在是不確定他有沒有在聽我說話,有時甚至還會問我剛剛已經回答過的內容。
除此之外,Facebook 要求在 45 分鐘內解出兩道程式題,通常都是 LeetCode 原題並且要求最佳解,即使這種面試或許對我是有利的 (其中一輪我只花了 30 分鐘就寫出兩題的最佳解,然後我們閒聊了 15 分鐘),但我認為這種填鴨式的面試方式完全不能反應一個人的工作表現,這或許可以招到一定聰明程度以上的人,但是他們不一定是個好的工程師或是很好合作的人。我認為維持這種大考式的 Coding 面試也是一種偷懶的表現,但這個面試形式卻會深深地影響招進去的人的類型,是我的話我會盡量避免跟這類型的人合作,因為我認為思考過程跟溝通比你能不能快速寫出最佳解還要重要。
如果這段文字有冒犯到在 Facebook 工作的朋友的話,我在這邊先說聲抱歉,但這確實是我面試完以後真實的感受。
#談薪水
近年來由於 levels.fyi 的關係薪水變得越來越透明,這對求職者來說是個好事,你可以知道某公司的某個級別合理的薪資範圍在哪裡。如果你對談薪水這個主題有興趣的話,可以參考這兩篇經典文章:
1. Ten Rules for Negotiating a Job Offer https://haseebq.com/my-ten-rules-for-negotiating-a-job-offer/
2. How Not to Bomb Your Offer Negotiation https://haseebq.com/how-not-to-bomb-your-offer-negotiation/
我自己談薪水的策略沒有那兩篇文章寫得那麼複雜,我認為最重要的原則是誠實,不要假裝你拿到其他公司的 Offer,也不要虛報你其他 Offer 的數字 (即便這個數字是合理的),你可以選擇性揭露你的資訊,對方問到你不想揭露的資訊時,你可以禮貌地說你不方便透露,但絕對不要說謊。
公司在給你 Offer 的時候會考慮到很多因素:年資、面試表現、現在的薪水以及職等、其他公司 Offer 以及其他的面試者等等。這其中大部分資訊我們是不會知道的,比如說每個因素佔的比重、總共有多少面試者、我們在所有面試者裡面的表現如何,而且年資跟面試表現基本上已經確定了,所以實際上你能夠用的資訊就是其他公司的 Offer 或是你現在的薪水以及職等 (當然是要比較高才有用)。
當然最有用的談判手段,就是你拒絕掉這個 Offer 也沒關係。公司招人需要成本,從一開始收履歷、電話面試到 Onsite 面試,他們已經在你身上花了這麼多時間,也給你 Offer 了,所以在這個階段公司也很希望你能加入,除非這是你夢想中的公司,你很怕談薪水所帶來的風險,不然一般來說求職者在這個階段是有比較大的話語權。
另一個建議是請把 recruiter 當成你的夥伴,通常他們是要看業績給獎金的,所以她是跟你站在同一陣線,要幫助你跟公司談出更好的薪水說服你加入。Facebook 的 recruiter 這方面做得很好,她很多資訊都很透明地分享給我,包含這個級別可以拿到最好的 Offer 以及我的面試表現,一開始給我初始 Offer 的時候還告訴我這只是標準包裹,她不預期我會接,整個很 Real!後來給我的 Offer 也比原來的高出了不少,並且我如果下定決心要加入 Facebook 的話,她可以幫我要到這個級別的頂包。
Robinhood 也對我蠻有誠意的,在過程中不斷溝通,安排我跟主管以及同事聊天,有必要的話還可以讓我跟上面的 VP 聊聊,解答我對於 Robinhood 所有的疑惑。後來在得知我有 Facebook 跟 Coinbase 的 Offer 以後,給了一個很有誠意而且超過 Facebook 的 Offer,真的是受寵若驚。Coinbase 給的 Offer 相對前兩家低了不少,而且往上談的空間不高,他們給的理由是他們現在使用的估值是兩年前募資的數字,所以實際上的股票價值遠高於那個數字,而且他們 Refresh 也會給的比較大方,讓你在四年以後薪水不會降。
#最後的決定
我在選擇公司時,通常會考慮三個點,第一個是這個職位本身,我在什麼組、負責的產品、使用的技術、發展的機會以及同事跟主管的做事風格等等,盡可能知道每天工作的樣貌,判斷自己未來的開心程度。第二個是關於公司,我會問自己兩個問題:
1. 公司的文化跟價值我是否認同?人生很短,千萬不要浪費時間在幫跟自己核心價值不合的公司賣命。
2. 我是否相信公司所描述的願景,公司在未來的 5 ~ 10 年內能持續成長並且有好的發展嗎?
第三個是薪資結構,包含了底薪、股票、簽約金、獎金以及 Refresh 等等,來預期未來幾年的薪資。
除了以上三點以外,還得考量到現在都是遠距上工,跟同事以及主管建立感情也相對比較困難,所以在新公司的適應難易度也得列入考慮。在綜合考量之下,我這次還是選擇先留在 Square,或許明年再看看有沒有更好的機會!
如果這篇文章有幫助到你,歡迎按讚拍手,有任何問題也可以在底下留言,或是私訊給我們也行!
軟體 工程師 面試心得 分享 在 Untyped 對啊我是工程師 Youtube 的最佳解答
拖了三個月的軟體工程師面試SOP在此獻上!把面試當作刷題的我,把面試經驗技巧,努力濃縮再濃縮,還是有15分鐘的精華,只要五步驟,面試照著做,保證你 ace the coding interview like a PRO (most of the time).
這集會聊到...
💬 Overview 💬
💙 什麼是 coding interview? 1:20
💙 面試必備 - 比履歷還重要的東西 3:44
💙 面試流程 1 - 聽問題問問題 4:15
💙 面試流程 2 - 如何分析問題 6:00
💙 面試流程 3 - 如何寫程式碼 8:45
💙 面試流程 4 - 測試程式碼 10:10
💙 面試流程 5 - 再問更多問題 12:08
💙 面試流程 0 - 寒暄問暖不囉唆 13:30
🙌🏻 面試好書推薦 🙌🏻
👍🏻 準備軟體工程師面試必備書
Cracking the Coding Interview 提升程式設計師的面試力 https://shp.ee/y7rbjqk
https://www.books.com.tw/products/0010881287
👍🏻 當畫家遇上演算法 看圖學演算法
Grokking Algorithms 白話演算法!培養程式設計的邏輯思考
https://shp.ee/k3jtmvg
👍🏻 置入生活中的演算法
Algorithms to Live By: The Computer Science of Human Decisions 決斷的演算:預測、分析與好決定的11堂邏輯課
https://shp.ee/rvvh89e
https://www.books.com.tw/products/0010761815
👍🏻 Logitech 羅技 MX Keys 無線鍵盤 https://shp.ee/ptt9wtm
👍🏻 Logitech 羅技 MX Master 3 無線藍牙滑鼠 https://shp.ee/pu9qtcc
👍🏻 Backbone 人體工學椅 https://shp.ee/fgi35c9
👍🏻 Tresanti 電動升降桌 https://shp.ee/9wmht7r
👍🏻 logitech 羅技 StreamCam https://shp.ee/fbvgbvc
👍🏻 RODE Lavalier GO 領夾式 小型麥克風 https://shp.ee/nx6w9vc
📢 📣 📢 本頻道影片內容有輸出成 podcast 📢 📣 📢
可以在各大podcast平台搜尋「Untyped 對啊我是工程師」
請大家多多支持呀!!🙏🏻💁🏻♀️
#面試SOP #工程師求職 #面試流程大剖析
一定要看到影片最後面並且在「YouTube影片下方」按讚留言訂閱分享唷!
【愛屋及烏】
YouTube 👉 https://www.youtube.com/c/Untyped對啊我是工程師
Podcast 👉 https://open.spotify.com/show/3L5GRMXmq1MRsliQt43oi2?si=3zgvfHlETeuGfp9rIvwTdw
Facebook 臉書粉專 👉 https://www.facebook.com/untyped/
Instagram 👉 https://www.instagram.com/untypedcoding/
合作邀約 👉 untypedcoding@gmail.com
-
Untyped 對啊我是工程師 - There are so many data types in the world of computer science, so are the people who write the code. We aim to UNTYPE the stereotype of engineers and of how coding is only for a certain type of people.
凱心琳: 一個喜歡電腦科學邏輯推理,在科技圈努力為性別平等奮鬥的工程師。
【Disclaimer 聲明】
Some links are affiliated.
上面有些連結是回饋連結,如果你透過這些連結購買商品,我可以得到一些小獎勵,但不會影響到你購買的價格,甚至會是更低的價格!謝謝你的支持💕

軟體 工程師 面試心得 分享 在 在地上滾的工程師 Nic Youtube 的精選貼文
經常面試是學習及瞭解自己價值的捷徑,然而這些面試的所累積的經驗,直到我換了一個視角
成為了軟體工程師的面試官時,才發現面試大概十分鐘左右,基本上就會決定這個求職者有沒有下一步了
這支影片和你分享我成為面試官之後,一路找人的心得以及如何讓自己成為更好的面試官
因為每個人想法不同,每間公司的團隊文化和做法也不同,有些我在乎的點不一定是其他面試官也在乎的,但主要的關鍵核心不會偏離一個好的面試者應該如何表現
影片章節:
00:00 成為面試官後
01:23 什麼樣的求職者會被拒絕
02:01 履歷或對話沒有線頭
05:22 對徵才方的公司一無所知
06:45 只在乎自己能拿到什麼
07:21 總是沒有問題
11:08 成為好的面試官
12:31 先看履歷
13:00 先看專案
13:19 針對專案可以討論的點
13:29 設計面試題
13:49 討論人格特質
14:00 三明治鼓勵法
15:03 總結
影片中提到:
履歷撰寫文章: https://blog.niclin.tw/categories/%e5%b1%a5%e6%ad%b7%e6%92%b0%e5%af%ab/
從被問到問人,那些我常問的面試問題
https://blog.niclin.tw/2020/01/07/interview-tips/
喜歡影片的話!可以幫忙點個喜歡以及分享、訂閱唷!😘
━━━━━━━━━━━━━━━━
🎬 觀看我的生活廢片頻道: https://bit.ly/2Ldfp1B
⭐ instagram (生活日常): https://www.instagram.com/niclin_tw/
⭐ Facebook (資訊分享): https://www.facebook.com/niclin.dev
⭐ Blog (技術筆記): https://blog.niclin.tw
⭐ Linkedin (個人履歷): https://www.linkedin.com/in/nic-lin
⭐ 蝦皮賣場: https://shopee.tw/bboyceo
⭐ Github: https://github.com/niclin
⭐ Podcast: https://anchor.fm/niclin
━━━━━━━━━━━━━━━━
✉️ 合作邀約信箱: niclin0226@gmail.com
#面試 #工程師 #前端 #後端

軟體 工程師 面試心得 分享 在 0到100的軟體工程師面試之路- 科技業板 - Dcard 的推薦與評價
... 不過也是參考- 軟體工程師,面試,刷題,leetcode,面試心得. ... 各種會遇到的情境/問題和心路歷程經驗,以及那些在網路上會查到的文章分享(是一 ... ... <看更多>
軟體 工程師 面試心得 分享 在 軟體工程師面試20家公司的心得(2)準備篇 - YouTube 的推薦與評價

我當時看的 面試 資源:https://docs.google.com/document/d/111Z2Nmsiv24FBX7e9eoWzyUIejKK1SpllIHzYzrxe0k/edit?usp=sharingFollow我的telegram以即時 ... ... <看更多>
軟體 工程師 面試心得 分享 在 [心得] 2023 軟體工程師(後端)面試分享- 看板Soft_Job 的推薦與評價
各位安安,這邊想簡單分享一下我 2023 年中旬(上週 ~ 昨天)的面試經驗。
先自我介紹一下,本人是某廣告相關公司的 Software Engineer, Backend,同時也是本次分享技術面試的主持人。
鑑於版上幾乎都是求職者進行分享,所以本次在主管(老闆)的授權下以面試主持人的角度進行分享,還請各方先進不吝指教。
本公司主要想找 PHP/Laravel Backend Engineer,如果有其它語言的經驗也願意學習 Laravel 的人也非常歡迎(受限於目前公司的人力資源,還無法擅自變更使用的框架與語言,但這是未來很重要的里程碑之一)
註:為避免有偷渡徵才訊息的疑慮,本篇文章不會直接寫出公司名稱,如果有興趣的話歡迎私信詢問
註2:本公司仍然有在徵才哦,如果你看到這篇文章覺得想來當我的同事可以來投看看 XDD
===
流程介紹
本公司技術面試為第二輪(第一輪我不會參與,這邊也無法分享相關經驗),表訂時間約在 1 小時(但如果想跟我聊多一些,可以到 2 小時甚至以上,目前最高記錄是 3.5 小時)。
1. 雙方自我介紹
基於禮貌,我會盡量期許自己先開口自我介紹,但最近還在習慣這件事所以有時候還是麻煩對方先行自我介紹,也感謝近期應徵者的海涵。
2. 面試偏好詢問
參考一些面試經驗,有些人不喜歡考卷、白板題或 assignment 等各種類別,所以我會先行詢問對方的面試偏好。
以下選項擇一或全選皆可,但選擇越多可能會延伸面試時間;選擇的項目並不會影響到評估的結果,因為會以各項分數平均計算(我會私心對一些有利於應徵者的項目做加權,不過也不是只有我決定)。
(1) 白板題:演算法,不能用 ChatGPT(或其它 AI 輔助) 但可以查文件
(2) 實作題:程式能力,能用 ChatGPT 也可以查文件
(3) 架構題:Senior 獨有,能用 ChatGPT
(4) 問答題:基礎知識,不能使用 ChatGPT 也不能查文件
(5) Assignment:指定一個 Open Source Repository,請你發一個 Pull Request(我會實際去看你的變更內容跟 commit message 以及跟 maintainer 的應對)
- 這部份會以自願為優先,如果覺得真的很不想做或不知道從何下手的話也可以放棄(不計分)
利益申告:所有的問題與公司現行產品都盡量無關,這是為了避免有白嫖應徵者思路的嫌疑;而 Assignment 的選擇也會盡量挑選有一定用戶基礎的 Repository。
3. 詢問想要面試的難度
目前有開放的職位有兩個:
(1) Mid ~ Senior:能夠考量系統架構並定義良好的 Interface,並且能跟架構師討論未來的一些技術選型
(2) Junior ~ Mid:實作一些 CRUD API,以及實作一些 Senior 工程師定義好的 interfaces
如果不知道怎麼選擇也沒關係,我可以根據應徵者的實力自動調整問題的難度。
=====
聊天題(為了更瞭解對方,並核對履歷內容,不列入計分)
1. 最近看了哪些值得一提的資訊領域的內容,包括但不限於文章、影片、漫畫、meme、新聞、論文等
2. 擅長的工具與程式語言(用於確認履歷中的敘述)
=====
白板題
給定一個二維陣列代表圍棋棋盤
- 1 代表黑子
- 2 代表白子
- N (null) 代表未落子
若棋盤一定是理想的(定義下述),那白棋會被提多少子、黑棋會被提多少子?
舉例:
N 1
1 2
(1,1) 白子會被提子
舉例:
N 1 1 1 N
1 2 2 2 1
2 1 1 N 2
1 1 2 2 1
(0,2) 的白子會被提子
(4,3) 的黑子會被提子
「理想的」棋盤表示不會存在「打劫」的問題,舉例來說下述棋盤結果是不會出現的,因為中間的白子與黑子會互相提子
N 1 2 N
1 2 1 2
N 1 2 N
備註:
這一題的來源是我曾經出給一個學生的作業,他是非本科轉職前端,我本來只是想請他用 HTML + CSS 寫個圍棋棋盤,並且用 JS 實現落子邏輯,結果他連提子邏輯都一併寫出來了。當時他是自行實現了 DFS 去計算棋子是否還活著(圍棋術語是「有氣」)。
題外話,前陣子跟這學生吃飯的時候他提到公司在做某個功能,他自行研發了一個資料結構來解決這個問題,我一看就說「你這不是自行實現了字典樹(Trie)嗎?!」,不得不說他真的是一個天賦異秉的人,怪我能力不夠沒能教好他。
(小聲)打色碼眼睛快脫窗 = =
=====
實作題
下列 PHP 程式碼存在一些問題,請嘗試指出這些問題並且重構它。
註:下述程式隱藏了一些不重要的細節(例如資料庫連線、失敗處理等),回答時也可以隱藏實作細節(不一定要精準的使用所有的函式)
<?php
extract($_POST);
$db = new DB(); // connect to DB
$user = $db->query("SELECT * FROM users WHERE username = $username AND password = $password"); // query from DB
echo $user ? 'Login Success' : 'Login Failed';
這一題其實是互動題,因為實作題可以使用 ChatGPT 所以我更期望應徵者能跟我說明「為什麼它要這樣改」。
而且就我實測 ChatGPT 會唬爛所以不能全信(我認為分辨 ChatGPT 是不是在唬爛也是很重要的能力)。
=====
問答題
這部份不開放使用 ChatGPT,因為這些題目都是屬於基礎知識,如果開放使用 ChatGPT 幾乎都會被秒殺。
然而,我們後續內部檢討認為應該要開放可查詢 Google,畢竟有些東西是真的不會背在腦子裡(雖然我是都有大概記著,但每個人習慣不同不能一概而論),如果版友們有任何想法也歡迎回饋,我們會盡可能改善我們的流程。
1. PHP 相關
(1) PHP 的執行與啟動流程?[中級]:主要指的是它在 PHP Source Code 層級的執行流程,不僅僅是在外部觀察到的結果
2. Redis 相關
(1) 單 Redis Instance 可能會當機或因為網路問題無法存取,有什麼解決方案?[初級]:這應該算是八股題
(2) Redis 的 "字串" 是如何實現的,有沒有什麼值得一提的陷阱或細節?[中級]:這個是 Redis Source Code 的入門題,畢竟甚至有一個專門的網頁來介紹 SDS
3. 作業系統相關
(1) Thread 跟 Process 有什麼差別?[初級]:這個也是八股題,問到爛的那種
註:其實作業系統相關還有不少題目,但鑑於重複利用性我就先不公開(這些題目都沒用到,因為我評估對方可能對作業系統沒這麼熟)
4. 資料庫相關
(1) 請簡述一下 MySQL InnoDB 的資料寫入流程。[中級]:這可能是比較有爭議的題目,因為不能查資料,如果沒有相關的經驗很難背起來
(2) 為什麼大部份的 RDBMS 會選擇 B+ Tree 作為其底層的資料結構?[中級]
(2.1) 有個應徵者說因為 B+ Tree 有自平衡的特性,所以我又加問了「那為什麼不使用 RBTree 或 AVLTree?」[中級]
(2.2) B Tree 跟 B+ Tree 又有什麼差異呢?[中級]
(2.3) 近年來,LSM-Tree 相當盛行,能聊聊它與 B+ Tree 的差異嗎,以及你認為為什麼它會流行起來?[中高級]
(3) 請簡單描述一下 CAP 理論。[初級]
(3.1) 因為有一個應徵者有 MongoDB 的經驗,所以我又加問了「那 MongoDB 叢集是犧牲了 CA 的哪個點來達到 P 的?」[中級]
5. 虛擬化/容器化
(1) 請簡述一下 Virtualization 與 Containerization 的差異。[初級]
(2) 在 Linux 中,是如何達成 Containerization 的?[中級]
(3) 假設想讓 PHP-FPM 與 Nginx 的應用程式 Containerize,會如何實踐?[初級]
(3.1) 假設再加上 Laravel Queue Worker 及 Cronjob Scheduler,又會如何設計?[中級]
註:這題是因為去翻應徵者的 GitHub 發現他有類似的經驗,所以另外加上去的
=====
架構題
這部份有些難以說明,因為更著重的是互動性(根據對方的回答去反問一些問題),這邊先省略
=====
Assignment
目前還沒有人選過這個項目,看來大家是真的很不喜歡 Assignment。
以前我比較喜歡 Assignment 的時代有出過一些簡單的(?)題目,例如用 Laravel 實現幾個 APIs,但想想這會花費應徵者太多時間這次就不採用這種方式,有興趣的話我要問一下公司能不能授權公開當時的題目。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.226.47.65 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1685626794.A.29B.html
※ 編輯: MoMoShota (36.226.47.65 臺灣), 06/01/2023 21:51:24
上述的題目其實是因為本次的應徵者都是有經驗的(至少都有 3 年以上),所以才會選擇這些題目。
如果是資工本科系畢業的話,其實我就會改問一些必修課上會遇到的問題。
舉例來說:請問 C 語言的 qsort ᄄ蝳〞漁伅■亠曮蚻O如何(可以查 Google)
正確答案是,其實 qsort 並沒有指定要用什麼演算法實作(C 語言規格書說的)
但有一些誤人子弟的網站會斬釘截鐵地說它「一定」是用 Quick Sort(包括我的教授也是這樣),那這表示他可能不習慣於看第一手資料
(小聲)之前我問過 ChatGPT 也是唬爛說是 Quick Sort
關於 Thread 的部份我統一在這邊回覆。
確實,我們的系統目前並沒有在 PHP 上「直接使用」Thread 或 Coroutine 之類的技術。
但是 PHP-fpm 是一個經典的 Parent/Child Process 模型,同時在 Laravel Horizon 也用純 PHP 加 pcntl extension 實作類似的模型。
之前我們團隊在遇到 Laravel Horizon 相關的問題時,如果不理解這種模型實作可能會增加 Debug 的難度。
回到 Thread 的話題,目前我們沒有計畫在 PHP 應用程式上加入任何 Multi-thread 的技術。
誠如版友所述,PHP 在多執行緒的記憶體管理跟控制簡直是災難,而避免災難的方式就是不要用它(?)
近年來因為 Swoole 的出現,讓大家開始思考 PHP 的另一種可能性:Coroutine
然而從我的角度其實我也不是很喜歡 Swoole,一個理由是之前社群的分裂問題,另一個理由是「那我為何不選 Go?」
剛剛有人私信我詢問類似的問題,我直接轉貼我的回覆:
我們知道,PHP 有幾種 SAPI:apache2handler, cli, fpm(這邊僅列舉比較常見的,其實還有很多)
我在這題會期待得到的回應是:當我們啟動 php-fpm 程式(你可以想成直接執行它的執行檔)時,PHP 實際上會做哪些事?
像是 php-fpm 是一個經典的 Parent/Child Process 模型,它會去 fork 出很多的 Child Processes,而實際處理請求的是這些 Child Process(Parent Process 主要是用來監測這些 Child Process 是不是「還活著」)
然後,當我們收到來自 Web Server 的請求時,PHP-fpm 的 Child Processes 又是怎麼去服務這些請求的呢?
我會很樂意看到有人從 source code 的角度去剖析這件事,但我老實說這非常罕見
所以其實只要能夠從外部表現的行為(例如我們可以觀察到出現 Parent/Child Processes),然後結合一些自己的經驗或知識講述它設計的理由,其實在面試就算是過關了
ps. 如果他要講 apache2handler 也是可以的,不一定只能講 php-fpm
ps2. 當然,如果對方要講得很深我也是可以一起聊聊的,雖然我研究 PHP Source Code 是 PHP 7 的時代的事了,但現在有些知識應該是通用的(如果被指出有誤的話,還可以順便學習 XD)
※ 編輯: MoMoShota (36.226.47.65 臺灣), 06/02/2023 03:46:08
php pthread extension 已經在 2019 年初宣告停止維護:https://github.com/krakjoe/pthreads/issues/929
原作者表示在 PHP 8+ 應該使用 parallel 取代之(它們互不相容、也不會相容):https://github.com/krakjoe/parallel
另一方面,pthread 或 parallel 都需要 enable ZTS,而在我的印象中在大部份的發行版這都是預設不啟用,顯見它在社群中並不是一個常用功能
綜上所述,大部份的開發者會誤認為「PHP 沒有 multi-threading」是可以理解的
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/02/2023 04:52:39
我滿認同這位版友的說法的,實際上也曾經有面試者回問我們「問這些內容,實際工作上真的用得到嗎?」
其實這些問答題大多是基於團隊或個人的開發經驗總結出來的一些精華,而不僅僅是抄襲一些中國所謂的「面經」
就拿 GC 的部份來說好了,曾經我們團隊發現大概每幾個小時應用程式會出現較高比例的 HTTP 500
經過分析,當時的應用程式 memory usage 會緩慢遞增,並在某個隨機的時間段突然下滑,而下滑當下的 HTTP 500 機率較其它時間高出幾個百分點
我們推測這是因為 PHP 在 GC 期間引發的暫停服務現象,我們因此查詢了 php.ini memory_limit 的設定是有問題的,再加上 linux memory overcommit 等設定引發一系列的錯誤
雖然高階語言為我們隱藏了很多底層的細節(這也是高階語言被發明的目的之一),但如果不瞭解這些細節就貿然開發,那某天晚上它們就會叫你起床重睡(?)
事實上,問答題這邊僅列出「基礎題目」,我通常都會根據應徵者的回應再深入去詢問。
這是個很有趣的過程,不僅可以更深入瞭解對方的能力,偶爾也能夠學習到新的知識。
很抱歉,因為 qsort 的那個例子是臨時想的,確實可能不夠周延
這個題目的用意在於:確認應徵者是否會查詢第一手資料,抑或是拿 Google 到的熱門資料搪塞。
正如同我寫 PHP 也是一天到晚在看 PHP 官方手冊(甚至有時候還要去看 PHP source code,因為文件有些細節會省略),而不是直接拿網路上的 Code 複製貼上。
註:在其它程式語言或許直接 copy + paste 可能是可行的,但網路上充斥著各種存在漏洞的 PHP Code(甚至包括 GitHub Copilot 都會出現),如果不經思索就貼上甚至有可能危及系統本身
關於有版友認為題目難度與薪資不成比例的問題,我認為這很值得討論,所以我今天已經將這件事往內部檢討呈報。
剛剛老闆的回覆是其實以前內部就有調整過,但 Cakeresume 上的 JD 一直忘記更新,而且昨天跟我講的數值還是舊的,這邊做一下更正:
Junior - Mid: 840K ~ 1M NTD/year
Mid - Senior: 1.2M ~ 1.8M NTD/year
不過也有可能是因為本篇心得是綜合多位應徵者的題目一次性 PO 上來才讓人產生誤會,事實上不會每一位都被問到所有的題目。
舉例來說:有些非 PHP 背景的應徵者就不會往 PHP 相關的題目去問。因為我認為那只是刁難、不是面試
上面也有提到,我會根據每位應徵者的履歷、GitHub 貢獻、Blog 文章等資訊去設計問答題
註:其實還是有題庫,因為我們資源不夠,真的沒辦法負擔為每一位應徵者重新設計題目的成本
註2:其實我個人非常喜歡暗殺教室殺老師為所有學生個別出一份題目的做法,但現實上我不是黃色的章魚、沒有超音速,我也不是漫畫人物
我也要聲明一下,核薪的部份並非我一人能決定(我僅會提供建議供主管參酌),這邊僅是 PO 出一個範圍,實際上還是會跟據一面、二面的狀況動態調整。
至於具體拿到 Offer 的核薪情況比例我並不是很清楚,但曾經有一個是超過 1.5M (上一版本的核薪上限)的資深工程師,他真的非常優秀且我也向他學習了不少東西
The most important goal of higher education: it was to ensure that graduates can recognize when "someone is talking rot." -- Jeremy Knowles
時至今日,我認為上述這句話的 "someone" 也可以改成 "ChatGPT",因為現在會告訴你假訊息的不是只有長輩、LINE 群或 Google,還多了 ChatGPT。
我一向認為基礎知識是非常重要的,因為它可以讓人在遇到「胡說八道」的時候還能夠分辨的能力,我也在這篇文章中反覆強調「目前的 ChatGPT 是會唬爛人的,所以我想找的是能夠分辨它是不是在唬爛的人」
事實上,在 PTT po 文之前我有先 po 給幾個比較熟識的朋友。
其中問答題的部份被某朋友吐嘈說:你這題目涵蓋了 Backend, DBA 跟 SRE,這在我們公司是各 1.5M 的三個缺
其實我在設計這些題目的時候,原本就沒有預期會有人全部都能對答如流,畢竟:
1. 面試會緊張,大部份人的表現都無法完全發揮(我絕對不會說我之前面試時連陣列的 mergesort 都寫不出來,笑死)
2. 問題的範圍領域很廣,不是每個人都專精每個領域
3. 真的都能夠答得上來的大神級工程師根本就不會選擇我們這種小公司
設計這些題目的用意在於「我大概想知道應徵者對哪些東西熟悉、哪些不熟悉」,這對未來的工作內容安排有很重要的意義(相信我,你絕對不會想讓一個後端工程師去寫前端,大家都痛苦)
欸不是,原來這題目有很卷嗎 XDD
除了我那個比較規格外的轉職學生之外,昨天我把同樣題目丟給今年高二的學生,他大概一小時內就解出來了(Python)
我本來還在想是不是我出得太簡單了說
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/02/2023 20:34:39
認真說,繼續學 Python,千萬不要把路給走窄了。
我希望以下言論不要代表我們公司,僅是 furrymosa 前深夜我個人的抒發
考跟公司無關的白板題:這工作用得到嗎 要下棋嗎
考跟公司有關的實作題:你們公司是不是想要白嫖人家做法?
沒辦法,父子騎驢。
我花費大量心力設計各種題型,就是不想浪費任何一個可能的人才。
我過去非常討厭白板題,我的心態就是:啊工作用又不到,我幹嘛要會?
我也非常歧視刷題仔,覺得 Side Project 跟 Open Source 貢獻才是王道。
就算我自己會把 Leetcode 當成開始吃藥之後取代咖啡的醒腦工具;就算我曾經還有去打過 ACM-ICPC;我仍是討厭白板題的。
我知道自己一定不是寂寞的,有很多人有著亮眼的 Side Project 或是很棒的 Contributor,但就是不會白板題所以無緣大廠。
我希望能以這種形式的面試,讓這些人有一個機會。
我知道自己只是一個人、一間公司,沒辦法撼動整個市場,也沒有那個資本跟什麼韌體廠競爭。
但我期許自己的任何一個行為,都能夠為整個產業帶來哪怕一點點的改變,我有能力做所以我去做。
被問倒真的不是任何應徵者的問題,我希望能夠更跟多有熱情的人一起參與改變--即便它的結局可能不盡人意。
看到鼓勵,其實我還是會開心的;看到批評,我還是會想多多檢討的;即便只是酸民,我也認為這些都是自己進步的可能性。
但我必須說,我沒有自己想像中的這麼堅強。
嘛,感謝版友們在在聽一個老人家深夜嘮叨,如果讓你不開心了衝著我來就好。
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/03/2023 04:11:39
容器化是因為有位應徵者的 GitHub 上有 Nginx + PHP-fpm 相關的實作,但他並沒有遵循最佳實踐
會問這題是想知道當時他是怎麼想的,是不是有什麼額外的考量
那題的背景是,問了 Virtualization 跟 Containerization 的差異之後,有位應徵者講出了 Virtualization 是依賴 KVM 達成(雖然不全對),我就順勢問了一下「那你知道 Containerization 是怎麼達成的嗎?」
雖然他沒能答出來,我認為合情合理。所以我在面試結束前也跟他提了 namespace 跟 cgroup 的概念,跟他說有興趣的話可以查一下相關的資料。
因為應徵者背景各有差異,例如會為具有一些 SRE 背景的人準備伺服器相關的題目;為履歷上寫著「精通」PHP 的人準備底層的問答
再次強調,上面是綜合多位應徵者的考題,不是每個人一進來就從第一題往下問
刷題仔沒錯,每個人都有自己的選擇,也沒有所謂「正確」或「錯誤」的選擇
我個人的偏好不會影響到實際評分的結果,即便我不喜歡白板題,我仍會喜歡將其作為智力測試或腦力激盪,因為這很「有趣」
其實,在本輪面試結束之後,我老闆傳了一篇文章給我
https://www.inside.com.tw/article/4268-coder-hacker-and-architect
他覺得,本次我應該要檢討的是「不是每個人都有志成為 Hacker 或 Geek,大部份的人都只想成為 Coder」
而他們在履歷上寫的「精通」也只是指 Coder 的精通,跟我的定義是有點差距的。
我不能透露太多關於應徵者的事,但其實這次過程中有一位讓我非常期待:
1. 資工本科系畢業
2. 有社群參與,跟我一樣是 SITCON
3. 豐富(多年)的 PHP 工作經驗
4. 自願挑戰比較難的考題
5. (他應該不知道)他曾經兩次從我手上搶走 Offer
雖然最後的結果有點不盡如人意,但我認為只是因為我們領域不同而有所歧異,他仍是很優秀的開發者這點無庸置疑
為什麼我會期待對方 Not only Coder?因為有一個能與人分享、共同學習、保有熱忱的夥伴,是人生中很棒的經驗。
我曾經在上一份工作,又或是大學時在資訊社群中有類似的感覺,而我很喜歡也很嚮往這種感覺。
向錢看齊並沒有什麼錯,認為工作只要完成就好也是一種選擇。
畢竟有人有家累、長輩與子女的期待,但如果可以選擇的話我還是想找個 Hacker 或 Geek 一起創造。
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/03/2023 11:46:09
那大概就是沒給到 PHP 業界前 5% 才會被批評吧 XD
我自己也是會自嘲「活該 PHP 薪水低」的那種鄙視鍊的一員,但這不應該是常態現象。
我永遠也不會忘記有個遊戲業的朋友在爆肝數十小時之後,問我薪水那種驚恐的神情(我當時也才 65k/月)
如果可以的話,我當然希望所有專業人士都能夠領到合理的報酬
但現實世界不是童話故事,也不是動漫,不公平比比皆是,我能做的只有盡量彌平這種不公平(或是去加劇這種不公平)
我年少輕狂時有想過創業做遊戲,當時跟幾個繪師(兼其它公司的遊戲美術)聊這件事,他問說:
「你覺得一個遊戲美術應該月薪多少」
『至少也要 60k/月 吧?』
「你創業之後請務必第一個找我,拜託。」
時至今日,他見到我還會開玩笑地問說什麼時候要創業。只不過,實際見過遊戲業出來的人(前公司 PM)之後,我只能說
我又不是礦裡有家,創個屁業。
我其實也做過一段時間的韌體開發,但我老實說我就對那個領域提不起熱情,所以我成為 web 仔。
我能理解你的想法,畢竟我大學教授有一模一樣的思維:
「前陣子,一個你們畢業的學長回來找我,我問他在做什麼工作。」
「你知道他回什麼嗎?他說他在寫 Web!」
「我就問他說『你是怎麼淪落到這種地步的?』」
以當時來看,web 雖然有很多機會,但薪資相對少(其實現在好像也一樣)
而且當時的 web 技術還沒有現在這麼百花齊放,教授會有這種觀念也不是不能理解
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/03/2023 12:08:07
我也覺得他是對的。
學學某大型 B2C 電商,筆試考卷發一發就好,反正都有標準答案,就算現在還在考 PHP 5 的東西也沒差;
學學一線大廠,白板題直接往上丟,反正 Leetcode 說多難就多難,也不用在那邊自己煩惱這題會不會太難;
反正有熱情的人進來還是有熱情
想跟 Hacker 或 Geek 共事,等他進來再確認也不遲
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/03/2023 12:20:34
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/03/2023 12:50:05
嘛,還是很感謝我朋友幫我 po 過去啦,不過他好像 po 到自己在那邊森77。
他幫我說話我是很開心啦,但他做人跟講話就比較機車(他自己說的,非詆毀),大家就不要太在意了
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/03/2023 13:12:32
別提了,剛剛他還 7pupu 跑來跟我說歧視啥的 XDDD
其實我們是有架構題的,for senior only,因為我對該職位的需求是「要能夠與架構師討論技術選型,並定義合適的 Interface」
本次有兩題架構題,但我覺得以 PTT 這類文字載體真的很難呈現那個互動感,不過既然有人提了我就稍微說一下,反正這些題目大概不會重複使用
1. Web 版簡訊實聯制服務
題目:
1. 共需要有 2 個 APIs:
(1) 讓商家可以發行商店代碼(需輸入店家地址或經緯度資訊,回傳一個不重複的商店代碼,一個 15 碼的純數字字串)
(2) 讓民眾可以傳送疫調資訊(需輸入一個字串,表示簡訊內容,「可能」存在商店代號,不會回傳或回傳 204)
注意事項:
1. 總商家數量約為數百萬,小於 1000 萬
2. 民眾每天會產生約 1 億筆資訊,需考量後續分析可行性與儲存成本
我通常會問一些問題,視對方的回答再決定要不要繼續問下去:
1. 你會如何產生商店代碼?
(1) 如果用 DB 的 Auto Increment 的話,會不會有偽造的可能性?
(2) 可以加個檢查碼,這樣對於一些不符檢查碼的請求就可以直接忽略?
(3) 會在哪裡儲存這些商店代碼與位置資訊?
2. 你會如何驗疫調資料的正確性?
(1) 如果沒有商店代號,那表示該請求是非法的,直接忽略
(2) 承 1-2,如果檢查碼不對,可以直接忽略,這樣也不用進 DB/Cache 查它是否存在
(3) 假設檢查碼的演算法被破解了,有沒有什麼好的方式更新演算法,還是直接讓它到 DB/Cache 裡查?
3. 那如何保證可以每天接受 1 億筆的記錄,會選擇什麼儲存方式
(1) 如果需要分析 XXXX,那這種儲存方式是合理的嗎?
(2) 如果需要分析 OOOO,那這種儲存方式是可以接受的嗎?
(3) 假設每天確診人數劇增,依你上述的方法在請求報表的時候會很慢,有什麼因應手段呢?
基本上這種題目題很自由發揮的,如果沒什麼想法也可以問問 ChatGPT(不限制),不過也要思考它回覆的合理性。
為什麼會出這題?
因為公司有某個業務會有大量的短的 HTTP 請求訊息,而且我們需要與 Data Team 合作,定義出他們易於分析的資料結構,並且還要注意是否適合儲存載體。
雖然也考量過會不會有點太過「政治」,但我認為技術是中立的,純做技術探討的話其實沒什麼政治問題。
利申
這題實際上提到的傳送資料方式、儲存方式與分析內容與公司主要業務差距甚大。
※ 編輯: MoMoShota (36.226.34.224 臺灣), 06/03/2023 14:13:45
身為一個近十年的焦慮症與恐慌症病患,不必擔心我有定期服藥與就醫,目前病情也尚未影響到生活與工作。
不過仍然很感謝您的關心。
我個人是不太介意這類言論,但期許您可以在發言時多站在對方的角度想一下,我能接受不代表其它人也可以。
AVL Tree 確實是較罕見的,它比較像是教材中的範例,畢竟它是最早出現的自平衡樹。
該題其實是因為應徵者提出了「自平衡樹」的說法,所以才想說進一步問「為什麼不採用其它的自平衡樹?」
其實這沒有絕對,畢竟每個人的經歷與專業不同。
有些人更熟悉具體業務的 Domain Know-How、設計模式,而有些人則喜歡底層技術,這都沒有對錯。
我時常會告誡自己「要成為一個有十年經驗的資深工程師;而不是有十個一年經驗的資淺工程師」
不過理想豐滿,現實骨感;我覺得自己大概只是個五年經驗的中階工程師吧。
或許我可以聊聊為何我會選擇這間公司。
2017 年左右,我前公司因為一些業務調整的緣故所以我離開了,當時我在求職時的基準就是:年薪至少要大於 1M
我當時面試了很多公司,像是創業家兄弟(生活市集/松果購物)、聯合購物網(好像之後收起來了?)
面試的經歷有好有壞(也有那種我到現在還在嗆他家 CTO 不懂技術的),不過絕大多數公司我都要求要 1M 以上。
只有目前這間公司例外。
當時我很認同它的產品理念與創辦人(目前的老闆)的想法,於是我只為這間開了特例,降了一些標準
其實公司最後也沒讓我失望。
剛入職時,公司還在很初期的階段,還跟別人共用小巨蛋的創業基地辦公室(雖然環境不錯,就是冷氣太冷),那時甚至連獨立的辦公桌都沒有 XD
隨著業務的穩定發展,我們先後搬到了共用辦公室,當時終於有自己的辦公桌了,也不用跟人搶會議室了;
最後,我們現在有一間獨立的辦公室,八樓、視野良好,可以看到台北 101,下班還可以走去吃個五之神再回家,還在捷運站旁邊非常方便。
哦對了,當然最重要的薪水早就遠超過我當時的預期了。
這就是為什麼我喜歡新創,隨時都有挑戰、隨時都有機遇,當然,隨時都有風險。
看著自己的努力發揚光大,具體地感受著自己與公司的進步,這種機遇與經歷絕對是人生中很美妙的一筆。
我承認自己應該是比較幸運的那一批,畢竟不是每一個新創都有這樣順風的經歷,我們「剛好」遇到疫情,又「剛好」業務會因為疫情而增長,又「剛好」遇到有足夠眼光的老闆與能力出眾的同事們。
誠如我一直強調的,不是每個人都有相同的機遇,也不是每個人都願意做出這樣的選擇。
適合我的,不一定適合你。所以我不會、也不可能要求每一個人都應該跟我一樣。
這次的面試型式一直是我想嘗試的方向,說是「對既有面試方式的挑戰」或許有點太自負了,但我真的很想要在尊重雙方的前提下設計一個令雙方都能夠滿意的經驗,所以我在能力允許的範圍下提供了很多選擇。
覺得問答題太難?可以,我們來實作。
覺得實作太無聊?可以,我們來架構。
覺得比較習慣其它公司的做法?可以,我們來白板題。
曾經有應徵者很驚訝,為什麼我們提供這麼多選擇。因為我想尊重每一個應徵者的意願與選擇,我覺得如果我加一點點工作量就可以讓應徵者感到他能夠發揮所長,那也算是值得的。
可能是我見識短淺,但我從畢業到現在幾乎都是遇到那種進門先甩你白板題的公司,其中不乏所謂的「一線大廠」,或許這已成為約定俗成的慣例了吧
還有那種事前從不跟你說要考什麼、要帶什麼,然後一進門就說「蛤?你沒帶筆電哦?」的公司;也有那種白板題考得像是要找人腦 compiler 的公司(但面試者連 C 語言的 sizeof 不是函數都不知道)
不可諱言地,他們(有些)的薪水是真的香,但是對一個你進門就知道面試者沒料的公司,我個人是不能接受:畢竟,面試是雙向的。
我承認,以前我是那種會想辦法說服對方用我的方案的那種人 XD
不過年紀大了之後,我比較傾向讓對方放手去試試看,除非我看出有明顯的問題,不然我不太會阻止他。
舉兩個例子:
1. 同事覺得我們可以在 Laravel 上嘗試用 Pest 框架取代 PHPUnit,當時我覺得這個點子不錯所以讓他放手去改,而直到現在我們公司還是大量用 Pest 框架(寫起來比較不囉嗦)
2. 同事用了原生函式取代我實作的 XML Parser,被我阻止了,因為經過測試它的實作會使用兩倍的記憶體與降低處理速度約 20% ~ 30%
2-1. 他還跑來跟我爭說「原生函式一定比較好」。兄弟,benchmark 就擺在那邊了,你覺得我的實驗有問題你自己設計實驗,不然我就只能阻止他的 PR
2-2. 這個重構是他認為我的實作耗費太多記憶體了,在某個極端情況下會 out of memory,然後他的實作在更多的情況下 out of memory(?)
另一方面,我是很願意培養新人的,我找人來最大的目的是為了把自己給 fire XDD。
之前有個新人(Junior)進來後問我該怎麼快速養成實力,我就把他工作時遇到的盲點分析了一次,認為他的基礎知識不夠紮實(因為是非本科轉職,不能怪他)
當時我就推薦他去看一些資料結構跟作業系統的科普(雖然我更推薦讀教科書,但說真的下班後還要去 K 教科書這種事不太現實),以及一些我覺得還不錯的入門書籍。
通常來說,如果有個人來問我問題,我會先確定他要的是「我認為的解答」還是「思考的方向」
- 如果他要解答,我就跟他講我的思路及我認為要這麼做的理由
- 如果他要思考,我就會給他一些可以嘗試的方向或可以去哪裡找資料
- 如果我也不知道,那我會跟他一起找找看,或是請他實驗看看(甚至是自己接過來做實驗 XD)
確實,雖然不是很頻繁,但有些問題是跨領域且需要各種背景知識才容易解決的。
這也是我對 Senior Engineer 有的期許(雖然看起來 Soft_job 版好像不太崇尚這種想法?)
我覺得,就算是 200+ 也一定會有人有意見。
我的心態就是「對,你說得都對,有能力選擇 200+ 還 2000+ 就不勞您加入我們了」
反正現在勞資雙方就是各自喊價,市場機制下喊得合理的就能找到人。
其實 Soft_job 版算是惠我良多,我已經著手調整目前的題目,目前傾向於降低整體難度與更明確劃分 Junior 與 Senior。
如果未來公司仍授權我將面試題目分享出來,我應該還是會跟版友們分享。
(至於 FB 那邊我應該會阻止我朋友 po 文吧,我是因為對紫色貓貓沒啥好感所以一直沒加入才想說請他幫個忙,然後他自己搞到崩潰笑死)
沒事,技能的培養不會是一瞬間的事。
如果真心喜歡這個領域、這個產業,那進步也只是時間問題。
※ 編輯: MoMoShota (36.226.26.49 臺灣), 06/18/2023 00:30:51
... <看更多>