關(guān)于2019的一些面試實戰(zhàn)小結(jié)

今日頭條屏幕適配的原理?

1:首先計算出 density龟虎,計算公式:當(dāng)前設(shè)備屏幕總寬度(單位為像素)/ 設(shè)計圖總寬度(單位為 dp) = densitydensity 的意思就是 1 dp 占當(dāng)前設(shè)備多少像素計算density 的原因:在布局文件中填寫的是什么單位璃谨,最后都會被轉(zhuǎn)化為 px,系統(tǒng)就是通過上面的方法鲤妥,將你在項目中任何地方填寫的單位都轉(zhuǎn)換為 px

但是佳吞,今日頭條適配方案默認項目中只能以高或?qū)捴械囊粋€作為基準,來進行適配

簡述Android中的加固和使用平臺?

加固:防止代碼反編譯,提高代碼安全性

加固三方平臺,梆梆安全,360加固,愛加密等
區(qū)別:梆梆安全,360加固看不到項目中的類,愛加密看的到Java類,單看不到里面的方法實現(xiàn)體,效果比前面差一點點

加固的底層原理:第三方加固的應(yīng)用會生成一個Apk,然后把你的APK讀取出來,在封裝到這個第三方應(yīng)用的APK里面.

如何對APK瘦身?

1)使用混淆,

2)開啟shrinkResourse(shrink-收縮),會將沒有用到的圖片變成一個像素點

3)刪除無用的語言資源(刪除國際化文件)

4)對于非透明的大圖,使用JPG(沒有透明度信息),代替PNG格式

5)使用tinypng進行圖片壓縮

6)使用webp圖片格式,進一步壓縮圖片資源

7)使用第三方包時把用到的代碼加到項目中來,避免引用整一個第三方庫

簡述多渠道打包及原理和常用操作?

針對每一個渠道(應(yīng)用市場)都生成一個帶有渠道標識的apk文件

原理:用戶下載啟動應(yīng)用,獲取渠道標識,和設(shè)備的唯一標識,并上傳到服務(wù)器里面,服務(wù)器這里就 會根據(jù)獲取的記錄,根據(jù)渠道號然后判斷是否存在該服務(wù)器的表里面.(打標記,取標記,上傳標記)

1)友盟多渠道打包:在清單文件中定義一個占位符,在gradle腳本中替換占位符(會使用到Python)

2)美團打包,在meta-data中創(chuàng)建一個空的文件,以文件名標識渠道,做一個解壓與壓縮的操作,速度會比較快

3)新一代多渠道打包,將渠道標識添加到.apk文件的末尾,并不會對源文件損壞

Android下的數(shù)據(jù)存儲方式有那些?

1)內(nèi)部存儲,直接存儲在內(nèi)部文件中

2)外部存儲,首先要判斷外部存儲條件是否可用,然后進行存儲

3)SP存儲,底層是Xml實現(xiàn)的,以鍵值對形式存儲內(nèi)部的數(shù)據(jù),適宜于輕量級的存儲,存儲的數(shù)據(jù)類型有,boolean,String,int

4)數(shù)據(jù)庫存儲,SQlite存儲,輕量級的數(shù)據(jù)庫,強大的增刪改查功能

5)內(nèi)容提供者,ContentProvider,將自己愿意暴露的一部分數(shù)據(jù)供外部使用操作

6)網(wǎng)絡(luò)存儲,等等

Sharepreference 線程安全問題棉安?

官方文檔明確指出底扳,SharedPreferences不支持多線程,進程也是不安全的

如果想要實現(xiàn)線程安全需重新實現(xiàn)其接口贡耽,如下

image

假設(shè)在多進程訪問SharePreferences的情況下衷模,該如何保證進程安全和共享數(shù)據(jù)?

解決辦法就是:將需要共享數(shù)據(jù)的字段提出來統(tǒng)一存儲到一個文件中羡滑。

Android開發(fā)下如何有效進行屏幕適配?

