【面試經驗】阿里數據研發工程師實習面試總結

阿里數據研發工程師實習面試總結

 

 2015.3.21

         阿里的實習崗的面試已經進行到第三輪了，若是順利的話，第四輪HR面試經過就能夠去實習了。回想這兩週以來，從忐忑的決定要投簡歷，到作簡歷時各類自卑，到抱着體驗的心態去投遞簡歷，到一輪一輪的面試，無論結果是否經過，都須要總結一下，以明確從此的複習準備方向以及重點。

         3月11日投遞簡歷，週五下午便有杭州的電話打過來，惋惜我去跑步沒接到，因而週末忐忑的準備着，半用心半浮躁的準備着。週一的時候等了一天沒有消息，整我的都煩躁了，因而決定再也不等待，不要太過於指望，因此次日與往常同樣去圖書館看《劍指Offer》。因此，有句話說的真是沒錯，你越是能淡定作本身該作的事，你所期待的事情纔會不經意間發生。週二上午在圖書館的時候接到了阿里的一面電話，本來有點遲疑，感受還有幾個方面沒準備好，可是我等了太長時間了，因而沒想改約時間，當時就接受第一次電話面試了。

　　說說一面。面試的是個男面試官，語言表達各方面都還很清晰。可是我很緊張，幾乎喘不過氣來，開始的一半時間聲音都是顫抖着的。面試官首先讓我自我介紹一下，而後讓我介紹本身的項目經歷。我當時只說了一些跟MapReduce和Spark相關的。而後面試官開始問MapReduce，問MapReduce的特性，適合解決什麼問題。而後他問Spark相對於MapReduce的特色，以及什麼狀況下須要用Spark。

　　以上問題都是概念和特色的簡述型問題，接下來面試官開始問一個具體的場景下的問題解決方案。在得知個人MapReduce學的時間比較長的狀況下，他描述了一個具體場景，問我用MapReduce怎麼作。這個場景是這樣的，淘寶的用戶在登陸後可能會有一系列的網頁查看記錄，如今咱們有這樣一個表，存有用戶ID，用戶訪問時間，當前頁面，跳轉頁面這樣四個字段。要求還原用戶的訪問路徑。我當時緊張的，以最naïve的想法達到，Map什麼都不用作，在reduce的時候獲得同一個用戶的多條記錄，而後根據時間前後還原訪問路徑。後來想一想，這個答案真是欠考慮啊，還好面試官比較Nice，他提醒我說淘寶有不少用戶，並且每一個用戶的訪問記錄成千上萬。因而我想到，我不能把全部的計算邏輯留到reduce裏作，既然訪問路徑是按時間來排序，我何不利用Shuffle中的自動排序，如此這樣須要key中含有時間，可是這樣的話reduce聚合的就不是同一個用戶的全部記錄了，因此想到了定製Partitioner，來作一個trick，讓全部的鍵值對排序時選用帶時間的Key，partition的時候用用戶ID作key。其實這個過程我開始並不那麼清晰，講着講着把本身講明白了，因而跟面試官談到MapReduce的Shuffle原理，他也進一步的要我描述Shuffle的過程，還好我週末準備了這塊，因而還算輕鬆的把Shuffle過程當中的步驟講清楚了。

