ref: https://towardsdatascience.com/five-things-i-have-learned-after-solving-500-leetcode-questions-b794c152f7a1
本文是作者敘述自身解決 500 題 leetcode 後的一些想法
對於每個軟體工程師來說，基本上都有聽過 leetcode 這平台，也勢必理解刷題這個行為
Leetcode 中的題目五花八門，大部分都聚焦於資料結構與演算法類別，而這類型的刷題也變得愈來愈普遍廣泛，
不論公司規模與否，很多都會需要透過刷題來進行面試，然而這類型的行為的確也出現了不少討論的聲音
譬如面試者擅長 leetcode 但是這項能力卻沒有辦法反映到日常工作所需要的真正技能上。
不考慮到底 Leetcode 這類型的刷題行為到底好不好，作者列出五個自己刷題完畢後學到的一些心得
1) The importance of Data Structures & Algorithms
2) There is always someone more knowledgeable than you
3) An edge case can ruin your day
4) Hard work beats talent…
5) Planning is an essential part of software development
The importance of Data Structures & Algorithms
Leetcode 本身不是一個資料結構與演算法的教學平台，不過其本身的題目可以幫助你瞭解更多資料結構與演算法使用的場景與使用方式。
作者提到這類型的基本功應該是每個軟體工程師都要有的，特別舉例不久前一篇玩家修改 GTA V 裡面某些資料結構的處理方式，使得整個讀取速度提升70% 的範例來闡述為什麼
需要掌握好資料結構與演算法。
There is always someone more knowledgeable than you
Leetcode 的解題過程中，最大的特點永遠都是留言區，裡面總是會有各種神奇厲害的解法，甚至會出現比官方解答更漂亮的解答方式。
作者自述有很大半的時間其實都是再重新實作這些很棒的解法。
這經驗讓作者體會到，人外有人天外有天，永遠都有比你厲害的人，工作上要盡可能的向那些厲害的人討教與學習，他們花了很多時間與經驗得來的知識都是非常寶貴且難得的，能夠學會就盡量學會。
An edge case can ruin your day
作者認為 Leetcode 的題目都擁有豐富的測試資料，包含了各種極端案例，這也意味刷題的時候如果沒有考慮各種不同情境常常沒有辦法順利通過問題。
這種思考過程的訓練對作者帶來了實質上的幫助，工作上能夠用更嚴謹的思路去思考每個撰寫的程式，思考有沒有可能有任何遺漏的案例可以在寫程式的過程中就找出來。
Hard work beats talent…
這句話的全文是
Hard works beats talent when talent doesn't work hard.
就算本身不是天選之人，但是透過努力還是有機會在天選之人松懈怠惰之時展現出自己強大與良好的一面。
註: 我想於如果天選之人比你還努力...那就讓天選之人拯救世界吧，我們還是做些簡單的事情就好
Planning is an essential part of software development
從眾多練習與面試的過程中，作者瞭解到 Coding 其實只是解決問題的一小部分，而聽到問題瞬間就馬上開始寫程式非常有可能走冤枉路。
軟體開發過程充滿各種不確定性，很多時候面試時遇到的問題其實都是那種曖昧或是不夠完整的敘述，再沒有掌握問題的全貌前就貿然寫程式常常只會愈走愈糟。
此外，軟體開發除了撰寫程式外，還必須要針對解決方法進行分析，該方法帶來的優點都需要仔細思考，同時也要確保團隊內對於該方法有一致性的同意才可以開始往下去撰寫程式。
作者最後強調，這個概念是真實工作中最重要的一環，透過溝通去理解所有的需求，確保一切都有共識後才開始實作。
剩下有興趣的歡迎閱讀全文
leetcode 刷題 速度 在 Re: [討論] 軟體工作真的有需要刷題嗎? - 看板Soft_Job 的推薦與評價
小弟在後端與資料領域打滾過幾年，也刷過上百題 Leetcode
同意大部分演算法題確實工作上不會用到，但仍然有很多潛在價值存在
就來分享一下我覺得刷題真的"有意義"的那部分好了
1. 工程基本功
例如天字第一題，Two Sum，考得就是一個 Hash Table 的基本概念
也是非常常見的 junior developer 會遇到的場景
例如現在有兩台機器，定期產出 1e6 筆資料量級的 excel 報表
現在要你寫個系統 on-demand 讀取並合併兩張報表後返回給客戶
如果做成 O(N^2) 然後跟主管說他就這麼慢沒辦法
那技術顯然很有問題...
2. 將理論實際應用的能力
例如 Trie 的概念本身不難
但突然碰到沒見過得複雜變化問題
你有辦法馬上反應過來應用上去嗎？
3. Coding 速度與準確度
你有沒有辦法在很短時間，實作一個中等難度的問題，然後一次就 bug free pass
這對應的是你平日工作的開發效率，還有邏輯是否縝密
如果你寫兩三行 code 就要一直 print 看輸出修改邏輯漏洞
代表你對程式操作變數的熟練度不足
當要大量開發一些不太困難的工項時（這是公司常見場景），效率會較低落
而且可能會有潛藏的 bug
甚至 unit test 也幫不了你，因為你根本就沒想到要測試這些 corner case
4. 後端系統設計
要你做資料庫選擇，那最少該對 B+Tree, LSM Tree 等結構有概念
要你做地圖系統，那 Quad-Tree, R-Tree, KD-Tree, Z-Order Indexing 也該能聊聊？
或 Cache 系統最常見的 LRU/LFU cache 選擇
分散式系統最基本的 Consistent Hashing 有哪些應用，好壞是什麼
這類演算法可能實作很複雜導致 Leetcode 不愛考
但 Leetcode 的部分題目也是從這些概念中提煉出來（例如一堆基本 Tree 操作）
足夠小到可以變成一個 10~20min 寫的完的題目
假如你 Leetcode 都寫的出來，想來要理解系統設計真實應用的演算法也不會太困難
5. 靈活思考
這就一些奇怪的觀察力考驗題
看你能不能看穿他轉幾個彎之後，就是某個簡單的演算法概念
跟考益智問題的意思差不多
因為他想找真的很聰明、頭腦很靈活的人
如果聰明人想得出來，大量努力刷題苦練過的普通人也想的出來
那起碼這個篩法有一定機率找到我想要的人，另一些也是肯努力的人
這樣對面試官來說也不錯了
6. 溝通能力
這個應該也被講爛了
很多公司也沒有要你一秒給最佳解（真的題題秒解還會懷疑你是哪邊去偷到題目）
而是要看你一路跟面試官怎樣討論溝通，將答案一步步優化到最佳的整個過程
你刷的題目足夠，思考也會更穩定，討論更聚焦更有方向，對答案更有自信
如果他覺得你是個一起討論研究問題很舒服的人，就有機會給正面評價
我自己就曾在 Appier 面試被丟了一個沒有優於 O(N^2) 還是 O(N^3) 解的問題
（細節部分記憶模糊了... 也可能是沒有 linear time 解）
但他問的一副有的樣子，一直要我再想想
我想了一陣子，還是跟他解釋了幾種不同思路、假設、還有分別會遇到的障礙
然後很有自信的跟他說這確實沒辦法
面試官就很滿意了，說那是他們真實遇到的難題，也確實還找不到辦法，所以跟我聊聊
後來我們又聊了很多有趣的問題，是很棒的面試經驗
假如當時我不夠熟練的話，一定只會一直擔心我哪裡沒想到，做不出來完蛋了死定了
大概就不會有後續了
當然啦，如果碰到不合格的面試官，或考題亂挑一通，那以上情境都不會發生
有些面試官只會背題，甚至自己也不懂
手上有一份答案，你講的跟答案一樣就 pass
你講不一樣但同樣可以過（甚至還更好）的答案，通通都算 fail
那遇到這種也只能說運氣不好，這場考試毫無意義
但不代表這整個演算法面試的模式沒有可取之處。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.240.122.161 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1629026770.A.B4E.html
我這篇是把"還算有用"的部分提出來講而已
不代表我贊成現在的海量刷題文化
但就面試成本來看
就是我花 30min 能看出上面這些能力 20~30%，其他重要的能力另外找方式考
跟我花 5~10hr 去把上面這些能力都過濾到 70%
很多公司還是寧可選前者，畢竟資深工程師的時間也是很貴的
當然找錯人的成本怎麼算，就看公司的智慧了...
討論區很多大神的想法也是幫助開拓思維的寶庫
不過我自己推薦的是 學習通用的思維方式 > 學會精妙神奇的解法
太神的解法，甚至利用語言特性一行解那種，實用度反而更低
除非你是要打比賽衝名次省時間
否則老老實實的用基本功堆砌的解法，才是更有意義的學習
... <看更多>