1:機型適配,去一些統(tǒng)計網(wǎng)站諸如友盟,現(xiàn)在叫友盟+去看一下市場上最流行的Android機型,有針對性的切圖

2:屏幕適配算芯,適配主流xhdpi屏幕尺寸柒昏,使用relativelayout,linerlayout等布局熙揍,多使用matchparent职祷,wrapcontent,及配合weight,權(quán)重處理届囚,

3:還有就是在代碼中有梆,設(shè)計到具體尺寸的要使用dp2px的轉(zhuǎn)換,

4:圖片使用可拉伸.9圖片意系,imageview使用scaletype縮放泥耀;

5:使用權(quán)重,等比例,百分比布局等等

對象序列化:

為什么要序列化?

1)永久性保存對象蛔添,保存對象的字節(jié)序列到本地文件中痰催;

2)通過序列化對象在網(wǎng)絡(luò)中傳遞對象;

3)通過序列化在進程間傳遞對象迎瞧。

在Android中實現(xiàn)序列化有兩個選擇:一是實現(xiàn)Serializable接口(是JavaSE本身就支持的)夸溶,一是實現(xiàn)Parcelable接口(是Android特有功能,效率比實現(xiàn)Serializable接口高效凶硅,可用于Intent數(shù)據(jù)傳遞缝裁,也可以用于進程間通信(IPC))。實現(xiàn)Serializable接口非常簡單足绅,聲明一下就可以了捷绑,而實現(xiàn)Parcelable接口稍微復(fù)雜一些,但效率更高氢妈,推薦用這種方法提高性能粹污。兩種實現(xiàn)方式依舊是貼url,方便大家快速查詢

兩種序列化相關(guān)

既然Google推薦Parcelable這種序列化允懂,在這里厕怜,推薦一鍵生成序列化的插件衩匣,

在Android Studio里面搜索插件蕾总,如下圖,寫起序列化(根本不用你寫)那就是一個美滋滋吶~

OkHttp相關(guān)?

OkHttp支持同步和異步數(shù)據(jù)請求琅捏,但異步請求是在子線程 (因為原生OkHttp的使用時回調(diào)方法是在子線程進行的生百,要刷新界面還需要用Handler作處理,可以使用第三方的okhttp-utils,Okgo等等)柄延;

OkHttp里面封裝了線程池蚀浆、數(shù)據(jù)轉(zhuǎn)換缀程、GZIP壓縮(減少流量的傳輸)、HTTP協(xié)議緩存等,

OKHttp優(yōu)點—-使用GZip壓縮減少傳輸?shù)臄?shù)據(jù)量,緩存(減少重復(fù)請求);

失敗重試(如果你的服務(wù)有多個IP地址,如果第一次連接失敗,OKHttp將使用備用地址)

OKhttp是對http協(xié)議的封裝,比較底層,因此拓展性強,便于封裝;

OKhttp基于NIO(JDK1.5,非阻塞式IO)效率更高

ButterKnife相關(guān)?

簡介:一款快速高效的注入框架市俊,節(jié)約開發(fā)時間減少代碼量(依靠插件動態(tài)生成View,點擊事件等等)

優(yōu)點:

1.強大的View綁定和Click事件處理功能杨凑,簡化代碼,提升開發(fā)效率

2.方便的處理Adapter里的ViewHolder綁定問題

3.運行時不會影響APP效率摆昧,使用配置方便

4.代碼清晰撩满,可讀性強

使用經(jīng)驗:

1.Activity ButterKnife.bind(this);必須在setContentView();之后,且父類bind綁定后绅你,子類不需要再bind

2.Fragment ButterKnife.bind(this, mRootView);

3.屬性布局不能用private or static 修飾伺帘,否則會報錯,(注意權(quán)限)

4.setContentView()不能通過注解實現(xiàn)忌锯。(其他的有些注解框架可以)

原理:利用注解和反射去獲取綁定ViewID,

關(guān)于原理詳情可參考筆者的這一篇:Android-定制專屬ButterKnife框架,該文詳細介紹了ButterKnife框架并模仿了一個注解綁定View的框架

