來源：http://www.sohu.com/a/246928493_464000

1如何巧妙地回答面試官的問題？

在程序員面試中，求職者不可避免地需要回答面試官各種刁鑽、犀利的問題，這時不能簡單地回答“是”或者“不是”，而應該具體分析“是”或者“不是”的理由。

那麼，面對面試官提出的各類問題，如何才能條理清晰地回答呢？如何才能讓自己的回答令面試官滿意呢？

談話是一種藝術，回答問題也是一種藝術。同樣的問題，不同的回答方式，往往會產生不同的效果，甚至是截然不同的效果。在此，編者提出以下幾點建議，供讀者參考。

首先，回答問題務必謙虛謹慎。既不能讓面試官覺得自己很自卑，唯唯諾諾，也不能讓面試官覺得自己清高自負，而應該通過問題的回答表現出自己自信從容、不卑不亢的一面。例如，當面試官提出“你在項目中起到了什麼作用”的問題時，如果求職者回答：我完成了團隊中最難的工作，此時就會給面試官一種居功自傲的感覺，而如果回答：我完成了文件系統的構建工作，這個工作被認爲是整個項目中最具有挑戰性的一部分內容，因爲它幾乎無法重用以前的框架，需要重新設計。這種回答不僅不傲慢，反而有理有據，更能打動面試官。

其次，回答面試官的問題時，不要什麼都說，要適當地留有懸念。人一般都有獵奇的心理，面試官自然也不例外，而且，人們往往對好奇的事情更有興趣、更加偏愛，也更加記憶深刻。所以，在回答面試官問題時，切記說關鍵點而非細節，說重點而非和盤托出，通過關鍵點，吸引面試官的注意力，等待他們繼續“刨根問底”。例如，當面試官對你的簡歷中一個算法問題有興趣，希望瞭解時，可以作如下回答：我設計的這種查找算法，對於80%以上的情況，都可以將時間複雜度從O(n)降低到O(logn)，如果您有興趣，我可以詳細給您分析具體的細節。

最後，回答問題要條理清晰、簡單明瞭，最好使用“三段式”方式。所謂“三段式”，有點類似於中學作文中的寫作風格，包括“場景/任務”“行動”和“結果”三部分內容。以面試官提的問題“你在團隊建設中，遇到的最大挑戰是什麼”爲例，第一步，分析場景/任務：在我參與的一個ERP項目中，我們團隊一共四個人，除了我以外的其他三個人中，兩個人能力很給力，人也比較好相處，但有一個人卻不太好相處，每次我們小組討論問題的時候，他都不太愛說話，也很少發言，分配給他的任務也很難完成。第二步，分析行動：爲了提高團隊的綜合實力，我決定找個時間和他好好單獨談一談。於是我利用週末時間，約他一起喫飯，喫飯的時候，順便討論了一下我們的項目，我詢問了一些項目中他遇到的問題，通過他的回答，我發現他並不懶，也不糊塗，只是對項目不太瞭解，缺乏經驗，缺乏自信而已，所以越來越孤立，越來越不願意討論問題。爲了解決這個問題，我嘗試着把問題細化到他可以完成的程度，從而建立起他的自信心。第三步，分析結果：他是小組中水平最弱的人，但是，慢慢地，他的技術變得越來越厲害了，也能夠按時完成安排給他的工作了，人也越來越自信了，也越來越喜歡參與我們的討論，並發表自己的看法，我們也都願意與他一起合作了。“三段式”回答的一個最明顯的好處就是條理清晰，既有描述，也有結果，有根有據，讓面試官一目瞭然。

回答問題的技巧，是一門大的學問。求職者完全可以在平時的生活中加以練習，提高自己與人溝通的技能，等到面試時，自然就得心應手了。

2如何回答技術性的問題？

程序員面試中，面試官會經常詢問一些技術性的問題，有的問題可能比較簡單，都是歷年的筆試面試真題，求職者在平時的複習中會經常遇到，應對自然不在話下。但有的題目可能比較難，來源於Google、Microsoft等大企業的題庫或是企業自己爲了招聘需要設計的題庫，求職者可能從來沒見過或者從來都不能完整地、獨立地想到解決方案，而這些題目往往又是企業比較關注的。

