python面試常用庫

① python運維開發工程師面試常見問題有哪些

面試python運維開發工程師每家公司對專業知識的考察側重點是不一樣的，下面給你整理了一些，希望能幫助到你!
python
1、python是強類型還是弱類型的語言
2、python的動態性體現在哪
3、python的namespace：四種；len()等函數的命名空間
4、range和xrange的區別，談到了迭代器
5、於是問怎麼實現迭代器，然後又問了生成器，yield語句
6、將list的中的一萬條字元串合成一條字元串的方法
7、python多線程（g il）
8、python的三目運算符有嗎？ 怎麼用一行代碼實現三目運算
linux
1、問linux命令
2、top和ps在進程佔有資源率的統計方式有什麼不同
3、然後扯到了頁表，內存管理，TLB
5、linux文件系統：inode，inode存儲了哪些東西，目錄名，文件名存在哪裡

② python面試一般問什麼常用設計模式

1.設計模式介紹
設計模式（Design Patterns）

——可復用面向對象軟體的基礎

設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。

2. 設計模式分類
經典的《設計模式》一書歸納出23種設計模式，這23種模式又可歸為，創建型、結構型和行為型3大類

2.1．創建型模式
前面講過，社會化的分工越來越細，自然在軟體設計方面也是如此，因此對象的創建和對象的使用分開也就成為了必然趨勢。因為對象的創建會消耗掉系統的很多資源，所以單獨對對象的創建進行研究，從而能夠高效地創建對象就是創建型模式要探討的問題。這里有6個具體的創建型模式可供研究，它們分別是：

簡單工廠模式（Simple Factory）；

工廠方法模式（Factory Method）；

抽象工廠模式（Abstract Factory）；

創建者模式（Builder）；

原型模式（Prototype）；

單例模式（Singleton）。

說明：嚴格來說，簡單工廠模式不是GoF總結出來的23種設計模式之一。

2.2 結構型模式
在解決了對象的創建問題之後，對象的組成以及對象之間的依賴關系就成了開發人員關注的焦點，因為如何設計對象的結構、繼承和依賴關系會影響到後續程序的維護性、代碼的健壯性、耦合性等。對象結構的設計很容易體現出設計人員水平的高低，這里有7個具體的結構型模式可供研究，它們分別是：

外觀模式（Facade）；

適配器模式（Adapter）；

代理模式（Proxy）；

裝飾模式（Decorator）；

橋模式（Bridge）；

組合模式（Composite）；

享元模式（Flyweight）

2.3 行為型模式
在對象的結構和對象的創建問題都解決了之後，就剩下對象的行為問題了，如果對象的行為設計的好，那麼對象的行為就會更清晰，它們之間的協作效率就會提高，這里有11個具體的行為型模式可供研究，它們分別是：

模板方法模式（Template Method）；

觀察者模式（Observer）；

狀態模式（State）；

策略模式（Strategy）；

職責鏈模式（Chain of Responsibility）；

命令模式（Command）；

訪問者模式（Visitor）；

調停者模式（Mediator）；

備忘錄模式（Memento）；

迭代器模式（Iterator）；

解釋器模式（Interpreter）。

3. 設計模式的六大原則
1、開閉原則（Open Close Principle）

開閉原則就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類，後面的具體設計中我們會提到這點。

2、里氏代換原則（Liskov Substitution Principle）

里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。—— From Bai 網路

3、依賴倒轉原則（Dependence Inversion Principle）

這個是開閉原則的基礎，具體內容：真對介面編程，依賴於抽象而不依賴於具體。

4、介面隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的介面，比使用單個介面要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟體的設計思想，從大型軟體架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。

5、迪米特法則（最少知道原則）（Demeter Principle）

為什麼叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。

6、合成復用原則（Composite Reuse Principle）

原則是盡量使用合成/聚合的方式，而不是使用繼承。

③ Python後端工程師面試題目有哪些

1. 我從來不問google可獲得的答案的問題， 只是問問面試者「在過去的工作中，遇到的Ta認為最有成就感的一件事情是什麼」和「如果出現了一個google不到的問題，你會怎麼解決」這樣的問題。

2. 我從來不問操作系統等和Python無關的話題，首先是我不怎麼問和工作太無關的話題，有些東西用不到很多就被會遺忘，挑起來這種問題其實挺無聊；其次我是非計算機專業畢業，問的東西說不定我自己都沒有把握，那就不出來獻丑了。我只關注面試者的學習能力和解決問題的方式，說白了，是不是就是看他是不是「聰明的人」。