Rxjava概念,常用操作符及拓展?

簡介:

一款優(yōu)雅的異步框架,代替之前的AsyncTask / Handler / XXX / …

其強大的操作符和鏈式寫法,線程切換等有助于提高開發(fā)效率和快速定位Bug

與Retrofit搭配使用更是有意想不到的效果伪嫁,

底層原理:觀察者模式

等一些相應(yīng)的博客

缺點:

1:操作符太多會增加學(xué)習(xí)成本時間

2:使用不好,容易導(dǎo)致內(nèi)存泄露(解決方式偶垮,推薦Rxlifecycle結(jié)合Rxjava张咳,規(guī)避內(nèi)存泄漏風(fēng)險)

ANR相關(guān)

ANR全名Application Not Responding, 也就是”應(yīng)用無響應(yīng)”. 當(dāng)操作在一段時間內(nèi)系統(tǒng)無法處理時, 系統(tǒng)層面會彈出上圖那樣的ANR對話框.

在Android里, App的響應(yīng)能力是由Activity Manager和Window Manager系統(tǒng)服務(wù)來監(jiān)控的. 通常在如下兩種情況下會彈出ANR對話框:

A) 5s內(nèi)無法響應(yīng)用戶輸入事件(例如鍵盤輸入, 觸摸屏幕等).

B) BroadcastReceiver在10s內(nèi)無法結(jié)束.

造成以上兩種情況的首要原因就是在主線程(UI線程)里面做了太多的阻塞耗時操作,, 例如文件讀寫, 數(shù)據(jù)庫讀寫, 網(wǎng)絡(luò)查詢等等.

如何分析ANR?

ANR產(chǎn)生時, 系統(tǒng)會生成一個traces.txt的文件放在/data/anr/下. 開發(fā)人員可通過adb命令將其導(dǎo)出到本地 ($adb pull data/anr/traces.txt .)通過分析,我們可以根據(jù)具體的日志查看Anr原因( 如: 普通阻塞,CPU滿負荷,內(nèi)存泄露 )

Android中那些場景是執(zhí)行在主線程的?

1)Activity生命周期回調(diào)都是執(zhí)行在主線程的.

2)Service默認是執(zhí)行在主線程的.

3)BroadcastReceiver的onReceive回調(diào)是執(zhí)行在主線程的.

4)沒有使用子線程的looper的Handler的handleMessage, post(Runnable)是執(zhí)行在主線程的.

5)AsyncTask的回調(diào)中除了doInBackground, 其他都是執(zhí)行在主線程的.

6)View的post(Runnable)是執(zhí)行在主線程的.等等

三級緩存:

當(dāng)我們第一次打開應(yīng)用獲取圖片或其它資源時,首先到網(wǎng)絡(luò)去下載似舵,然后依次存入內(nèi)存緩存晶伦,磁盤緩存,

當(dāng)我們再一次需要用到剛才下載的這張圖片時啄枕,就不需要再重復(fù)的到網(wǎng)絡(luò)上去下載婚陪,直接可以從內(nèi)存緩存和磁盤緩存中找,由于內(nèi)存緩存速度較快频祝,我們優(yōu)先到內(nèi)存緩存中尋找該圖片泌参,如果找到則運用,

如果沒有找到(內(nèi)存緩存大小有限)常空,那么我們再到磁盤緩存中去找沽一。

只要我們合理的去協(xié)調(diào)這三層緩存運用,便可以提升應(yīng)用性能,給用戶更好的體驗

三級緩存指的是:內(nèi)存緩存漓糙、本地緩存铣缠、網(wǎng)絡(luò)緩存。其各自的特點是內(nèi)存緩存速度快, 優(yōu)先讀取昆禽,本地緩存速度其次, 內(nèi)存沒有該資源信息就去讀取本地內(nèi)存蝗蛙,網(wǎng)絡(luò)緩存速度較慢(比較對象是內(nèi)存緩存和本地緩存),假設(shè)本地內(nèi)存也沒有,才請求網(wǎng)絡(luò)獲取。

