1. 程式人生 > >準備了兩個月的阿里面經,寫給初中級Java程式設計師 的BAT 面試寶典

準備了兩個月的阿里面經,寫給初中級Java程式設計師 的BAT 面試寶典

1. 簡介

筆者普通院校畢業,沒有光鮮亮麗的職業背景,憑著自己的激情和兩個月的準備最終拿到京東和阿里巴巴 Offer。下面就是作者此次跳槽經歷所有準備工作和心得,希望對你有幫助,作者工作經驗有限,此文適合少於5年工作經驗者。初次寫作如有不對之處,歡迎批評指正。

本文是作者覆盤自己兩個月的面試經歷,希望通過我的分享,對大家有幫助,祝大家跳槽成功。

2. 克服心理是投簡歷的第一步

第一章是枯燥的心理建設,如果你內心足夠強大,直接略過看下一章。

2.1 擺脫舒適區

筆者妄自揣度讀者的心裡,公司現在經營不景氣、公司沒有發展、公司可能會倒閉、自己的職業生涯沒有規劃、公司現在做的東西和我的理想不一致等各種原因,但卻說服不了處於舒適區的自己走出來。

大多數的我們都是呆在舒適區,在這個區域壓力和變化都很小,讓我們的生活很平靜,同時改變相對就少很多了。在舒適區待久的我們真的很難邁出一步去挑戰自己,因為我們需要再次去學習,去挑戰自己。

離開舒適區就意味著較高的風險和焦慮,它可以導致積極的和消極的結果,然而學習區是真正的 “ 產入 ” 階段。是讓人精力和行為達到最佳狀態的區域,在學習區你會消失因為期待帶來的不安,也不會有每天無所事事,自怨自艾的 “ 工作迷茫 ”,更不會每天晚上感嘆一天又是無所事事。

當你真正挑戰自己時,你所做出的成就會讓人驚歎。正如一句話:“ 你不逼自己,永遠不知道自己有多強。然而要把握好自己的容忍度,如果到了恐慌區不僅工作效率不高,還會失去信心。所以現在的你應該考慮自己是不是那個在舒適區的自己,如果你還想挑戰自己,而不是每天自怨自艾,請行動起來。筆者也是特別不願意投第一封簡歷,也不想去面試,有一天實在忍不下去了,咬著牙投出去第一封,接下來就會投 2,3,4 ...

結語:你不逼自己永遠不知道自己有多強,如果你不想整天自怨自艾,那麼就讓自己行動起來,邁出一步,後面就好走多了。

2.2 地球沒有你一樣可以轉

當然此段落可能說的不是你,之前和好幾個朋友聊過,他們都覺得公司對自己不錯,同事關係很好,而且公司業績正在發展,現在不能沒有我,遲遲不忍心動手。那麼如果你有這種想法你就錯了,地球沒有誰都在轉動,如果你真的覺得自己沒有在成長,那麼果斷的離開,對於你和公司都是一件好事。

對於公司,沒有那麼忠誠的你他們可以找更好的,而且你要知道,一個產品的靈魂其實更多的是 PM 賦予的,我們這種做程式的是這個行業最容易替換的職位,所以公司不會因為一個技術的離開會一蹶不振;對於你,如果你沒有更好的平臺、經歷來武裝自己,時間久了就會和正在成長的公司、朋友們脫節,現在也許你們在一個起跑線,過一段時間,再好的關係也會變得陌路。

結語:地球沒有誰都在轉動,換工作沒有對不起誰,對不起的只是自己,只有自己才能為自己買單。

2.3 明日復明日,明日何其多

之前遇到一堆問題無從下手的時候,時不時用 “ 明日復明日,明日何其多 ” 給自己打趣。其實你原本計劃的事情沒有完成,究源還是你的時間管理不規範導致,隨便拿一個 “ 奇妙清單 ” 就過來使用其實效果很不好,如果你覺得自己的計劃和時間也安排的亂糟糟,請看看這本書。《搞定Ⅰ:無壓工作的藝術》 ,這本書是時間管理領域最具影響力的著作之一,書中介紹的 GTD(Getting Things Done)時間管理方法也成為全球千萬讀者用來輕鬆高效完成工作與個人事務的最佳工具。

結語:所以既然決定的時候就一定要付諸行動,如果因為繁雜的事情沒有安排好,那麼就嘗試使用 GTD 合理的規劃一下自己。你要知道,我們都有拖延症,你永遠都不會準備好,只有邁出第一步才能開始準備。

