3年工作經驗程式設計師應有的技能(面試)
面試主要看幾點:專案經驗+基本技術+個人潛力(也就是值不值得培養)。
關於專案經驗,我認為併發程式設計網的創始人方騰飛老師講的一段話非常好:
介紹產品時面試官會考察應聘者的溝通能力和思考能力,我們大部分情況都是做產品的一個功能或一個模組,但是即使是這樣,自 己有沒有把整個系統架構或產品搞清楚,並能介紹清楚,為什麼做這個系統?這個系統的價值是什麼?這個系統有哪些功能?優缺點有哪些?如果讓你重新設計這個 系統你會如何設計?
我覺得這就已經足以概括了。也許你僅僅工作一年,也許你做的是專案中微不足道的模組,當然這些一定是你的劣勢且無法改變,但是如何彌補這個劣勢,從方老師的話中我總結幾點:
1、明確你的專案到底是做什麼的,有哪些功能
2、明確你的專案的整體架構,在面試的時候能夠清楚地畫給面試官看並且清楚地指出從哪裡呼叫到哪裡、使用什麼方式呼叫
3、明確你的模組在整個專案中所處的位置及作用
4、明確你的模組用到了哪些技術,更好一些的可以再瞭解一下整個專案用到了哪些技術
在你無法改變自己的工作年限、自己的不那麼有說服力的專案經驗的情況下(這一定是扣分項),可以通過這種方式來一定程度上地彌補並且增進面試官對你的好感度。
關於專業技能
寫完專案接著寫寫一名3年工作經驗的Java程式設計師應該具備的技能,這可能是Java程式設計師們比較關心的內容。我這裡要說明一下,以下列舉的內容不是都要會的東西—-但是如果你掌握得越多,最終能得到的評價、拿到的薪水勢必也越高。
1、基本語法
這包括static、final、transient等關鍵字的作用,foreach迴圈的原理等等。今天面試我問你static關鍵字有哪些作 用,如果你答出static修飾變數、修飾方法我會認為你合格,答出靜態塊,我會認為你不錯,答出靜態內部類我會認為你很好,答出靜態導包我會對你很滿 意,因為能看出你非常熱衷研究技術。
最深入的一次,LZ記得面試官直接問到了我Volatile關 鍵字的底層實現原理(順便插一句,面試和被面試本身就是相對的,面試官能問這個問題同時也讓面試者感覺到面試官也是一個喜愛研究技術的人,增加了面試者對 公司的好感,LZ最終選擇的就是問了這個問題的公司),不要覺得這太吹毛求疵了—-越簡單的問題越能看出一個人的水平,別人對你技術的考量絕大多數都是以深度
static表示“全域性”或者“靜態”的意思,用來修飾成員變數和成員方法、靜態內部類,也可以形成靜態static程式碼塊。被static修飾的成員變數和成員方法獨立於該類的任何物件。也就是說,它不依賴類特定的例項,被類的所有例項共享。只要這個類被載入,Java虛擬機器就能根據類名在執行時資料區的方法區內定找到他們。因此,static物件可以在它的任何物件建立之前訪問,無需引用任何物件。
一般我們匯入一個類都用 import com…..ClassName;而靜態匯入是這樣:import static com…..ClassName.*;這裡的多了個static,還有就是類名ClassName後面多了個.*
final類不能被繼承,沒有子類,final類中的方法預設是final的。
final方法不能被子類的方法覆蓋,但可以被繼承。
final成員變量表示常量,只能被賦值一次,賦值後值不再改變。
final不能用於修飾構造方法。
transient標識的變數可以被標記為表示它們不是物件的持久狀態的一部分。java 的transient關鍵字為我們提供了便利,你只需要實現Serilizable介面,將不需要序列化的屬性前新增關鍵字transient,序列化物件的時候,這個屬性就不會序列化到指定的目的地中。
1)一旦變數被transient修飾,變數將不再是物件持久化的一部分,該變數內容在序列化後無法獲得訪問。
2)transient關鍵字只能修飾變數,而不能修飾方法和類。注意,本地變數是不能被transient關鍵字修飾的。變數如果是使用者自定義類變數,則該類需要實現Serializable介面。
3)被transient關鍵字修飾的變數不再能被序列化,一個靜態變數不管是否被transient修飾,均不能被序列化。
第三點可能有些人很迷惑,因為發現在User類中的username欄位前加上static關鍵字後,程式執行結果依然不變,即static型別的username也讀出來為“Alexia”了,這不與第三點說的矛盾嗎?實際上是這樣的:第三點確實沒錯(一個靜態變數不管是否被transient修飾,均不能被序列化),反序列化後類中static型變數username的值為當前JVM中對應static變數的值,這個值是JVM中的不是反序列化得出的
volatile:
https://www.cnblogs.com/zhengbin/p/5654805.html
https://www.cnblogs.com/paddix/p/5428507.html
---------------------
作者:特種兵-AK47
來源:CSDN
原文:https://blog.csdn.net/m13666368773/article/details/7513049
版權宣告:本文為博主原創文章,轉載請附上博文連結!
2、集合
非常重要,也是必問的內容。基本上就是List、Map、Set,問的是各種實現類的底層實現原理,實現類的優缺點。
集合要掌握的是ArrayList、vector、LinkedList、Hashtable、HashMap、ConcurrentHashMap、 HashSet的實現原理,能流利作答,當然能掌握CopyOnWrite容器和Queue是再好不過的了。另外多說一 句,ConcurrentHashMap的問題在面試中問得特別多,大概是因為這個類可以衍生出非常多的問題,關於ConcurrentHashMap, 我給網友朋友們提供三點回答或者是研究方向:
(1)ConcurrentHashMap的鎖分段技術
(2)ConcurrentHashMap的讀是否要加鎖,為什麼
(3)ConcurrentHashMap的迭代器是強一致性的迭代器還是弱一致性的迭代器
https://blog.csdn.net/u010648555/article/details/56049460(底部引出集合所有系列)
3、設計模式
本來以為蠻重要的一塊內容,結果只在阿里巴巴B2B事業部面試的時候被問了一次,當時問的是裝飾器模式。
當然咱們不能這麼功利,為了面試而學習,設計模式在工作中還是非常重要、非常有用的,23種設計模式中重點研究常用的十來種就可以了,面試中關於設計模式的問答主要是三個方向:
(1)你的專案中用到了哪些設計模式,如何使用
(2)知道常用設計模式的優缺點
(3)能畫出常用設計模式的UML圖
4、多執行緒
這也是必問的一塊了。因為三年工作經驗,所以基本上不會再問你怎麼實現多執行緒了,會問得深入一些比如說Thread和Runnable的區別和聯 系、多次start一個執行緒會怎麼樣、執行緒有哪些狀態。當然這只是最基本的,出乎意料地,幾次面試幾乎都被同時問到了一個問題,問法不盡相同,總結起來是 這麼一個意思:
假如有Thread1、Thread2、ThreaD3、Thread4四條執行緒分別統計C、D、E、F四個盤的大小,所有執行緒都統計完畢交給Thread5執行緒去做彙總,應當如何實現?
聰明的網友們對這個問題是否有答案呢?不難,java.util.concurrent下就有現成的類可以使用。
另外,執行緒池也是比較常問的一塊,常用的執行緒池有幾種?這幾種執行緒池之間有什麼區別和聯絡?執行緒池的實現原理是怎麼樣的?實際一些的,會給你一些具體的場景,讓你回答這種場景該使用什麼樣的執行緒池比較合適。
最後,雖然這次面試問得不多,但是多執行緒同步、鎖這塊也是重點。synchronized和ReentrantLock的區別、 synchronized鎖普通方法和鎖靜態方法、死鎖的原理及排查方法等等,關於多執行緒,我在之前有些過文章總結過多執行緒的40個問題,可以參看40個Java多執行緒問題總結。
5、JDK原始碼
要想拿高工資,JDK原始碼不可不讀。上面的內容可能還和具體場景聯絡起來,JDK原始碼就是實打實地看你平時是不是愛鑽研了。LZ面試過程中被問了不 少JDK原始碼的問題,其中最刁鑽的一個問了LZ,String的hashCode()方法是怎麼實現的,幸好LZ平時String原始碼看得多,答了個大 概。JDK原始碼其實沒什麼好總結的,純粹看個人,總結一下比較重要的原始碼:
public int hashCode() {
int h = hash;
final int len = length();
if (h == 0 && len > 0) {
for (int i = 0; i < len; i++) {
h = 31 * h + charAt(i);
}
hash = h;
}
return h;
}
hashCode = (49*31 + 50)*31 + 51
hashCode=('1' * 31 + '2' ) * 31 + '3'
這樣有個明顯的好處,就是字首相同的字串的hash值都落在鄰近的區間。
1.可以節省記憶體,因為hash值在相鄰,這樣hash的陣列可以比較小。比如當用HashMap,以String為key時。
2.hash值相鄰,如果存放在容器,比好HashSet,HashMap中時,實際存放的記憶體的位置也相鄰,則存取的效率也高。(程式區域性性原理)
以31為倍數,原因了31的二進位制全是1,則可以有效地離散資料。
(1)List、Map、Set實現類的原始碼
(2)ReentrantLock、AQS的原始碼
(3)AtomicInteger的實現原理,主要能說清楚CAS機制並且AtomicInteger是如何利用CAS機制實現的
(4)執行緒池的實現原理
(5)Object類中的方法以及每個方法的作用
這些其實要求蠻高的,LZ去年一整年基本把JDK中重要類的原始碼研究了個遍,真的花費時間、花費精力,當然回頭看,是值得的—-不僅僅是為了應付面試。
6、框架
老生常談,面試必問的東西。一般來說會問你一下你們專案中使用的框架,然後給你一些場景問你用框架怎麼做,比如我想要在Spring初始化bean 的時候做一些事情該怎麼做、想要在bean銷燬的時候做一些事情該怎麼做、MyBatis中$和#的區別等等,這些都比較實際了,平時積累得好、有多學習 框架的使用細節自然都不成問題。
如果上面你的問題答得好,面試官往往會深入地問一些框架的實現原理。問得最多的就是Spring AOP的實現原理,當然這個很簡單啦,兩句話就搞定的的事兒,即使你不會準備一下就好了。LZ遇到的最變態的是讓LZ畫一下Spring的Bean工廠實 現的UML圖,當然面對這樣一個有深度的問題,LZ是絕對答不出來的/(ㄒoㄒ)/~~
7、資料庫
資料庫十有八九也都會問到。一些基本的像union和union all的區別、left join、幾種索引及其區別就不談了,比較重要的就是資料庫效能的優化,如果對於資料庫的效能優化一竅不通,那麼有時間,還是建議你在面試前花一兩天專門 把SQL基礎和SQL優化的內容準備一下。
不過資料庫倒是不用擔心,一家公司往往有很多部門,如果你對資料庫不熟悉而基本技術又非常好,九成都是會要你的,估計會先把你放到對資料庫使用不是要求非常高的部門鍛鍊一下。
8、資料結構和演算法分析
資料結構和演算法分析,對於一名程式設計師來說,會比不會好而且在工作中絕對能派上用場。陣列、連結串列是基礎,棧和佇列深入一些但也不難,樹挺重要的,比較 重要的樹AVL樹、紅黑樹,可以不瞭解它們的具體實現,但是要知道什麼是二叉查詢樹、什麼是平衡樹,AVL樹和紅黑樹的區別。記得某次面試,某個面試官和 我聊到了資料庫的索引,他問我:
你知道索引使用的是哪種資料結構實現嗎?
LZ答到用的Hash表吧,答錯。他又問,你知道為什麼要使用樹嗎?LZ答到因為Hash表可能會出現比較多的衝突,在千萬甚至是上億級別的資料面 前,會大大增加查詢的時間複雜度。而樹比較穩定,基本保證最多二三十次就能找到想要的資料,對方說不完全對,最後我們還是交流了一下這個問題,我也明白了 為什麼要使用樹,這裡不說,網友朋友們覺得索引為什麼要使用樹來實現呢?
至於演算法分析,不會、不想研究就算了,記得某次面試對方問我,Collections.sort方法使用的是哪種排序方法,額,吐血三升。當然為了 顯示LZ的博學,對演算法分析也有一定的研究(⊙﹏⊙)b,LZ還是硬著頭皮說了一句可能是氣泡排序吧。當然答案肯定不是,有興趣的網友朋友們可以去看一下 Collections.sort方法的原始碼,用的是一種叫做TimSort的排序法,也就是增強型的歸併排序法。
9、Java虛擬機器
出乎LZ的意料,Java虛擬機器應該是很重要的一塊內容,結果在這幾家公司中被問到的概率幾乎為0。要知道,LZ去年可是花了大量的時間去研究Java虛擬機器的,光周志明老師的《深入理解Java虛擬機器:JVM高階特性與最佳實踐》,LZ就讀了不下五遍。
言歸正傳,雖然Java虛擬機器沒問到,但我覺得還是有必要研究的,LZ就簡單地列一個提綱吧,談談Java虛擬機器中比較重要的內容:
(1)Java虛擬機器的記憶體佈局
(2)GC演算法及幾種垃圾收集器
(3)類載入機制,也就是雙親委派模型
(4)Java記憶體模型
(5)happens-before規則
(6)volatile關鍵字使用規則
也許面試無用,但在走向大牛的路上,不可不會。
10、Web方面的一些問題
Java主要面向Web端,因此Web的一些問題也是必問的。LZ碰到過問得最多的兩個問題是:
談談分散式Session的幾種實現方式
常用的四種能答出來自然是讓面試官非常滿意的,另外一個常問的問題是:
講一下Session和Cookie的區別和聯絡以及Session的實現原理
這兩個問題之外,web.xml裡面的內容是重點,Filter、Servlet、Listener,不說對它們的實現原理一清二楚吧,至少能對它 們的使用知根知底。另外,一些細節的方面比如get/post的區別、forward/重定向的區別、HTTPS的實現原理也都可能會被考察到。
噢,想起來了,一致性Hash演算法貌似也被問到了幾次,這個LZ以前專門深入研究過並且寫了兩篇博文,因此問到這個問題LZ自然是答得毫不費力。文章是MemCache超詳細解讀和對一致性Hash演算法,Java程式碼實現的深入研究,特別說明,LZ真的不是在為自已以前寫的文章打廣告啊啊啊啊啊啊。
最後,如果有興趣有時間,建議學習、研究一下SOA和RPC,面向服務體系,大型分散式架構必備,救命良方、包治百病、屢試不爽。
關於HR面試
如果你過五關斬六將,成功地通過了所有的技術面,那麼恭喜你,你離升職加薪、出任CEO、迎娶白富美、走向人生巔峰又進了一步。但是還沒有到談薪資 待遇的時候,最後還有一個考驗:HR面試。基本所有的大公司都有這一輪的面試,不要小看HR面試,很多公司的HR對於面試者都有一票否決權的—-即使前面 的面試對你的評價再高。
所以,這輪的面試也必須重視起來,HR面試主要問的是幾點:
1、簡歷中寫的過去工作經歷的離職原因
2、當前公司薪資待遇
3、期望能到怎樣的一家公司
4、個人未來的發展方向
我專門提一下第2點。可能有人比較排斥也不想說這個,我個人倒是持開放狀態,問了就說了,當然一些的誇大還是必要的,當前公司薪資待遇多報個一千塊 錢完全沒問題(畢竟是一家網際網路公司總多多少少有些補貼啊什麼的嘛)。因為這和你在新公司能拿到的薪水關係不大,新公司能拿到的薪水的決定因素是整個公司 的薪資情況以及根據你的面試情況在公司的定位,都是有固定的薪資範圍的。HR問這個主要也就是心裡有個數並且看你是否誠信—-有些公司入職時會要求你提供 最近一家單位的銀行流水號。
HR面試就說到這裡了,總結起來其實就是四個字:滴水不漏。整個面試過程態度積極向上,不要有任何悲觀消極的態度(尤其在談到以前公司情況的時候,即使有再多的不滿),就不會有問題。
關於面試心態
這個嘛,LZ其實在公司也面試過幾個人,一半以上的面試者回答問題的時候都屬於那種雙腿發抖、聲音顫抖的型別。在LZ看來這大可不必並且這還是扣分項,回答問題的時候最最基本的兩個要求:
1、不緊不慢,平心靜氣
2、條理清晰
表達能力絕對是面試的時候重要的考察專案。咱們做的是程式設計師這一行,講究的是團隊協作,不是寫作、畫畫,一支筆、一個人就行了,一個表達能力不行的程式設計師,要來又有什麼用呢?
除此之外,就是保持良好的心態。古語說得好,只要功夫深,鐵杵磨成針,面試的成功與否,在於平時的積累,臨時抱抱佛腳,看兩道面試題是沒有用的,只 要平時足夠努力,成功是水到渠成的事情,平時不怎麼研究技術的,那也就是個聽天由命的事情,只要充分地展示平時自己的所學就可以了。
因此在我看來,不要把面試當作面試,當做一次技術交流,把面試的心態從我要找到一份工作轉變為我要通過面試去發現不足、提升自己,這樣就會平和多了,即使失敗也不會有太多失望的感覺。
另外,如果平時自己熱衷於研究技術的朋友,真的要有自信,不要覺得別人面試你別人就比你厲害。面試官未必比你優秀,他問的問題往往都是他平時研究得比較多的問題,你一樣有很多自己的研究面試官未必知道。
關於Java
網上常看到一種說法:Java比較簡單。某種程度上這會打擊Java程式設計師的信心—-原來咱們平時用的是這種小兒科的玩意兒啊,在我看來這種想法大可不必,這一部分我來講講對於這個話題的看法。
這種說法有些片面,得分開兩部分來看,我用四個自總結一下就是:易學難精。
1、易學部分
Java易學我認為有兩部分的原因:
(1)很多培訓公司包括大四的學生找工作都會學習Java,絕大多數是因為易學。Java從C/C++發展而來,感謝前人的智慧,它消除了C /C++中最複雜和讓人困惑的語法、它消除了平臺的差異性、它不需要使用者手動釋放記憶體空間、它避免了Java程式設計師和本地語言的互動,讓程式設計師只需要專注 於語法層面和應用層面。
(2)Java作為一門面向物件的語言,在企業級開發中體現出了它無與倫比的特性,整個開發流程比較固定化、模組化,需求分析起來也相對容易。我舉 個自己以前的例子吧,我在大一學習C語言的時候,用C語言寫了一個圖書管理系統寫了2000+的程式碼,大四學了C++之後,用面向物件的語言C++取代面 向過程的語言C語言重新寫了一個功能相似的圖書管理系統,只寫了1100行的樣子,這就是面向物件的優勢。
2、難精部分
接著咱們聊聊難精的部分。
Java語言的設計者幫助Java程式設計師做了這麼多事情,這有利也有弊。有利的部分前面已經說過了,讓Java易學,不過有弊的部分同樣明顯。假如 在應用執行過程中遇到了語法層面和應用層面之外的錯誤,應當如何處理?比如線上環境出現記憶體溢位怎麼辦?GC時間過長怎麼辦?IO長時間沒反應怎麼辦?方 法丟擲莫名其妙的異常怎麼辦?
凡此種種,絕不是一名只會寫幾個if…else…的Java程式設計師就可以解決的,這需要大量的經歷、大量的實踐、大量對Java底層實現細節的研究,而這往往是最難、最考驗Java程式設計師的部分,一些人根本就不想往深去研究,另外一些人研究了一點點就研究不下去了。
Java為什麼難精?就是這個原因。除非你水平特別高,否則五年工作經驗以下的Java程式設計師在簡歷上寫”精通Java”絕對是一件非常愚蠢的事情。