「屹」：Grindr補考

原本沒那麼快要再挑戰第二次的，但Terry丟給了我Grindr第二波的招募消息

我見獵心喜，剛好也滿了六個月，於是這次我戰戰兢兢地透過LinkedIn直接敲Alex

也就是上次把我刷掉的VP，結果他說「你的狀況比較特殊，我先聯絡你聊聊」

Alex打給我，果然是我聊我EQ的問題 (居然真的記得我，可是不知道該開心還不開心QQ)

最後Alex願意給我再一次機會，這次直接考複試

 

Q: 請實作一個Offline like button的程式，並思考有什麼Edge cases

我腦袋立馬想到兩台手機同一個Like API的conflict問題

思考良久，Alex等不耐煩，說我可以先講想法，看有沒有問題
(要檢討：我一開始就在想edge case)
(肝糖說其實應該先問對方能不能假設這不會發生，先回答最簡單的case，之後再修)

我講了一下，Alex也說好，那我就把它寫成"真實的code" (滿滿的既視感)lex
(這句我有點無法區分到底指pseudo code還是類似leetcode)

一開始我寫了Server class，但因為題目並非像Leetcode，所以我有些地方寫pseudo

Alex看了之後說"這樣會Work嗎..."
(滿滿的既視感，之前就是聽到這句我開始情緒亂掉)
(這一次我深呼吸，要練習不要說服別人而是聽對方說，不要總是想要佔上風)
(肝糖說我太在乎別人質疑才會這樣)

後來問了一下Alex意思，最後我寫了

1. DataProvider
2. ServerCommunicator
3. NotificationCenter
4. UIViewController

(到這個時候我才知道這的確是完整code，只是沒有真的跑起來而已)

然後Alex開始跟我討論edge case

1. 兩個基於同一個timestamp狀態做修改的API，會以較新的API為優先 (server)
2. 如果client短時間發兩個API request，可以用window來解這個問題
3. 兩個API回到client時的race condition：第一次API回來之前，又觸發第二個API

Alex提了dirty bit作法，不在我的思路裡面
我分析一下原因但Alex不想聽這個，後來我直接接受dirty bit作法，這樣溝通比較快
原本要繼續討論怎麼修改dirty bits才能修正race condition
但因為Alex已經是美國半夜12點要睡了，所以變成作業讓我後面再LINE給他

但這變很麻煩，很多演算法用講的容易，用寫的很難
所以我花了一小時跟肝糖討論(中間還爆氣Q_Q 幸好肝糖人很好，連肝糖都說如果面試官知道，我大概又要被刷了)
然後花了好幾個小時做投影片和講解影片，上傳Youtube，後續還修了文字
我LINE完他看過後就讓我進下一關了

Alex給我的comment:
1. 你比較缺乏在邏輯正確性/複雜度/簡單的solution裡找平衡，
   不過這本來就是個須要經驗累積的事。
2. 在做思考時，可能因為急著要回答，所以作的思考不夠全面。
   // 我要練習提問，把我腦袋蹦出的edge case先說出來
3. 在討論時，除了表達自已的想法，
   有時更重要的是了解對方在想什麼及對方想要的是什麼
   (像平常工作和非eng溝通就特別須要這塊)

雖然很直接但這都是真的，只是我很不習慣聽人說缺點而已，唉...
但真的感謝主，透過這個機會，讓我可以面對自己長久以來的問題
不管上與不上，都交給上主帶領