2. 4 盲目自信也是在耽誤你

筆者起初也是頗有自信,覺得自己工作三年有餘就獨立的負責很大的模組,並且是公司的核心開發人員,一直在給自己心理暗示:“ 我現在就是不想找工作,現在我在創業公司能夠獨當一面,啥時候想找不是很輕鬆的事情? ”。

然而就是這個想法讓我從有想法換工作到開始動身足有小一年。等到動身的時候我才知道自己曾經的想法是錯誤的。

“ 格局的侷限是你致命錯誤 ”。我開始試水是在拉鉤上面投了 10 幾封簡歷,結果一週過去毫無音訊。

我開始反思問題,於是託了一位工作很久的朋友幫忙看一下簡歷,反饋竟是這樣:“ 你的簡歷寫的太亂了,沒有條理,蒼蠅蚊子一把抓,而且你的經歷太散,沒有重點,你得好好整理下自己的專案經歷和技術能力。”。

於是,就有了下面一章《 整理簡歷,好的開始是成功的一半》,怎麼整理簡歷和自己的技能點。

結語:盲目的自信也是你一拖再拖的理由,是騾子是馬,拉出來溜溜一下子就知道了。

3. 整理簡歷,好的開始是成功的一半

這是我的第一份簡歷,打個樣你就知道有多差了,其實當時我自己覺得內容很多,技術點很多,還說明了做什麼了,並且最後還言明自己在這個專案中的厲害和學到了什麼,不應該是很不錯嗎?

然而事情並不是我想的那樣,很大一個篇幅描述,雜糅到一起既顯得雜亂無章,也讓閱讀者抓不住重點,其實你可以把簡歷比喻成程式碼,這樣一坨還不重構怎麼讓人維護? 不噴你才怪。

首先需要整理版面,起碼讓閱讀者看著舒服,筆者找了很多方案,覺得下面兩種方案不錯:

使用表格很規整的 Word 文件,清晰呈現自己的資訊和工作經歷,具體模板 點選獲取。

使用 Markdown 編寫簡歷,原本我們就非常熟悉 Markdown 的語法,而且他的樣式對於我們閱讀來說已經很可以了,並且層次目錄清晰。

其次是個人基本資訊,個人基本資訊一定要字字珠璣,不要寫沒用的,比如駕照,血型。羅列重點資訊即可,並且學歷一定寫的清清楚楚,不要讓面試官去猜疑。如果有不錯的社交屬性可以放上,比如不錯的 Github 或者是簡書。

然後就是最重要的一點清晰的描述自己的工作內容並突出重點,一定要有條理並且分層次,最簡單的方式就是公司用 #,專案名稱用 ##,技能,內容,描述分別用 ###,這樣結構就非常清晰,然後使用 FAB 或者是 STAR 原則,描述自己的貢獻,這樣就清晰多了。

打個樣,看一下筆者修改以後是不是好了一些:

切記不能有錯別字,這是寫簡歷的大忌。

最後是技能一定要突出重點,如果你找的是 JAVA 工作,其實一線網際網路公司是不會關心你對 HTML 有多麼熟悉,所以重心放在 JAVA 上面,比如 NIO、多執行緒、JVM 等。

筆者注:當然如果你選擇寫上去的東西,必須可以自圓其說,必須真實,不然就適得其反了。

簡歷確實是非常重要的,作者找到了一篇還不錯的文章,寫的非常詳細,裡面還有技巧和模板,比筆者總結的好那麼一丟丟[壞笑],如何寫好技術簡歷 —— 例項、模板及工具,可以參考一下。

結語:好的開始是成功的一半,一定要在自己的簡歷上面下一番功夫。

4. 打造自己的社交簡歷

一份 PDF 簡歷是求職必須的,然而有一份 “ 社交簡歷 ” 更能讓你錦上添花,可以簡單的從“訂閱號”說起,為什麼訂閱號放在社交簡歷的第一位呢?

4.1 訂閱號

每天地鐵裡面上下班你用什麼來打發時間?大多數人都在看訂閱號吧,微信訂閱號這麼大的體量,又源於社交,那不是最好的打造自己社交的一個工具?

筆者瞭解,85% 以上的訂閱號作者都是自己樂於分享,樂於傳播,樂於交友的,那麼筆者問你,你訂閱了那麼多自己覺得還不錯的公眾號,加了幾個訂閱號主的微信?

驚訝臉?還有這操作,如果沒有意外,90% 的訂閱號主都會把自己的微信獲取方式放到訂閱號的選單裡面。

