從一道簡單的面試題考查應聘者的技術能力

面試觀察中發現，很多開發同學平時只注重各種框架、新技術的學習，對於基本功不夠重視，然而對於框架的學習，很多時候也只停留在會用的水平，對於框架的實現原理以及框架能解決哪些問題不是非常清楚。日常的開發實踐中，很多時候也只是照著現成的代碼拷貝粘貼，然後再修改，最終是可以用的。但如果要從頭開始，搭建一個完整的項目框架，或者寫一些稍微複雜的代碼，就完全暴露出真實水平了。

問題

下面是筆者在面試中經常讓應聘者手寫代碼的一個題目。要求如下：

輸入：一個帶轉義字元』』的字元串

要求：刪除轉義字元』』和它前面的字元，如果遇到多個連續的』』，則刪除相同數量的轉義字元和前面的字元

輸出：最終的結果字元串

舉例：輸入"abcdghi"，期望輸出"ghi"

題目本身比較簡單，主要涉及字元串操作，但和流行的C語言面試題目strcpy類似，可以從很多細節處考查應聘者多方面的能力。

基本功

下面總結應聘者常見的幾類表現，來一一說明。

第一類：做不出來

做不出來分兩種情況。

第一種是需求沒有理解清楚。

1. 不知道轉義字元，認為』』是兩個字元，從而把問題複雜化

2. 簡單地用字元串的replace操作替換』』字元

這類應聘者在你講的時候，可能根本沒有認真聽，放到日常的工作中，可能一件事情要反覆講很多遍，才能達到你想要的結果。

第二種是真的做不出來，可以給適當提示，如果還是完成不了，可能基本功就不過關。

第二類：基本能實現需求

public String stringReplace1(String str) {

if (StringUtils.isEmpty(str)) {

return StringUtils.EMPTY;

}

int index = str.indexOf("");

if (index == -1) {

return str;

}

return stringReplace1(index <= 1 ? str.substring(index + 1)

: str.substring(0, index - 1) + str.substring(index + 1));

}

這是一個典型的遞歸解決辦法，可以看出對於String類的基本操作比較熟悉。從一些細節上，字元串的判空處理、substring的index處理，都可以看出來應聘者比較細心。我會追問效率問題，還有當輸入是一個非常大的字元串時會不會有問題，如果應聘者能考慮到非遞歸方法和棧溢出的問題，會得到加分。

public String stringReplace2(String str) {

int count = 0;

StringBuilder sb = new StringBuilder;

for (int i = 0; i < str.length; i++) {

if (str.charAt(i) != "") {

sb.append(str.charAt(i));

count++;

} else {

if (count > 0) {

sb.deleteCharAt(count - 1);

count--;

return sb.toString;

}

這個實現更讓人滿意一些，實踐中發現有不少人不知道如何刪除StringBuilder對象中的一個字元，可能大家append方法用的最多，不知道還有一個deleteCharAt方法。如果有應聘者知道這個方法，或者假設有這麼個方法，可以問問實現原理，效率如何，如果能夠答上來基於數組實現的數據結構的優點和缺點，我會相當滿意。

第三類：更好的實現

public String stringReplace3(String str) {

int dstPos = 0;

char result = new char[str.length()];

result[dstPos++] = str.charAt(i);

} else {

if (dstPos > 0) {

dstPos--;

return String.valueOf(result, 0, dstPos);

}

這是最滿意的一個實現，與第二種類似，無非就是把StringBuilder換成了char array，這樣在刪除一個字元的時候只需要移動下標即可，性能肯定比用StringBuilder要快不少。

第四類：把問題考慮的太複雜

有的應聘者會把問題考慮的過於複雜，比如可能會考慮到搜索連續的非』』字元區域和連續的』』區域，然後計算需要保留的字元區域，整塊拷貝，以為這樣可以提高效率。顯然對於這個問題，最終的結果可能是對的，但是寫起來比較複雜，面試中極容易因為細節沒處理好而被面試官指出來。實際上對於這個問題，這種做法的效率並不高。實踐中這類應聘者，題目多半會做不出來。

代碼

雖說面試時時間緊張，首要目標是完成題目，但很多應聘者寫的代碼潦潦草草，根本沒法看，只能邊看邊解釋。也有應聘者會寫完第一遍，覺得沒問題後再謄寫一遍，這至少是一個好的習慣，以體現對面試官的尊重。更好的做法是先理好思路，再一氣呵成。從完成的代碼，至少可以看出代碼的整潔程度和代碼風格，俗話說字如其人，放到代碼上也是一樣的道理。

態度

往往大家認為，筆試對於剛出校門的人是強項，很多工作了好多年的人，對於筆試是極其反感的。筆試分兩種，一種是面試之前，讓你先做做筆試題，考查應聘者的技術基礎，大部分都比較簡單，本人對這一類筆試是反感的。首先，很多題目都比較偏門，類似運算符的優先順序、指出構造了幾個對象等等，固然可以測試應聘者在很多細節上的掌握程度，但在實際的開發過程中，這些細節又能用到多少呢，特別是對於Java之類高級語言。其次，答題的時間多了，交流的時間相對就少了。

另一類筆試是本人比較喜歡的，面試中除了交流，還可以讓應聘者做幾個小題目，或者搞個白板編程也不錯。這類題目一般都不會特別複雜，如果應聘者不是很配合，或者草草了事，我可能會認為這個人的態度有問題。作為一個軟體工程師，寫代碼是最基礎的能力。如果覺得有不理解的地方，或者有困難，可以和面試官交流，給予適當的提示，但首先需要端正態度。

寫在最後

對於面試中小題目的選擇上，可以稍微靈活點，結合一些實際中遇到的問題，讓應聘者來嘗試解決，簡單的可以寫出代碼實現，複雜的給出解決問題的思路和過程也是好的；不贊成直接用明確的演算法題，比如快排、二叉樹遍歷，這類題目目標非常明確，只要應聘者熟悉這個演算法，或者準備過這個演算法，很容易就可以寫出來，無法考查出分析問題和解決問題的能力。

本文只是舉一個簡單的例子，小題目本身可能並不是目標，通過應聘者在解決這些小問題時的表現，根據實際情況作適當的延伸，可以考查更深層次的知識，以及應聘者解決問題的思路和反應，也同時可以反應出一個人對於工作的態度。

本文譯者：袁國營（點融黑幫），現任點融資深軟體工程師，負責資產端的系統架構設計和開發工作，從頭開始搭建了統一進件和自動審批系統。先後任職於上海貝爾、IBM，在電信、伺服器開發、互聯網金融等多個領域工作過。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！