如何能夠回答好這些技術性的問題呢？編者建議：會做的一定要拿滿分，不會做的一定要拿部分分。即對於簡單的題目，求職者要努力做到完全正確，畢竟這些題目，只要複習得當，完全回答正確一點問題都沒有（編者認識的一個朋友據說把《編程之美》、《編程珠璣》、《程序員面試筆試寶典》上面的技術性題目與答案全都背得滾瓜爛熟了，後來找工作簡直成了“offer殺器”，完全無解了）；對於難度比較大的題目，不要驚慌，也不要害怕，即使無法完全做出來，也要努力思考問題，哪怕是半成品也要寫出來，至少要把自己的思路表達給面試官，讓面試官知道你的想法，而不是完全回答不會或者放棄，因爲面試官很多時候除了關注你的獨立思考問題的能力以外，還會關注你技術能力的可塑性，觀察求職者是否能夠在別人的引導下去正確地解決問題，所以，對於你不會的問題，他們很有可能會循序漸進地啓發你去思考，通過這個過程，讓他們更加了解你。

一般而言，在回答技術性問題時，求職者大可不必膽戰心驚，除非是沒學過的新知識，否則，一般都可以採用以下六個步驟來分析解決。

（1）勇於提問

面試官提出的問題，有時候可能過於抽象，讓求職者不知所措，或者無從下手，所以，對於面試中的疑惑，求職者要勇敢地提出來，多向面試官提問，把不明確或二義性的情況都問清楚。不用擔心你的問題會讓面試官煩惱，影響你的面試成績，相反還對面試結果產生積極影響：一方面，提問可以讓面試官知道你在思考，也可以給面試官一個心思縝密的好印象；另一方面，方便後續自己對問題的解答。

例如，面試官提出一個問題：設計一個高效的排序算法。求職者可能丈二和尚摸不到頭腦，排序對象是鏈表還是數組？數據類型是整型、浮點型、字符型還是結構體類型？數據基本有序還是雜亂無序？數據量有多大，1000以內還是百萬以上個數？此時，求職者大可以將自己的疑問提出來，問題清楚了，解決方案也自然就出來了。

（2）高效設計

對於技術性問題，如何才能打動面試官？完成基本功能是必須的，僅此而已嗎？顯然不是，完成基本功能頂多隻能算及格水平，要想達到優秀水平，至少還應該考慮更多的內容，以排序算法爲例：時間是否高效？空間是否高效？數據量不大時也許沒有問題，如果是海量數據呢？是否考慮了相關環節，例如數據的“增刪改查”？是否考慮了代碼的可擴展性、安全性、完整性以及魯棒性？如果是網站設計，是否考慮了大規模數據訪問的情況？是否需要考慮分佈式系統架構？是否考慮了開源框架的使用？

（3）僞代碼先行

有時候實際代碼會比較複雜，上手就寫很有可能會漏洞百出、條理混亂，所以，求職者可以首先徵求面試官的同意，在編寫實際代碼前，寫一個僞代碼或者畫好流程圖，這樣做往往會讓思路更加清晰明瞭。

切記在寫僞代碼前要告訴面試官，他們很有可能對你產生誤解，認爲你只會紙上談兵，實際編碼能力卻不行。只有徵得了他們的允許，方可先寫僞代碼。

（4）控制節奏

如果是算法設計題，面試官都會給求職者一個時間限制用以完成設計，一般爲20分鐘左右。完成得太慢，會給面試官留下能力不行的印象，但完成得太快，如果不能保證百分百正確，也會給面試官留下毛手毛腳的印象，速度快當然是好事情，但只有速度，沒有質量，速度快根本不會給面試加分。所以，編者建議，回答問題的節奏最好不要太慢，也不要太快，如果實在是完成得比較快，也不要急於提交給面試官，最好能夠利用剩餘的時間，認真仔細地檢查一些邊界情況、異常情況及極性情況等，看是否均能滿足要求。

（5）規範編碼

回答技術性問題時，多數都是紙上寫代碼，離開了編譯器的幫助，求職者要想讓面試官對自己的代碼一看即懂，除了字跡要工整，不能眉飛色舞以外，最好是能夠嚴格遵循編碼規範：函數變量命名、換行縮進、語句嵌套和代碼佈局等，同時，代碼設計應該具有完整性，保證代碼能夠完成基本功能、輸入邊界值能夠得到正確地輸出、對各種不合規範的非法輸入能夠做出合理的錯誤處理，否則，寫出的代碼即使無比高效，面試官也不一定看得懂或者看起來非常費勁，這些對面試成功都是非常不利的。