為什麼筆者建議你新增訂閱號主,因為網際網路圈子就這麼小,人脈是非常重要的一個財富,工作越久你就會越覺得人脈很重要,既然你沒有父輩帶來的人脈,那麼自己擴充套件也是一個不錯的選擇。另一個原因,有一句古話說的好:“ 近朱者赤近墨者黑 ”,如果你想進大廠,是不是先了解一下大廠的人怎麼思考,怎麼做事,是一個什麼水平?

那麼訂閱號不少都源於大廠,這是你最方便可以觸及大廠人的生活的方式,新增他的微信則是更一步的方式。沒事多閱讀下他的文章,點贊,互動一下,慢慢就會變成你的關係網。

打個樣,比如筆者的收集,阿里巴巴的 併發程式設計網,京東的 開濤的部落格,ThoughtWorks 的 諾普部落格,還有筆者的微信 碼匠筆記,不過筆者還是一個初級選手。 如果你留心,訂閱號會成為你最好的人脈。

4.2 寫部落格

然後是部落格,筆者私以為一個做技術的沒有一個部落格是萬萬不能夠的。一個好的部落格不僅體現了你對技術的那份熱情,還有你水平的最好的體現。短短的幾個小時面試是不能夠深入的瞭解一個人的,但是你的部落格是你閱歷的寫照,有心的面試官會仔細審度你的部落格,挖掘你的亮點。同時你的部落格也能提高你的知名度,比如“阮一峰老師”或者是“張鑫旭老師”去找工作,是不是會輕鬆很多?

當然我們不會把部落格打造成他們那個樣子,那麼權威,但是提高自己,整理思路還是足夠的。

雖然下文中《怎麼複習》章節,筆者說看別人的文章複習是不足的,但是你寫部落格是把你的知識表達出來,你看明白和你能講明白是兩碼事。所以《收藏 != 擁有》章節講,你需要把你收藏的東西整理成自己的文章,然後發表出來,這樣自己掌握的便會更加深入。

4.3 單身交友社群 Github

Github,都說 Github 是單身交友俱樂部,不過也有妹子哦。

作為技術人員,Github 是最好的社群了,你可以在上面看到非常不錯的開源,同時也能和作者互動,當然互動的方式很多,比如 Pull Request,Issues,Star,Fork 等等,如果你自己熱愛開源,有小想法,可以自己做一個開源的小工具,哪怕只有一個點,也是一份開源的熱愛。

筆者的 Github 還算是樸素,只是添加了一些自己業餘時間的開源,比如 Chrome 目錄外掛,Facebook Messenger SDK 封裝 ,同時傳送 Markdown 文章到 CSDN、SegmentFault、簡書等平臺工具 等,同時有時間也會參與開源社群的翻譯,比如MDN、ElasticSearch 官方文件、Spring4All 譯文等。

這樣你長期堅持下去,會在 Github 結交一些志同道合的人,同時也能增加自己的亮點。何樂而不為?

筆者也是初入社會,才疏學淺,如果你有更好的 “ 招式 ” 歡迎留言區留言,讓筆者和其他讀者能學到更多的 “ 武術 ”。結語:PDF 的簡歷只是你面試的一部分,如果你對這個行業充滿著好奇,那麼就用業務時間多經營一下自己的社交簡歷。

5. 你最關心的面試點

筆者在網上看到過 N 多的面經,上來就說面試問到什麼,具體到類,物件,有的可能還有答案,但是筆者這個章節並不會 一 一 羅列面試問題。

哎,但是筆者考慮到有的讀者想看一下筆者經歷的面試題,所以還是把自己的面試問題放在下面《我的面試經歷》章節

回到正題,因為筆者認為,面試點雖然很重要,但是它並不代表你掌握了就可以輕鬆應付,它只是知識面裡面的一個點而已。你記住今天的問題,明天面試官換一個問題你,你還是回答不上來,但是大部分面試官提問的知識面其實都差不多。所以如果你想應付自如,就從面試官的知識點中挖掘出知識面,從而達到舉一反三,觸類旁通。

你是否有這樣的經歷:明明每次面試之前都認真研究面經,整理知識點的,但是去面試的時候總是被問住。如果是,那說明你可以根據筆者的方法挖掘一下知識面了。

下面筆者通過一個具體的例子講解一下怎麼從知識點分析出知識面,然後再全面複習。

因為不同的領域的知識點也不一樣,筆者只是拋磚引玉,具體的技術,還得你根據自己的情況仔細揣摩。