內(nèi)存泄漏:

當(dāng)應(yīng)用內(nèi)部不再需要某個實例后醉鳖,但是這個對象卻仍然被引用捡硅,這個情況就叫做內(nèi)存泄露(Memory Leak)。安卓虛擬機為每一個應(yīng)用分配一定的內(nèi)存空間盗棵,當(dāng)內(nèi)存泄露到達一定的程度就會造成內(nèi)存溢出壮韭。
導(dǎo)致內(nèi)存泄露常見原因:
1)靜態(tài)變量直接或者間接地引用了Activity對象就會造成內(nèi)存泄露

2)Activity使用了靜態(tài)的View(View會持有Activity的對象的引用)

3)Activity定義了靜態(tài)View變量???

4)ImageSpan引用了Activity Context

5)單例中引用了Activity的Context(需要使用Application的Context)

6)對于使用了BraodcastReceiver北发,ContentObserver,F(xiàn)ile喷屋,Cursor琳拨,Stream,Bitmap等資源屯曹,應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷从绘,否則這些資源將不會被回收,從而造成內(nèi)存泄漏是牢。

7)靜態(tài)集合保存的對象沒有及時消除(不使用的時候置為null)

8)在Java中,非靜態(tài)(匿名)內(nèi)部類會引用外部類對象,而靜態(tài)內(nèi)部類不會引用外部類對象

9)在Activity中,創(chuàng)建了非靜態(tài)內(nèi)部類(內(nèi)部類直接或者間接引用了Activity)的靜態(tài)成員變量

10)線程包括AsyncTask的使用,Activity退出后線程還在運行(線程在死循環(huán)),并且在線程中使用了Activity或view對象(解決方法:不要直接寫死循環(huán),可以設(shè)置一個布爾類型的TAG,當(dāng)activity推出的時候,設(shè)置TAG為False)

11)Handler對象的使用,Activity退出后Handler還是有消息需要處理(解決方法:在退出activity之后,移除消息)

12)WebView造成的內(nèi)存泄漏(在onDestory中銷毀)

如何進行內(nèi)存泄露分析?

A: 通過Android Studio 窗口進行分析,查看內(nèi)存分配情況,如果操作應(yīng)用是內(nèi)存一直往上漲說明存在內(nèi)存泄露

B: 定位內(nèi)存泄露分析的工具—-MAT(Memory Analyzer tool)

C: 使用開源庫LeakCanary快速定位內(nèi)存泄露

Android中的四大組件相關(guān)?

Activity:

Activity是一個應(yīng)用程序組件僵井,提供一個屏幕(狹義的理解就是當(dāng)前APP的界面),用戶可以用來交互為了完成某項任務(wù)驳棱。(點擊,登錄,跳轉(zhuǎn)頁面)

Activity中所有操作都與用戶密切相關(guān)批什,是一個負責(zé)與用戶交互的組件,可以通過setContentView(View)來顯示指定控件(設(shè)置布局文件)社搅。

在一個android應(yīng)用中驻债,一個Activity通常就是一個單獨的屏幕,它上面可以顯示一些控件也可以監(jiān)聽并處理用戶的事件做出響應(yīng)形葬。

Activity四種啟動模式?

Activity的啟動模式指,可以根據(jù)實際開發(fā)需求為Activity設(shè)置對應(yīng)的啟動模式合呐,從而可以避免創(chuàng)建大量重復(fù)的Activity等問題。

1)standard

standard為Activity的默認啟動模式笙以,可以不用寫配置淌实。在這個模式下,都會默認創(chuàng)建一個新的實例猖腕。因此拆祈,在這種模式下,可以有多個相同的實例倘感,也允許多個相同Activity疊加放坏。(點back鍵會依照棧順序依次退出)

2)singleTop

singleTop模式下,Activity可以有多個實例,但是不允許多個相同Activity疊加老玛。即淤年,如果Activity在棧頂?shù)臅r候,啟動相同的Activity蜡豹,不會創(chuàng)建新的實例麸粮,而會調(diào)用其onNewIntent方法。

