若確認自己想去的公司會考 live coding,那總得練習。
就算不會,我個人認為多寫一點也是好事。
筆者剛開始練習的狀況十分慘烈,連最基本的 Easy 程度都常常寫不出來。
恩,這樣的我,或許應該要重新好好學一次資料結構和演算法,但為了趕緊面試,我還是邊寫邊學了。
如果一開始狀況不太優,推薦可以回去慢慢上演算法和資結走穩紮穩打路線。
不然第一次寫題目,先不用要求自己太多。
我自己的要求是這樣依序降低標準:
推薦一些資源,可以稍微翻翻選個順眼的就好,反正重點是要做:
寫得出來只是基本,這裡列下 submit 過後我會做的事情:
這裡不教學,請自行 Google 去複習
同樣都是 O(N) 等級的 code,不同實作方式仍有很大的差異。有些人可以跑 20 ms,有些人寫的要跑 100 ms,所以除了判斷 big O,細節檢討是必須的。
在 Leetcode 上 submit 後會看到 runtime(ms) 和 memory(mb),以及其百分比,
先提醒這不怎麼準,Leetcode 的機器不太穩,有時候多 submit 幾次可能會變慢變快幾十 ms。
我覺得很有參考價值的是 Distribution 的圖,可以獲得的資訊有:
以分布圖的情形配合百分比判斷這題還需不需要多做優化
例如有時候 runtime 剛好落在多數人後面一點點,百分比可能看起來就很慘烈,但這時候可能可以歸咎於機器的誤差。
分布圖前端的人的 code sample
看一下跑比較快的人怎麼寫的、跑比較慢的人又都怎麼寫的?
Solution 官方解有時候可能被鎖起來要付費才能觀看。
大家可能比較喜歡直接去討論區看 optimal solution。
但我覺得需要認真弄懂不同想法怎麼來的,以及不同解法的特點。
是注重時間複雜度?還是空間換時間?有沒有變動原來的 Tree node?
畢竟一個問題丟過來時,會依據狀況有各種不同的需求,符合需求的解法才是真正的 optimal solution。
一開始以弄熟語言特性、語言的 Syntax,以及基礎資料結構的題型為主。
開始熟悉後,或是本來就很熟悉的話,
接著建議不要用題型來分類,而是隨便挑個順眼的題目來做,
真的做不出來就照上面步驟依序降低標準,
要能訓練出看到問題,去分析可能的 approach,並實際寫 code 的能力。
畢竟不管是面試時還是未來實際寫程式,是不會告訴你這次要用 dp 還是 greedy 解的。
我曾經和很多夥伴們一起寫過題目,真的看過不按 run 只按 submit 的人XD
對一開始的我來說,因為程度關係很難自行想到各種 edge cases,
所以蠻常是 submit 後才發現某個 case 過不了,再去做修正。
但每次 submit 失敗,應該要好好在腦袋跑過一次流程,確認自己的邏輯是哪裡有問題,而不是照著那個特例 case 去更改 code。
請參考 Cracking the coding interview 6th Edition p.66 關於 Test 的技巧
大概寫 Leetcode 注意的點就這樣,
比我寫得好的人大有人在,比我懂面試的人大有人在,
有空一定要翻個書爬個文,汲取一下前人智慧。
就算一開始再怎麼菜,只要保持謙遜,
把寫 Leetcode 變成有成就感的事情並持續進步,
時間是最好的投資。
明天進 String~