Synchronized 和 ReentrantLock 鎖機制?

HashMap 的原理?當談到執行緒不安全時自然引申出 ConcurrentHashMap ,它的實現原理?

寫一下生產者消費者。

介紹一下 BlockingQueue 原理。

介紹一下 PriorityBlockingQueue 原理。

說一下 CountDownLatch 的使用場景和原理。

羅列一些你知道的執行緒安全的集合類。

上面這些問題都是筆者在面試不同公司的問題,萬卷不離其宗,都是在考 JAVA concurrent 包下面的知識點,那麼我們需要梳理一下 concurrent 包下面都有什麼,都有什麼關聯的知識點,然後統一複習,即便是面試官再換一些問題也沒有關係了。直接用圖來說明一切

上圖是整個 JAVA concurrent 包下面的類,我們有了這個圖就可以各個擊破了,比如我們需要看訊號量 Semaphore,讀寫鎖 ReentrantReadWriteLock,CountDownLatch 它們的實現和使用場景,當然他們的實現需要依賴 AQS,CAS,Atomic,具體它們都是什麼呢?這就需要你細細去品了。

下文章節《怎麼複習》裡面提到,切記不能看部落格,也別聽筆者道聽途說,一本書的內容筆者三言兩語就講清楚了,那麼也不需要畫這麼大一個圖了,也就沒有那麼高深了。

所以請繼續往下看《怎麼複習》章節怎麼做。然後到了 collections 下面的集合類,每一種的實現都離不開 Lock,具體它們之間怎麼關聯的呢?你一看原始碼就懂了。最後是 executor,它就是一個工具,但是也離不了上面的 Lock 和集合類,所以只要你仔細的看 《Java併發程式設計的藝術 (Java 核心技術系列)》這本書,想必好多問題你都可以迎刃而解。

再舉一個筆者複習 ElasticSearch 的例子,通過《我的面試經歷》章節你可以發現,4家公司都問過 ElasticSearch 的問題,比如ElasticSearch儲存過程,索引過程,查詢過程,原理和資料結構。那麼筆者勢必要下功夫了,於是筆者從頭到尾讀了一遍《ElasticSearch 權威指南》。

筆者沒有找到合適的書籍,中文文件是 2.0 版本有些過時了,但是基本原理類似,如果英文好的話可以直接看 6.0 最新英文文件。裡面會給你講用法、實現、儲存結構、設計原理還有叢集搭建、分片原理,反正你可以學到好多東西,這樣你就可以參照《學以致用》章節,掌握以後馬上考慮哪裡可以用到當前專案中。

結語:面試點只是一個表象,你需要針對知識點找到它對應的知識面,等你看完你會發現由點及面的掌握了知識,這樣才能舉一反三,觸類旁通。怎麼樣收集這個知識點呢?那就是下文講到的《我的面試經歷》中通過試水收集。你可以通過自己試水獲得

6. 怎麼複習

6.1 收藏 != 擁有

你的微信收藏是不是有很多未讀文章?如果你不定期的整理收藏夾,那麼等於沒有收藏夾。收藏是好習慣,看到了不錯的文章就收藏下來,並且微信的訂閱推送體系是獲取知識開拓眼界最好的方式,但是你需要懂得利用。

筆者每隔一週就會清理一次收藏夾。當然清理不是刪除,是把有用的知識點抽離出來,然後通過搜尋資料和查閱書籍把他變成自己的知識儲存到 “ 有道雲筆記 ”,雖然有道雲筆記沒有印象筆記穩定,筆者只是喜歡他的 Markdown 功能。

6.2 部落格不一定真實

好多人複習的時候都是看一下網上的面經,整理一下知識點,然後百度,谷歌看幾篇帖子就以為自己掌握了,自以為已經 “ 學富五車 ”,其實不是這樣的。

網上的文章不一定講的全面,好多都是以偏概全,甚至有的不一定準確,加上國內的複製,抄襲嚴重,能看的文章其實是少之又少。所以這裡筆者推薦複習一定要看書,原因很簡單,寫部落格的門檻是在太低了,隨便動動手就來一篇,然而書不是那麼簡單,校審,出版社層層把關,而且業界那幾本值得看的書大家其實還是知道的。

