如何面試前端工程師：Github很重要

　　12月30日 2013年，作者 Alex MacCaw, 翻譯：myownghost

　　注：之前我們介紹過：一名靠譜的JavaScript程式設計師應備的素質，從程式設計師的角度提出要去學習哪些知識，下面這篇文章從面試官的角度介紹到面試時可能會問到的一些問題。

　　我在Twitter和Stripe的一部分工作內容是面試前端工程師。其實關於面試你可能很有自己的一套，這裡我想跟你們分享一下我常用的方法。

　　不過我想先給你們一個忠告，招聘是一件非常艱鉅的任務，在45分鐘內指出一名侯選人是否合適是你需要完成的任務。不過面試的最大問題是每個人都會想著去僱傭他們自己，任何通過我面試的人想法大都跟我差不多（注：因為你總會問你自己關心和知道的問題），這其實不是一件好事。因此我之前的決定都有很大碰運氣的成分。不過，這也是一個良好的開端。

　　最理想的情況下是侯選人有一個全面的Github“簡歷”，這樣我們可以同時通過他們的開源專案瞭解他們。我經常會瀏覽他們的程式碼然後針對一些特定的程式碼設計問一些問題。如果侯選人有非常好的開源專案記錄，接下來的面試會直接去檢驗他們的團隊協作精神。否則，我不得不去問他們一些程式碼方面的問題了。

　　我的面試非常有實踐性，全部是寫程式碼。沒有抽象和理論上的東西（注：作者是個行業派），其他的面試官很可能會問這些問題，但是我認為他們前端程式設計的能力是值得商榷的。我問的問題大多看上去非常簡單，但是每組問題都能讓我考查侯選人某一方面JavaScript的知識。

　　第一部分：Object Prototypes (物件原型)

　　剛開始很簡單。我會讓侯選人去定義一個方法，傳入一個string型別的引數，然後將string的每個字元間加個空格返回，例如：

    spacify('hello world') // => 'h e l l o  w o r l d'    

　　儘管這個問題似乎非常簡單，其實這是一個很好的開始，尤其是對於那些未經過電話面試的侯選人——他們很多人聲稱精通JavaScript，但通常連一個簡單的方法都不會寫。

　　下面是正確答案，有時侯選人可能會用一個迴圈，這也是一種可接受的答案。

    function spacify(str) {
      return str.split('').join(' ');
    }

　　接下來，我會問侯選人，如何把這個方法放入String物件上面，例如：

    'hello world'.spacify();

　　問這個問題可以讓我考察侯選人是否對function prototypes(方法原型)有一個基本的理解。這個問題會經常引起一些有意思的討論：直接在物件的原型（prototypes）上新增方法是否安全，尤其是在Object物件上。最後的答案可能會像這樣：

    String.prototype.spacify = function(){
      return this.split('').join(' ');
    };

　　到這兒，我通常會讓侯選人解釋一下函式宣告和函式表示式的區別。

　　第二部分：引數 arguments

　　下一步我會問一些簡單的問題去考察侯選人是否理解引數（arguments）物件。我會讓他們定義一個未定義的log方法作為開始。

    log('hello world')

　　我會讓侯選人去定義log，然後它可以代理console.log的方法。正確的答案是下面幾行程式碼，其實更好的侯選人會直接使用apply.

    function log(msg)　{
      console.log(msg);
    }

　　他們一旦寫好了，我就會說我要改變我呼叫log的方式，傳入多個引數。我會強調我傳入引數的個數是不定的，可不止兩個。這裡我舉了一個傳兩個引數的例子。

    log('hello', 'world');

　　希望你的侯選人可以直接使用apply。有時人他們可能會把apply和call搞混了，不過你可以提醒他們讓他們微調一下。傳入console的上下文也非常重要。

    function log(){
      console.log.apply(console, arguments);
    };

　　接下來我會讓侯選人給每一個log訊息新增一個"(app)"的前輟，比如：

    '(app) hello world'

　　現在可能有點麻煩了。好的侯選人知道arugments是一個偽陣列，然後會將他轉化成為標準陣列。通常方法是使用Array.prototype.slice，像這樣：

    function log(){
      var args = Array.prototype.slice.call(arguments);
      args.unshift('(app)');

      console.log.apply(console, args);
    };

　　第三部分：上下文

　　下一組問題是考察侯選人對上下文和this的理解。我先定義了下面一個例子。注意count屬性不是隻讀取當前下下文的。

var User = {
  count: 1,

  getCount: function() {
    return this.count;
  }
};

　　我又寫了下面幾行，然後問侯選人log輸出的會是什麼。

    console.log(User.getCount());

    var func = User.getCount;
    console.log(func());

　　這種情況下，正確的答案是1和undefined。你會很吃驚，因為有很多人被這種最基礎的上下文問題絆倒。func是在winodw的上下文中被執行的，所以會訪問不到count屬性。我向侯選人解釋了這點，然後問他們怎麼樣保證User總是能訪問到func的上下文，即返回正即的值：1

　　正確的答案是使用Function.prototype.bind，例如：

    var func = User.getCount.bind(User);
    console.log(func());

　　接下來我通常會說這個方法對老版本的瀏覽器不起作用，然後讓侯選人去解決這個問題。很多弱一些的侯選人在這個問題上犯難了，但是對於你來說僱傭一個理解apply和call的侯選人非常重要。

    Function.prototype.bind = Function.prototype.bind || function(context){
      var self = this;

      return function(){
        return self.apply(context, arguments);
      };
    }

　　第四部分：彈出視窗（Overlay library）

　　面試的最後一部分，我會讓侯選人做一些實踐，通過做一個‘彈出視窗’的庫。我發現這個非常有用，它可以全面地展示一名前端工程師的技能：HTML,CSS和JavaScript。如果侯選人通過了前面的面試，我會馬上讓他們回答這個問題。

　　實施方案是由侯選人自己決定的，但是我也希望他們能通過以下幾點來實現：

　　在遮罩中最好使用position中的fixed代替absolute屬性，這樣即使在滾動的時侯，也能始終讓遮罩始蓋住整個視窗。當侯選人忽略時我會提示他們這一點，並讓他們解釋fixed和absolute定位的區別。

    .overlay {
      position: fixed;
      left: 0;
      right: 0;
      bottom: 0;
      top: 0;
      background: rgba(0,0,0,.8);
    }

　　他們如何讓裡面的內容居中也是需要考察的一點。一些侯選人會選擇CSS和絕對定位，如果內容有固定的寬、高這是可行的。否則就要使用JavaScript.

    .overlay article {
      position: absolute;
      left: 50%;
      top: 50%;
      margin: -200px 0 0 -200px;
      width: 400px;
      height: 400px;
    }

　　我也會讓侯選人確保當遮罩被點選時要自動關閉，這會很好地考查事件冒泡機制的機會。通常侯選人會在overlay上面直接繫結一個點選關閉的方法。

    $('.overlay').click(closeOverlay);

　　這是個方法，不過直到你認識到點選視窗裡面的東西也會關閉overlay的時侯——這明顯是個BUG。解決方法是檢查事件的觸發物件和繫結物件是否一致，從而確定事件不是從子元素裡面冒上來的，就像這樣：

    $('.overlay').click(function(e){
      if (e.target == e.currentTarget)
        closeOverlay();
    });

　　其他方面

　　當然這些問題只能覆蓋前端一點點的知識的，還有很多其他的方面你有可能會問到，像效能，HTML5 API, AMD和CommonJS模組模型，建構函式（constructors），型別和盒子模型（box model）。根據侯選人的情況，我經常會隨機提些問題。

　　原文 blog.sourcing.io