3)singleTask

singleTask表示只有一個實例余素。在同一個應(yīng)用程序中啟動他的時候豹休,若Activity不存在炊昆,則會在當(dāng)前task創(chuàng)建一個新的實例桨吊,若存在威根,則會把task中在其之上的其它Activity destory掉并調(diào)用它的onNewIntent方法。如果是在別的應(yīng)用程序中啟動它视乐,則會新建一個task洛搀,并在該task中啟動這個Activity,singleTask允許別的Activity與其在一個task中共存佑淀,也就是說留美,如果我在這個singleTask的實例中再打開新的Activity,這個新的Activity還是會在singleTask的實例的task中伸刃。

4)singleInstance

只有一個實例谎砾,并且這個實例獨立運行在一個task中,這個task只有這個實例捧颅,不允許有別的Activity存在景图。

BraodcastReceiver:(待補充)

使用了設(shè)計模式中的觀察者模式:基于消息的發(fā)布/訂閱事件模型。

注冊的方式分為兩種:靜態(tài)注冊碉哑、動態(tài)注冊

ContentProvider:(待補充)

外界可以通過ContentResolver接口來訪問ContentProvider(內(nèi)容提供者)中的數(shù)據(jù)挚币。Uri 通用資源標志符(Universal Resource Identifier)Uri代表要操作的數(shù)據(jù),Android中可用的每種資源 - 圖像扣典、視頻片段等都可以用Uri來表示妆毕。ContentProvider共享數(shù)據(jù)是通過定義一個對外開放的統(tǒng)一的接口來實現(xiàn)的。然而贮尖,應(yīng)用程序并不直接調(diào)用這些方法笛粘,而是使用一個 ContentResolver 對象,調(diào)用它的方法作為替代湿硝。ContentResolver可以與任意內(nèi)容提供者進行會話闰蛔,與其合作來對所有相關(guān)交互通訊進行管理。當(dāng)外部應(yīng)用需要對ContentProvider中的數(shù)據(jù)進行添加图柏、刪除序六、修改和查詢操作時,可以使用ContentResolver類來完成蚤吹,要獲取ContentResolver對象例诀,可以使用Context提供的getContentResolver()方法。

IntentService:

IntentService是Service的子類裁着,比普通的Service增加了額外的功能繁涂。IntentService會創(chuàng)建獨立的worker線程來處理所有的Intent請求;會創(chuàng)建獨立的worker線程來處理onHandleIntent()方法實現(xiàn)的代碼二驰,無需處理多線程的問題扔罪;所有請求處理完成后,IntentService會自動停止桶雀,開發(fā)者無需手動調(diào)用stopSelf()方法停止Service矿酵;

簡述System.exit(0) 唬复、onDestory()、Activity.finish()三者的區(qū)別

1)System.exit(0) 是你正常結(jié)束程序,kill 掉當(dāng)前進程,針對的是整個Application

2)onDestory()方法是Activity生命周期的最后一步全肮,資源空間等就被回收了敞咧。當(dāng)重新進入此Activity的時候,必須重新創(chuàng)建辜腺,執(zhí)行onCreate()方法.

3)Activity.finish()當(dāng)你調(diào)用此方法的時候休建,系統(tǒng)只是將最上面的Activity移出了棧剂癌,并沒有及時的調(diào)用onDestory()方法禽捆,也就是占用的資源沒有被及時釋放。

圖片優(yōu)化形导,以及圖片加載框架的使用百匆,如Picasso邑彪、 Fresco、Glide等胧华?

1)盡量使用小的圖片,對圖片進行壓縮寄症,bitmapfactory.options圖片配置類,insimplesize進行縮放矩动,設(shè)置圖片的編碼方式有巧;對圖片使用軟引用,內(nèi)存不夠時即時釋圖片內(nèi)存悲没;對圖片的復(fù)用篮迎,三級緩存的使用;

即時回收不再使用的bitmap對象示姿;

