本人以前寫了三篇博文,從面試官角度來告訴你們,哪些人能面試成功,你的簡歷能幫你爭取到面試機會嗎,以及從面試官角度告訴你們如何準備項目方面的描述,均獲得了比較好的反響。這裏咱們就從面試流程入手,告訴你們哪些人能面試成,本文一樣是是據java web輕量級開發面試教程改編的。html
其實有時候面試官本身也知道,在一些問題上候選人頗有可能作過準備,從這些問題上可能沒法瞭解到候選人的真實狀況,但若是候選人沒回答好,那就不會認爲候選人「沒作足準備」,而會認爲候選人在問題所涉及到的方面有欠缺點。前端
並且,經過準備,候選人還能在面試中找到合適的機會更有效地展現本身的亮點,相反,若是候選人沒說,或沒說好,面試官是必定沒法瞭解到候選人的相關特長的。java
若是你們認爲我這篇博文寫很差,請反對我,同時給出改進建議,若是認爲確能從中獲得收穫,也請你們儘可能點擊「推薦」按鈕,你們的推薦是我繼續寫文章的動力,謝謝你們了。web
在下表裏,咱們概括了些能夠在Java核心(Java Core)方面展現的亮點。事實上,咱們不可能列出全部的亮點,這裏只是給出些案例,你們能夠據此擴展。面試
技術方面數據庫 |
能夠說的亮點後端 |
Java集合對象設計模式 |
1 能根據項目的需求選用合適的集合對象,好比知道ArrayList和LinkedList的差別,並能合理選用。多線程 2 能在合適的場合選用WeakHashMap。架構 3 能夠適當講一些集合的JDK底層實現代碼。 |
異常處理方面 |
能在finally從句裏寫釋放資源的代碼 |
JDBC方面 |
1 能經過PreparedStatement的預處理方法來防止SQL注入。 2 能經過批處理來提高操做性能。 3 能經過實例講述事務隔離級別的含義 |
多線程方面 |
1 會使用線程池 2 能經過鎖或信號量等手段正確地處理多線程併發時的數據一致性。 |
在下表裏,咱們列了些在數據庫方面能夠準備的亮點。
技術方面 |
能夠說的亮點 |
建表 |
建表時須要根據項目的數據狀況,考慮是採用三範式或是反範式。 |
SQL調優 |
1 能夠經過查看日誌等方式看哪些SQL須要調優。 2 能夠經過執行計劃查看SQL的所消耗的代價,並據此調優。 3 能夠經過建索引,建分區等手段來優化SQL性能。 |
事務 |
1 能夠說下JDBC或Spring裏是如何管理事務的。 2 能夠說下Spring裏的聲明式事務的作法和優勢。 3 能夠舉例說明事務隔離級別和事務傳播機制的用法。 |
分佈式數據庫 |
1 能夠經過水平或豎直等方式的方式來拆分數據庫,從而減輕對單表訪問所須要的代價。 2 能夠經過集羣等方式來承擔對數據庫的過量的訪問請求。 |
NoSQL和Hadoop |
這兩個自己就是個亮點,若是你們用過,能夠結合項目來講明。 |
在下表10.8裏,咱們也概括出在這方面你們能夠準備的亮點。
技術方面 |
能夠說的亮點 |
Spring MVC架構 |
1 能夠說下Spring的IOC和AOP是如何優化項目結構的。 2 能夠說下攔截器等Spring組件對項目的幫助。 |
ORM,好比Hibernte或Mybatis |
使用這種ORM技術時,如何優化訪問和操做數據庫的性能。 |
Spring和Mybatis等的整合 |
能夠講下整合框架的細節,並能夠舉例說明整合後的框架能很好地適應需求的變動。 |
此外,你們還能夠在Linux使用技能以及項目管理軟件的使用經驗方面展現本身的亮點。這裏請注意,必定找合適的機會「順帶」地說,若是沒機會寧肯別說,更不能仗着有所準備就直接自說自話地說。不然的話,反倒可能會獲得「表達能力不清晰」或「敘述條理混亂」等的不良評價。
面試官只有當確認候選人在責任心和團隊協做能力方面沒問題,纔敢把他招進公司。有些面試官會經過問問題來確認這兩點,但有些有經驗的面試官甚至能夠經過候選人回答問題的方式和說話的語氣上來確認。
因此你們在面試前,首先能夠按以下的要點,在平時的生活和工做中練熟良好交流方式。
第一,談吐清晰,語速不急不緩,至少讓面試官能聽懂你說的話。並且力求說話果斷,別吞吞吐吐的,這樣能顯示出你有足夠的擔當。
第二,交流時儘可能目視面試官,語氣不亢不卑,別太僵硬,說話別過於強勢。臉部能夠適當微笑,面試官在說話時能夠適當點頭互動,總之得讓面試官感受和你交流不吃力,最好還讓面試官感受樂意和你交流。
第三,應積極主動回答面試官的提問,若是沒聽明白問題,別僵持着等面試官進一步解釋,應當主動詢問。若是感受面試官沒徹底理解本身的回答,或者理解有誤,應當進一步主動解釋,以展現積極溝通的姿態。
第四,即便不認同面試官的觀點,也應小心平氣和地交流,不能急躁,別輕易打斷面試官的話,能夠傾聽完面試官的話後耐心地與之交流。有些面試官可能會故意刁難候選人,美其名曰「壓力測試」,在這種狀況下,候選人更應小心平氣和,不能起爭執。
在面試過程當中,再有經驗的面試官可能也沒法經過實例來驗證候選人的「團隊協做能力」(由於在短期內沒法協做),但若是你們能給面試官留下「溝通表達沒問題」、「爲人和藹」和「遇到難點能積極主動協調溝通」的良好印象,那麼面試官通常也能承認候選人的團隊協做能力。
此外,你們還能夠準備以下的說辭,一旦能找合適的機會說出來,面試官更會承認你們的責任心和團隊協做能力。
說辭1:(在介紹項目時)這個項目作到一半時,客戶方變動了一些需求點,這給咱們項目組形成了比較大的壓力。在項目經理的帶領下,咱們都被分配了更多的任務,在這種狀況下,我經過加班按時按質完成了任務,並且在作的過程當中,一旦出現需求或技術方面的問題,我也會主動找同事或項目經理確認。
總之,在出現問題時,你不是退縮,而能經過加班等方式積極面對和解決問題,並且一旦有問題,你不是得過且過,而會主動確認。
說辭2:(介紹本身在項目中的角色)在這個項目組裏,除了本職的開發工做外,我還會積極主動地和測試人員溝通,一方面告訴他們該怎麼測,另外一方面,一旦發現問題,我會和他們一塊兒重現問題,完成修改後我也會主動告訴測試人員,讓他們儘快確認。
總之,在項目裏,你不只能完成本職工做,並且還能和團隊其它人員一塊兒協做。
說辭3:(介紹項目的亮點)在項目裏,我遇到一個需求點,這須要多個團隊一塊兒開發,這時我會和相關人員一塊兒開會,肯定各自的任務點和工期,完成功能點後咱們會一塊兒聯調。
說辭4:(若是面試官問你,遇到本身沒法解決的問題該怎麼辦?)我不會推掉任務,我先會查閱資料,若是不行,我會問項目經理,在他們給出的解決方案基礎上,我會細化成具體的實現代碼,最後我會把實現好的功能點和項目經理確認,以求沒有理解上的誤差。
在責任心和團隊協做能力這兩方面,不建議直接說「我有」,由於這至關於自我表揚,可信度不高,你們能夠採用上述「用具體事實證實」的方式,這樣面試官聽了後就天然能承認你們的相關能力。
當技術面試官問完全部問題後,通常都會說:「我沒問題了,你有什麼問題?」
這時你們能夠在這個環節裏經過提問進一步展現本身和這個職位的匹配度,這些問題也能夠事先準備。下面列些能夠提問的要點,在具體操做中你們能夠酌情選用。
要點一,展現本身技能和要作項目的匹配度。具體而言,你們能夠看下職位介紹裏列的技能點,這些技能點應該在以前的面試裏都已經聊過。這時你能夠問,接來下我會進哪一個項目組?作哪一個項目?其中會用到哪些框架和技術?
當面試官解釋好以後,你就能夠「順口」說,xx技術或框架(這能夠是以前沒充分展現的)我以前在項目裏用過,我作了xx(必定是亮點),能夠再介紹下優化後的效果,再說下體會。
要點二,展現本身吃苦耐勞的能力,同時也能夠展現下責任心。好比能夠問,大家加班多很少?會不會到客戶現場?會不會出差?
不論面試官如何回答,你也能夠「隨口」說,其實在項目比較緊的狀況下,首先得保證進度和質量,在以前的項目裏,有段時間確實進度比較緊,我就去和項目經理多申請了些任務,而後經過加班,按時按質完成了任務。
要點三,展現本身學習能力。好比能夠問,在這項目裏,會不會「調研新技術」?若是項目經理說沒,那就別繼續說了。若是有,那麼你就能夠說,在以前的項目裏,咱們須要用到xx技術,但誰也沒太多的經驗,在項目經理的帶領下,我用了一些時間作了調研,最後項目組根據個人調研後寫的代碼,成功地把這技術應用到項目裏。
要點四,展現本身的職業發展規劃和這個項目的需求是一致的,同時展現本身的穩定性。好比能夠問,若是我在這個項目裏作得好,我能夠獲得哪些提高的機會?
當面試官說完後,你也能夠「隨口」一說,這也是我指望的發展方向。或者也能夠說,若是我有幸面試成功,我也打算沉浸到這個項目裏,好好幾年,若是有機會,我也打算向高級開發或架構師發展(請注意,這個發展方向最好和項目組的指望一致)。
要點五,進一步展現本身溝通交流和團隊協做的能力,以前面試官必定考察過,這裏能夠再強調一下。好比能夠問,這個項目組有哪些成員?通常是怎麼構成的?
這時面試官就會和你介紹,這個項目有一位項目經理,一位架構師,x位後端開發,x位前端開發,x位測試。這時你就能夠說,這和我以前的公司很類似,在以前的項目裏,我作的是後端,個人體會是,在項目組裏必定得多交流多溝通才能把項目作好,靠一我的是不行的,好比有需求或進度上的問題,我會及時和項目經理交流,若是發現bug,我也會及時和測試人員交流。
再次強調,出於誠信的原則,這階段你們介紹的狀況必定得是真實的。
在這個階段,你們也能夠問些比較關心的問題,好比後繼的面試流程,但別什麼都不問,這樣面試官可能會感受你沒準備過,也不在意這個崗位。也別問些能輕易從網上能找到的資料,好比這個公司主營業務是什麼,這樣會讓招聘方感受你以前由於不在意這個機會,因此沒了解過這個公司的狀況。也最好別問工資(或和應聘者切身福利有關)的事,一方面技術面試官(或後繼的項目經理)未必能作主,另外一方面會給他們留下比較功利的印象,關於這些能夠等到經過面試後和人事具體地談。
通常來講,國內公司會要求候選人有「讀英語文檔」的能力,而外企則會要求候選人能在純英語環境下工做,即不只能看英文文檔,能用英文郵件交流,並且還能用英語和國外的同事開會交流。
面試的時間有限,通常不會讓候選人當場翻譯英文文檔,而是會考察英語的口頭交流能力。
有些公司會全程用英語面試,這要求就高了,通常的公司(包括一些外企),則是大部分用中文面試,中間夾雜着一些英文問題。這裏給出些常見的英語問題點。
1 用英語介紹最近的項目。2 用英文作自我介紹。3 用英語介紹本身的興趣愛好。4 用英語介紹你本身最擅長的技術點。5 用英語介紹下你的優缺點。6 用英語介紹上家公司,並敘述離職緣由。這些均可以事先準備,面試時,發音能夠稍微不標準,但力求流利,並且說得量須要適當。
準備時,你們能夠根據問題點先把要回答的英語句子寫下來,多練習幾遍,這樣在面試時就能有信心地展現準備好的成果。
講個咱們據說過的笑話,小A被臨時抽調去爲一個日本項目組面試,其中須要考察候選人的日語,但問題是小A不懂日語,時間又比較緊,又找不到其它面試官。在日本項目組的容許下,小A採用以下的面試方式,讓候選人用日語介紹本身,並介紹上個項目。
雖然小A聽不懂,但若是候選人說不上或不說,日語評定是「不及格」,若是能說得上,但磕磕巴巴,並且說得量又少,屬於及格,若是發音標準並且流利,那麼就屬於良好或優秀了。
從這個笑話裏你們能夠獲得以下的啓示:
第一,說不說有着本質的差異,不說必定是不及格。
第二,內容儘可能符合要求,不求措辭精美,用比較簡單的表達方式便可。由於面試官考察重點不是內容,而是發音(至少能保證聽懂)、流利程度(有信心流利地說,儘可能別磕磕巴巴)和說的語句的數量(別太少,也別太囉嗦)。
第三,說的時候能夠目視面試官,並用手勢等方式互動,以此來展現本身說英語很是有信心。而別低着頭或用其它方式暴露出本身信心不足。
面試官有時會問些刁鑽的問題,對於這類問題,你們應當事先準備好。若是等面試時被問到時再臨時想,未免會措手不及,並且一旦回答很差,輕者面試失分,重者可能直接致使面試失敗。
問題一,你有哪些缺點?
你們別說沒缺點(說出來沒人信),也別說主觀上的缺點,好比粗心辦事拖拉等,能夠往「好心辦壞事」方面說,甚至還能夠適當展現本身的一些優點。好比能夠說,以前在項目裏,我可能比較心急,總想讓項目一天內就作好,因此總會加班來力求按質提早完成任務,這樣就讓其餘成員感受壓力過大了,不利於團隊建設。
最後還得提一句,本身已經意識到這個缺點了,正在改進或已經改正了。好比能夠這樣說,後來項目經理和我溝經過這個問題,讓我定時和組員分享些技術點,以求你們一塊兒進步,當我作了幾回分享後,整個項目組的進度都提高了。
問題二,你本身感受,在以前的項目裏,你有哪些失誤?
這裏你們也能夠往「好心辦壞事」方面說,應當儘可能避免說可能致使項目有重大損失的失誤,好比寫代碼得過且過,或不注重單元測試。
你們能夠按以下說辭的思路來回答這個問題。在以前寫代碼時,我總會盡可能在代碼裏使用設計模式以求提高代碼的可維護性,後來通過項目經理的幫助,我意識到了應當注重進度和質量的平衡,應當只在可能會常常變動的模塊裏使用設計模式。
或者能夠說,在以前遇到問題時,我和測試人員溝通時,總會說些技術相關的術語,這就致使了溝通效率不高。後來我也注意到了,和他們溝通時,應當儘可能注重功能點的實現方式,如今和他們溝通起來就沒什麼問題了。
問題三,若是你和項目經理或同事工做上有分歧,你通常會怎麼處理?
在項目裏,遇到分歧是很正常的,但要讓面試官感受遇到分歧你不會迴避,而是會主動溝通,在溝通時也不是一味強求別人接受你的觀點,而是經過協商得出一個你們都能接受的方案。
對此你們能夠舉例說明,在xx項目裏,在xx功能的實現上,我和項目經理有分歧,我主張用鏈接池,項目經理主張用通常的鏈接便可,不必用鏈接池。對此,我會主動和項目經理溝通,說出我主張的理由,同時也聽下項目經理的理由,最後你們討論出了一個解決方案。
問題四,你指望的團隊工做氛圍是什麼樣的?
遇到這種問題,若是你的指望和招聘公司的狀況不一致,招聘方可能就會懷疑你未必能作久。因此在回答這類問題時,應儘可能少加些本身主觀的願望,好比別說,我但願團隊能定時出去活動,或但願工做的氛圍比較寬鬆。這樣一說,一旦招聘方項目壓力比較緊,而你卻但願寬鬆,那麼成功應聘的可能性就下降了。
對此你們能夠說些不大容易被挑錯的答案。好比能夠說,我但願在團隊裏,遇到技術難點,你們能一塊兒協商解決,遇到有什麼好的點子,也能夠和你們一塊兒分享,若是項目進度比較緊,我也願意一塊兒加班。
問題五,你是否有失敗的經歷?
這裏面試官不在意結果,更關注於你處理問題的心態(得積極些)和措施(應盡最大努力)。所謂失敗,就是沒達到預期目標,這裏你們能夠把預期目標設置高些(對本身嚴格要求),並且能夠展現出是在窮盡一切可能後才遺憾地失敗,同時說下失敗後的補救措施。
這裏給個咱們以前聽到的回答,在以前的項目裏,一段程序消耗的內存過大,峯值達到2個G,我就去優化,(中間省略一些積極的優化措施),最後雖然減小1個G,但離開預約的500M的目標還有差距。在和項目經理確認後,最終咱們不得不給這段程序分配了更多的內存空間。