　　到這裏項目的問題便結束了。面試官下一步問我平時常用的編程語言是什麼，我說是Java，因而他問了幾個Java的問題，哎，這就是我一開始接到電話差點想改約時間的緣由，我沒準備Java面試常問的問題，面試官問的幾個問題我都含含糊糊的答了一下，根本接不下去話。第一個問題是Java的GC原理，我只說是分代GC，含糊的提到新生代老年代，說先是存在某個代裏，存滿了再幹嗎，面試官讓我確認存在哪一個區，我說不記得了，因而這個問題做罷。接下來問我如何定位JVM的性能問題，進一步解釋說怎麼知道是內存不夠仍是怎麼樣，我含糊的提到若是出現OutOfMemory異常的就是內存不夠，應該增大heapsize之類的，這個問題也是含糊做罷。面試完以後回想並在網上查了一下，他多是想問我JVM的性能監測工具的使用，這個部分在《深刻理解JVM》中有，可是我沒有注意過。第三個問題他問我HashMap的實現原理，天啊，我只是記得之前大體看過一篇博客講HashMap的存儲結構，說存儲效率不高，根本不記得了，含糊的說利用hash結構。面試官進一步提醒問我key是什麼，以及若是兩個key的hashcode重複了怎麼辦，我說了線性探測和二次探索，就是沒想起來應該是正確答案的鏈式衝突解決方案。而後出現了一小段空白，面試官說就這些問題了。全程時間27min左右。額，當時好崩潰啊，Java的問題基本都沒答上來，可是過了幾分鐘在阿里招聘網上看進度，竟然經過了，如今想來雖然都沒答上來，可能也粘了一點邊，因此不至於刷掉我。

         總結一下一面，仍是很是刺激的，我聲音基本顫抖着，直到在混亂中理清思緒答完了第一個實際場景題，才漸漸平靜，可是接下來的Java問題真是面的夠差的。還好，一面僥倖經過，接下來等二面，由於聽組裏同窗說過阿里的效率很高，基本一面經過以後次日就會二面，次日下午果真等到了二面。

         二面是三次面試中最輕鬆愉快的一次，面試官很和藹，讓我提一下本身的項目經歷，我也不太緊張，簡要的說了一下用MapReduce Spark HBase來作一些並行優化應用。他對HBase感興趣，好像是直接問了一個實際場景的問題，問的是有一個表存儲用戶信息，購物信息之類的，要統計出該用戶一天的購物信息，大體意思是這樣的。我說的是根據時間戳來實現，先詢問rowkey是什麼，面試官說多是用戶信息什麼的，在於我設計，我就提出了兩個解決途徑，一是把時間信息加到rowkey中，這樣因爲HBase的按照rowkey有序的特性，檢索會快不少；或者兩一個方法就是在時間戳上創建索引。面試官表示我講的沒錯，而後問我除了HBase以外還知不知道其餘的NoSQL數據庫，我說了redis，他問我redis的特性，我簡單說了下它是內存數據庫，也是key-value結構。而後他問我redis的數據分片原理，我說我不清楚redis的底層原理，而後他就問我HBase的分片原理以及副本存儲什麼的，我說了一下是分紅region而後再存入regionserver，副本數是由底層的HDFS來決定的。而後面試官接着問我知不知道mango DB，我說不知道。而後他就說他沒問題了，說接下來還會有一個主管面試和HR面試，經過了就能夠來面試。我還興奮的問了他主管面可能問什麼問題，丫的告訴我會問些宏觀的問題，我覺得不再須要問技術問題了，還覺得本身經過了。

         三面仍是在二面以後的次日，下午正在開會時打過來的，我出去接了下，有點蒙，很緊張。不是說是主管面，主要是聊天聊規劃聊人品的麼，怎麼又是一輪技術面試，並且強度比二面強多了。聽起來，三面這個面試官年紀應該大一點，表達更有一種威勢，因此我被嚇到了，又是聲音顫抖的一面，一直抖個不停，我只好找了個沙發坐下來了，中間好幾回聽不見聲音，到中間我有點不耐煩了，也就開始不怕他了，他沒表達清楚的我就再問。他首先讓我選一個經從來重點說，我有點遲疑，而後他也開始問Spark和MapReduce，讓我用簡單的語言介紹Spark，而後說什麼狀況下須要用Spark。

　　提了一個具體場景問題，讓我用MapReduce解決。場景是現有商品的一系列購買記錄，另有一張表存有商品的類別，現要統計每一個類別商品的成交額。我當時懼怕了，由於聽起來是個錶鏈接的問題，這個地方我在準備的時候沒有重點看，有點後怕，搞了半天，才漸漸在他的提醒下理清思緒。我先說的是Map什麼都不用作，在reduce裏面，以類別ID爲Key獲得全部相同類別的商品，成交額相加，而後把類別表放在DistributedCache中。他確認了一下我說的是把哪一個表放在DistributedCache中，我說商品類別表相對小些，放在DistributedCache中。而後他提醒說Map中什麼都不作麼，說你須要考慮到每一個商品記錄中，有訂單信息，成交日期等等信息，會有成千上萬條記錄，我就順着他說，那Map中須要Combine一下，把局部的類別相同的記錄先累加起來，去掉不要的信息，而後再送給reduce處理。而後他又問到這種問題適不適合用Spark來作，我想都沒想就說不須要，要不他怎麼問我MapReduce怎麼處理呢，哈哈，仔細想一想這類分析工做確實能夠線下來作，不須要Spark來作。

　　接着他問我項目的問題，問的還挺細，我去，這比第一個面試官還難纏。而後又問HBase和MySql的區別。這些問完以後，問了一個算法題，說一個發紅包的問題，若是A給B發了，B給C發了，那麼他們三個均可能有關係，如今給你一系列這樣的記錄，要找出全部沒有關係的人。我去，我當時傻了，想不出什麼算法，什麼思路都沒有，他提醒了一下我仍是無果，他百般安慰我說不必定要什麼算法，就直觀上想到什麼都行，我真是不爭氣啊，主要我老往圖上去想，圖我又學的很差，總覺得是什麼高深的東西，因而我放棄了，說暴力搜索老是能夠找出來的，他也只好做罷。面試事後，我想了想，其實真是不難，我從頭遍歷全部的記錄，把第一條記錄中的兩我的放到一個集合裏，而後再搜索，把全部跟集合中元素有關係的都挪進來，這樣把全部的記錄分紅一個個集合，不一樣集合中的元素就不可能有關係。好吧，不說這個了，當時問完這個問題以後，他好像就沒問其餘的了，問我從此打算作些什麼方向，而後說了些輕鬆的，就結束了。

         今天是3月21日，從3月17日開始面試的，阿里的效率還真是高啊。