アメリカでの面接のお話

僕も一応、一番の下っ端というわけではないので、結構面接にかりだされる。
アメリカでの面接という題にしたんだけど、別に僕はあちこちの会社で面接を受けた経験があるわけではないので、ちょっと誤解を招くタイトルかもしれないが、「活字中毒R」の「就職の面接で、「すごくおっぱいが大きいけど、得するの?」と聞かれたら」について、「404 Blog Not Found」の「採用面接はどこまで踏み込んでいいのか?」から、「未来のいつか/hyoshiokの日記」の「面接での質問。欧米ではには気をつけろ」経由で。。。

僕もhyoshioki氏と同様、面接の際に聞いてはいけない事柄を言われている。出身、既婚かどうか、家族はどうか、だけでなく、年齢、性別も聞いてはいけない。これらの事柄を基準に採用を決定することは差別に値するからである。

年齢はさておき、性別もだめって、まぁ聞くことでもないけど、サンフランシスコ近辺のシリコンバレーならではなのかも。俺にしてみれば、プログラム書ければなんでもいいんだけどね。

また、不採用の理由も明確でなければならないので、それらをきっちり説明できるように書類に残して欲しいといわれる。まぁドキュメント化は面倒なので横着しているのが本音であるが。。。

日本とは違って、結構、末端の人間も面接に参加する。実際に募集しているポジションがあり、そのポジションの直属の上司はもちろん、そのポジションのリーダー的な人のレベルまで面接に参加する。自分が一緒に働く人を選ぶわけだから、選ぶ方も必死であるし、また、面接に参加することにより、大体自分と同じような経験の人がどのようなことを考えているのかとか、どんな経験を積んできているのかを教えてもらうのにも、とても勉強になる。
人事部の人と役員面接だけの面接とはまったく違うので、逆に面接されるほうは、実際にどんなふうに仕事をすすめるのかを、具体的に話を聞くことができる。

僕はどちらかというと、かなり圧迫面接に近い手法をとる傾向がある。

もちろん、Jrのポジションに対する面接と、Srのポジションに対する面接とでは圧迫の方法も度合いもまったく違う。

Jrの場合、事前になんでもいいから言語や分野をとわず、サンプルのソースコードは見せてもらっている。このソースコードに対してコードレビューをかけていく。
僕のコードレビューのやり方は、僕がレビューをしていくというよりも、書いた本人にコードを説明させる。そしてその説明において欠けている点を指摘していく。

なぜこのような関数名にしたのか、関数の引数のチェックについて、条件文の書き方とその条件で全ての場合が網羅されているかの検証などを細かく聞いていく。

次に簡単な問題、例えば長方形と円の衝突判定とか、再帰の問題とか、その場で思いついたものをプログラムにしてもらう。
これは別にプログラムを書いてもらうことが目的ではなく、どのように方針を立て、どのように問題に取り組むのかを見たいと事前に説明してから作業に取り掛かる。

ここで最初に行われるのは問題の把握のはずである。いきなりプログラムを書き始めてはいけない。問題についてどのように理解したのかを説明してもらうことから始まる。問題について曖昧な点があれば、質問があるべきだし、逆にちょっとレベルの高い人を対象にしている場合は、出した問題自体にあいまい性を持たせて提示することもある。仕様書は完璧ではないということを前提にどのように対処するのかを見たいのである。自分で考え込んでしまう人もいれば、これはどうゆうこと?と即座に聞いてくれる人もいる。

逆に問題がきっちり定義されて理解されればおのずと方針は見えてくる問題ばかりである。ここまでたどりつけた人は、プログラムを書いてもらうのは無駄なのでそこまでお願いしない。

ついでに、今考えたアルゴリズムを、あなたのまったく知らない言語、例えば、Lispでもなんでもいいけどで書いてもらいたいと仮定する。どのような作業工程になるのかその手順と期間を説明して欲しいとお願いする。

Srの場合、募集しているポジションにあった経験を積んできたとレジュメに記載されていることが多いので、まずそのレジュメの内容を細かく説明してもらう。
正確には、説明してもらうというよりも、こちらから、この内容はこうゆう内容も含まれているのかしら?とか、その内容の経験をしたということは、このような問題が起きたことが予想されるんだけど、どうなのかしら?とかそのように細かく聞いていく。

例えば、サーバークライアントのシステムのデザインの経験があると言われれば、サーバーの負荷について、具体的にどのように見積もりをしたのか、それに対してどのように試験したのか、こんなバグが出ることが予想されるんだけど、それについてどのようにガードをしているのかなど、事細かに聞いていく。

次に、その分野でのプログラミングの経験を、新しいポジションではこのように使おうと思うのだが、その手法についてどう思うのか、現在、われわれのプロジェクトではこのような問題があるのだが、君の経験ではこの分野について解決することができると思われる。では具体的にどのように進めていくのか、など、実際に作業をする前に行われるミーティングというかブレインストーミングのような状況に持ち込んでいく。

ここまでくるとコミュニケーション能力の判断が70%、テクニカルな考え方が20%、残りは感覚というかエンジニアの臭いとかそうゆう領域になってくる。

最終的に作業項目が見えてきて、その作業がどれくらいの期間で実現可能なのかという見積もりまでも聞いたりする。

30分から1時間もこんな話をしていれば、こいつと一緒に働いたときに、1を説明したら10の反応が返ってくる人間か、それとも言われたことを着々とこなしていくタイプかなどの判断が大体付く。

ブレインストーミングを一緒にやっていて面白い人間と一緒に働きたいと思うからである。

雇用者と被雇用者の間には非対称性が横たわる。これは厳然たる事実だ。厳然たる事実だからこそ、建前が大切になってくるはずだ。ましてや、面接時点では面接官と応募者は雇用関係すらない赤の他人だ。見知らぬ街角の人に対して失礼にあたる質問は、理由は何であれやはり失礼だと私は考える。

残念ながら、僕の所属している会社は大手企業ではない。それこそ中小企業のスタートアップである。だからこそ、普段からこんなに一生懸命議論して、いろんな問題をどんどん解決していく姿勢を見せようと思っている。エンジニアとしてそれなりのプレッシャーのなかでみんなで議論しつつアイデアをまとめて、ひとつのものを作り上げていくなんて、こんな面白い場所は、他にはあんまり無いよ。というアピールである。

うちの会社に入社するとそれなりに仕事はしんどい。もちろんそのことは説明する。こんな事情があってこんなタイミングでリリースがあるので、この時期は忙しい。でも、こんなにいっぱい議論ができて、こんなにいっぱいアイデアが転がっていて、それを実現できる場所がここにあって、楽しい仕事ができるんだぜ。] ]>

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください