UT斯達康筆試面試經(jīng)驗

　　一篇來自網(wǎng)友的UT斯達康筆試面試經(jīng)驗，看完后受益良多……

　　7月17號去的UTS軟件部門面試，至今已半月，很想把心得寫出來大家共享，今天終于抽出空來了。

　　一.compile和link哪個先哪個后，生成文件的格式分別是什么?.

　　二.字符串比較是哪個函數(shù),兩個串比較后大于和小于的返回值分別是什么?

　　原型：extern int strcmp(char *s1,char * s2);

　　用法：#include 功能：比較字符串s1和s2。

　　說明： 當s1

　　當s1=s2時，返回值=0

　　當s1>s2時，返回值>0

　　舉例： // strcmp.c

　　#include

　　#include

　　main()

　　{

　　char *s1="Hello, Programmers!";

　　char *s2="Hello, programmers!";

　　int r;

　　clrscr();

　　r=strcmp(s1,s2);

　　if(!r)

　　printf("s1 and s2 are identical");

　　else

　　if(r<0)

　　printf("s1 less than s2");

　　else

　　printf("s1 greater than s2");

　　getchar();

　　return 0;

　　}

　　三.在用VC編譯時debug和release兩種編譯指令有啥區(qū)別?

　　relese版和debug不同在于:

　　debug版使用于調(diào)試的,它關(guān)閉了大多數(shù)代碼優(yōu)化,并回自動初始化開辟出來的內(nèi)存(置為0xcc),并攜帶調(diào)試信息,但是執(zhí)行起來比較慢。

　　release版是最終給客戶的,開啟了代碼優(yōu)化,不會自動初始化內(nèi)存,一般不攜帶調(diào)試信息執(zhí)行比較快。

　　debug和release還有一個區(qū)別，呵呵，編譯成的exe，dll，lib文件的大小差太多了。

　　如果debug下正確,release版本出錯，原因可能很多，畢竟debug多做了很多事。建議你用寫log到文件的方法除錯。

　　常見問題:

　　1.變量未初始化。

　　下面的程序在debug中運行的很好。

　　thing *search(thing , *something)

　　{

　　BOOL found;

　　for(int i = 0; i < whatever.GetSize(); i++)

　　{

　　if(whatever->field == something->field)

　　{ /* found it */

　　found = TRUE;

　　break;

　　} /* found it */

　　}

　　if(found)

　　return whatever;

　　else

　　return NULL;

　　}

　　而在release中卻不行，因為debug中會自動給變量初始化found=FALSE,而在release版中則不會。所以盡可能的給變量、類或結(jié)構(gòu)初始化。

　　2. 數(shù)據(jù)溢出的問題

　　如：char buffer[10];

　　int counter;

　　lstrcpy(buffer, "abcdefghik");

　　在debug版中buffer的NULL覆蓋了counter的高位，但是除非counter>16M,什么問題也沒有。但是在release版中，counter可能被放在寄存器中，這樣NULL就覆蓋了buffer下面的空間，可能就是函數(shù)的返回地址，這將導致ACCESS ERROR。

　　3. DEBUG版和RELEASE版的內(nèi)存分配方式是不同的。

　　如果你在DEBUG版中申請 ele為 6*sizeof(DWORD)=24bytes,實際上分配給你的是32bytes(debug版以32bytes為單位分配)，而在release版，分配給你的就是24bytes(release版以8bytes為單位)，所以在debug版中如果你寫ele[6],可能不會有什么問題，而在release版中，就有ACCESS VIOLATE。

　　四.野指針的問題：

　　在指針P用完后執(zhí)行了一句free(p);為什么還要加一句 p=null; ?

　　“野指針”不是NULL指針，是指向“垃圾”內(nèi)存的指針。人們一般不會錯用NULL指針，因為用if語句很容易判斷。但是“野指針”是很危險的，if語句對它不起作用。野指針的成因主要有兩種：

　　1、指針變量沒有被初始化。任何指針變量剛被創(chuàng)建時不會自動成為NULL指針，它的缺省值是隨機的，它會亂指一氣。所以，指針變量在創(chuàng)建的同時應當被初始化，要么將指針設(shè)置為NULL，要么讓它指向合法的內(nèi)存。

　　2、指針p被free或者delete之后，沒有置為NULL，讓人誤以為p是個合法的指針。別看free和delete的名字惡狠狠的(尤其是delete)，它們只是把指針所指的內(nèi)存給釋放掉，但并沒有把指針本身干掉。

　　通常避免野指針的辦法是正確的使用指針:

　　1.聲明一個pointer的時候注意初始化為null

　　int* pInt = NULL;

　　2.分配完內(nèi)存以后注意ASSERT

　　pInt = new int[num];

　　ASSERT(pInt != NULL);

　　3.刪除時候注意用對操作符

　　對于new int類型的，用delete

　　對于new int[]類型的，用delete []

　　4.刪除完畢以后記得給他null地址

　　delete [] pInt;

　　pInt = NULL;

　　5.記住，誰分配的誰回收，不要再一個函數(shù)里面分配local pointer，送到另外一個函數(shù)去delete

　　6.返回local address是非常危險的，如必須這樣做，請寫注釋到程序里面，免得忘記

　　五.最后一個問題，也是壓死我這個駱駝的最后一根稻草：二分查找法的程序能不能上機寫出來?

　　看到題目我第一反應是：太簡單了吧，這樣子搞那我豈不是想不留在這里做事都很難了，簡直不給我選擇的機會嘛，于是我很爽快的答應了，2分鐘之內(nèi)寫出程序，要知道我面試前做了三天的準備，這個程序可是譚浩強的書中最經(jīng)典的程序之一，我背都背下來了。