2)Picasso,不支持gif甜橱,緩存的是Argb8888的原圖,占用內(nèi)存較大,圖片的框架使用了OkHttp緩存機制,使用Http協(xié)議緩存,也是異步加載.

3)Fresco,框架是FaceBook公司推出的,適合批量加載圖片,底層是通過三級緩存(2級內(nèi)存,1級磁盤)

加載成功后自動替換成目標圖片

4)glide,Google公司14年推出來的,可以加載GIF圖,也可以根據(jù)指定圖片清晰度,底層的原理:為Bitmap維護一個對象池,對象池的目的是通過減少對象的分配,以重用來提高性能.對象池也可以幫助提高滾動的性能栈戳。API簡潔易調(diào)用

Handle相關(guān):

Handler 工作流程基本包括 Handler岂傲、Looper、Message子檀、MessageQueue 四個部分镊掖。但我們在日常開發(fā)中,經(jīng)常都只會用到 Handler 和 Message 兩個類褂痰。Message 負責(zé)消息的搭載亩进,里面有個target用于標記消息,obj用于存放內(nèi)容缩歪,Handler 負責(zé)消息的分發(fā)和處理归薛。

一般在開發(fā)中是怎么使用 Handler 的?

官方不允許在子線程中更新 UI,所以我們經(jīng)常會把需要更新 UI 的消息直接發(fā)給處理器 Handler主籍,通過重寫 Handler 的handleMessage()方法進行 UI 的相關(guān)操作习贫。

Handle使用中就沒什么需要注意的嗎?

有崇猫,Handler 如果設(shè)置為私有變量的話沈条,Android Studio 會報警告需忿,提示可能會造成內(nèi)存泄漏诅炉,這種情況可以通過設(shè)置為靜態(tài)內(nèi)部類 + 弱引用,或者在onDestroy()方法中調(diào)用Handler.removeCallbacksAndMessages(null)即可避免

Handler 整體工作流程淺析分為以下四個步驟:

異步通信準備 => 消息入隊 => 消息循環(huán) => 消息處理

A:異步通信準備

I:假定是在主線程創(chuàng)建 Handler屋厘,則會直接在主線程中創(chuàng)建處理器對象Looper涕烧、消息隊列對象MessageQueue和 Handler 對象。

需要注意的是汗洒,Looper和MessageQueue均是屬于其創(chuàng)建線程的议纯。

II:Looper對象的創(chuàng)建一般通過Looper.prepareMainLooper()和Looper.prepare()兩個方法,而創(chuàng)建Looper對象的同時溢谤,將會自動創(chuàng)建MessageQueue瞻凤。

III:創(chuàng)建好MessageQueue后,Looper將自動進入消息循環(huán)世杀。此時阀参,Handler自動綁定了主線程的Looper和MessageQueue。

B:消息入隊

工作線程通過Handler發(fā)送消息Message到消息隊列MessageQueue中瞻坝,消息內(nèi)容一般是 UI 操作蛛壳。發(fā)送消息一般都是通過Handler.sendMessage(Message msg)和Handler.post(Runnabe r)兩個方法來進行的。而入隊一般是通過MessageQueue.enqueueeMessage(Message msg,long when)來處理所刀。

C:消息循環(huán)

主要分為「消息出隊」和「消息分發(fā)」兩個步驟衙荐,Looper會通過循環(huán)取出消息隊列MessageQueue里面的消息Message,并分發(fā)到創(chuàng)建該消息的處理者Handler浮创。如果消息循環(huán)過程中忧吟,消息隊列MessageQueue為空隊列的話,則線程阻塞斩披。

D:消息處理

Handler接收到Looper發(fā)來的消息瀑罗,開始進行處理。

拓展

先簡單介紹下你自己雏掠?

分析:除了向面試官做簡單的基本自我介紹之外斩祭,還需向面試官展現(xiàn)自身對該職業(yè)所必須具備的一些自身特質(zhì),