舉一堆栗子,如果你想複習 JVM,那就看 《深入理解 Java 虛擬機器:JVM 高階特性與最佳實踐(第 2 版)》, 如果你想複習多執行緒那就看 《Java 併發程式設計的藝術 (Java 核心技術系列)》,如果你想複習 ElasticSearch 就看 《ElasticSearch 權威指南》,如果看 Redis 就看 《 Redis 實戰》,不過筆者也看過國產的一本不錯的 Redis 書籍 《Redis設計與實現 (資料庫技術叢書)》,《高效能 MySQL》,《Spring 實戰》,《RabbitMQ實戰:高效部署分散式訊息佇列》等等,當然筆者只是根據這幾個領域列舉,如果這些不包含你想看的,一定要買一本這個領域經典的書來看,好書永遠都不過時。

這裡一定要提醒大家,看書一定不要走馬觀花,我們是從書中汲取知識,不是以量取勝,千萬不能有我多久多久就看完一本書而自豪,那樣其實你並沒有真正掌握裡面的知識,小筆者最長看書的時候,第一章就看了一個月(當然是每天看一點)。

原因是每看到一個知識點就不懂了,馬上停下來查網上的資料和相關的書籍,如果別的書籍也有講到就不懂的就繼續刨根問題,直到所有問題都解決了再繼續看當前書籍的下一個章節。這樣以後你覺得你慢了?其實你是快了,因為你掌握了更多的東西,再看接下來的章節其實會很快。

這樣堅持看完幾本書以後你就會發現自己有些特別了。

6.3 好記性不如爛筆頭

what?都什麼年代了你還和我說用筆?是的,你沒看錯,筆者嘗試的最好的複習方式就是買一個筆記本,每天把自己看書所得整齊的寫上去。網上的雲筆記多方便,一貼上一大堆,但是就是因為他方便才更不容易加深印象,和上面的 《收藏 != 擁有》一個道理,你以為你整理到雲筆記上面了,其實你就是複製貼上了一下,完全沒有過腦。

所以記筆記一定要用紙質的,即便是筆者用雲筆記記錄,也不會貼上。還有一個就是感覺,為什麼 Kindle 那麼火,還那麼多人買紙質書呢?

6.4 配合原始碼

看書一定會有不懂的地方,不理解的點,如果遇到直接看原始碼就好了,比如 JVM,Redis 都可以找到原始碼的,雖然他們都是 C 的程式碼,但是我們有 JAVA 的基礎,都不在話下。其他的原本就是 JAVA 實現的看其原始碼還會更簡單,尤其是 JAVA 併發包下面的內容。所以遇到問題一定要仔細的鑽研原始碼。

筆者在看 hashcode 的時候就是不理解,為什麼每次執行主執行緒的類 hashcode 不變,其他類會變,於是筆者在 os.cpp 中的 os::random() 方法找到了原因,他 random 的 seed 不變,所以每次第一個執行緒的 hashcode 勢必一樣。雖然可能和麵試不相關,但是起碼以後不會因為這個問題而困擾。

6.5 舉一反三,觸類旁通

學而不思則罔,思而不學則殆。學習以後一定要多總結和思考,比如你知道 JAVA 裡面的 PriorityQueue 是優先佇列,那麼 ElasticSearch 的query 預設搜尋數量要限制 2000 也是因為它使用的是分散式的 PriorityQueue 嗎?

比如你可以思考 JAVA 的 HashMap 的hash 實現為什麼使用 (h = key.hashCode()) ^ (h >>> 16);

這樣一步位運算?

它原理和 Redis 的是否一樣呢?

MySQL 在分庫分表的時候是否也可以使用類似的原理?

ElasticSearch 也有分片的概念,那麼是不是也用的同一種hash原理?

hash是不是有多種實現,哪一種更好用,哪一種hash衝突的概率更小?

這個課題答案並不重要,重要的是你在探尋答案過程中的收穫。

6.6 學以致用

通過上面的學習想必你已經掌握了一些東西了,那麼掌握裡以後怎麼讓他們更有意義?那就是 Redesign ,不知道這詞好不好理解。意思就是你既然通過分析知識點掌握了之前沒有掌握的知識,那麼為什麼沒有在原來的專案中使用呢?知識沒有真實的使用場景,面試官怎麼認可你?所以通過複習掌握的知識一定要及時的應用到原來的專案上面,具體怎麼應用就要看你之前的專案了。

比如你自己學習了 Dubbo,就把原來的專案改成全部使用 RPC 呼叫的專案;比如你學習了 Spring - Boot,就把原來的 Tomcat 的方式全部去掉;比如你學習了多執行緒,就去把原來的耗時任務修改掉;比如你學習了設計模式,就思考一下原來什麼地方修改一下更優雅?

