面接（なぜかする側編）２

細かい事情は当然書けないのだが、とある事情から採用面接で面接する側になってしまった。２回目のことだ。
１回目は 面接（なぜかする側編） - @Hanadix Reloaded を参照ください。

今回の人、どうなんだろう。

Windows での開発を長らくされていたというので聞いてみた。

わたし：Win32 API とか MFC とかを使われましたか？
その人：はい。Win32API は使ってました。
わたし：Win32 API っていろいろアレなところがあると聞きますが、よく使ったものとか、使い方で苦労したものとかを教えてください。
その人：いえ、特にはないですね。
わたし：じゃあ、強いて言えば、何になりますか？
その人：いえ、ないです。

って、ホントに使ってたなら１つや２つ武勇伝があると思うんだが。

俺上司：ご自身で「こういうところは自信がある」というアピールポイントを教えてもらえますか？
その人：いえ、特にこれ、というものは…。

うーむ、ウソとは言わんまでもハッタリかませるポイントぐらいは言ってもらわないと、こっちも突っ込めなくて、スキル読めないので困りますね。

で、今回ちょっと思いついた質問。

わたし：ドキュメントで文章は量を書きますか？　短いほうですか？
その人：短いほうですね。

わたしはドキュメントは量を書いて、レビューでアラを探ししてもらうし、レビュアーになったらそれなりの量を書いて欲しいと思う。短めなのは空気嫁ということなのかもしれんが、私はそれは受け入れない。

ソースは DRY であるべきだが、ドキュメントはコストと品質のトレードオフで、重要な点は参照先を明記した上で重複して書くべきだと考えている。一歩も二歩も踏み込んだ記述をしないと、レビュー時に認識誤りを見つけられない。記述量が多くなれば、それを見やすく書く工夫も必要だ。そういうスキルは重要だ。可能なかぎり箇条書きや、マトリクスなど表を使い、それでも表現できないものを文章で示す。

とか書いてたら「こういう風に書いたら、仕様変更があった場合に記述を直さないといけないので、ちょっとぼかしましょう」とか言われて本気か？　と思った過去を思い出してちょっと悲しくなった。仕様変更だがソース直さなくていい場合でも、ドキュメントは直して「実装には影響なし」と書くべきだろうに。

と、後半違う話題になってしまいましたが、今回の方は、私の中では低印象。でも決めるのは俺上司なので、どうなるのかは知りません。

なお、来週「面接（なぜかする側編）３」がある予定になってしまいました。が、エントリ書くかどうかはわかりません。