3. 不問面試者的短處。我在自己被面試的時候有過這種精力，面試者問他擅長的內容，我不一定搞的定，如果反過來面試Ta，我也會滅掉Ta。所以我會盡力尋找面試者的優勢和優點，尤其是對方已經明確承認。其實很多經驗和能力，只是需要一個機會和環境，所以我不想放過任何一個合適的人。

4. 面試者不會Python也沒有關系。面試者的主動性和學習能力覺得更重要，如果他在其他領域能證明做的不錯或者能讓我感覺到這個一個未來有潛質成為優秀工程師的人，不會Python沒有關系。 嗯目前看來，我沒有看錯過。

5. 我從來不問Python語法這種看書和google就能學會的問題，我只想了解Ta是否願意去學。舉個例子，我會讓面試者「講講日常開發中都用到了那些Python內置的模塊」，原因在我的專欄「Python之美 - 知乎專欄」的 Python不能不知的模塊 - Python之美 - 知乎專欄中有寫，基本上說完我就能評估出他的能力和風格，繼而就是再問一些問題去驗證我的評估是不是准確。

6. 最後，我一般都會和面試者細聊一個Ta認為在過去的工作或者自己開源的項目中最熟悉的一個，從項目設計、踩過的坑兒、開發周期以及如何安排、如何確定需求、如何和其他人協作等方面，最後評估下Ta是否能很容易的融入到我們現在的團隊，大家是否可以接受Ta，對工作不負責的、沒有用心工作的、沒有團隊意識的、溝通能力有缺陷的就放棄掉，對性格上容易發生沖突的、不適合團隊合作的我就得考慮下，未來也會如實反饋給HR。

④ python的筆試面試題，或題庫哪裡有

特殊的語句yield, with
垃圾回收機制
Decorators的定義,以及用法
python線程機制以及為啥python多線程很慢。
Errors and Exceptions
還有什麼比較重要的，大家幫我想想，我一時想不起來還有哪些比較重要了。

⑤ 心得分享!Python面試都要做哪些准備

首先，准備好簡歷。找工作，最開始競爭的是什麼?最開始競爭的是簡歷。你到任何一家公司應聘，第一件要做的事情就是投簡歷，簡歷是應聘公司了解你的第一窗口，也是應聘公司了解你的第一途徑。一份好的簡歷可以讓你在眾多的簡歷中脫穎而出，給招聘者留下深刻印象，然後決定給你面試通知，它是幫助你成功面試的敲門磚。

其次，對於Python常見面試問題要有了解。在面試前我們一定要通過各種渠道了解Python面試中常見的面試問題，做到心中有數。在Python的面試中，一些Python基本常識問題，有些面試官還是會考察的，如果你連基本的常識問題都回答不上來，那麼你後面的面試可能無法進行下去，如果能勉強進行下去，最後面試的成功率也會降低。

最後，在面試前准備一套大方得體的服裝。穿著得體表現的是對面試的尊重。穿著得體，會給面試官一種愉悅的心情。相反，如果你穿著比較邋遢，當面試官看到你的時候，會覺得你不注意細節，有的面試官甚至會懷疑你的工作能力，這樣會給面試官留下非常不好的印象，也可能最後導致面試的失敗。

如果在面試前你做好充足的准備，面試官會覺得你是一個對於工作認真、態度真誠的一個人，會增加心裡認同感，也會增加面試的成功率。

關於心得分享!Python面試都要做哪些准備，環球青藤小編就和大家分享到這里了，學習是永無止境的，學習一項技能更是受益終身，所以，只要肯努力學，什麼時候開始都不晚。如果您還想繼續了解關於python編程的學習方法及素材等內容，可以點擊本站其他文章學習。

⑥ 面試題：你為什麼選擇python

為什麼Python比MATLAB、R語言好呢？
其實，這三種語言都很多數據分析師在用，但更推薦python，主要是有以下幾點：
1、python易學、易讀、易維護，處理速度也比R語言要快，無需把資料庫切割；
2、python勢頭猛，眾多大公司需要，市場前景廣闊；而MATLAB語言比較局限，專注於工程和科學計算方面，而且MATLAB價格貴，免費版或盜版都只能玩玩學慣用；
3、python具有豐富的擴展庫，這個是其他兩個不能比的；
python版本選擇
初學者版本選擇是很多人都會問的，我們也不會偏向某個版本，主要根據自己的所需，但建議是選擇最新版本Python3.x，這樣很多新功能和舊功能都會有的，但是目前很多第三方庫仍然不支持Python3,因為Python2.x已經停止繼續開發，不意味著不能使用。