比如乡话,面試程序員職業(yè)需要間接的向面試官表示自己思維嚴謹摧玫,對細節(jié)的處理,理性思維,假設(shè)論證等等诬像;面試產(chǎn)品等職業(yè)屋群,需要向面試官通過自己的一些故事間接展現(xiàn)對產(chǎn)品的看法以及獨特的思維個性等等

切入點:自身特質(zhì)能否符合該職位的預(yù)期需求

自己的興趣愛好特長有那些?

在企業(yè)和面試官看來坏挠,如果求職者的愛好和應(yīng)聘的崗位在某些方面恰恰有正向關(guān)聯(lián)芍躏,就會有興趣。面試官也會通過應(yīng)聘者的興趣愛好來判斷其價值觀是否與企業(yè)文化契合降狠,能否很好地融入工作團隊对竣。求職者的回答將有可能為面試加分。

下列興趣愛好所反映出的一些性格和職業(yè)方向可供參考:

1.籃球榜配,足球否纬,排球:團隊精神,適用大多數(shù)崗位蛋褥。

2.圍棋临燃,國際象棋:戰(zhàn)略意識,適合市場類或高端職位烙心。

3.閱讀膜廊,古典音樂:高雅,適合文職類的職位淫茵。

4.旅游:適應(yīng)不同環(huán)境的能力爪瓜,快速學(xué)習(xí)的能力,適合銷售業(yè)務(wù)類職位痘昌。

5.舞蹈:外向钥勋,易溝通,適合公關(guān)辆苔、市場類的職位算灸。

對自己的期望和規(guī)劃?

分析:職業(yè)發(fā)展規(guī)劃表面上看是在考察你(求職者)驻啤、職位菲驴、公司三者之間長期的契合程度,但實際上骑冗,這么大的一個問題完全不是三眼兩語間能夠表達清楚的赊瞬。面試官(無論HR還是專業(yè)部門的)主要是看你回答問題時的思路是否清晰,回答中表現(xiàn)出的工作態(tài)度如何贼涩,順便看看你是否對公司和職位有足夠的了解巧涧。所以不管答案如何,最關(guān)鍵的就是不能茫然遥倦。

切入點:依舊自身特點谤绳,對未來期望和規(guī)劃需表述清晰,思維敏捷

談?wù)勛约旱膬?yōu)點和缺點?

先談缺點:

技術(shù)行業(yè)面試基本是由該崗位未來同事和上司進行缩筛。這種面試技術(shù)性強消略,行為問題主要考察就是你是否真心想做這個工作(而不是當(dāng)跳板或者聽說高薪體面而來)和你性格與文化是否相符。所有答案都應(yīng)該圍繞這兩點組織(即每個經(jīng)歷都應(yīng)回歸到你通過這個經(jīng)歷學(xué)到什么瞎抛,該職位所需關(guān)鍵技巧艺演,這些經(jīng)歷為何讓你想做這個工作,和該經(jīng)歷體現(xiàn)出你什么樣的個人風(fēng)格)桐臊。對這個問題因為好的回答而留下好印象很難胎撤,

關(guān)鍵是避免留下壞印象。

要點以下:

1)避免避重就輕豪硅,不要談一個算不得缺點的缺點哩照。比如熬夜會困挺物,或者(待人接物)太客氣等等懒浮。

2)避免談非職業(yè)缺點,比如有感情潔癖识藤,挑食砚著,不擅長陪女友逛街,做飯經(jīng)常不懂會煮糊痴昧。

3)避免談到無法改善的弱點稽穆,比如我算數(shù)必須用計算器,我腦子不好用看書不理解赶撰。

4)避免談到致命弱點舌镶,比如脾氣怪異,不喜歡合作,遲到早退等。

那談什么最好呢豪娜?我認為要點有三:

1)談已經(jīng)在改正的缺點/有明確計劃來改正的缺點餐胀。尤其是你能夠充分論證在近期就可以解決的缺點。

2)談一個利用你的優(yōu)點改正的缺點瘤载,順便帶出一個優(yōu)點否灾。(這是較高效的溝通技巧)

相對較好的回答:

