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

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

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

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

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

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

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

class Stack

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

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

RubyやRailsが書けることが前提の候補者には、典型的な構造を持つ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が辛いんだけど、どうしたら良いか
Railsのparamsが壊れている気がするんだけど、どうなってんのこれ？
MySQLが遅いのをなんとかする方法はあるか

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

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