Re: [討論] 軟體工作真的有需要刷題嗎?
小弟在後端與資料領域打滾過幾年,也刷過上百題 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
那遇到這種也只能說運氣不好,這場考試毫無意義
但不代表這整個演算法面試的模式沒有可取之處。
--
推
推
推
推好文
同意
開發需要這些演算法就會去研究,但跟是否要在面試考
是兩回事 。
不過對應不同的場景,可以使用何種演算法倒是不錯的考法
但直接考那些 Pseudo Code,沒什麼意義
知道用什麼來解,對工程師來講就是後續製作的小細節
就資方成本最低的面試的方法 可以吹成這樣也不簡單
那些網路查就有
死背那些 Pseudo Code 沒什麼意義
讓這些有興趣的新手們,多貢獻程式到 github 吧
不就是資方沒能力鑑別人才,才用這樣的方式方便省事,也能
我連two sum是啥都不知道 我好廢
吹成這樣也不簡單了,考oral language你一定上
但是真的人才是不會浪費時間去搞刷題的,賺錢都來不及了
推
推
酸的大概菜雞吧 真的有在面試的就知道
以前都要研讀候選人的履歷針對性問一些問題
刷題就面前上去leetcode挑個題目 看一下各種解答
就跟聯考一樣 大家都標準一致
要一個一個去理解每個高中生的特質成本低呢
還是同一份考卷給大家寫成本低 挑出成績高的容易呢
還是大家都寫同一份考卷 挑出成績高的容易呢
你說的其實沒錯,確實最終是成本問題 我這篇是把"還算有用"的部分提出來講而已 不代表我贊成現在的海量刷題文化 但就面試成本來看 就是我花 30min 能看出上面這些能力 20~30%,其他重要的能力另外找方式考 跟我花 5~10hr 去把上面這些能力都過濾到 70% 很多公司還是寧可選前者,畢竟資深工程師的時間也是很貴的 當然找錯人的成本怎麼算,就看公司的智慧了...
推好文
這篇也太強XD
推
大家有空就多刷題
考試在業界一直都是最簡單的做法,只是有些特質考試考
不出來就是。
刷起來!
同意這篇
不過台灣很多公司考刷題 薪水也不怎麼樣就是了
推
大聯盟的面試 中華職棒的薪水
這篇正解 從面試官的角度來看 就是這麼一回事
台廠很多只是學樣子 考官還不准你和他討論答案
有的還直接開leetcode讓你自己寫 笑死
台廠考leetcode 就跟我文章說那些公司問腦筋急轉彎依樣
推
面試考一堆,薪水也要跟上啊
推
11
推推 謝謝分享
推
但我想說實際工作的場合m需要一直看output修正結果的
場合意外地多呢. 因為很多時候用戶最初給的公式和預期
的結果會有出入. (有時是基於前一個系統的bug)
因為已交上去的報表不能改, 所以如何有效率的能data
map到用戶要求的結果在實際操作也同樣重要. 甚至關係到
專案能不能結尾.
有道理
公司沒時間好好挑人也能被你神話成這樣 你馬好~ lol
誰兩三行會印一次阿 但十行二十行檢查一次不好嗎?
高手一定都是寫完一個project 才print一次
unit test cases 寫完還需要print?
3現在是我的痛點 明知道有錯還是想讓編譯器幫我檢查
寫unit test 跟自己在寫的時候先確認 不衝突吧?
寫完一個project 才print一次 是反串????
強
推好文
刷題的重點不是在記解法吧 如果認真思考收穫其實不少
討論區的神人都能想到令人嘆為觀止的答案
但可惜的是大部分人只為了求職硬記解法
這點說的不錯 討論區很多大神的想法也是幫助開拓思維的寶庫 不過我自己推薦的是 學習通用的思維方式 > 學會精妙神奇的解法 太神的解法,甚至利用語言特性一行解那種,實用度反而更低 除非你是要打比賽衝名次省時間 否則老老實實的用基本功堆砌的解法,才是更有意義的學習
推
推 好文分享
4
我是非本科,以前聽過很多人的說法說刷題甚至資料結構演算法根本只是應付面試用,一點都不重要,進去公司就用不到了 但我必須說這種說法不完全正確。 我在進現在這家公司前,刷了600題,經典的題目大概來回做了10遍 來這家公司後,我接到了一個很複雜的任務,大概是倉儲物料的分派系統,某個物料根據某些邏輯所以被分配到哪個廠區,中間很多特殊需求但我不想講太多 為了讓程式高效能化,我手寫了樹的節點,用BFS和DFS來遍歷(不同用途),節點用priority queue排序,然後也用到deque來資料處理,map就不說了,太常用了10
最近才從刷題苦海中上岸 刷了五百多題後很幸運拿下faang其中一家的offer 我覺得對於我這樣剛畢業沒多久的人而言 有考白板題至少不會在面試時一定輸給多兩年三年經驗的人 (我只有實習跟side project 人家有正職經驗)14
忍不住回應下,有在使用 Homebrew 應該知道這套件管理軟體超級強大 作者 Max Howell 去 Google 面試被問如何反轉 binary tree 這位大神當場掛掉,面試失敗 這種反轉二元樹題目po上ptt還會被鄉民笑,7
單純只回這個 Homebrew 創始人被拒的例子 Max Howell 在事件兩年後有再Po文回應 原文在此: 英文好的同學可以自己去看比較原汁原味 簡單節錄:10
刷題至少可以確保有一定水準的coding能力 也因為刷題滿辛苦的,所以代表這個人可能是個努力的人 像做embedded system相關,跟刷題相關性不大 但是至少有一定水準的coding能力在設計架構跟實作比較不會犯基本錯誤 曾經面過一個說的一嘴的好經驗~ 但是寫個LinkedList都寫不出來1
還是要看在公司做什麼吧 如果是走前端的感覺用到的機會就很小 畢竟前端鮮少的情況需要處理繁雜的資料 接到的資料很多都是後端處理好的 頂多做個排序但也是直接call funtion就解決了7
18年工作經驗 應該不用刷題 就算應徵資深工程師 考coding也只是確定一下你會寫code而已 18年工作經驗的面試 如果是工程師職位 面試會著重在系統設計/架構 管理職位的話 就會著重在更多communication部分 回到你刷題的部分 這時候應該探討的是: 為什麼公司要考刷題?8
我是不知道台灣軟體狀況怎麼樣啦 但在美國不考現場白版題或是現場Coding 你會發現白人和印度人真的很會吹 吹到那種好像 Linux 是他發明的一樣 而且標準很難拿捏 面試官沒有一個行量尺
爆
[心得] Leetcode 刷題解答與 Python 3 小技巧分享嗨,大家週末愉快! 不知道還記不記得之前小弟有分享面試 Google TW SWE 的心得, 最後有提到小弟當初有發願,如果順利進去要把過去寫過題目留存的解答整理分享出來, 最近終於施工完了,提供給有需要的人可以自由取用。 這份解答內涵蓋了 781 題的 Python 3 解法(太早期刷的題目就沒留解法了 QQ),爆
[面試] 2021跳槽面試: Google/Linkedin/Oracle左思右想,身在科技業還是該承擔起分享面試經驗的責任 以下簡短介紹拿到面試途徑, 面試難易度評價及心得 跳槽職位介於SDE mid ~ senior level ------------------------------- Google (Offer)79
[面試] 2020新鮮人面試(MixerBox/Nvidia/AWS/Sho自我介紹: 四大學碩 這篇文章大概分享我今年2月多到現在面試的結果跟心得 但有幾間公司還在等結果 因為疫情影響都沒什麼面試機會 原本想試看看新思的研替 結果連面試機會都沒有40
[心得][美國] 幾年的面試者+面試官經驗鑑於近年來LeetCode刷題被神化,被認為是面試必備 所以我想以5年多以來無論是當面試者還是當面試官的經驗 來分享一下如何準備面試 首先先分享一下我的經歷 我不是什麼強者,沒有參加過ACM競賽,Code jam頂多做兩題26
Re: [討論] 我就問,刷題強者的實務表現?小時候「會考試不代表會做事」 長大後「會面試不代表會做事」 感覺失敗的人總是一百種藉口 這種讓失敗者自慰的言論也常常被吹捧 但事實就是19
[心得] 面試心得之前有發過一篇,後來想說等Amazon面完再一起發 今天終於把Amazon面完了,分享一些心得給大家 背景: 四大CS學碩,目前在MTK做軟韌體 程式能力就一般,跟板上大神比差很多15
Re: [討論] 演算法不強,還有辦法在資工混下去嗎?我覺得啦 刷刷leetcode 刷刷題 應該不需要多強的演算法能力 就跟高中數學一樣 應用而已7
Re: [討論] 我就問,刷題強者的實務表現?不知道您是面試什麼產業、什麼規模的公司、什麼職位 我建議還是講的具體一點,大家比較有討論空間 : 我就不指名道姓了 : 大概是被刷題進去的人佔到主管位, 就我經驗大部分公司,你去面主管位置的職缺