《.NET程式設計師面試寶典》是2009年由電子工業出版社出版的圖書，作者是歐立奇。本書主要講述的是程式設計師面試的技巧和如何擁有一個樂觀的態度。
基本介紹
- 書名：.NET程式設計師面試寶典
- 作者：歐立奇
- ISBN：978-7-121-06540-8
- 出版社：電子工業出版社
- 出版時間：2009-01
- 叢書：程式設計師面試寶典
內容簡介,目錄,
內容簡介
《.NET程式設計師面試寶典》涉獵各大IT公司歷年面試真題（包括筆試題、口試題、電話面試、英語面試，以及邏輯測試和智力測試），通過精確詳細的分類，把在應聘程式設計師（含網路、測試等）過程中所遇見的常見考點為你一一點破。
《.NET程式設計師面試寶典》分為6部分，主要內容包括：求職過程，C#程式設計，數據結構和軟體工程，UNIX、Oracle和網路，.NET擴展項目，綜合面試題等。最後《.NET程式設計師面試寶典》著力講述了如何進行英語面試和電話面試，並給出了大量實際英語面試中的問題、參考答案及常用辭彙，嘗試解決程式設計師應聘外企時語言問題造成的瓶頸。《.NET程式設計師面試寶典》的面試題除了有詳細解析和回答外，對相關知識點還有擴展說明。希望真正做到由點成線，舉一反三，對讀者從求職就業到提升計算機專業知識都有顯著幫助。
許多面試看似簡單
卻需要深厚的基本功才能給出完美的答案
我們能真正寫好一段C#歸併排序代碼嗎？
我們都覺得自己能
可是我們寫出的代碼很可能只能拿到10分中的2分……
《.NET程式設計師面試寶典》將告訴你如何提高自身功力
以從容面對企業的面試
《.NET程式設計師面試寶典》要點：
求職過程
．NET程式設計
數據結構與設計模式
作業系統，資料庫與網路、軟體測試
英語面試，電話面試與智力測試
如果你的簡歷上寫著：“本人精通C#編程、．NET體系；熟悉設計模式、數據結構。”並且自認足夠機智，還能在工小時內對下列問題給出準確的答案．那么．毫無疑問你可以通過多數，NE丁程式設計師面試了。
(1)const和staticreadonly的區別是什麼？
(2)XmlSerializer如何工作？
(3)靜態構造函式是否可使用this？
(4)實現C#歸併排序。
(5)寫一個事件：飲水機沒水時，A或B或其他人給它加水。
(6)“不要和陌生人說話”是設計模式中哪種原則的通俗表達？
(7)解釋UML中的4個名詞：依賴、聚合、泛化和關聯。
(8)對象實現了Finalize將對垃圾收集有何影響？
(9)描述你對．NETFramework2．0中匿名方法的認識。
(10)1000瓶藥水至多有l瓶含劇毒．給你10隻狗，在24小時內通過給狗試藥的方式找出哪瓶藥水有毒或者全部無毒(狗服藥X小時後毒發，19<X<23)。
如果，你還不能對上面大部分題目立刻給出準確的答案，甚至還茫無頭緒，那或許《.NET程式設計師面試寶典》將有效彌補你在．NET程式設計師面試中的缺項，並構造完備的知識體系。
目錄
第一部分：求職過程 - 4 -
第1章：應聘求職 - 4 -
1.1【渠道】 - 5 -
1.2【流程】 - 5 -
1.3【職位】 - 6 -
第2章：求職五步曲 - 7 -
2.1【筆試】 - 7 -
2.2【電話面試】 - 11 -
2.3【面試】 - 11 -
2.4【簽約】 - 12 -
2.5【違約】 - 17 -
第3章：簡曆書寫 - 18 -
3.1【簡歷注意事項】 - 18 -
3.2【簡歷模版】 - 19 -
第4章：職業生涯發展規劃 - 24 -
4.1【缺乏工作經驗的應屆生】 - 24 -
4.2【更換工作的程式設計師們】 - 26 -
4.3【快樂的工作】 - 26 -
第二部分：C#程式設計 - 28 -
第5章：C#程式設計基本概念 - 28 -
5.1【常見概念】 - 29 -
5.2【C++和C#區別】 - 31 -
5.3【數據類型】 - 31 -
5.4【extern】 - 39 -
5.5【其它】 - 39 -
第6章：const異常 反射 - 40 -
6.1【const】 - 40 -
6.2【異常】 - 42 -
6.3【反射】 - 44 -
第7章：傳遞與引用 - 49 -
7.1【傳值】 - 50 -
7.2【靜態變數與私有變數】 - 51 -
7.3【輸入輸出流】 - 51 -
7.4【程式集】 - 52 -
7.5【序列化】 - 53 -
第8章 循環，條件，機率面試例題 - 54 -
8.1【foreach】 - 54 -
8.2【遞歸與回朔】 - 56 -
8.3【條件語言】 - 60 -
8.4【隨機數】 - 61 -
第9章：關於面向對象的面試問題 - 63 -
9.1【面向對象的基本概念】 - 63 -
9.2【訪問修飾符】 - 65 -
9.3【類和結構】 - 67 -
9.4【Static】 - 72 -
9.5【密封類】 - 75 -
9.6【構造函式和析構函式】 - 76 -
9.7【虛函式】 - 78 -
9.8【靜態構造函式與私有構造函式】 - 78 -
9.9【多態的概念】 - 82 -
9.10【索引器】 - 85 -
第10章：繼承與接口 - 86 -
10.1【繼承基礎問題】 - 86 -
10.2【關於new】 - 91 -
10.3【this問題】 - 96 -
10.4【base問題】 - 99 -
10.5【抽象類】 - 101 -
10.6【接口】 - 108 -
10.7【其它】 - 111 -
第11章：委託，事件，泛型 - 117 -
11.1【委託】 - 117 -
11.2【事件】 - 127 -
11.3【泛型】 - 130 -
第二部分：數據結構和軟體工程 - 132 -
第12章：數據結構 - 132 -
12.1【鍊表】 - 132 -
12.2【棧和堆】 - 134 -
12.3【樹】 - 135 -
第13章：字元串 - 144 -
13.1【字元串基礎】 - 144 -
13.2【StringBuilder】 - 145 -
13.3【正則表達式】 - 146 -
13.4【數組】 - 147 -
13.5【字元串其他問題】 - 148 -
第14章：排序 - 150 -
14.1【排序基礎知識】 - 150 -
14.2【冒泡排序】 - 153 -
14.3【雞尾酒排序】 - 156 -
14.4【選擇排序】 - 157 -
14.5【插入排序】 - 159 -
14.6【希爾排序】 - 160 -
14.7【快速排序】 - 163 -
14.8【歸併排序】 - 167 -
14.9【堆排序】 - 170 -
第15章：設計模式 - 172 -
15.1【基礎模式】 - 173 -
15.2【結構模式】 - 181 -
15.3【Clone】 - 184 -
15.4【觀察者模式】 - 187 -
15.5【UML】 - 189 -
15.6【軟體工程】 - 192 -
第16章：軟體測試 - 194 -
16.1【白盒測試】 - 195 -
16.2【性能測試】 - 200 -
16.3【關於遊戲】 - 200 -
第三部分：Unix，Oracle，網路 - 202 -
第17章：作業系統面試例題 - 202 -
17.1【進程】 - 203 -
17.2【執行緒】 - 207 -
17.3【UNIX】 - 209 -
17.4【Windows】 - 212 -
第18章：資料庫和SQL語言 - 213 -
18.1【資料庫理論】 - 213 -
18.2【ORACLE基礎】 - 215 -
18.3【SQL語言客觀題】 - 217 -
第19章：計算機網路及分散式系統 - 222 -
19.1【網路結構】 - 222 -
19.2【TCP/IP】 - 223 -
19.3【網路安全】 - 227 -
19.4【網路其他】 - 228 -
第四部分：.NET擴展項目 - 230 -
第20章 Winform窗體與控制項 - 231 -
20.1【窗體類】 - 231 -
20.2【控制項類】 - 232 -
20.3【圖形】 - 232 -
第21章 ADO資料庫相關 - 233 -
21.1【ASP.NET基礎】 - 234 -
21.2【ADO.NET體系結構】 - 235 -
21.3【數據綁定】 - 237 -
21.4【Datagrid】 - 239 -
21.5【Dataset】 - 240 -
第22章 .NET中Web設計 - 241 -
22.1【Session】 - 242 -
22.2【Cookie】 - 244 -
22.3【XML】 - 245 -
22.4【數據傳遞】 - 247 -
第23章ASP.NET套用技術 - 249 -
23.1【.NET 區域網路】 - 250 -
23.2【.NET Remoting體系】 - 251 -
23.3【Webservice】 - 254 -
第24章 .NET性能與安全 - 255 -
24.1【記憶體管理】 - 255 -
24.2【垃圾管理】 - 256 -
24.3【.NET安全設定】 - 258 -
第五部分：綜合面試題 - 258 -
第25章 英語面試 - 259 -
25.1【面試過程和技巧】 - 259 -
25.2【About job】(關於工作) - 260 -
25.3【About person】(關於個人) - 263 -
25.4【About future】(關於未來) - 266 -
第26章 電話面試 - 267 -
26.1【電話面試之前的準備工作】 - 267 -
26.2【電話面試交流常見問題】 - 268 -
第27章 智力測試 - 274 -
27.1【關於數字的智力問題】 - 274 -
27.2【關於推理的智力問題】 - 277 -
27.3【關於綜合的智力問題】 - 280 -
27.4【關於群體面試】 - 281 -
第28章 邏輯測試 - 284 -
28.1【文字邏輯】 - 284 -
28.2【圖形邏輯】 - 286 -
28.3【找規律】 - 288 -
28.4【關於表格】 - 290 -
附錄 面試經歷總結 - 298 -
本書樣張如下：
5.5【其它】
面試例題1：編寫一段代碼，其功能是列印代碼本身。（要完全使用程式代碼生成一段和自己的代碼一模一樣的字元串）。[歐盟著名通訊公司N面試題，2008]
解析：一道很有趣的面試題，就好像要求一個魔術師，扯著頭髮把自己拔起來的感覺。本題在編寫時要注意計算代碼長度。
答案：用C#編寫代碼如下：（僅一行）
class P { static void Main() { string s = "class P{{static void Main(){{string s=;System.Console.WriteLine(s,s,(char)34);}}}}"; System.Console.WriteLine(s, s, (char)34); } }
6.1【const】
面試例題1：const 和 static readonly 區別是什麼？
解析：
這個問題雖然很簡單，但有時候也能困擾我們。const和static readonly的確很像，都在程式中唯讀，都是一旦初始化則都不再可以改寫，都是屬於語言的靜態。並且在多數情況下可以混用。
兩者區別是這樣的，關於const
1.在編譯期間解析的常量；
2.必須在聲明就初始化；
3.既可用來修飾類中的成員，也可修飾函式體內的局部變數。
而關於static readonly
1.在運行期間解析的常量；
2.既可以在聲明時初始化，也可以在構造器中初始化；
3.只可以用於修飾類中的成員
這裡有幾個例子：
static readonly MyClass myclass = new MyClass();
//必須使用static readonly,因為new需要在運行時確定
//而const只能必須在編譯時就確定
static readonly A = B * 20;
static readonly B = 10;
//可以使用static readonly,顯然可以在運行時確定語句
//也可以使用const// const A = B * 20;
// const B = 10;
//編譯器會在編譯時候，就把B編譯為10，A編譯為200，而不是在運行時再計算B * 202.
下面有一個項目，有一個MyInt的屬性，定義如下：
public class MYClass
{
public const int MyInt = 5;
public static readonly String strStaticReadonly = "StaticReadonly";
}
另一個項目中引用該屬性
public class AnotherClass
{
int I = MYClass.MyInt;
string kk = MYClass.strStaticReadonly;
}
編譯運行程式, I = 5；kk = StaticReadonly。這是當然的。但是如果我們改變MYClass中的MyInt和strStaticReadonly的值：
public class MYClass
{
public const int MyInt = ; //這裡改為6
public static readonly String strStaticReadonly = "changed";//這裡改為changed
}
然後編譯MYClass所在的項目，生成dll。再運行程式AnotherClass（只是運行，而不是編譯後運行），發現I還是= 5，而不是6！，但是strStaticReadonly卻變成了changed。為什麼會這樣？因為在AnotherClass中，I已經被定義為5而不是運行時再去取dll的值，所以說const是編譯時就唯一確定了。
答案：C#擁有兩種不同的常量：靜態常量(compile-time constants)和動態常量(runtime constants)。它們有不同的特性，錯誤的使用不僅會損失效率，還可能造成錯誤。相比之下，靜態常量在速度上會稍稍快一些，但是靈活性卻比動態常量差很多。
//靜態常量(隱式是靜態的)
public const int compiletimeConstant = 1;
//動態常量
public static readonly runtimeConstant = 1;
靜態常量在編譯時會將其替換為所對應的值，也就是說下面這2句話通過編譯器編譯後產生的中間語言是一樣的。
//通過編譯後二者會被翻譯成相同的中間語言
int myNum = compiletimeConstant;
int myNum = 1;
動態常量的值是在運行時獲得的。編譯器將其標為唯讀常量，而不是用常量的值代替。靜態常量只能被聲明為簡單的數據類型(內建的int和浮點型)、枚舉或字元串。下面的程式段是通不過編譯的。你不能用new關鍵字初始化一個靜態常量，即便是對一個值類型來說。
//這樣是錯誤的
public const DateTime myDateTime = new DateTime(2006,9,1,0,0,0);
//這樣是可以的
public static readonly DateTime myDateTime = new DateTime(2006,9,1,0,0,0);
唯讀數據也是常量的一種，它們不能在構造器初始化之後被修改。但是它同靜態常量不同，它的值是在運行時才被指派的，因此就會獲得更大的靈活性。動態常量可以是任意的數據類型。二者最大的差別在於：靜態常量在編譯時會將其換為對應的值，這就意味著對於不同的程式集來說，當你改變靜態常量的時候需要將其重新編譯，否則常量的值不會發生變化，可能引發潛在的問題，而動態常量就不會有這種情況。用const定義的常量(隱式是靜態的)，需要像訪問靜態成員那樣去訪問const定義的常量，而用對象的成員方式去訪問會出編譯錯誤。 聲明的同時要設定常量值。從另一方面來說，如果你的確要聲明一些從不改變且處處唯一的常量，例如鉤子函式SetWindowsHookEx的idHook參數或序列化時的版本等，就應該使用靜態常量。但是用到這樣的常量的機會不多。一般來說我們應該使用靈活性更高的動態常量。
兩者區別如下：
靜態常量 動態常量
記憶體消耗 無 因為要保存常量 有消耗
初始化 很少的簡單類型；不能new，必須在聲明同時賦值 任意類型，可以在類構造函式中賦值
何時發揮作用 編譯時進行替換 相當於類中的數據成員
11.2【事件】
面試例題1：寫一個事件，公司飲水機沒水時候，小王、小李或者公司其他同事給引水機加水？
解析：本題主要考校觀察者模式，觀察者模式中主要包括如下兩類對象：
1. Subject：監視對象，它往往包含著其他對象所感興趣的內容。在本範例中，飲水機就是一個監視對象，它包含的其他對象所感興趣的內容，就是waterTankState欄位，當這個欄位的值為0的時候，會不斷把數據發給監視它的對象。
2. Observer：監視者，它監視Subject，當Subject中的某件事發生的時候，會告知Observer，而Observer則會採取相應的行動。在本範例中，Observer就是員工，它們採取的行動分別是Drink和FillWater。
在本題中，事情發生的順序應該是這樣的：
1. 員工告訴飲水機，它對它的容積比較感興趣(註冊)。
2. 飲水機知道後保留對員工的引用。
3. 員工到飲水機前進行飲水這一動作，當容積為0，通過引用，自動調用Fillwater()方法。
類似這樣的例子是很多的，GOF對它進行了抽象，稱為觀察者模式：觀察者模式是為了定義對象間的一種一對多的依賴關係，以便於當一個對象的狀態改變時，其他依賴於它的對象會被自動告知並更新。觀察者模式是一種松耦合的設計模式。
答案: 詳細代碼如下:
// Observer pattern -- Structural example
using System;
//Delegate 加水委託
delegate void fillwaterDelegate();
//ConcreteWaterTank 創建水箱類
class ConcreteWaterTank
{
// Fields
private int subjectCubage; //當前容積
public event fillwaterDelegate fillwaterHandler; //建立加水事件
// Properties
public int waterTankCubage
{
get { return subjectCubage; }
set { subjectCubage = value; }
}
// Methods
public void Attach(fillwaterDelegate ud)
{
fillwaterHandler += ud;
}
public void Detach(fillwaterDelegate ud)
{
fillwaterHandler -= ud;
}
public void Notify()
{
if (fillwaterHandler != null) fillwaterHandler();
}
}
// "ConcreteEmployee" //建立員工類
class ConcreteEmployee
{
// Fields
private string employeeName; //員工姓名
private int observerCubage; //關注水箱狀態
private ConcreteWaterTank subject;
// Constructors //建立構造函式
public ConcreteEmployee(ConcreteWaterTank subject,
string employeeName)
{
this.subject = subject;
this.employeeName = employeeName;
}
// Methods
public void fillWater()
{
if (subject.waterTankCubage == 0)
//關注水箱 如果水箱沒水 則注水
{
Console.WriteLine("Employee go to waterTank and find the water is Null", employeeName);
subject.waterTankCubage = 10;
observerCubage = subject.waterTankCubage;
Console.WriteLine("Employee fill water to waterTank.Now waterTank's state is ", employeeName, observerCubage);
subject.waterTankCubage = subject.waterTankCubage - 1;
observerCubage = subject.waterTankCubage;
Console.WriteLine("After do that he drink, Now waterTank's state is ",employeeName, observerCubage);
}else
{
//否則 則飲水
subject.waterTankCubage = subject.waterTankCubage - 1;
observerCubage = subject.waterTankCubage;
Console.WriteLine("Employee go to waterTank, and he drink, Now waterTank's state is ",employeeName, observerCubage);
}
}
// Properties
public ConcreteWaterTank waterTank
{
get { return subject; }
set { subject = value; }
}
}
// "ConcreteEmployee" //其他觀察者 他們僅是觀察但不動作
class AnotherObserver
{
// Methods
public void Show()
{
Console.WriteLine("AnotherObserver got an Notification!");
}
}
public class Client
{
public static void Main(string[] args)
{
ConcreteWaterTank s = new ConcreteWaterTank ();
//建立水箱s
ConcreteEmployee o1 = new ConcreteEmployee(s, "ZhangSan");
ConcreteEmployee o2 = new ConcreteEmployee(s, "LiSi");
ConcreteEmployee o3 = new ConcreteEmployee(s, "WangEr");
ConcreteEmployee o4 = new ConcreteEmployee(s, "ZhaoLiu");
//建立員工對象 張三 李四 王二 趙六並綁定水箱s
AnotherObserver o5 = new AnotherObserver();
//建立普通觀察者對象 o5
s.Attach(new fillwaterDelegate(o1.fillWater));
s.Attach(new fillwaterDelegate(o2.fillWater));
s.Attach(new fillwaterDelegate(o3.fillWater));
s.Attach(new fillwaterDelegate(o4.fillWater));
s.Attach(new fillwaterDelegate(o5.Show));
//綁定事件fillwaterHandler
s.waterTankCubage = 2;//水箱初始狀態2升
s.Notify();//事件開始運行
Console.WriteLine("--------------------------");
s.Detach(new fillwaterDelegate(o1.fillWater));
//把o1也就是員工張三加水行為從事件中剝離
s.waterTankCubage = 1; //水箱初始狀態1升
s.Notify();//事件開始運行
}
}
12.2【棧和堆】
面試例題1：編號為123456789的火車經過如下軌道從左邊入口處移到右邊出口處(每車都必須且只能進臨時軌道M一次，且不能再回左邊入口處) [中國台灣計算機硬體公司W面試題，2008.11]
-----------------------------------------------------
987654321
-------------------\ /-----------------------------
| |
| |
|M|
| |
|_|
按照從左向右的順序，下面的結果不可能是______
A 123876549
B 321987654
C 321456798
D 987651234
解析：本題實際上考的是數據結構的棧。臨時軌道M就是棧。
A 123挨個過去，45678入棧再出棧變成87654，9再過去；
B 123入棧再出棧變成321，456789入棧再出棧變成987654；
C 123入棧再出棧變成321，4567直接過去，89入棧再出棧變成98；
D 98765在前,則1234必須全部先進棧,98765過去後,剩下1234必須先回到左邊,再通過才滿足1234。但是題意要求不可再回到左邊入口處，所以這個選項不可行。
答案：D
擴展知識：如果M只能容納4列車。上面選項因該選哪個才可行？
16.2【性能測試】
面試例題1：在用戶體驗測試中，發現問題可能存在誤測，誤測包括兩種：第1，問題被遺漏了；第2，不是問題卻被認為是問題。我們的測試通常通過兩種不同的測試方法來進行，他們依據完成不同的設計思路，但是有一些共同的：第1他們都能發現所有存在的問題；第2仍然會有百分之三的誤測率；第3不會出現同一問題被對兩個系統都誤測的可能性。為了測試一個非常重要的系統，我們會把兩個測試方法進行交叉測試，測試結果採取並集，我們可以這樣推理：採用這種方法的時候是不會出現任何誤測的情況。
以下哪項最恰當描述了上述推理？
A 上述推理是必然的，即如果前提為真，則結論一定真；
B 上述推理很強，但不是必然，即如果前提條件為真，則為結論提供很強的證明，但附加信息仍可削弱論證；
C 上述推理很弱，前提條件儘管與結論相關，但最多只為結論提供不充分證明；
D 推論不成立，因為他把某些必要的條件當作了充分的條件。
解析：因為從前提條件中只知道有兩種誤測，但並未說明兩種誤測能夠在測試時就知道，因此當誤測發生時，我們無法區分是哪種誤測，因此即使使用兩種測試方法進行交叉測試取並集，最多只能保證不被遺漏，但是不能解決不是問題卻被認為是問題。
答案：D
第27章 智力測試
27.1【關於數字的智力問題】
面試例題3：1000瓶藥水，其中至多有1瓶劇毒，現在給你10隻小狗在24小時內通過小狗試藥的方式找出哪瓶藥有毒或者全部無毒（小狗服完藥X小時後才會毒發。19<X<23）[中國著名網際網路企業T面試題，2008年11月]
答案：按10進制方式給狗編號分別是1-10。按2進制方式給藥水編號。按照藥水第幾位數字為1，給相應的狗服藥。如下：
第1瓶 0000000001 第1位數字為1，給1號狗服藥。
第2瓶 0000000010 第2位數字為1，給2號狗服藥。
第3瓶 0000000011 第1、2位數字為1，給1、2號狗服藥。
第4瓶 0000000100 第3位數字為1，給3號狗服藥。
……
第99瓶 0001100011 第1、2、6、7位數字為1，給1、2、6、7號狗服藥。
……
第455瓶 0111000111 第1、2、3、7、8、9位數字為1，給1、2、3、7、8、9號狗服藥。
……
第1000瓶 1111101000 第4、6、7、8、9、10位數字為1，給4、6、7、8、9、10號狗服藥。
最後看哪只狗毒發，則通過狗的編號得出藥瓶號碼。比如1、2、3、7、8、9號狗毒發，則455瓶（編號0111000111）為毒藥。