筆者拋磚引玉舉一個自己學以致用的例子,筆者學習了 Redis 的資料型別和實現原理以後,覺得有序集合(sorted set)設計很適合做每週最熱閱讀排行,這是筆者前公司的一個功能介面,於是筆者就使用 sorted set 重新設計了每週最熱閱讀排行,為什麼說他適合呢?

筆者理解到 sorted set 裡 items 內容大於 64 的時候同時使用了 hash 和 skiplist 兩種設計實現。這也會為了排序和查詢效能做的優化。新增和刪除都需要修改 skiplist,所以複雜度為 O(log(n))。 但是如果僅僅是查詢元素的話可以直接使用 hash,其複雜度為 O(1) ,其他的 range 操作複雜度一般為 O(log(n)),當然如果是小於 64 的時候,因為是採用了 ziplist 的設計,其時間複雜度為 O(n)。這樣以後查詢和更新閱讀都變得簡單,那麼這樣簡單的就實現了之前複雜邏輯而且效率並不高的介面何樂而不為?

如果你也想初步看一下 Redis 的資料型別和實現原理,可以看看 《Redis 設計與實現 (資料庫技術叢書)》,講的還算是淺顯易懂。

結語:收藏沒有用,重要的是消化吸收,部落格只是讓我們接觸知識的一種途徑,但是深入理解這個知識一定要通過看書來完成,看書的同時不要忘記做筆記,掌握知識以後及時使用到專案中。

7. 最高效的投遞途徑

萬事俱備,只欠東風。什麼都準備好了,什麼途徑是最高效的呢?筆者也不敢說能完全瞭解。

不過筆者整理了下自己的投遞方式,以供大家參考。

7.1 拉鉤不是很理想

筆者剛整理完上面那份 “ 次的簡歷 ”,在拉鉤上面投了 10 份,杳無音信,於是筆者思考一下是不是簡歷質量問題,開始修改,但這是下文,HR 小姐姐就沒有點選查收,總不會因為檔名就看不上了?

所以筆者私以為簡歷沒關係,而是拉鉤的處理速度很慢。

7.2 內推效果佳

網際網路圈子這麼小,工作幾年你會發現,差不多的公司都有自己的人脈,找他們幫忙推一下就好了。

筆者之前很不好意思找熟人幫忙內推,覺得萬一掛了,會給熟人丟面子。但是等小白進了一線公司以後發現,內推是一種常態,甚至有的部門要求內推名額,所以不要擔心內推會給你的朋友帶來負面影響,他很願意為你效勞。

7.3 訂閱號推薦也不錯

通過上面筆者的侃侃而談,你是不是發現自己也有一些訂閱的大 V?那麼主動的去聯絡他們一下,詢問一下在什麼公司高就,能不能幫忙內推,你會得到意想不到的結果。

7.4 別忘記單身會所

Github 也是一個不錯的找工作的地方,你每天在逛 Github 的時候發現不錯的人記得 follow 一下,時不時看一下他們的動態,發現做了一些你很嚮往很喜歡的事情,那麼事情好辦了,說明你未來的同事你很崇拜和欣賞,那麼去勾搭一下吧。

7.5 果汁簡歷

果汁簡歷 這是筆者最近發現的一個訂閱號,每天會推送一些求職攻略,有一些質量還不錯,還能免費幫忙大廠內推,這樣就不用你一個一個找大廠的訂閱號了,也是一個可以選擇的途徑,筆者強烈推薦。

7.6 Boss 直聘

這個算是筆者最喜歡的了,上面的 Boss 不一定是 HR,好多都是你將來的同事,比如我[陰險臉]。其實想想也對,最瞭解部門需求和同僚水平的還是同行,那麼技術直接來招聘其實也是最有效的方式了,所以 Boss 直聘 是我使用的反饋最快效率最高的招聘平臺。筆者強烈推薦。

筆者又囉嗦一句,一個平臺某個公司掛了,沒關係換個平臺再投;一個平臺某個公司部門關了,沒關係,換一個部門再投。筆者的親身經歷,不同平臺和部門之前影響很小。下文筆者的面試試水經歷有更詳細的介紹。結語:好的簡歷很重要,但是投遞的途徑也很重要,一個高效的途徑可以節省時間,也能合理的安排自己的面試節奏。

8. 合理規劃自己的面試和複習節奏

這一章節其實內容相對比較少了,筆者放到這裡只是為了總結一下,因為面試節奏很重要。下文的章節《我的面試經歷》會具體羅列一下面試的節奏和時間節點。

