哈囉~我是林太太🙋🏻
今天想來做個簡單的說明，沒想到這天來得這麼快，本來還想說以下這席話不會有獨立成篇的一天，但既然來了..那就開始吧~
是這樣的..昨晚林先生剪好扭蛋影片時跟我說他要把youtube那邊的留言功能關掉，那邊留言的人不像粉絲頁那麼多熟面孔，我們不會在那邊互動，再來就是他覺得那邊的留言有些講得很難聽...看了心情都不是很好，他講到這裡時其實我很無感，因為在youtube的留言我一則都沒看過，林先生是一個非常樂觀的人，當他會說出什麼東西看了心情不是很好的時候，我想可能真的是講的很誇張了吧，所以睡前我就花了一點時間把所有扭蛋影片底下的留言都看完。
其中一些批評我的聲音做作啊噁心啊~說實在的批評聲音這點我不痛不癢，人的聲音本來就會因為情緒的不同而改變，高興的時候分貝就高了一點，不爽的時候講話就是低沈，我也是這樣~沒什麼好爭誰對誰錯。
再來就是我會想極力反駁的主要點了，就是 我扭蛋到底是花誰的錢!?讓我印象最深刻的一則留言是「林家瑋 你家很有錢吼!林太太花錢不手軟!娶老婆是要賢慧!省錢!娶個會花錢的，整個家都敗光了!可憐!」(我有省略很多佔版面的驚嘆號)，本來我是覺得沒必要公開說明這點..但是下午我就在粉絲頁的訊息裡收到來信詢問我到底是花林先生的錢扭蛋?還是花我自己的錢扭蛋?在這之前我在我的個人頁也收到過這類的來信詢問，時不時的在照片影片底下的留言也是有這種問句，我都回答過..但好像不是每個人都會看到..每次被問我就要重新講一次，不然就會被認為妳就是花老公的錢才可以這麼花錢不眨眼!唉....回答得很累啊~~~為了省去以後這些麻煩問題，我就公開的再講一次，也是最後一次...
我所有個人娛樂購物的花費全部都是自己負責，因為我喜歡花錢花的理直氣壯，我不愛看人臉色過日子，這樣夠清楚了吧~以後再有這些問題一律不回應了。
男女網友的抱怨來信我都收過，男友說他女友看完扭蛋影片就吵著要去扭蛋 男生花費很大..問我為什麼林先生都不會生氣我這樣亂花錢..(因為我花的是自己的錢啊)，女友說她男友看完扭蛋影片就更加嚴管她買玩具 看到喜歡的扭蛋也不能扭..問我為什麼林先生不會生氣我這樣亂花錢(再講一次 因為我花的是自己的錢啊)，我不知道別對情侶夫妻的相處模式是什麼，不過我跟林先生是各自花各自的錢買自己喜歡的東西 不會互相干涉~如果你們想拿我們當榜樣的話，就要先知道真實的我們是怎麼樣，而不是看完扭蛋影片就直接去跟另一半說林先生林太太可以怎樣怎樣為什麼我不行...
還有...其實我在扭蛋上的花費沒有很誇張，我不是天天扭月月扭，扭蛋社團裡全部大收集的人很多~只是因為我們有拍影片..被大家看到了..就覺得我天天都在花大錢扭蛋.....我下午算過了，目前手邊收集的扭蛋總共66顆，是從去年8.9月到現在的累積，算起來我一天花不到20塊在這件事情上讓自己開心..比起一天一包菸或是一天幾杯飲料幾杯酒，我想我不算過分~別再誤會我是不是每個月在扭蛋上面花五六七八千甚至一萬了...我沒在買名牌 沒在迷最新3C 沒在迷吃燕窩魚翅，我就扭個蛋而已...是有什麼好囉唆的。
再來最後一點，林先生可能會因為當時的氣氛講出一些很有效果的話，但不是句句都是真實...我從來沒有真的扭過他的蛋......看到那種留言說先生好可憐~這種老婆好可怕~不帶她去花錢就要扭老公的蛋~這個女人瘋子~要是她是我女友的話我馬上分手~...我真的錯愕原來世界上還是有不會分辨節目效果跟真實性的人，我大可無所謂笑笑就好的不理這些話，但我的親朋好友會怎麼想...明明他們認識的我就不是這樣的人，為什麼要被講成這樣我還默不吭聲!?所以一樣 我就講一次，純屬節目效果~
扭蛋影片的開始很簡單，只是因為我喜歡扭蛋，林先生喜歡紀錄我們的生活小事(我記性很差..萬一有天我老人癡呆或是失憶了，他還有一些以前的片段可以給我看)，影片剪好了我們會放在個人頁跟朋友分享，剛好林先生之前有辦粉絲頁..後來就連這邊也會放，然後就好像會比原先預想的有更多人看到，人一多就沒有那麼單純了....我不希望初衷簡單的事情後來會變這麼複雜...
當然啦~~~我知道喜歡我們的人其實也是有很多~每天收到的正面話語遠遠超越這些莫名其妙錯誤認知所產生的攻擊言論，很感謝口出善言溫暖人心的你們~但我真的是咽不下這口氣的人啦，尤其一想到林先生曾經因為那些話而心情不好我就更不想什麼都不說，連他都可以受影響了，我不得不為其他愛我的人想，我勢必要來把話說清楚，現在也都說清楚了~就以上那樣。
謝謝大家高度耐心的看完，以後不會再有這種長篇文了😂，還是希望我們可以繼續簡單的分享歡樂💖
活著覺得麻煩的人心得 在 [心得] 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
... <看更多>