1)喜歡追求細節(jié)導(dǎo)致項目/作業(yè)未能按期完成。通過時間管理能力改變工作方式鸣奔,先完成框架再改善細節(jié)得以解決墨技;

2)不知如何拒絕,同事要求幫忙一概攬下挎狸,影響自身工作進度扣汪。通過多任務(wù)處理能力設(shè)定優(yōu)先順序,以該優(yōu)先順序表向求助同事展示自己手上工作锨匆,并給其一個自己在何時可以給予幫助的時間估計崭别,讓求助人自行決定是否求助,問題解決

3)對處理同一問題的解決辦法上,由于組員自己的技術(shù)偏好和技術(shù)構(gòu)成不一樣容易造成溝通障礙及影響項目計劃紊遵,所以,應(yīng)學(xué)會高效和有效溝通方式及工作技巧
關(guān)于2019的一些面試實戰(zhàn)就小結(jié)到這里了,另外分享一些關(guān)于Android開發(fā)進階的小資料給大家账千,進qq 群【512255478】直接找群主即可領(lǐng)取。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末暗膜,一起剝皮案震驚了整個濱河市匀奏,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌学搜,老刑警劉巖娃善,帶你破解...
    沈念sama閱讀 219,539評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異瑞佩,居然都是意外死亡聚磺,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,594評論 3 396
  • 文/潘曉璐 我一進店門炬丸,熙熙樓的掌柜王于貴愁眉苦臉地迎上來瘫寝,“玉大人,你說我怎么就攤上這事稠炬』腊ⅲ” “怎么了?”我有些...
    開封第一講書人閱讀 165,871評論 0 356
  • 文/不壞的土叔 我叫張陵首启,是天一觀的道長暮屡。 經(jīng)常有香客問我,道長毅桃,這世上最難降的妖魔是什么褒纲? 我笑而不...
    開封第一講書人閱讀 58,963評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮钥飞,結(jié)果婚禮上莺掠,老公的妹妹穿的比我還像新娘。我一直安慰自己代承,他們只是感情好汁蝶,可當(dāng)我...
    茶點故事閱讀 67,984評論 6 393
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著论悴,像睡著了一般掖棉。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上膀估,一...
    開封第一講書人閱讀 51,763評論 1 307
  • 那天幔亥,我揣著相機與錄音,去河邊找鬼察纯。 笑死帕棉,一個胖子當(dāng)著我的面吹牛针肥,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播香伴,決...
    沈念sama閱讀 40,468評論 3 420
  • 文/蒼蘭香墨 我猛地睜開眼慰枕,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了即纲?” 一聲冷哼從身側(cè)響起具帮,我...
    開封第一講書人閱讀 39,357評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎低斋,沒想到半個月后蜂厅,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,850評論 1 317
  • 正文 獨居荒郊野嶺守林人離奇死亡膊畴,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,002評論 3 338
  • 正文 我和宋清朗相戀三年掘猿,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片唇跨。...
    茶點故事閱讀 40,144評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡稠通,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出轻绞,到底是詐尸還是另有隱情采记,我是刑警寧澤佣耐,帶...
    沈念sama閱讀 35,823評論 5 346
  • 正文 年R本政府宣布政勃,位于F島的核電站,受9級特大地震影響兼砖,放射性物質(zhì)發(fā)生泄漏奸远。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,483評論 3 331
  • 文/蒙蒙 一讽挟、第九天 我趴在偏房一處隱蔽的房頂上張望懒叛。 院中可真熱鬧,春花似錦耽梅、人聲如沸薛窥。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,026評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽诅迷。三九已至,卻和暖如春众旗,著一層夾襖步出監(jiān)牢的瞬間罢杉,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,150評論 1 272
  • 我被黑心中介騙來泰國打工贡歧, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留滩租,地道東北人赋秀。 一個月前我還...
    沈念sama閱讀 48,415評論 3 373
  • 正文 我出身青樓,卻偏偏與公主長得像律想,于是被迫代替她去往敵國和親猎莲。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,092評論 2 355

推薦閱讀更多精彩內(nèi)容