本文主要輸一下幾點:

面試試水節奏要把握好,既然開始了就不要輕易的拖延和停止,通常兩週面兩次,或者一週面兩次的節奏比較合適,能對自己的複習馬上試錯,再次檢驗和整理。不能拖太久,不然節奏和掌握程度效果很不好,記憶曲線你也是明白的。

體量均衡,如果你想去一線公司,建議不要用小公司試水,有的朋友擔心自己現在沒有準備好,想去小公司試試,然後再試大公司。其實沒用,小公司的套路和大公司的套路差很多,大部分小公司只需要你過來幹活就可以了,面試的知識點大多數偏應用,而大公司多數偏原理和能力,所以如果你想試水,一定拿體量相當的嘗試。PS:反正網際網路公司這麼多。

及時複習,上面說了很多筆者複習技巧,面試結束後第一時間整理面試點,分析面試點,然後全方面複習。怎麼複習呢?那就參照上文的章節《怎麼複習》。

9. 面試技巧

9.1 自我介紹

每一次面試都會有一個開場,通常開場會以求職者的自我介紹開始,所以你要準備一個簡短卻能把經歷講的說明的自我介紹。內容不需要長篇大論介紹專案,簡歷中不已經有了嗎?這是一個開放性的話題,可以快速的讓面試官認識你。筆者認為如下幾點還蠻重要的,供你參考。

履歷,快速的描述一下自己的履歷,學歷,畢業時間,從事了幾份工作,都是什麼行業,主要擅長哪方面。這樣面試官瞭解你的情況,也好進一步提問。

業餘,工作是你面對公司的,但是你的業餘是什麼樣子的,比如業餘時間我會看書,寫部落格,開源小東西,當然不是讓你說我業餘時陪女朋友,看電影,而是說一些和技術相關的。這樣讓面試官可以看到 “ 工作以外 ” 的你。

原因,每個面試官還是蠻關心你的離職原因,所以你開篇直接簡單介紹一下你的情況和離職原因,這樣讓面試官瞭解了情況。

9.2 知之為知之

好多人聽聞有這樣的面試經驗,如果遇到問題不會以後找一個自己會的點侃侃而談,這樣不僅能蓋住剛才自己的不會,還能展示自己另一面的實力。這種想法是錯誤,知之為知之,不知為不知,如果你不會直接乾脆的說,這個地方我不瞭解,這個我不清楚,這個我沒有遇到過。

原因很簡單,面試官閱人無數,這些套路他早知道,反而覺得你不誠懇,答非所問的浪費彼此時間。面試官都會考一些通用的基礎問題,但是也會貼近當前專案中使用的技術來提問,因為大部分面試官不是來選拔培訓者,而是選拔幹活的人,所以他們需要知道你當前掌握技能的程度,不要錯用技巧。

9.3 最有挑戰的專案

好多面試官都喜歡問這個問題,他想知道你處理問題的難易程度和你處理問題的方式,當然這個問題也有其他的提問方式,比如 “ 你遇到過比較困難的問題嗎,怎麼解決的 ”。

所以這個地方需要我們提前準備的,當然不是讓你準備好說謊,而是面試之前仔細推敲自己的經歷,找出一些自己覺得有挑戰的事情。可以是業務上面的難點,技術上面的突破,黑魔法實現的功能,實際一次記憶體洩漏的除錯,每一個點都能說明你的工作難度。

9.4 一言不合就上圖

沒有絕對的權威,如果面試過程中覺得面試官說的不恰當,或者是自己怎麼也描述不清楚,那麼直接找一個白板畫圖說一下自己的思路。筆者參加的幾個面試基本都有白板,還專門準備了白板筆。所以對於自己參與的專案的架構圖,自己學習的中介軟體的流程圖,系統的例圖等,還是要有充分的理解。

同時呢面試的時候不要怯場,哪怕是問你一個 CurrentHashMap 的原理,如果你願意展示自己的備課能力,也可以去白板上面畫一畫。

9.5 備課

選擇是雙向的,所以大多數面試官問完你問題以後都會問你,你有什麼要問我的?這個時候你的主場就來了,雖然是讓你問他,但是這是最好的機會讓你自由發揮的時候。

你可以提前插好公司和部門的背景和市場的前景,結合自己的思考問一下當前業務的發展。也可以提前看一下技術點,團隊合作,開發方式等具體的問題,一方面你可以瞭解這個公司的模式是不是你喜歡的,另一方面面試官也會覺得你是一個細心的人。