⑦ python要學到什麼程度能找工作

下面我們就來看看Python學到什麼程度才算是真正學會Python可以去一展身手。

一、確立目標、了解需求

做什麼事情都要先確定好目標，才不至於迷失方向。我們就是Python爬蟲工程師為職位目標。

通過分析各大招聘網站，我們可以得出以下幾點：

1、 python 不是唯一可以做爬蟲的，很多語言都可以，尤其是 java,同時掌握它們和擁有相關開發經驗是很重要的加分項

2、 大部分的公司都要求爬蟲技術有一定的深度和廣度，深度就是類似反反爬、加密破解、驗證登錄等等技術；廣度就是分布式、雲計算等等，這都是加分項

3、 爬蟲，不是抓取到數據就完事了，如果有數據抽取、清洗、消重等方面經驗，也是加分項

4、 一般公司都會有自己的爬蟲系統，而新進員工除了跟著學習以外最常做的工作就是維護爬蟲系統，這點要有了解

5、 最後一個加分項就是前端知識，尤其是常用的 js、ajax、html/xhtml、css 等相關技術為最佳，其中 js 代碼的熟悉是很重要的

6、 補充一條，隨著手持設備的市場佔比越來越高，app 的數據採集、抓包工具的熟練使用會越來越重要

以上內容，不要求全部掌握，但是掌握的越多，那麼你的重要性就越高

二、關於Python面試的四點，你做到就萬事大吉了！

第一點：Python

因為面試的是Python爬蟲崗位，面試官大多數會考察面試者的基礎的Python知識，包括但不限於：

Python2.x與Python3.x的區別

Python的裝飾器

Python的非同步

Python的一些常用內置庫，比如多線程之類的

Python的線程

python學習網，大量的免費python學習視頻，歡迎在線學習！

第二點：數據結構與演算法

數據結構與演算法是對面試者尤其是校招生面試的一個很重要的點，當然小公司不會太在意這些，從目前的招聘情況來看對面試者的數據結構與演算法的重視程度與企業的好壞成正比，那些從不問你數據結構的你就要當心他們是否把你當碼農用的，當然以上情況不絕對，最終解釋權歸面試官所有。

第三點：Python爬蟲

最重要也是最關鍵的一點當然是你的Python爬蟲相關的知識與經驗儲備，這通常也是面試官考察的重點，包括但不限於：

你遇到過的反爬蟲的策略有哪些？

你常用的反反爬蟲的方案有哪些？

你用過多線程和非同步嗎？除此之外你還用過什麼方法來提高爬蟲效率？

有沒有做過增量式抓取？

對Python爬蟲框架是否有了解？

第四點：爬蟲相關的項目經驗

爬蟲重在實踐，除了理論知識之外，面試官也會十分注重爬蟲相關的項目：

你做過哪些爬蟲項目？如果有Github最好

你認為你做的最好的爬蟲項目是哪個？其中解決了什麼難題？有什麼特別之處？

以上問題都能解決，面試已經不成問題了。

⑧ python自動化測試面試題問答匯總

（1）根據需求文檔，深挖需求文檔中的細節進行用例設計
（2）根據自己的測試經驗和一些常識補充用例
（3）參考同事曾寫過的用例或網上的資料進行一些用例補充

測試序號、測試模塊、測試環境、前置條件、操作步驟和數據、預期結果、實際結果、是否通過、備注

（1）等價類劃分法：把所有可能輸入的數據劃分為若干個區域，然後從每個區域中取少數有代表性的數據進行測試即可。有效等價類、無效等價類
（2）邊界值分析法：輸入條件是一個取值范圍，對取值范圍的邊界進行邊界值測試；輸入條件中規定輸入數據是一個有序集合，對有序集合的邊界進行邊界值測試。
（3）錯誤推測法：根據經驗的補充，如超長混合字元串，全形字元串、數字「0」及單引號
（4）正交表分析法：多個輸入框組合的情況，可以藉助正交設計助手小工具，有效減少用例設計個數
（5）因果判定法：