（6）精心測試

在軟件界，有一句真理：任何軟件都有bug。但不能因爲如此就縱容自己的代碼，允許錯誤百出。尤其是在面試過程中，實現功能也許並不十分困難，困難的是在有限的時間內設計出的算法，各種異常是否都得到了有效的處理，各種邊界值是否都在算法設計的範圍內。

測試代碼是讓代碼變得完備的高效方式之一，也是一名優秀程序員必備的素質之一。所以，在編寫代碼前，求職者最好能夠瞭解一些基本的測試知識，做一些基本的單元測試、功能測試、邊界測試以及異常測試。

在回答技術性問題時，注意在思考問題的時候，千萬別一句話都不說，面試官面試的時間是有限的，他們希望在有限的時間內儘可能地去了解求職者，如果求職者坐在那裏一句話不說，不僅會讓面試官覺得求職者技術水平不行，而且會認爲求職者思考問題能力以及溝通能力可能都存在問題。

其實，在面試時，求職者往往會存在一種思想誤區，把技術性面試的結果看得太重要了。面試過程中的技術性問題，結果固然重要，但也並非最重要的內容，因爲面試官看重的不僅僅是最終的結果，還包括求職者在解決問題的過程中體現出來的邏輯思維能力以及分析問題的能力。所以，求職者在與面試官的博弈中，要適當地提問，通過提問獲取面試官的反饋信息，並抓住這些有用的信息進行輔助思考，從而博得面試官的認可，進而提高面試的成功率。

3如何回答非技術性問題？

評價一個人的能力，除了專業能力，還有一些非專業能力，如智力、溝通能力和反應能力等，所以在IT企業招聘過程的筆試面試環節中，並非所有的筆試內容都是C/C++、數據結構與算法及操作系統等專業知識，也包括其他一些非技術類的知識，如智力題、推理題和作文題等。技術水平測試可以考查一個求職者的專業素養，而非技術類測試則更加強調求職者的綜合素質，包括數學分析能力、反應能力、臨場應變能力、思維靈活性、文字表達能力和性格特徵等內容。考查的形式多種多樣，但與公務員考查相似，主要包括行測（佔大多數）、性格測試（大部分都有）、應用文和開放問題等內容。

每個人都有自己的答題技巧，答題方式也各不相同，以下是一些相對比較好的答題技巧（以行測 爲例）：

1）合理有效的時間管理。由於題目的難易不同，所以不要對所有題目都“絕對的公平”、都“一刀切”，要有輕重緩急，最好的做法是不按順序回答。行測中有各種題型，如數量關係、圖形推理、應用題、資料分析和文字邏輯等，而不同的人擅長的題型是不一樣的，因此應該首先回答自己最擅長的問題。例如，如果對數字比較敏感，那麼就先答數量關係。

2）注意時間的把握。由於題量一般都比較大，可以先按照總時間/題數來計算每道題的平均答題時間，如10s，如果看到某一道題5s後還沒思路，則馬上放棄。在做行測題目的時候，以在最短的時間內拿到最多分爲目標。

3）平時多關注圖表類題目，培養迅速抓住圖表中各個數字要素間相互邏輯關係的能力。

4）做題要集中精力，只有集中精力、全神貫注，才能將自己的水平最大限度地發揮出來。

5）學會關鍵字查找，通過關鍵字查找，能夠提高做題效率。

6）提高估算能力，有很多時候，估算能夠極大地提高做題速度，同時保證正確率。

除了行測以外，一些企業非常相信個人性格對職位匹配的影響，所以都會引入相關的性格測試題用於測試求職者的性格特性，看其是否適合所投遞的職位。大多數情況下，只要按照自己的真實想法選擇就行了，不要弄巧成拙，因爲測試是爲了得出正確的結果，所以大多測試題前後都有相互驗證的題目。如果求職者自作聰明，選擇該職位可能要求的性格選項，則很可能導致測試前後不符，這樣很容易讓企業發現你是個不誠實的人，從而首先予以篩除。

4如何回答系統設計題？

應屆生在面試的時候，偶爾也會遇到一些系統設計題，而這些題目往往只是測試一下求職者的知識面，或者測試求職者對系統架構方面的瞭解，一般不會涉及具體的編碼工作。雖然如此，對於此類問題，很多人還是感覺難以應對，也不知道從何說起。

