読者です 読者をやめる 読者になる 読者になる

コーディング面接の例

プログラマの面接をするときには実際にコーディングをしてもらうべきという話は良く聞くが、もうちょっと細かくどういうお題を出したら良いかとか、どういう風に評価したら良いかとかの話はあんまり聞かない気がする。せっかくなので、ユビレジでの面接で私がコーディングについて確認するときのパターンを、いくつか紹介してみようと思う。

実際にコードを書いてもらうパターン

候補者がどのくらいプログラミングできそうかの予備情報がない場合に、簡単なアルゴリズムを書いてもらうことが多い。例としては、

  • Linked Listを書いてください
  • Stackを書いてください

など。ここで、おもむろに

int main(int argc, char* argv[]) {

などと書き始める人は、あまり良い印象をもたれない。

class Stack

などと書き始める人は上よりは期待できる。

このとき、わざと出題で詳細をあまり明らかにしないことも多い。言語や環境によって、事前にもっと細かい仕様を確認する必要があることもあるはずだけど、そういうのに気が回ることを示せるととても良いと思う。けど、あんまり重視はしていない。基本的には、プログラムを書くことができるかどうかに注目している。

RubyRailsが書けることが前提の候補者には、典型的な構造を持つRailsのモデルについて聞くこともある。「お会計に対応するCheckoutというモデルがあって、そこに顧客を保存したい」といったお題を出す。

ここで、

  • checkouts.customer_idを追加する

みたいな議論ができるかどうかを確認する。その後、「Rubyで書けます?」みたいな話をして、

class Checkout
  belongs_to :customer
end

などとすぐにそらで書ければ良い。これは基本的なレベルなので、3秒以上詰まる人は低評価。

さらに、「でも顧客が二人いることもあるんだけど」みたいな発展をする。

  • checkouts_customersみたいな関連テーブルを追加する

みたいな話ができれば良い。has_many :throughがすぐにそらで書けなくても許容範囲内という判断は、しても良いと思う。

その人が書いたコードについて質問するパターン

GitHubなどで意味があるコードが見られる人の場合は、コードレビュー的なことをやることがある。(「Railsの練習」みたいなリポジトリは相手にしない。)

例えば、

  • この正規表現はどういう意味?この{1,3}ってなに?
  • ここのsetTimeoutいる?

などと聞く。

ちゃんと自分の書いたコードの意味をわかっているかどうかを聞くのが目的。

  • 全然見当違いの回答をする人
  • なにも答えられない人

は評価が悪い。

  • ちゃんと説明できる人
  • 忘れていたとしても(古いコードだったら「今ならそうは書かない」みたいなことはよくあることだ)、他の正しい書き方を説明できる人
  • @soutaroの勘違いであることを説得できる人

は良い評価ができる。

ユビレジのデバッグをやってもらうパターン

面接の最初に製品と会社の説明をしているときなど、じっくりユビレジの挙動を見ていると、変な挙動に気付くことがある。(もしくは、原因が判明している不具合を含むバージョンを使ってデモをする。)

こういうときに「これ変ですよねー」みたいに聞いてみて、どういう返答が得られるかを調べることがある。あんまり変なバグだと難しすぎるので、典型的な間違いを犯しているコードであると推測できるような不具合について聞くのが良い。(実際の間違いが予測できないものであったとしてもかまわないが、挙動を見た瞬間に予想できるものではないと難しすぎる。)

私の例では、

  • Ajaxのリクエストが連続して発行された場合に、先に発行されたリクエストで結果が上書きされる
  • イベントハンドラを二重に登録してしまったために、イベントへのアクションが二重に実行される

などの不具合で議論したことがある。

これらのありがちな間違いの確認を提案できる人は、当該の環境での経験がある程度あると期待できる。(本当の原因が全然違うもので、推測が見当違いだったとしても、それ自体はマイナスにはならない。)

次に「どうやって確認したらいいですかねー」などと、開発環境やデバッグの手順について聞くこともある。デバッグプリントよりもデバッガの使用を提案できる方が、評価が高い。

こういう方法をやっているという話を他に聞いたことがないので、適切な方法でないかもしれない。

コーディングについて聞かないパターン

GitHubでスターを集めまくってる候補者の場合や、よく知っている開発者からの強い推薦がある候補者の場合など、候補者が十分にコードを書く能力があることに確信が持てる場合は、コーディングをスキップすることがある。

この場合は、ユビレジで抱えている技術的な問題について議論したり、適当なライブラリについて質問したりして、一緒に上手く仕事ができそうかどうか、気分よく仕事をしてもらえそうかどうかについて考えることになる。仕事で発生するコミュニケーションのほとんどは、

  • Backboneが辛いんだけど、どうしたら良いか
  • Railsparamsが壊れている気がするんだけど、どうなってんのこれ?
  • MySQLが遅いのをなんとかする方法はあるか

みたいな感じで議論することなので、ある程度抽象的な議論をして上手くやれそうか見るのには意味があると思う。

基本的には議論になるかどうか、好みが合うかどうかを見れば良い。議論にならないパターンはいくつかあるけど、抽象化のレベルが合わないものを見落とさないように注意した方が良い。一般的すぎる議論とか具体的すぎる議論になる場合は、その候補者とあなたの興味の範囲が違いすぎている。好みが合わない場合はしょうがない。

なにがわかるのか

結局のところ、いつもやっている仕事を上手く一緒にできそうかどうか予想している。面接では、

  1. 十分なスピードでコードを書くことができるか
  2. コードレビューについてはどうか
  3. 典型的な誤りを正しい手順で調査できるか
  4. 開発の過程で実際に発生する議論が上手くかみ合うかどうか

などについて予想する材料を集めている。

ちなみに、1.については実は明らかにテストが不十分で、いつも私が使っている問題は簡単すぎてその人の腕力・体力がどのくらいあるかは上手く予想するのが難しい。

  • もうちょっと難しい問題でコーディングしてもらう
  • もうちょっと複雑な構造を持つプログラムを、あらかじめ書いてきてもらう

といった方法が考えられると思う。

参考文献

こういう本もある。例題を探すために買った。(英語版を買ったけど、和訳も結構前に出てたことに気付いた……)

世界で闘うプログラミング力を鍛える150問 ~トップIT企業のプログラマになるための本~

世界で闘うプログラミング力を鍛える150問 ~トップIT企業のプログラマになるための本~


この記事は最初Qiita Teamに公開してたけど、社内から好意的な反応をもらえたような気がしたので、@k_katsumiの提案もあって公開することにした。