支付寶這次面試,直接是一波流搞定,沒有HR問為毛辭職,職業規劃之類的問題,都是直接上干貨的,技術.
筆試40分鐘,然后帶上試卷直接去面試,面試時間長短就不清楚了,我大概面了1個小時左右.
筆試:
1. cookie 和 session 的區別
2. JVM 內存模型
3. SQL注入的原理
4. 悲觀鎖 和 樂觀鎖
5. 讀程序,輸出結果. 關于treemap的
6. linux 基礎命令,統計日志中的信息
7. java 分布式集群
8. 一道設計題,具體到數據庫的表.大概是淘寶的搜索中,輸入手機,會出來很多類型,按品牌按價格區間按手機種類.
還有2道題我記不住了.
面試:
1.介紹你做過的項目,用到的技術,涉及到的模塊,然后從項目中問各種技術實現的細節(為了確保你是真的懂了).
2.看你的試卷,喊你講解做題的思路,以及這樣結果的原因.(考的是各位的java基礎知識了,這點是繞不過去的,懂了就懂了啊,只有平時多看書)
3.團購6位驗證碼以及團購成功后,發送到你手機上的條碼的實現方式.(第一個問題我說用隨機數+時間來驗證.第二個問題老實說,我也沒答上來,我說用序列,面試官說序列到后期20位以上的時候,用戶體驗很差的)
4.淘寶上是如何保證庫存和訂單之間的數據準確性的.(CICS Tuxedo，考點是分布式事務,這個問題我也沒答上來,最后他問我有什么問題問他的時候,我就反問的這個問題,面試官人挺好的,給我耐心的講解了一遍淘寶的實現方式以及
epay的實現方式. 淘寶是通過分布式事物,中間用了一個叫協調者角色的程序,當那邊點擊購買時,會庫存減一,保存一條預扣的狀態,但是是個預準備狀態,然后做成功后,協調者會在另一個數據庫生成訂單,然后這個訂單也是預狀態,等兩邊都準備好以后,通知協調者,又協調者統一完成這2個數據庫的事物,從而達到完成一筆交易的目的,若其中一方失敗,則將預扣的數字返回到庫存從而實現類似回滾的操作.)
5.索引的原理.能否構建時間索引.時間索引構建后會存在什么問題.(索引原理我是回答的堆表索引的構建原理以及查詢原理,但是關于時間索引的問題,我也沒回答出個所以然來,看面試官的反饋,好像回答得不夠好吧)
6.你們數據庫的數據量有多大,(回答:我們是電信方面的系統,表上億的數據很正常).問:如果保證效率?
(我是如此回答的,各位自行結合自身的情況參考.答:后臺J OB程序會定期備份,把生產表數據移走,然后備份表也會再備份一次,如此剃度的備份,保證生產庫的數據是最小的.然后備份表采用分區和子分區,加上構建戰略索引(分析系統的sql,常用
查詢字段構建復合索引,以減少每次查詢時對表的訪問次數)).
7.SQL注入的原理以及如何預防,并舉例.(這個相對簡單,網上一搜一大片)
8.使用過Memcache么? 用在項目中哪些地方? (答,在門戶主機上使用,緩存session,分布式的時候,統一訪問這臺主機驗證用戶session是否存在,來維持回話的狀態和實現回話同步.又追問:java代碼中如何實現訪問門戶服務器的這個session池子的? 幾年前的代碼,確實忘記了..于是坦白的說,記不清楚了 )
這些是主要的問題,當你回答一個大問題時中間還有很多比較碎的追問性質的小問題,總體給我的感覺是,氛圍很輕松+愉快的,技術層面上還是需要你真正的理解透徹一些關鍵技術點,才能做到應付各種追問和給出滿意的答案吧.如果只是一知半解想去蒙混過關肯定是不行的,畢竟在支付寶的技術大牛面前,多追問幾句,也就把你逼到死角了.
還有一點比較重要的感覺就是,他們比較在意你是否了解當下的一些比較熱的技術點,比如淘寶的秒殺,是如何保證高并發下的安全性和性能,新浪微博那種大數據量的發送,怎么就保證正確性和時效性的.
自我感覺面試得很一般,估計希望比較小吧,共享這些希望能給各位小伙伴帶來實際上的幫助.