如何應對此類題目呢？在正式介紹基礎知識之前，首先羅列幾個常見的系統設計相關的面試筆試題，如下所示：

1）設計一個DNS的Cache結構，要求能夠滿足每秒5000次以上的查詢，滿足IP數據的快速插入，查詢的速度要快（題目還給出了一系列的數據，比如站點數總共爲5000萬、IP地址有1000萬等）。

2）有N臺機器，M個文件，文件可以以任意方式存放到任意機器上，文件可任意分割成若干塊。假設這N臺機器的宕機率小於1/3，想在宕機時可以從其他未宕機的機器中完整導出這M個文件，求最好的存放與分割策略。

3）假設有三十臺服務器，每臺服務器上面都存有上百億條數據（有可能重複），如何找出這三十臺機器中，根據某關鍵字，重複出現次數最多的前100條？要求使用Hadoop來實現。

4）設計一個系統，要求寫速度儘可能快，並說明設計原理。

5）設計一個高併發系統，說明架構和關鍵技術要點。

6）有25T的log(query->queryinfo)，log在不斷地增長，設計一個方案，給出一個query能快速返回queryinfo。

以上所有問題中凡是不涉及高併發的，基本可以採用Google的三個技術解決，即GFS、MapReduce和Bigtable，這三個技術被稱爲“Google三駕馬車”，Google只公開了論文而未公開源代碼，開源界對此非常有興趣，仿照這三篇論文實現了一系列軟件，如Hadoop、HBase、HDFS及Cassandra等。

在Google這些技術還未出現之前，企業界在設計大規模分佈式系統時，採用的架構往往是database+sharding+cache，現在很多公司（比如taobao、weibo.com）仍採用這種架構。在這種架構中，仍有很多問題值得去探討。如採用什麼數據庫，是SQL界的MySQL還是NoSQL界的Redis/TFS，兩者有何優劣？採用什麼方式sharding（數據分片），是水平分片還是垂直分片？據網上資料顯示，weibo.com 和 taobao 圖片存儲中曾採用的架構是Redis/MySQL/TFS+sharding+cache，該架構解釋如下：前端cache是爲了提高響應速度，後端數據庫則用於數據永久存儲，防止數據丟失，而sharding是爲了在多臺機器間分攤負載。最前端由大塊大塊的cache組成，要保證至少99%（該數據在weibo.com架構中的是自己猜的，而taobao圖片存儲模塊是真實的）的訪問數據落在cache中，這樣可以保證用戶訪問速度，減少後端數據庫的壓力。此外，爲了保證前端cache中的數據與後端數據庫中的數據一致，需要有一箇中間件異步更新（爲什麼使用異步？理由簡單：同步代價太高。異步有缺點，如何彌補?）數據，這個有些人可能比較清楚，新浪有個開源軟件叫Memcachedb（整合了BerkeleyDB和Memcached），正是爲完成此功能而設計。另外，爲了分攤負載壓力和海量數據，會將用戶微博信息經過分片後存放到不同節點上（稱爲“Sharding”）。

這種架構優點非常明顯：簡單，在數據量和用戶量較小的時候完全可以勝任。但缺點是擴展性和容錯性太差，維護成本非常高，尤其是數據量和用戶量暴增之後，系統不能通過簡單地增加機器解決該問題。

鑑於此，新的架構應運而生。新的架構仍然採用Google公司的架構模式與設計思想，以下將分別就此內容進行分析。

GFS：GFS是一個可擴展的分佈式文件系統，用於大型的、分佈式的、對大量數據進行訪問的應用。它運行於廉價的普通硬件上，提供容錯功能。現在開源界有HDFS（Hadoop Distributed File System），該文件系統雖然彌補了數據庫+sharding的很多缺點，但自身仍存在一些問題，比如：由於採用master/slave架構，因此存在單點故障問題；元數據信息全部存放在master端的內存中，因而不適合存儲小文件，或者說如果存儲大量小文件，那麼存儲的總數據量不會太大。

MapReduce：MapReduce是針對分佈式並行計算的一套編程模型。其最大的優點是：編程接口簡單，自動備份（數據默認情況下會自動備三份），自動容錯和隱藏跨機器間的通信。在Hadoop中，MapReduce作爲分佈計算框架，而HDFS作爲底層的分佈式存儲系統，但MapReduce不是與HDFS耦合在一起的，完全可以使用自己的分佈式文件系統替換掉HDFS。當前MapReduce有很多開源實現，如Java實現Hadoop MapReduce，C++實現Sector/sphere等，甚至有些數據庫廠商將MapReduce集成到數據庫中了。