（1）測試用例是否依據需求文檔進行編寫
（2）測試用例中的執行步驟、輸入數據是否清晰、簡潔、正確；對於重復度高的執行步驟，是否進行了簡化
（3）每個測試用例是否有明確的預期結果
（4）測試用例中是否有多餘的用例
（5）測試用例中是否覆蓋了需求文檔的所有功能點，是否有遺漏

（1）要確保測試用例是針對需求文檔編寫的，確保測試點能覆蓋所有的需求點
（2）保證操作步驟、具體數據、預期結果的清晰性、簡潔性、明確性，以確保測試用例的可操作性和可復用性
（3）確保有足夠多的異常測試用例，同時要確保沒有多餘的重復用例
（4）對測試用例進行評審

（1）大致體驗一下軟體，對於如邊界值、輸入數據類型不明確的問題集中反饋給產品經理，待產品經理給出相應的標准後再設計用例。
（2）對於測試 軟體的過程中，發現有些模塊功能不明確影響用戶正常使用的地方，會及時反饋給測試經理，協助解決這類問題
（3）會積極參與項目的各種討論會議；查看已有的測試用例、bug庫中已有的bug、已有的用戶手冊和幫助文檔，咨詢產品人員並盡可能多的了解相關需求信息，並以此為基礎設計測試用例
（4）參考軟體功能，直接設計用例，然後提交給測試組（必要情況下可以提交給整個項目組）進行評審，得到統一意見。

（1）根據常識想像出ATM機的功能點：插卡、退卡、輸入密碼、修改密碼、余額查詢、取錢、存錢、轉賬等
（2）根據自己的操作經驗，分別制定每個功能點的需求文檔。

（1）根據經驗判斷，像頁面顯示，布局，兼容性問題都是前端的問題
（2）查後端服務日誌，如果日誌沒有記錄，很可能是介面沒有調用成功，有可能是這個功能沒有與後端進行交互，也就不存在後端的問題。如果有日誌輸出可以查一下日誌信息，進一步分析
（3）如果是前端顯示的數據有誤，可以查介面，如果介面返回的實際沒有問題，就是前端的問題，如果介面返回數據有問題，前端顯示的與後端一致，就是後端的問題
（4）查看狀態碼，404可能是前端傳參錯誤或後台介面改了，500是後端的問題

（1）bug概述
（2）bug具體描述
（3）bug的嚴重程度：致命問題、嚴重問題、一般問題、
（4）bug的處理優先順序：立即處理、高優先順序處理、排隊處理、低優先順序處理
（5）bug的指派人
（6）bug的狀態
（7）附件截圖或日誌
（8）其他信息點

通常要對修復好的產品進行多輪測試，回歸測試，因為即使之前的bug修復好了，在下一輪測試中還有可能發現新bug
（1）回歸測試時執行全部用例
（2）選擇重要功能點、常用功能點、與bug關聯的功能點進行測試
（3）選擇性執行關鍵功能點的測試用例
（4）僅測出現bug的功能點

（1）測試的版本號和測試環境要描述清楚
（2）bug概要：通過bug概要讓項目組其他成員知道這個bug單描述的是什麼問題
（3）bug具體描述：也就是bug的重現步驟，bug記錄的細節越詳細越好，包括出錯前後執行的操作步驟，涉及的具體數據等
（4）附上相應的截圖和日誌，特別是截圖能為bug提供有力的說明

把發現的這個bug操作步驟補充到測試用例中，以便下一次測試的時候能夠注意到這個問題

（1）檢查是否是因為bug描述不清楚，造成對bug的爭議，確保bug單清晰明確，描述清楚，並且有截圖或日誌。
（2）如果bug單寫清楚了。就要以心平氣和的心態和開發人員進行溝通，說明bug對產品的不良影響
（3）如果溝通後還是不願意修改的話，可以向測試經理反饋這一情況，由測試經理出面解決，或召開三方會議共同商討定奪。
（4）作為測試人員，一定要堅定自己的立場原則，以產品為出發點，不能經開發的解釋後就放棄自己的觀點，認為自己找到的不是bug了。

首先我會截圖並搜集日誌，保留好測試現場，沒有重現可能是因為沒有觸發到bug產生的點，我會想方設法讓這個bug重現，如果實在無法重現，會提交bug、截圖和日誌給開發人員。如果開發人員要求重現，就後續繼續觀察，觀察到了可以邀請開發來工位進行調試，確定問題；如果最終還是無法重現的話，就把問題反映給測試經理，由測試經理和開發人員進行評審和解決方法，雖然現在沒有重現，但不能保證在用戶那裡不會出現。

