Re: [閒聊] interview 心得

作者: yzugsr (miaout17)   2014-08-02 19:18:24
背景介紹:我是後端工程師,不特別專精資料庫。
目前離職休息三個月,最近比較少碰程式。
未婚妻不是資工人,但她的興趣是逛論壇拿各種題目考我 XD
一早沒睡醒就被她挖起來回答問題
除了1NF一時忘掉精確定義,只能說明正規化的概念
其他應該都自信有答對。
因此,我想以資工系背景來說,如果當初是選擇花些工夫在基本功上,
儘管離開學校幾年後,理論上都還能回答出來,算是很合理跟用心的面試題。
不過,晚上回來看到板上眾多回應,也想分享幾點看法
* 關於很多人覺得像聯考
一言以敝之:我覺得聯考般的筆試與面試有關鍵的差異。
考題是死的,考官是活的。
優秀的考官能從談話中了解對方是死背還是活記。
對方答得極流暢時,有經驗的考官總是能看出對方是死背還是真理解,
或者換個角度問個相關的應用問題,看看對方能不能正確的運用自己知道的概念。
即便對方答不太出來時,考官也可以選擇從旁引導,
看看對方是不是知道概念但一時忘了定義。
以normalization及join為例,
大學時認真修過資料庫(或認真自學)的話都會有個印象。
如果對方第一時間答不出來,但經過引導後可以講出概念,也可能會算是不錯的表現。
反倒是如果面試者的心態停留在面試題只有對與否,只有說對才過關,
這樣才是真正停留在非黑即白的聯考心態。
* 關於很多人覺得台灣業界用不到
DK大的例子大多是DB及資料結構的基礎知識。
如果「台灣業界用不到」指的是:用不到這些底層、基礎、細節的知識與概念。
甚至就連應徵相關工作的人也不需要對其有更扎實地了解,
我覺得這是很堪慮的一件事。
這代表台灣的業界大多數在做一些表淺的軟體工作。
做專案容易流於把現成技術兜一兜
而不去理解底層實作,運用演算法及資料結構上等底層技術改善問題的解法。
別誤會,我不是說表淺的軟體工作不好。
市場上是的確需要這樣的工作,也需要有人具備技術及管理的經驗。
但整個業界都在做表淺工作的話,那就代表我們的業界很缺乏多元性,容易抑制不同方向
的創造能量。
而一個健康的產業是需要有各式各樣的人做各式各樣的工作
但人要正面思考,
所以我想不是台灣業界都不用到啦,至少DK大的公司就有用啊。
* 記起來或查出來?這是一個程度問題
所有工程師都必須承認,我們就是沒辦法記起所有領域內的知識。
但這不代表熟悉並內化領域知識不重要,
儘管還是會忘,真正了解的人其回復速度還是要快得多。
事實上,當你腦海裡這些真正了解的東西越多,
通常就越容易找到貼近本質問題的解法。
寫出來的程式架構也越簡單,需要的程式碼量也越少,
不容出易錯。
(這邊原本想舉個例子來說明,但怕文章太長,我把例子放到下面,
如果有興趣的再看,我想說的結論差不多也如上述了)
==例子分隔線例子分隔線例子分隔線例子分隔線例子分隔線例子分隔線==
在以下的例子中,我預設所謂的記起來,都是真的有一定程度的理解,
不是當成單純背英文單字。
畢竟驗證面試者究竟死背還是活記當然是面試官的責任。
你在線上遊戲「鬼島online中」實作一個「鬼島無雙」的遊戲活動。
在15分鐘活動內,維持每分鐘都有殺人且越久不死的積分排名越高。
超過一分鐘沒殺人或被殺時移出排行榜並積分歸零。
每個玩家隨時可以看到自己前後五名的玩家積分。
(MMORPG通常是分散式系統,但假設「鬼島無雙」由一台server控管
其他server會把擊殺event送到這台server處理)
(這當然不是一個精確的spec,只是粗略的例子)
把每次擊殺記錄放進用資料庫嗎?
但短短15分鐘的活動不需要persistence,用資料庫只是白白增加複雜度。
如果自己寫code處理呢?
回憶自己知道的資料結構
或許可以找出更新排行榜O(N)或O(logN) time complexity的解法
仔細想想或許會靈光一現,LRU Cache和這個問題好像有點像
LRU Cache常用一個linked list+一個hash map實作
鬼島無雙也可以用一個linked list最後一次殺人時間的順序。
再用一個hash map記住玩家ID與資料的對映(含linked list node pointer)。
與LRU Cache不同的是,再多用一個linked list記住排行榜順序。
在這個資料結構下,所有排行榜的更新都可以在constant time完成。
(包含計算排名變動時,有哪些前後五名的玩家需要被通知)
好啦,這個例子可能有bug或不清楚的地方,請不要跟小弟計較 XD
但相信大家應該可以理解我想說什麼。
把一個應用問題(鬼島無雙)化為正規的抽象問題。
思考各種可以應用的資料結構特性、時間空間複雜度是否適合解決這個問題。
試著在記憶中尋找表面毫不相關但本質相似類似的問題(LRU cache)取得靈感。
改變現有的方法以解決自己的應用問題,甚至從頭構思方法。
這些能力都需要充足的基本功,在腦海中搜尋可用的知識。
而不是要用的時候再一一去查。
(至少google「鬼島」「殺人」應該找不到LRU cache啦 XD)
就面試官或公司的角度而言,有時候期望的不只是找到單純能接工作的人
而是潛力十足、有機會青出於藍的人
作者: kkdlin (kkdlin)   2014-08-02 19:26:00
作者: LetDogDay (推動世界讓狗日~~)   2014-08-02 20:58:00
作者: stonehomelaa (清新、健康、專業)   2014-08-02 22:23:00
小錯字 不需要presistance => persistence
作者: lovdkkkk (dk)   2014-08-02 22:35:00
例子的部份我覺得比較像 #1Jt8xivt 的考法OO 問題 -> 可以用 XX, YY + ABC..., 問題 -> 解法這樣不過擅常這種的, 不見得擅常 "XX 跟 YY 的差別" 這種問題(甚至可能反而更不擅常...)"廣、多、實測、活用" 與 "熟記、深入細節"有一定程度上的衝突
作者: chrisyanglom (澎澎)   2014-08-02 22:44:00
推這篇 很多人覺得工作用不到的,或許是真的不需要但也有可能你從來沒有仔細想過是不是可以用到這些東西去改善自己的程式 其他很多領域也是一樣當一個人心存反正用到再去查的時候其實也有可能代表真正要用到的情況他卻沒有想到可以這樣用真正看重的不是一個員工會不會implement某個資料結構而是他是不是能在適當的時機想到要用哪個結構但如果還需要google才知道這些結構是什麼我覺得應該很難自己判斷何時需要用
作者: lovdkkkk (dk)   2014-08-02 22:51:00
我覺得前面講估狗的指的是很細節的部份就是例如排序, 知道有 quick 跟 merge 比較快但是兩者差別不是很清楚這種至少我是這個意思, 之所以提到沒學過去估狗也很快是強調對沒學過的人來說都不難, 學過只是忘記的人回熟更沒問題
作者: chrisyanglom (澎澎)   2014-08-02 23:01:00
所以說有實力的面試官應該要能分辨得出是不是死背的另外如果真的理解的人,面試前花點時間準備一下也不會太麻煩吧,就像我們也要整理履歷自傳一樣如果只知道quick、merge比較快,再問下去卻都不知道反而容易讓人懷疑是用背的,不是嗎?
作者: lovdkkkk (dk)   2014-08-02 23:05:00
嗯嗯, 對, 知道方向的話有複習應該就 ok 才對痾, 不過那是我都沒複習下最記得的事耶 XDD
作者: chrisyanglom (澎澎)   2014-08-02 23:07:00
哈哈,我好像也是,面試突然被問到如果又有點緊張我也不確定是不是能馬上想起來可是話說回來,我認為比我厲害的那些高手我覺得有可能不需要準備也能從容回答,因為他們已經可以運用自如了,就像公車搭久了就不用特別查時刻表所以關鍵還是能不能判斷出是死背還是真的懂XD
作者: pest (這些分鐘妳有沒有想過我?)   2014-08-02 23:14:00
作者: greatroy (沒有暱稱)   2014-08-02 23:24:00
每每看到這類討論,總覺得台灣的軟體業其實是很有希望的但不知為何,我們遇到的國內軟體廠商卻完全不是這麼一回事...一家號稱國內前幾大的軟體公司,卻連支轉檔程式寫了半年到現在都快8個月了,還不時出現問題...希望各位有志之士,有機會的話可以留個名合作,省的老是遇到這種XXX的廠商.
作者: chrisyanglom (澎澎)   2014-08-03 05:24:00
因為大學時認識資工領域最強的幾個朋友幾乎都出國了
作者: michaelz   2014-08-03 19:20:00
這更新得要O(n)吧 constant time應該不行
作者: stonehomelaa (清新、健康、專業)   2014-08-03 22:34:00
資工的強者大多不是出國就是去ic design
作者: bleed1979 (十三)   2014-08-04 03:42:00
map查詢插入時間複雜度。。。 這個map實作是用那種DS?
作者: lovdkkkk (dk)   2014-08-04 08:13:00
這分數怎麼算啊, 看起來規則好像變了 @@變成越接近最後一瞬間殺人的排名越高
作者: FukadaKyoko (小毛哥)   2014-08-04 14:33:00
推 沒用到不代表用不到 只是問題深淺的差異
作者: kimmyariel (Davy)   2014-08-04 23:35:00
推...

Links booklink

Contact Us: admin [ a t ] ucptt.com