BigTable：BigTable俗稱“大表”，是用來存儲結構化數據的，編者覺得，BigTable之所以在開源界最火爆，是因爲其開源實現最多，包括HBase、Cassandra和levelDB等，使用也非常廣泛。

除了Google的這“三駕馬車”以外，還有其他一些技術可供學習與使用：

Dynamo：亞馬遜的key-value模式的存儲平臺，可用性和擴展性都很好，採用DHT（Distributed Hash Table）對數據分片，解決單點故障問題，在Cassandra中，也借鑑了該技術，在“BT”和“電驢”這兩種下載引擎中，也採用了類似算法。

虛擬節點技術：該技術常用於分佈式數據分片中。具體應用場景是：有一大塊數據（可能TB級或者PB級），需按照某個字段（key）分片存儲到幾十（或者更多）臺機器上，同時想盡量負載均衡且容易擴展。傳統的做法是：Hash(key) mod N，這種方法最大的缺點是不容易擴展，即增加或者減少機器均會導致數據全部重分佈，代價太大。於是新技術誕生了，其中一種是上面提到的DHT，現在已經被很多大型系統採用，還有一種是對“Hash(key) mod N”的改進：假設要將數據分佈到20臺機器上，傳統做法是Hash(key) mod 20，而改進後，N取值要遠大於20，比如是20000000，然後採用額外一張表記錄每個節點存儲的key的模值，比如：

node1：0～1000000

node2：1000001～2000000

……

這樣，當添加一個新的節點時，只需將每個節點上部分數據移動給新節點，同時修改一下該表即可。

Thrift：Thrift是一個跨語言的RPC框架，分別解釋“RPC”和“跨語言”如下：RPC是遠程過程調用，其使用方式與調用一個普通函數一樣，但執行體發生在遠程機器上；跨語言是指不同語言之間進行通信，比如C/S架構中，Server端採用C++編寫，Client端採用PHP編寫，怎樣讓兩者之間通信，Thrift是一種很好的方式。

本篇最前面的幾道題均可以映射到以上幾個系統的某個模塊中，如：

1）關於高併發系統設計，主要有以下幾個關鍵技術點：緩存、索引、數據分片及鎖粒度儘可能小。

2）題目2涉及現在通用的分佈式文件系統的副本存放策略。一般是將大文件切分成小的block（如64MB）後，以block爲單位存放三份到不同的節點上，這三份數據的位置需根據網絡拓撲結構配置，一般而言，如果不考慮跨數據中心，可以這樣存放：兩個副本存放在同一個機架的不同節點上，而另外一個副本存放在另一個機架上，這樣從效率和可靠性上，都是最優的（這個Google公佈的文檔中有專門的證明，有興趣的可參閱一下）。如果考慮跨數據中心，可將兩份存在一個數據中心的不同機架上，另一份放到另一個數據中心。

3）題目4涉及BigTable的模型。主要思想是將隨機寫轉化爲順序寫，進而大大提高寫速度。具體是：由於磁盤物理結構的獨特設計，其併發的隨機寫（主要是因爲磁盤尋道時間長）非常慢，考慮到這一點，在BigTable模型中，首先會將併發寫的大批數據放到一個內存表（稱爲“memtable”）中，當該表大到一定程度後，會順序寫到一個磁盤表（稱爲“SSTable”）中，這種寫法是順序寫，效率極高。此時可能有讀者問，隨機讀可不可以這樣優化？答案是：看情況。通常而言，如果讀併發度不高，則不可以這麼做，因爲如果將多個讀重新排列組合後再執行，系統的響應時間太慢，用戶可能接受不了，而如果讀併發度極高，也許可以採用類似機制。

5如何解決求職中的時間衝突問題？

對於求職者而言，求職季就是一個趕場季，一天少則幾家、十幾家企業入校招聘，多則幾十家、上百家企業招兵買馬。企業多，選項自然也多，這固然是一件好事情，但由於招聘企業實在是太多，自然而然會導致另外一個問題的發生：同一天企業扎堆面試，且都是自己心儀或欣賞的大牛企業的現象。如果不能夠提前掌握企業的宣講時間、地點，是很容易遲到或錯過的。但有時候即使掌握了宣講時間、筆試和麪試時間，還是有可能錯過，爲什麼呢？時間衝突，人不可能具有分身術，也不可能同一時間做兩件不同的事情，所以，很多時候就必須有所取捨了。