當然你不要誤解筆者是故意讓你準備一些什麼,而是讓你準備好這些面試官可能問的問題和經歷的面試環節需要的點,別突然遇到了讓自己無計可施,並非刻意而為。

9.6 真實

面試過程中難免會有一些除了技術以外的話題,比如你怎麼看待這種情況,你怎麼怎麼對待這種人,遇到這種情況你怎麼辦?有一些面試技巧的人一下子就猜出來面試官的意圖,故意按照面試官的意思回答。

筆者私以為這樣其實不對,你就完全按照自己的想法去說就好了,如果你因為猜到了面試官的想法因此獲得了 offer,那麼你每天工作的環境可能都需要偽裝的你,時間久了你也會覺得那並不適合自己。

面試其實是雙向的選擇,面試官選擇你,同時你也在選擇公司。

結語:真實是最好的面試技巧,知之為知之,不知為不知,是知也。但是也要提前準備面試過程中可能遇到的問題。

10. 面試通過怎麼從容的談 offer

10.1 不要輕易說出自己的底線

這是你的底牌,有個談判原則,先亮底牌,往往會失去主動權,面試完一輪就問你期望薪水,這時你可以回答給個範圍:如他的崗位招人薪水範圍椒是 15k - 30k,你也可以回答:我期待薪水是:15k - 30k。如果他再問你具體的話,你可以說:現在討論這個還過早,我相信在決定錄用我前,再討論會更合適。這樣大家都不會尷尬。

10.2 和 HR 溝通要大膽說出自己的期望

一定要說出自己的期望,如果你到了 HR 環節,一個公司的招聘成本真的太高了,如果你真的到 HR 環節,那麼說明你足夠優秀。足夠優秀 HR 就不會因為你要的太高拒絕你,當然你要的太離譜他肯定會給你一個最大的價格,你自己要控制好就可以了。

10.3 不後悔

來之前談好待遇,來之後無論多少都不能後悔,這是底線。既然選擇便只顧風雨兼程,不然你工作也沒心情,沒動力,最後害得不還是自己?

11. 你想要的 “ 我的面試經歷 ”

時隔比較久,面試問題筆者就記下了一些重點,整理給大家,僅供參考。

排名是時間先後

 

11.1 瓜子二手車

快排;

二分法查詢,推到時間複雜度;

BlockingQueue 實現原理;

二叉樹遍歷;

ElasticSearch 儲存結構和原理;

MySQL 索引,優化;

SpringMVC 請求過程;

Dubbo 原理。

 

11.2 愛奇藝

SpringMVC 請求過程;

Dubbo 原理;

MySQL 快取,效能優化,索引結構;

ElasticSearch 儲存結構和原理;

設計模式;

Proxy 和 CGLib 區別和原理;

樂觀鎖和悲觀鎖;

ThreadLocal;

閉包。

 

11.3 每日優鮮

TCP 三次握手;

MySQL 分庫分表,效能優化;

HashMap 實現原理;

庫存設計原理(電商相關);

Redis 基本資料結構和使用;

ElasticSearch 儲存結構,查詢過程,索引原理;

多執行緒;

生產者消費者。

 

11.4 滴滴

閉包;

反射的實現和原理;

JDK8 lambda 使用和原理;

SQL 注入和 XSS 攻防;

設計模式;

Redis 基本資料結構和原理;

Http1.0 和 Http2.0 區別;

MySQL 索引結構,基本資料型別和使用場景;

Shell 分析日誌檢視 QPS;

JDK8 中多執行緒的變化;

 

11.5 京東

Spring AOP 原理,Proxy 和 GCLib 原理;

多執行緒;

CountDownLatch;

庫存設計;

大秒設計;

SpringMVC 請求過程和使用設計模式;

手寫單例;

Redis sorted set 實現原理;

HashMap 實現原理;

MySQL 索引和優化;

分散式擴容和容災;

PriorityQueue 使用和原理;

 

11.6 阿里巴巴

HashMap 和 CurrentHashMap 區別;

Hashcode;

用過的集合類;

ThreadExecutorPool ;

volatile 記憶體模型;

ElasticSearch 叢集路由規則和容錯;

Dubbo 原理;

Redis Hash 設計原理;

最後,有需要Java面試題(含答案)的朋友可以點個贊然後加入我的個人粉絲群Java填坑之路:789337293獲取,還有更多的進階Java高階程式設計師的學習視訊等你