　　bool binary_search(int* arr, int key, int n)

　　{

　　int low = 0;

　　int high = n - 1;

　　int mid;

　　while (low <= high)

　　{

　　mid = (high + low) / 2;

　　if (arr[mid] > k)

　　high = mid - 1;

　　else if (arr[mid] < k)

　　low = mid + 1;

　　else

　　return ture;

　　}

　　return false;

　　}

　　面試經(jīng)歷：

　　寫完程序后，我匆匆的試著執(zhí)行了一下，看著屏幕上顯示的OK，心中揣著的那塊大石頭也就提前登陸了。 我叫來面官，原以為他應該看兩眼就完事了，沒想到那家伙居然鄭重其事的坐下來一板一眼的輸入一長串代碼去執(zhí)行，看著屏幕上顯示的一行又一行"No Found!",我感覺有點不妙。

　　面官很和藹的讓我再調(diào)試下，就起身忙他的去了，而我在調(diào)試了3，4分鐘后還是沒有找到問題的情況下徹底傻眼了，我根本就沒做這個預案，而且我敢對天發(fā)誓，我寫的程序絕對和書上就差幾個字符不一樣。

　　就在這萬分危急的時刻，那家伙居然跑過來站在我的身后假惺惺的做指點。他的一句：“你的“TURE”寫錯了!”基本上是扒掉了我身上的最后一塊遮羞布。我在把函數(shù)的返回值和變量定義改了幾個回合之后徹底繳械了。

　　但是我的繳械不是迫于他的淫威，而是出于我的過分自信。在我看來我已經(jīng)表現(xiàn)的很好了(當時確實是這么認為的)，因為我以往寫的代碼，一調(diào)試往往都是幾十行的錯誤信息，今天寫的這段從第一遍調(diào)試起就一直沒有語法錯誤，我已經(jīng)創(chuàng)造了歷史，更何況結(jié)果已經(jīng)出來了，只是有那么一點點小小的錯誤嘛，表現(xiàn)太完美了也不太好吧??

　　然而我得到的卻是完全出乎意料的答復，而且這個答復來的那么快。“很遺憾，我們不能錄用你!”，面官還是那么和藹，而且還在后面加了一句我懷疑是出于安慰才說的話。“要是你這個程序調(diào)出來了可能我們就會錄用你了，但是我們畢竟有個標準。”

　　他在最后還是給了我一個理由，這個理由成了我此行最大的收獲，這個理由讓我至今都覺得我那次面試有重大意義。“其實程序是調(diào)出來的，不是寫出來的。我剛剛看了你調(diào)試的過程，你沒有使用斷點，也沒有使用單步運行，這些是程序調(diào)試最重要的手段。”

　　這個理由讓我輸?shù)男姆�口服，讓我至今任仍有很多感觸。今天我愿把我的感觸拿出來與大家分享：

　　1.學校和公司對我們的要求不一樣，評價的標準也不一樣。在學校，我上面的那段代碼可能是滿分，我也有過很多次這樣的經(jīng)歷。紙上寫個程序，拿眼睛看看，沒有問題，交上去就完成任務(wù)了。但是在公司，他們只看你代碼執(zhí)行的結(jié)果和執(zhí)行效率，根本不關(guān)心你用多久寫出來，你寫的過程是一帆風順還是錯誤累累，只要結(jié)果和預期值不一樣，哪怕你的代碼和標準答案只差一個字符，也是白搭。其實，在哪以后的代碼編寫中我也很多次發(fā)現(xiàn)，程序沒法得到正確結(jié)果經(jīng)常就是一個非常非常小的錯誤，小的可以忽略。

　　2.“紙上得來終須淺”，軟件學習，其實書看不看，看多少，根本沒那么重要，重要的是自己能動手寫出來而且正確執(zhí)行。在程序的調(diào)試過程中最好不要忽略任何一個細小的錯誤，一切以能否得到正確的執(zhí)行結(jié)果為唯一判斷準則。所謂的經(jīng)典著作上的經(jīng)典程序，很多時候執(zhí)行起來是通不過的，不是我貶低那些個大師，而是程序是要結(jié)合一定的環(huán)境才能談?wù)摻Y(jié)果和效率的，不同的編譯工具對于代碼的執(zhí)行影響很大。

　　3.要重視基礎(chǔ)，在斯達康之后，我還去過阿里巴巴和諾基亞西門子杭州研發(fā)中心(NSN)做筆試題，一個共同的特點都是很注重基礎(chǔ)，我事先著重準備過的鏈表的操作以及析構(gòu)函數(shù)等等很多東西根本沒涉及到。都是基礎(chǔ)題目，只不過選取的考點都很獨特，都是平時容易被我們忽略的細節(jié)，所以不容小覷。很多人做完都覺得很簡單，知道面試名單里面沒有自己時才清醒，因為這種大公司筆試名單基本上都是完全按照筆試分數(shù)高低來確定的。

http://m.ardmore-hotel.com/

【UT斯達康筆試面試經(jīng)驗】相關(guān)文章：

騰訊筆試面試經(jīng)驗07-17

搜狐暢游筆試面試經(jīng)驗07-18

筆試面試的經(jīng)驗談08-27

北京銀行筆試面試經(jīng)驗08-10

國企面試筆試經(jīng)驗分享07-26

廣發(fā)銀行面試筆試經(jīng)驗07-16

企業(yè)面試筆試經(jīng)驗分享07-29

阿里巴巴的面試筆試經(jīng)驗07-15

廣州電信面試筆試經(jīng)驗分享07-16