首先我覺得凡事影響用戶體驗的問題都是大問題，如果用戶體驗不好，會造成大量潛在用戶的流逝，對產品的後續發展是非常不利的；其次如果每個問題都因為修改成本高而不去修改的話，就無法提升產品的質量，我認為無論是什麼問題，都應該要求開發人員去修改，這是對產品負責，也是對用戶負責。

之前有用過tapd，也有聽說過禪道、TestLink，測試管理工具，主要用於降低產品、開發、測試溝通成本，可以根據公司的具體情況進行使用，應該都差不多，能夠很快上手

一個軟體版本一般要測三到五輪，每一輪測試的時間不能確定，受需求規模、測試人員、測試技術、軟體質量等多方面因素影響，要視具體的情況確定

（1）編寫目的
（2）模塊功能描述
（3）測試過程：測試時間、地點、人員、版本
（4）測試環境
（5）測試功能點的范圍
（6）測試執行結果
（7）風險評估
（8）測試結論
（9）附件

（1）按照測試計劃安排完成了所有測試工作
（2）測試用例全部完成，執行通過率達到標准
（3）每個測試人員手上的bug處於關閉狀態
（4）回歸測試全部執行完畢，沒有發現影響產品上線的bug，軟體產品達到了上線標准
（5）每個測試人員負責的測試報告已完成，並提交給了測試經理

需求評審，測試計劃的制定、測試用例的設計、用例評審、測試環境搭建、測試執行（提交BUG、回歸測試）、撰寫測試報告

對於功能測試人員，是在系統測試時介入的

首先測試工作是產品誕生過程中必不可少的環節，對產品質量有明顯的改善作用；其次測試能對開發工作起到一定的監督和推動作用，能夠加快軟體開發周期，加快軟體發布的進程

首先熟悉項目組成員，包括開發、測試、產品。其次我會從熟悉需求文檔開始，依次熟悉測試組的測試用例、bug管理工具以及bug庫中已提交的bug。最後我會想測試組的老同事或我的導師請教測試組的基本工作流程等細節問題，並結合測試經理分配的任務，通過這些任務熟悉整個測試流程和工作要點。

受測試時間、測試人員數量、測試人員技術等方面的因素影響，無法發現所有bug。有些bug是需要在特殊環境下長期使用才會發現的。一般情況下，在交付用戶後都不應該有影響用戶使用和體驗的bug出現，萬一在用戶使用過程中發現了bug，應該迅速打補丁或升級軟體。

⑨ Python編程面試常見問題有哪些

Python編程面試題目一：python下多線程的限制以及多進程中傳遞參數的方式，以及區別

(1)python下多線程的限制以及多進程中傳遞參數的方式

python多線程有個全局解釋器鎖(global interpreter lock)，這個鎖的意思是任一時間只能有一個線程使用解釋器，跟單cpu跑多個程序一個意思，大家都是輪著用的，這叫“並發”，不是“並行”。

多進程間共享數據，可以使用 multiprocessing.Value 和 multiprocessing.Array

(2)python多線程與多進程的區別

在UNIX平台上，當某個進程終結之後，該進程需要被其父進程調用wait，否則進程成為僵屍進程(Zombie)。所以，有必要對每個Process對象調用join()方法 (實際上等同於wait)。對於多線程來說，由於只有一個進程，所以不存在此必要性。

多進程應該避免共享資源。在多線程中，我們可以比較容易地共享資源，比如使用全局變數或者傳遞參數。在多進程情況下，由於每個進程有自己獨立的內存空間，以上方法並不合適。此時我們可以通過共享內存和Manager的方法來共享資源。但這樣做提高了程序的復雜度，並因為同步的需要而降低了程序的效率。

Python編程面試題目二：lambada函數

lambda 函數是一個可以接收任意多個參數(包括可選參數)並且返回單個表達式值的函數。 lambda 函數不能包含命令，它們所包含的表達式不能超過一個。不要試圖向lambda 函數中塞入太多的東西;如果你需要更復雜的東西，應該定義一個普通函數，然後想讓它多長就多長。

更多關於Python編程的技巧，干貨，資訊等內容，小編會持續更新。

⑩ python面試必備題目有哪些