到底該如何取捨呢？該如何應對這種時間衝突的問題呢？在此，編者將自己的一些想法和經驗分享出來，以供讀者參考：

1）如果多家心儀企業的校園宣講時間發生衝突（前提是隻宣講，不筆試，否則請看後面的建議），此時最好的解決方法是和同學或朋友商量好，各去一家，然後大家進行信息共享。

2）如果多家心儀企業的筆試時間發生衝突，此時只能選擇其一，畢竟企業的筆試時間都是考慮到了成百上千人的安排，需要提前安排考場、考務人員和閱卷人員等，不可能爲了某一個人而輕易改變。所以，最好選擇自己更有興趣的企業參加筆試。

3）如果多家心儀企業的面試時間發生衝突，不要輕易放棄。對於面試官而言，面試任何人都是一樣的，因爲面試官誰都不認識，而面試時間也是靈活性比較大的，一般可以通過電話協商。求職者可以與相關工作人員（一般是企業的HR）進行溝通，以某種理由（例如學校的事宜、導師的事宜或家庭的事宜等，前提是必須能夠說服人，不要給出的理由連自己都說服不了）讓其調整時間，一般都能協調下來。但爲了保證協調的成功率，一般要接到面試通知後第一時間聯繫相關工作人員變更時間，這樣他們協調起來也更方便。

正如世界上沒有能夠包治百病的藥物一樣，以上這些建議在應用時，很多情況下也做不到全盤兼顧，當必須進行多選一的時候，求職者就要對此進行評估了，評估的項目可以包括：對企業的中意程度、獲得offer的概率及去工作的可能性等。評估的結果往往具有很強的參考性，求職者依據評估結果做出的選擇一般也會比較合理。

6在被企業拒絕後是否可以再申請？

很多企業爲了能夠在一年一度的招聘季節中，提前將優秀的程序員鎖定到自己的麾下，往往會先下手爲強。他們通常採取的措施有以下兩種：第一種，招聘實習生；第二種，多輪招聘。

招聘開始後，往往是幾家歡喜幾家愁，提前拿到企業綠卡的，於是對酒當歌、歡天喜地，而沒有被選上的，擔心從此與這家企業無緣了，於是整日囧字寫在臉上，憂心忡忡，感嘆生不逢時。難道一次失望的表現就永遠會被企業拉入黑名單了嗎？難道一次失敗的經歷就會永遠被記錄在個人歷史的恥辱柱上了嗎？

答案當然是否定的，對心儀的女孩表白，即使第一次被拒絕了，都還可以一而再再而三地表白呢？多次表白後成功的案例比比皆是，更何況是求職找工作。一般而言，企業是不會記仇的，尤其是知名的大企業，對此都會有明確的表示。如果在企業的實習生招聘或在企業以前的招聘中不幸被pass掉了，一般是不會被拉入企業的黑名單的。在下一次招聘中，和其他求職者，具有相同的競爭機會（有些企業可能會要求求職者等待半年到一年時間再能應聘該企業，但上一次求職的糟糕表現不會被計入此次招聘中）。

對心儀的對象表白被拒絕了，不是一樣還可以繼續表白嗎？也許是在考驗，也許是在等待，也許真的是拒絕，但無論出於什麼原因，此時此刻都不要對自己喪失信心。工作也是如此，以編者身邊的很多同學和朋友爲例，很多人最開始被一家企業拒絕了，過了一段時間，又發現他們已成爲該企業的員工。所以，即使被企業拒絕了也不是什麼大不了的事情，以後還有機會的，有志者自有千計萬計，無志者只感千難萬難，關鍵是看你願意成爲什麼樣的人了。

本文節選自《數據庫程序員面試筆試真題庫》

作者：李華榮，網名“小麥苗”，甘肅慶陽人，中國科學技術大學軟件工程碩士，獲得計算機四級數據庫工程師認證，獲得OCM大師認證，長期從事Oracle數據庫的研究，具有豐富的開發和維護經驗，興趣愛好廣泛，熱衷技術分享。