実力を測るのにFizzBuzzも二分探索も使えない
FizzBuzzをサービスにする「CodeEval」が面白い、というエントリーは、プログラマ採用に必要なスキル判定とリクルーターのマッチングをサービスとして提供するベンチャーの紹介でした。
しかし「良いプログラマ」というのがいるとして、それを見るのに、アルゴリズムのコーディングなんか必要なのか、そんなもので測れるのかという根本的な問題があるように思えます。
最近、RubyInsideで見かけた「Practical Tips for Hiring Ruby Web Developers」（RubyのWeb開発者を雇うための実践的なティップス）と題されたエントリは、まさにこれに答える内容で興味深いです。オーストラリア人開発者のTim Gohさんは、CのatoiだのQuickSortだのを書かなきゃいけなかったことなんて最近ないでしょ、Fizzなんてプロダクション環境で出力したことねぇよとして、次のような課題が良いのではないかと挙げています。
- Twitter APIでパブリックTLのJSONを取ってきて、“Ruby”という文字列が含まれるツイートからなるArrayを返せ
- 同じくパブリックTLのJSONからフォロワー数でソートしたツイートのArrayを返せ
これに対する候補者のコードを見れば、例えばinjectを使うべきときに、冗長なコードを書いたりしていないかが分かるといいます。それは日々のコードベースにマイナスの影響を与えるプログラマをフィルタするためのテストということです。外部からのデータのサニタイズやHTTPのタイムアウトを考慮しないコードも、日々の業務で足かせになるので“No Hire”だろうとしています。
既存のコードベースに対して作業ができることも現代的なプログラマの要件だとして、Tim Gohさんは、
- Sinatraフレームワークのsend_fileメソッドを改変して、NginxのX-Accel-Redirectをサポートせよ
- アプリ起動になぜ時間がかかるのかを調べるために、Gem（Rubyのライブラリ）のロードタイムのプロファイリングをしたい。BundlerもしくはRubygemsが必要な統計情報を出力するよう改変するdiffを示せ
という課題も挙げています。
このほか、高度なアルゴリズムに関する質問によって複雑さにどれぐらい対応できるかを見る、HTTPやDNSといったプロトコルに関する質問もする良いだろうといいます。プロトコルの質問は、
- イメージファイルのリンクをクリックしたら表示されずにダウンロードが始まる。どうやって直すか？
- HTTPのトラフィックを調べるにの好きなツールは？ 実際にHTTPヘッダを見てデバッグする必要があった場面について説明せよ
といったものです。
候補者のインタビューで何よりも大事なのは、「どのように」ではなく「なぜ」を問うもので、すぐに答えが出るようなものは聞いても仕方がないともいいます。トレードオフの関係にあるもの、例えば設定をYAMLに書くべきか、Rubyのコードに埋め込むべきか、そのメリット・デメリットはなにかといったことについて聞くべきだ、と。国際化のためには、ブラウザのAccept-Languageヘッダを見るべきか、それともIPアドレスによる地理情報を使うべきか、なども良い質問の例だといいます。
Tim Gohさんの言い分は説得力があって、よくよく考えると、CodeEvalではあまり現実的なスキルが測れないのではないかという気もしてきました……。もちろん、複雑なデータ構造やアルゴリズムが扱えて、Apacheの設定を覚えるのに難儀するというようなことはないでしょうから、アルゴリズム系のコンテストにも意義があるように思えるのですけどね。