HackMD2021 年「資訊科技產業專案設計」課程第 3 次作業
輝瑞-BNT
Good Parts
interviewer
- 有提到時間複雜度問題
- 有提供 example 說明
Interviewee
- 部分 code 有附上註解，表示程式碼的意思
- 嘗試跑 REACTO 流程
- 在第二題後有在白板上先寫出想法
- 清楚地表示每個迴圈的時間複雜度
待改進
interviewer
- 沒有確認面試者身份
- 4:27: 應該在寫 code 之前確認演算法的複雜度
- 問題只有問時間複雜度沒有更深的追問
- 16:38: 直接跳到下一題
- 19:04:
- 可以問 unordered_map 跟一般的 map 有什麼差異
- 可以詢問為什麼要使用 priority_queue ?
- 23:07:
- 時間複雜度需要在知道解法的時候提出問題，甚至打斷 interviewee 詢問
- 在工作上，如果已經實作完才修改，會需要很高的成本．
- 時間 "有慢到" 的基準是 ?
- 時間複雜度需要在知道解法的時候提出問題，甚至打斷 interviewee 詢問
- 30:42
- 可以請 interviewee 解釋 "裡面乘以外面一定等於 k 值" 這句話的意思
Interviewee
- 0:52-1:48 解釋解法:
- 解說問題時可以在 白板/google doc/線上編輯器 上邊打邊解說想法
- 沒有詢問 interviewer 對於解法的看法
- 說明完解法直接寫 code
- 沒有額外確認範例
- 1:48-4:28 撰寫程式碼:
- 可以採用 pseudo code 的方式或者寫上註解來引導 interviewer 目前寫到哪裡
- 06:19-16:21 延伸題: 解釋解法 and 撰寫程式碼
- 同1的問題
- 不能預期編輯器有 展開 或者 收縮 程式碼的功能
- 當寫到後面覺得疲倦時，或者程式碼變的複雜時，請使用 pseudo code 來做解說，再補上相關程式碼
- 17:22 第二題:
- 假設對方已經知道一些 stdlib( ex: unordered_map, priority_queue)
- 24:48 improvement :
- 應該要把原本的程式碼留下，而不是刪除 : 因為文件可能在之後會被其他工程師 review
一般問題
- 使用 google doc 會讓面試更真實
- 使用 "我們"，面試的人應該要強調 "我"
- interviewer 跟 interviewee 的字需要從頭到尾都顯示在影片上
- 可以直接跳過跑程式碼的階段
- 空間複雜度問題 ?
- 沒有驗證步驟，而是使用 leetcode 的執行
勞孰-Mouse
Good Parts
interviewer
Interviewee
Bad Parts
interviewer
Interviewee
- 0:38: 確認題目時可以使用 白板 或 google doc
- 1:47: 說要舉例結果最後是連解法一起解出，有點不太清楚當時是要做哪一件事情(舉例確認想法? 還是 提出解決方案?)
- 6:33: 第一個解法可以保留，不用擦掉
- 7:20: 可以邊打範例跟流程然後邊解說
- 8:07: 程式碼可以從架構寫起，不用從第一行寫到最後一行
- 12:43: 問題同2
- 13:24: 在說明時間複雜度時，最好也把 pseudo code 打出來，會比較清楚
- 13:41: 不用擦掉任何寫在上面的內容．
- 13:52: interviewer 沒有提出加速的問題，可以先詢問再來決定(增加互動)
- 15:45: 問題同5
一般問題
- 空間複雜度問題 ?
- 沒有驗證步驟
心得:
- 第一題通常會表現不錯，第二題會因為疲倦而開始出現不知所云的情形
- 任何一項解說都 "務必" 要邊寫 doc 邊解說，單靠口語解說很難記得全部內容
- 想辦法用
我取代我們(英文也相同) - 跟 interviewer 需要多點互動，不過因為這樣會拍攝難度，所以會偷懶簡化
- 寫程式要先從 "架構" 寫起，而不是從頭寫起，這點跟一般的 coding 有點不太一樣．需要反覆的練習．
- 以上內容都是 "熟練過" 的結果，對於不熟練或者無解的問題還沒有好的面對方案．
許願池
- 如果遇到題目完全不會寫的該怎麼辦 ?
- 比方說只能寫出最簡單的暴力解，但是後續複雜的問題都無法解
- 會考慮開 system design 問題嗎 ?