Q：你做一個自我介紹吧？
旁白：其實遇到好幾家面試官都讓我做自我介紹了，該如何自我介紹陽哥估計都會背了，好玩（惡心）的是在萬達信息面試，面試了3個技術官，每個人都分別讓我做了自我介紹，尼瑪，他們3個就不會溝通一下要問我啥嗎，一個問題至於問我3遍嗎~:funk:陽哥是敢怒不敢言，畢竟在人家的地盤。
PS：自我介紹的內容就不說了，每個人都是獨特的，我就跟大家說一下應該如何自我介紹吧。
一個優良的自我介紹會給面試官留下深刻的印象，大部分情況下，所謂的面試好壞其實看的就是你給面試官留下的印象怎麼樣了，我們用俗語叫感覺。
自我介紹應該分以下幾個部分，按照一定的邏輯連貫起來。如果連貫不起來，或者不夠熟練一定在台下多背幾遍，多講幾遍，但是面試的時候不要說的跟背過似的，高境界就是讓面試官感覺你是臨場發揮的，卻又比背的都好。
1）個人基本信息（姓名、年齡、老家、居住地等）
2）自己來自哪裡（工作地點），是干什麼的（給自己一個清晰的定位，比如：我是一名Android開發工程師），擔任過什麼職務、做過什麼樣的項目
3）自己為何來貴公司面試
4）最後祝願（希望能得到貴公司的認可等等，不用太多，一兩句話就ok）
Q：介紹一下你做過的項目吧？
PS：黑馬那麼多項目，隨便准備3個就ok了。
介紹項目大概的思路如下：
1）這個項目是干什麼的（比如是一個類似網易新聞的地方新聞客戶端，或者類似美團的o2o，或者類似豌豆莢的一個應用市場，或者類似淘寶的購物平台）？解釋就是拿一個市場上耳熟能詳的應用跟自己的應用做類比，省的面試官聽的雲里霧里的。
2）自己負責了哪些模塊（功能）的職責（比如負責系統的架構，核心代碼的編寫，xx功能模塊的開發等等）
3）自己在這個項目中擔當的責任（比如，這個項目是自己獨立開發的，這個項目是和另外一個同事一起架構一起開發的，這個項目是自己負責了幾個核心模塊）
4）項目中都用到了哪些技術
5）從項目中學到了哪些東西（可以從技術方向和業務兩個方向入手）
旁白：面試官問的很多技術性問題跟之前問的都大同小異，因此這里只給出有特色且技術含量高的。陽哥正在寫面試寶典，該寶典核心內容針對的還是技術問題，陽哥會從javase基礎到javase高級，從Android基礎到Android高級以及到Android項目依次展開分析，其次也會寫一些常見的非技術性問題，敬請期待~
Q：①在Listview的優化中，我們為何使用ConvertView？②為何使用ViewHolder？③你認為哪個更能解決問題？④你認為view.inflate和view.findviewById哪個更耗時，為什麼？⑤如果這兩個AP讓你重新寫，你怎麼寫？
PS：上面的問題，陽哥認為是面試以來遇到很難的一個，也是很有技術含量的一道題。前一半問題還好回答，最後一個問題真的需要發揮想像了。
A：①使用ConvertView可以實現對view的復用，這樣大大節約了每次創建對象的時間，提升了ListView的顯示效率。②使用ViewHolder作為內部類，可以將view的子控制項封裝在ViewHolder類中，然後通過View.setTag(ViewHolder)將view和ViewHolder進行綁定，這樣我們就不用每次都調用view的findViewById(id)方法來查找控制項。③使用ConvertView解決了一大部分問題，使用ViewHolder實現了控制項換時間的問題，因為給View對象設置一個Tag本身就是佔用內存的，因此ViewHolder的使用還是需要區分不同的應用場景的， 沒有絕對的好與不好。如果內存足夠需要高效則ViewHolder建議使用，否則不建議使用。④當然是view.inflate耗時，這個函數完成的功能是把xml布局文件通過pullParser的形式給解析到內存中，需要io，需要遞歸子節點。⑤我其實還不太相信我寫出來的代碼比Google官方寫的好，如果讓我寫的話我可能會這樣考慮，當用戶在使用view.inflate的時候將多個id作為數組添加到形參中，這樣在初始化view的使用我就可以給這個view直接調用setTag方法綁定需要的子控制項。不過這個原生方法其實也應該保留共不同的需求使用。
PS：技術面試時間並不長，我回答了幾個之後，他們兩個大眼瞪小眼，A看看B問：你還有什麼問的嗎？B說我沒有，你還有嗎？A說我也沒了。那行，接下來，他們就讓我等人事了。