ウェブ開発者として仕事を得る方法

この記事はClaudeによって英語原文から翻訳されたものです。

2008年、日本で英語を二年間教えたあと、私はイギリスに渡った。新婚で、仕事はなく、自分の貯金もほとんどなかった。英語を教えていた頃も、大学に通っていた頃も、フリーランスでウェブ開発の仕事を多少はしていたが、プログラミングの腕でフルタイムの仕事を取れるほどの自信はなかった。それでもウェブ開発者として身を立ててみるつもりだった。これは、その挑戦の記録だ。

最初にしたのは、CVを用意し、Googleで「junior web developer UK」と検索して、出てきたものに手当たり次第に応募することだった。面接にこぎつけるまでに、二、三社に応募する必要があった。最初に呼んでくれた会社を、ここではAlphaと呼んでおく。

Alphaとの面接は、ロンドンの反対側にあるオフィスビルの一階のカフェで行われた（片道一時間半の通勤だ）。面接はほとんど技術的な内容ではなかった。フルタイムの経験がなかったので、彼らはコンテンツ管理可能なウェブサイトを作る私の能力を心配していた。面接後すぐに、CMSを実際に納品できるという証拠が欲しい、ということだった。

私は、その晩のうちにコンテンツ管理可能なサイトを作り、翌朝の始業前にURLを送ると決めた。家に帰って、限られたPHP／MySQLの知識で、極めて単純で、ほとんど壊れているCRUDアプリケーションを急ごしらえで組み上げた。当時の道具はWindowsのノートパソコン、Crimson Editor、Fasthostsの共用ホスティングアカウントで、バージョン管理はなかった。これは極めて辛い経験だった。

ほぼ一晩中SQLの構文エラーを直し続けたあと、翌朝十時前には動くアプリケーションのURLを送ることができた。その週のうちに、年俸21,000ポンド（およそ34,000ドル）の正社員フルタイムのオファーをもらった。当時の私でも、これがいい給料でないことくらいは分かっていた。

仕事に応募してオファーをもらえる確率を p としよう。当時のキャリアでは、p の値を自信を持って見積もるだけのデータがなかった。次のオファーをもらうまでにあと百回応募する必要があるかどうかも分からなかった。さらにまずいことに、ジュニア開発者の求人がそもそもどれくらいあるのかも知らなかった。だから、そのオファーを受けた。

Alphaで働いている間、私はスキルを磨くことに多くの時間を費やした。HTTP、複雑さの管理、バージョン管理について独学した。タッチタイピングに投資し、vimを中級レベルまで使えるようにし、ウェブアプリケーションのセキュリティの世界に手痛い洗礼を受けた。

何より、自分で保守と拡張をしなければならない（ひどい）コードを大量に書いた。給料は低かったかもしれないが、Alphaでの経験からは多くを得たし、後悔はない。

偶然「シニア」開発者になった話

Alphaを一年で辞め、より高い給料を提示してきた別の会社に移った。同時にフリーランスの仕事もして収入を補ったが、給料はだいたい20kから30kポンド（34kから48kドル）の範囲にとどまっていた。

Alphaを離れて一年半ほど経った頃、いくつかの正社員ポジションの面接を受けていて、二つのオファーを手にしていた。両方とも38kポンド（61kドル）で、当時の私にはばかげたほど高い給料に感じられた。そのうちの一つを受けるつもりではいたが、リクルーター経由でもう一社、ここではBravoと呼ぶ会社の面接が組まれていたので、せっかくだからとそちらにも出向いた。

ある幸運な手違いで、リクルーターは私を「シニア」開発者のポジションとして応募していた。この時点で私のプロとしてのウェブ開発の経験はおよそ二年で、自分の判断でシニア開発者として応募する勇気は決して持てなかっただろう。

その先に待っていたのは、私がこれまで経験した中で最も過酷な技術面接だった。

まず、CVに書いたすべてのスキルについて質問された。どの項目でも、最終的には「分かりません、でも調べるならドキュメント／RFC／Googleで x を引きます」と答えるところまで掘り下げられた。高スケーラビリティのウェブアプリケーションについての仮想シナリオを与えられ、「動物や図形を使わずに多相性を説明してください」と言われ、チームの開発者と一緒にコードレビューを通り抜けながら、まずい選択のアルゴリズム、微妙なエラー、悪いコーディングスタイルを、できるだけ礼儀正しく指摘していくという課題もあった。

家に帰った時点で、自分がどれだけうまくやれたか、まったく分からなかった。私は普段、面接ではうまくいくほうだが、これほど難しい面接は経験したことがなかった。少なくとも、組織との相性がどれくらい良かったかは、面接が終われば普通分かるものだ。今回は、その日のうちにオファーが来ても、即座に断られても、どちらも驚かない、そんな状態だった。

数日後に二次面接に呼ばれ、こちらが選んだ技術トピック（候補リストの中から）についてプレゼンをすることになった。私はハッシュテーブルを選んだ。大学で習ったことを少しは覚えていたし、残りはWikipediaから組み立てられたからだ。

プレゼンの冒頭で「これはWikipediaの記事を凝縮しただけのものです」とはっきり断った上で、十分ほどそのトピックについて話した。プレゼンのあとは、今度はハッシュ関数の望ましい性質、よくある問題、その解決策などについて掘り下げて質問された。事前にリサーチしていたので最初の波には備えていたが、すぐに知識の底が見えてしまった。

再び家に帰ったとき、今度はBravoからオファーは来ないだろうと確信していた。私には「シニア」開発者としての経験が足りないし、面接中に知識が尽きる場面があまりに多すぎた。

ところが一週間ほど経って、リクルーターから連絡があり、Bravoは年俸44,000ポンド（70kドル）でシニア開発者として私を採用したい、と伝えられた。たった二年前にウェブ開発者として始めたときの給料の倍以上だ。

知らせを聞いた妻の唯一の反応は、「そこまで欲張りしなくてもいいと思う」だった。私にとってあまりにも大きな飛躍で、まだ自分にこのレベルの報酬を受け取る資格はないのに、何か見落としている落とし穴があるのではないか、と感じてしまった。

オファーを受けた。Bravoでの仕事は、これまで経験した中で最も辛く、そして最も学びの多い技術職だった。とりわけ、次のような環境があった。

自分たちの仕事をよく分かっているベテランのプロダクトマネージャーのチーム。
実際に機能しているアジャイルプロセス（本当に）。
たいてい理にかなっている、変化の速いビジネス要件。
二十人を超える開発チームと、百人を超える会社で当然のように発生するすべての政治。
一つずつリファクタリングされている、山のような技術的負債。
多言語のコードベース（ウェブのフロントエンドはPHP／ActionScript、バックエンドサービスはJava）。
非常に優秀な開発者たちとの、白熱した議論の数々。

私の仕事は、自分よりはるかに賢い人たちに、自分の前提を徹底的に問いただされることだった。その結果、強い技術的意見を持つだけでなく、それを明確に言葉にできるようになった。仕事を始めた時点ではシニア開発者ではなかったかもしれないが、辞める頃には少なくとも自分の能力にずっと自信が持てるようになっていた。

最初の数件のウェブ開発者の仕事を見つける

キャリアを通じて、私は正直に思い出せないほど多くの求人に応募し、面接を受け、オファーを断ってきた。この業界に入ってからの短い年月で、ある程度の成功は味わえたと思うので、プログラマーとして仕事を見つけ、確保することについて、少しは語る資格があるだろう。

これから書くアドバイスの一部は、技術面接官が口にする「望ましい姿」とは食い違っており、平均的なウェブ開発者には受け入れがたいかもしれない。それでも、私自身にはずっと効いてきたし、似たような戦略は多くの技術系求職者にも効くはずだと信じている。

これは、もし2008年の自分に会えるなら伝えたいアドバイスだ。

0. 戦略を持つ

私の最初の戦略（悪い）。

関連する求人をGoogleで探す。
求人の説明に合わせたCVとカバーレターで、最初の三、四社に応募する。
待って、祈る。
これで面接とオファーにつながれば受ける。そうでなければ1に戻る。

この戦略は最終的にはうまくいったが、結果は最適ではなかった。

キャリアの初期にいる人たちに勧める戦略（やや良い）。

自分を採用されやすくする資産を築き始める。
大量の求人情報を集めて、市場の感覚をつかむ。
自分にとっての判断基準を作り、それに従ってリードに優先順位をつける。
最も魅力的なリードに、CVとカバーレターで応募する。
招かれたら、よく準備して良い面接をする。
少なくとも三つのオファーを手にしてから、決断を下す。

この戦略の目的は、オファーを受けるときに、情報に基づいた選択をすることだ。求人がすべて30kポンド未満だというなら、それを、自分が安い給料を受け入れることで利益を得る誰かの言葉ではなく、自分自身で確かめられるようにしておくべきだ。

私の現在の戦略は、上記をさらに簡略化したもので、ほとんど労力を必要としない（これがベストだが、そのためにはネットワークが必要だ。それがあるなら、たぶんこの記事を読んではいないだろう）。

以下の組み合わせ宛にメールを送る。
- 親しい契約者仲間。
- 地元のRubyユーザーグループ。
- 過去のクライアント。
- 手が空いていなくて断った見込みクライアント。
興味を示してくれた三、四社と面接する。
その時の状況、関心、その他の基準に照らして、最も良いオファーを受ける。

1. 強みを築く

応募のプロセスを始める前に、いくつかの強みを持っておく必要がある。順不同で挙げると、ウェブ開発者を採用する会社から予測可能にオファーをもらえるようになるには、以下のうちのいくつかが必要になる。

社会的証明（ソーシャル・プルーフ）。 過去に三社に雇われた実績があり、推薦の声と、それを得るまでに修羅場をくぐった経験があれば、採用ははるかにやりやすくなる。そういう実績があるならこの記事を読んでいないだろうとは思うが、これが採用のされやすさにどれほど重要かは指摘しておく価値がある。

自分を推薦できるプロフェッショナルのネットワークを築くことは、潜在的な採用者から見た価値を高めるだけでなく、面接に臨むときの自信にもなる。そのネットワークに面接官本人が含まれていれば、ボーナス点だ。

具体的なアドバイス。 ウェブ開発者として就職して、数年間きちんと仕事をする。それが無理なら、地元のユーザーグループや技術コミュニティのイベントに出て、実生活で人と会い、何かしらの価値を相手に提供してみる。

技術的な深さ。 コンピューターを職業としていじる人なら、電子からエンドファンクターまで、スタック全体について「自分が何を知らないかを知っている」べきだと私は思っている。それに、データ構造とアルゴリズムを仕事で使わないと思っているなら、おそらく一生使うことはない。

具体的なアドバイス。 プログラミングという仕事について読み、それを上達させるための行動を取る。OSの基礎、オブジェクト指向のデザインパターン、関数型プログラミング、ネットワークプロトコル、有限オートマトン、データ構造とアルゴリズム、その他手に入るものは何でも学ぶ。

技術的なスキル。 Dreamweaverを使い、スクリプト言語にAPLを選んでウェブサイトを作っていても構わない。その道具をよく知ってさえいれば。また、バージョン管理システム（例えばgit）の使い方を学ぶことは、21世紀のあらゆるプログラミングの仕事における前提条件だ。

具体的なアドバイス。 意図的な練習を通じて、ソフトウェアを作る腕を磨く。完璧なローストチキンのレシピを知っていることと、六十秒で鶏一羽を骨抜きにできるスキルとは、別物だ。自分に欠けていると感じる技術的なスキルがあれば、それを追いかけ、練習し、自分のものにする。

例としては、お気に入りのテキストエディタでのコード編集をうまくなる、ウェブサーバーを手作業で立ち上げて設定する、SQLで自明でないJOINを書く、coreutilsを使ってターミナルでの作業を上達させる、などがある。

ウェブ上の存在感。 自分の個人ウェブサイトに来た人が、そこから自分の専門分野を簡単に知れるか。経験やスキルセットを読めるLinkedInのプロフィールはあるか。少なくともCVは入手できるか。多作のブロガーである必要はないが、潜在的な採用者が非同期に自分のことを知れる、明らかな出発点があるべきだ。

具体的なアドバイス。 自分のスキル、経験、ポートフォリオを見せるウェブサイトを作り、ネット上の他の場所にも自分を見つけられるリンクを必ず置く。1ページに自己紹介、連絡先、そして「スキル」「経験」「ポートフォリオ」「リンク」と題したセクションを置く、それだけでも十分だ。これに時間をかけすぎないこと。とにかくその1ページを公開し、まずまずの見栄えに整え、次に進む。

動くソフトウェアを公開する。 オープンソースへの貢献歴が長い、輝かしいGitHubプロフィールは要らない。採用者はただ、自分がコードを書けるということを確認したいだけだ。そのためには、何かを作って、作ったものを彼らが見られる場所に置けばよい。GitHubはそのための便利な道具なので、公開プロジェクトのホスティングに使うとよい。

具体的なアドバイス。 ポートフォリオになりそうなアイデアを少し挙げてみて、その中で一番面白いものを選んで作る。小さくて完成させやすいものほど良い。完成したら、公開URLで利用できるようにし、コードはGitHubで公開する。これを二回繰り返すのがベストだ。

特に経験がない場合、この最後の点はおそらく一番重要だ。とにかく何かを作って、公開して、それを自分の名で世に出す。Todoリストのアプリ、自分のブログ、Twitterのクライアント、オンライン写真ギャラリー、何でもいい。

何かを作るという行為自体が、上に挙げた他の各属性のスキルポイントも確実に上げてくれる。

これらの強みは、どれも一晩で身につくものではない。少なくとも一ヶ月程度の継続的な努力が必要だ。これがなければ、面接にこぎつけるのは難しい。

2. リードを集める

Highrise、テキストファイル、紙のファイリングシステム、何でも構わないので、リードのリストを作る。それぞれのリードについて、以下を記録する。

分かるなら会社名。
応募を送るための連絡先。
該当する場合は求人ページのURL。

良いリードの情報源を、好ましい順に挙げる。

自分のネットワーク。 プロフェッショナルな人間関係の中の誰かが推薦してくれる求人は、ほとんどあらゆる種類のリードより望ましい。経験やスキルセットとの相性が良い可能性が高く、採用される可能性も高い。
直接応募（通常は会社のウェブサイトの求人説明から）。リストを作るのに少し手間がかかるが、求人サイトへの投稿に応募する場合のように他の応募者と数で競う必要がないため、面接率は高くなりやすい。
求人サイトは、リードを見つける良い場所だが、大量の他の応募者と競うことになる。全分野を扱う一般的な求人サイトより、技術系に特化した求人サイトに絞ったほうが、多くて質の高いリードが得られると感じている。
リクルーターは、扱いが難しい。彼らのインセンティブをきちんとモデル化すれば理解しやすくはなるが、高圧的な営業手法をかけてきがちだ。それに耐えられて、彼らの振る舞いがすべて「ゲームの一部」だと割り切れるのなら、有望な機会の良い情報源にはなる。

ネットワーク経由のリードについては、自分の知り合い宛てに、現在の状況、求めている仕事の種類、採用者が自分についてもっと知れる個人ウェブサイトへのリンクを、丁寧に伝えるメールを送る。

全員に同じメールを送ってもいいし、各人にカスタムのメッセージでもいいし、あるいは（私の好みでは）カスタムと既製を組み合わせたハイブリッドが良い。歩留まりは低くなりがちだが、ネットワーク経由のリードは通常、非常に質が高い。

技術スタッフを募集している会社を見つけるには、ソフトウェアを作っている会社のリストがすでに載っている場所を探すといい。Silicon Milkroundabout、TechCrunch、YCの卒業生、ソフトウェアコンサル会社のクライアント一覧など、ソフトウェア企業がリストアップされている場所ならどこでも役に立つ。各リストについて、会社のウェブサイトに行き、「採用」のセクションを探し、有望なリードをリストに追加する。

求人サイトは、そのまま使えばよい。訪れて、有望な求人を探し、リストに追加する。質の高いリードを継続的に掲載してきたサイトをいくつか挙げる。

Authentic Jobs
GitHub Jobs
Stack Overflow Jobs
Hacker Jobs UK
CWJobs

すぐに応募したくなる衝動には抗うこと。今の目的は、現時点の技術系雇用市場の感覚をつかむために、大量のリードを集めることだ。

リストに挙げたリードの一部はリクルーター経由のものだろう。当面、リクルーターも他のリードと同じように扱い、求人説明を記録して次に進む。実際の求人でリクルーターと仕事をする前に、Roger DawsonのSecrets of Power Negotiating（『パワー・ネゴシエーションの秘訣』）を強く勧める。リクルーターが自分に対して使う戦術が、その本に詳しく書かれている。リクルーターとの取引には、目を見開いて臨むべきだ。

3. リードを絞り込む

求人を見るとき、何が重要かは人によって違う。あなたにとって何が重要かは私には分からないが、自分があるリードを絞り込むときに自問する質問のリストを挙げる。

オファーをもらえる可能性はあるか？ 推測しにくいこともあるが、たとえばそのポジションが三年のプロのプログラミング経験を要求しているなら、大学を出たばかりでオファーをもらえる見込みはほぼない、というのは明らかだ。
自分のスキルと知識は、（行きたい方向に）伸びるか？ 開発者としてレベルアップしたいなら、ずっとコンテンツ管理可能なウェブサイトを作り続けるような環境では挑戦にはならない。会社の事業内容や、想定される技術的な仕事の性質から、その仕事に情熱を持てそうか。
その仕事は十分な報酬になるか？ 必要なものは人によって違うが、応募するどんな仕事も、お金が問題にならない水準を払ってくれる必要がある。
その仕事は十分に安定しているか？ アーリーステージのスタートアップでの最初の採用者になりたいか。確立した技術チームの新しいメンバーになりたいか。大企業でスーツを着たJava開発者になりたいか。正解も不正解もないが、応募を進める前に、その会社のリスクプロファイルを評価しておく価値はある。
その会社で自分は生産的になれるか？ 何らかの反復的な開発プロセスを持っているか、それとも、プログラマーを必要とする多くの会社にありがちな、いつもの混沌があるだけか。

質問は自由に追加・削除すればよい。主要都市の近くに住んでいないなら、リモートワークが重要な要因かもしれない。コンサル会社で多くのクライアントと働きたい人もいるだろうし、新機能と保守の両方を担当する社内開発チームで働きたい人もいるだろう。フロントエンドよりバックエンドを好む人もいる。

集めたリードをもとに、現在の市場で自分に開かれている仕事のタイプの感覚はつかめるはずだから、それに合わせて基準を調整するといい。リモートワーク可能な求人が一つもないなら、応募するポジションへの絶対条件としてのリモートは緩める、という選択もある。

リストは鉄壁である必要はない。今やっているのは、求人に関して自分にとって何が重要かを把握するだけのことだ。仕事を探していると、来たオファーは何でも受けたくなるものだが、応募する前にこの作業をしておけば、自分を採用しようとする会社の優先順位ではなく、自分の優先順位に集中しやすくなる。

自分にとって何が重要かが分かったら、リードの候補リストから、自分の基準を満たす見込みがまずないものを取り除く。あまり多くを除外したくはない。明らかに自分に合わないものだけだ。対面の面接なしで相性を判断するのは難しいので、現時点では緩めに通すのがいい。

4. 応募する

リードの数を絞り込んだら、応募を始めるときだ。絞り込み段階を通過した各リードに対して、CVと短いメールで応募する。

まず、自分が築いてきたすべての強みを際立たせるCVを用意する必要がある。繰り返すと、これには技術的な深さ、技術的なスキル、社会的証明、動くソフトウェアが含まれる。

社会的証明については、過去に働いた会社や、過去の同僚からもらった推薦の声などを挙げるとよい。関連するフルタイムの経験がなければ、技術以外の仕事でも構わない。
技術的な深さとスキルについては、自分がこれまで扱ってきて、複数の抽象度で語ることのできる技術をいくつか挙げるとよい。ここに書いた内容については自信を持って話せるべきだし、面接で関連スキルを示せるべきだ。
動くソフトウェアについては、自分が作ったアプリケーションの動いているインストールか、自分が責任を持って書いたコードサンプルのいずれかにリンクを張る。見つけてプレビューしやすくしておく。

上記のそれぞれについて二つから五つの例があれば、面接候補者を選ぶ採用者に対する説得力は格段に上がる。

CVの中核の内容やストーリーは同じでいいが、特定の求人説明に合わせてカスタマイズする価値はある。統計や機械学習を伴う仕事に応募するなら、Eコマースのウェブサイトを作る仕事に応募するときとは違うサンプルプロジェクトのセットを選ぶことになるだろう。

CVに加えて、その役職に対する自分の適合性を示す短いカバーメールも書く必要がある。

求人で求められている主要な要件のどれかが欠けている場合、それを無視するのは最悪の手だ。欠点をカバーするための最良の策は、それを正面から取り上げ、速く学ぶ意志と能力があり、未来のチームの負担にはならないと示すことだ。カバーレターは、それをするのにふさわしい場所だ。

経験のない新人の自分が、ソフトウェアでお金を稼ぐ世界での冒険を始める準備ができたとき、送るかもしれないカバーレターの例を以下に書いておく。

アリス様

はじめまして。ボブと申します。現在フルタイムの雇用を探しているウェブ開発者です。

御社のウェブサイトを拝見し、現在ウェブ開発者を募集されていると知りました。掲載されている情報を見るかぎり、私は御社のチームに良い貢献ができると考えています。

ご覧の通り、商業的な経験はありませんので、ジュニア開発者としての応募になります。フルタイムでウェブ開発者として働いた経験はありませんが、御社の要件に挙がっている技術の多くを使いこなせますし、動くソフトウェアをデプロイした経験もあり、初日から開発チームに価値を提供できると考えています。

私の能力を示すコードサンプルとプロジェクトへのリンク付きのCVを添付しました。また、私のGitHubプロフィールはこちらでご覧いただけます。http://github.com/example-example-example

ご興味があれば、どこかでお会いしてお話しできれば幸いです。

よろしくお願いいたします。

── ボブ http://bobthewebdeveloper.example.com/

これをそのままコピーして送るのはやめておこう。自分が良い相性である理由を書く。Facebookアプリケーションの経験がある人が必要だと書かれていれば、ちょうど数週間前に作ったFacebookアプリのことに必ず触れる。分析やユーザビリティテストに熱心な会社なら、自分もその分野に興味があり、もっと学びたいと書く（まだ興味がないし学びたいとも思っていないなら、興味を持つべきだし、学ぼうとするべきだ）。

各応募について、応募した日付をリードのファイリングシステムに記録し、決まった日数後にメールで必ずフォローアップする。私のフォローアップスケジュール（返信がない前提）は、三日後、さらに一週間後、さらに二週間後、その後はそのリードを諦める、というものだ。潜在的な採用者が返信を忘れる理由は無数にあるので、思い出しやすくしてあげる。フォローアップ。

各応募に丁寧に取り組み、一度に三、四件しか送らないこと。すべてのリードに同時に応募すると、自分が混乱するし、各採用者にできるだけ良い印象を残すのにも役立たない。次の応募までは一週間待ち、新しい機会や情報を踏まえてリードのリストを更新する余地を残しておく。

不採用の通知が来たら、それを学びの機会として使う。可能なかぎり礼儀正しく、自分のプロフィールについての懸念点を尋ねる。今後の応募では、彼らが挙げた問題に対応できるようカバーレターの文面を修正する。

5. 良い面接をする

応募がうまくいけば、運が良ければ少なくとも一度は面接に呼ばれるはずだ。ここまで来たら、おめでとう。オファーを得るまでの道のりは、ほとんど終わっている。採用に興味がなければ、彼らは自分を面接に呼んだりしない。

プログラマーを採用する会社の数だけ、面接のタイプも存在する。データ構造とER図をホワイトボードで延々と扱う、非常に技術的な殴り合いもある。経歴と能力について非常に大まかに話す、まったく非技術的な面接もある。一対一、二対一、パネル形式もある。面接が一度だけのこともあれば、未来のチームメンバーに順番に会わせられることもある。対面の面接の前に、面接前のプログラミング課題や複数回の電話スクリーニングがあることもある。これだけバリエーションがあると、プログラマーの面接で成功するための一般的な戦略を立てるのは難しい。

面接官側から見ても、事情はあまり良くない。あらゆるポジションに対して、適切な候補者よりはるかに多くの応募が来る。運が良くて、応募者がCVで露骨に嘘をついていなかったとしても、面接に呼んでみたらどんなプログラミング言語でも配列をループできない、という次の驚きが待っていることがある。それに、自分たちの面接プロセス（良い候補者を見つけるのに不十分である可能性は非常に高い）が、良い開発者を遠ざけ、悪い開発者を通してしまうのではないか、という心配もある。

たいていの面接官は、自分が面接を受けるのが下手なのと同じくらい、面接をするのが下手だ。候補者を不安にさせる気まずい社会的失敗をするし、その人がどれだけ仕事ができるかを示すのにはあまり役立たないクイズのような質問をしてくる。自分の任務は、それでもなお自分をどうしても採用したくなる存在にすることだ。

プログラミングの仕事の面接には、順序はさまざまだが、典型的に以下の要素が含まれる。

自分への非技術的な質問。
自分から彼らへの質問。
自分に解いてもらう技術的な課題。

以下に書くのは、それぞれの段階を、自分が組織に提供できる価値を示すために、そして会社が自分の基準にどれだけ合っているかを確かめるためにどう使うかの、私の一般的な戦略だ。

自分への質問

面接の非技術的な部分は、自分がもたらせる価値を見せる機会が次々と訪れる場所だ。そういう機会を探し出して、自分にとっても面接官にとっても利益になる形で活用するのが自分の仕事だ。開発者を採用する人で「コードと同じくらい上手にコミュニケーションのできる、技術的に有能な候補者には今日は会いたくない」と朝起きて思う人はいない。

簡単な練習をしよう。ノートに、面接官が自分に聞きそうな質問のリストを書き出す。もし自分が自分を採用する側で、自分のCVを渡されたら、何を聞くか。私自身でやってみる。質問は人それぞれ違うはずだ。

これまでの職歴について教えてください。
Ruby on Railsの経験はどれくらいありますか？
日本語が流暢と書かれていますが、本当ですか？
#{過去の会社}での経験はどうでしたか？
最近取り組んだ、技術的に難しい仕事を教えてください。
強みと弱みは？
五年後、自分はどこにいたいですか？
フロントエンドとバックエンド、どちらの開発者ですか？
開発チームでどんな役割を果たすことが多いですか？

挙げた各質問に対して、答えを準備しておく。緊張が心配なら、答えを詳しく書き出してもいい（実際にそうすることをお勧めする）。私は普段、各質問の下にノートに二つか三つのポイントを走り書きしておく。面接中に答えを忘れたら、いったん止まり、ノートを開いて、続きから始める。

目的は、考えうるすべての質問に対して用意した答えを暗唱することではなく、ただ、自分の経験とスキルについて自信を持って話せる状態に入ることだ。

これまでの経験、使ってきた技術、作ってきたソフトウェアについて、語れる物語を持っておく。面接官が追いやすいように、自分の仕事の経歴について筋の通った物語を編み上げる。

準備していない質問が来ることもあるだろうが、十分なサンプルで考え抜いておけば、ほとんどの非技術的な質問には自信を持って取り組めるはずだ。

可能なかぎり、面接官の会社でやることになる仕事に直接関連するスキルと経験を強調する。

彼らへの質問

これは、自分にとって何が重要かを表明し、もっと価値を見せる機会だ。

仮に、自分が以下のことを気にしていると仮定する。

検討している会社と、その目標。
労働条件、技術、プロセス、文化。
自分が作ることになるソフトウェアと、それを作る理由。
絞り込み段階で挙げた、その役職について自分にとって重要だった、すべてのこと。

ある面接の前には、これから話す会社の名前で「会社X」という見出しを作る。会う人の名前と肩書き、住所、電話番号を書く。求人説明を見て、責任、必要なスキル、技術選択など、重要な詳細を書き出す。会社のウェブサイトに行って、何をしているのか、どうやって稼いでいるのか、コアバリューは何かを調べる。彼らのウェブサイトをいじってみる（ボーナス点として、壊せないか試す）。とにかく彼らについて、できるかぎりたくさん知っておく。

「自分への質問」でやったのと同じように、彼らに聞きたい質問をリストアップする。いくつかの例を挙げる（本当に知りたいことをイタリックで添える）。

過去一ヶ月以内にユーザーに届けたソフトウェアを教えてください。 （動くソフトウェアを定期的に届けていますか？）
作ったソフトウェアのエンドユーザーへの影響をどう測っていますか？ （作っているものが本当にユーザーの求めているものかを、どうやって知っていますか？）
黒字ですか？ （この仕事はどれくらい安定していますか？）
なぜ今、開発者を採用しているのですか？
開発者の時間は、保守と新機能の開発でどう配分されていますか？ （時間の大半を火消しに費やすことになりますか？）
技術スタックとアーキテクチャを教えてください。
開発者の仕事はどう組織化されていますか？反復的な開発プロセスを使っていますか？
ドキュメント、ユニットテスト、コードレビューに対するチームの姿勢は？
開発チームが今、取り組んでいる主要なプロジェクトは何ですか？その戦略的な動機は？
{ある技術}を{ある目的}に使っていますが、選んだ理由は？これまでの経験はどうですか？
過去六ヶ月にどれくらいダウンタイムがありましたか？今ウェブサイトが落ちたら、どう対応するかを説明してもらえますか？ （週末や深夜にウェブサイトを直すことが求められますか？）
ユーザー体験やA/Bテストはやっていますか？
自動受け入れテストや専属のQAはありますか？
開発チームには、ソフトウェアの質を改善する時間が与えられていますか？ （根本的な改善に時間を割けますか？）

これはあくまで質問のサンプルだ。上から選んでもいいし、自分が気にすることについての質問を追加してもいい（ヒント。自分で作った優先事項のリストを見直すこと）。

会社についてもメモを取ってあるはずなので、彼らに固有の質問もいくつか用意する。ここでは会社を尋問しているわけではない。ただ、彼らの問題、日々の活動、変えたい・改善したいことについて話してもらおうとしているだけだ。彼らに自分自身のことを話してもらえばもらうほど良い。

技術的な課題

面接官が能力を測るために投げかけてくる技術的な課題には、さまざまなタイプがある。ライブラリAPIに関する恣意的な知識から、オブジェクト指向のデザインパターンとデータ構造についての質問、フェルミ推定の能力を試すものまで及ぶ。

面接の時点では、彼らが課す試験への準備ができているか、できていないかのどちらかだ。技術面接でズルをする方法はない。あるのは、目の前の状況に対する自分の反応をコントロールすることだけだ。

目の前に出された技術的な質問や課題に対して、自分の自信のレベルに応じて私がやることを書いておく。

悪い：この問題に取り組むだけの知識もスキルも、自分には完全に欠けている。

この場合、すぐに正直になり、自分のスキルセットではこの問題は解けないと面接官に伝えるのが一番いい。

ここでの最悪手は、知ったかぶりで問題を切り抜けようとすることだ。あなたが知ったかぶりしている分野の技術知識を持つ人なら、ほぼ瞬時にそれを検知するし、これは確実にマイナス評価になる。

この状況に陥ったら、答えられなかった内容は必ず後で読み込んでおく。

まずまず：たぶん解けるが、途中で助けやドキュメントが必要かもしれない。

ここでも正直に。不明な点を面接官に伝え、問題を彼らに復唱する。一人で問題を解こうとせず、彼らと一緒に取り組む。

良い面接では、ほとんどの質問はこの難易度のはずだ。あなたが自明でない問題に技術スキルと創造的・知的な能力を使っていく様子を見ることが、そもそも面接官が技術課題を出す理由なので、ゆっくり進めて、その機会を最大限に活かす。

最高：二十秒ください……はい、できました！

fizzbuzz、「selectなしでselectを実装する」、「配列に含まれる各クラスのインスタンスを数える関数を書く」のような小さなコーディング問題は、文字通り目をつぶってでも解けるべき類のものだ。

こういうプログラミング課題は、自分のスキルを少しだけ華やかに見せる絶好の機会だ。書くように言われた関数に簡単なユニットテストを書いてもいいし、相手が知らなさそうな微妙な言語機能を披露してもいい。

これらの技術課題でうまくやるための、その他のランダムなアドバイス。

自分のノートパソコンを持っていく。 面接の最中に、誰かの開発環境に慣れることに気を取られるのは最悪だ。
自分のスキルについて正直になる。 自分の能力や経験について嘘をつくのは、真実を語るよりはるかに難しい。嘘には支えとなる嘘が必要で、プロの詐欺師でないかぎり、真実を扱うほうがはるかにシンプルで効果的だ。
混乱したり緊張したりしたら、休憩を取る。 「これを整理して戻ってくるのに五分ほどいただいてもよろしいですか？」と面接の途中で言ったところで、誰もマイナス評価にはしない。その時間を使って落ち着き、神経をなだめ、ゆっくり問題に取り組める。
前提を確認する。 これらの試験で微妙な間違いをしても、面接官は訂正してくれない。だから自分の思考の各段階で、置いている前提を必ず確認する。

面接後。応募のときと同じく、会社から連絡がなければ必ずフォローアップする。今回オファーを出さないと決めたなら、フィードバックを求める。

6. オファーを比較する

決断を下す前に、これから数年を一緒に過ごしてもいいと思える会社からの、少なくとも三つのオファーを手にしているべきだ。複数のオファーを持つべきだと私が思う理由は、次の通り。

複数のオファーは、より大きな自信を与えてくれる。 二つのオファーを手にして次の面接に臨むと、心構えはこう変わる。

どうかこの仕事をください、一所懸命に働きますから！

から、

お互いに何を提供できるか、見てみましょう。

へ。前者は焦りから生まれ、後者は対等な立場で価値を交換したいという欲求から生まれる。働く価値のある潜在的な採用者は、どちらを好むだろうか。

複数のオファーは、（ある程度）オファー同士をぶつける余地を生む。 これは必ずしも給料の話とは限らない。優先事項リストに書いた、どの点についての交渉でもいい。

これは私が操作的になることを勧めているように聞こえるかもしれないが、複数のオファーを持った状態でそれをするのは、操作的の反対だ。本当はX社で働きたいけれど、週末の本番サポート当番には入りたくない、ということがあれば、それを伝えるのは、受けてしまった後ではなく今、正直にすべきだ。

実際には、こちらから能動的にこの種の交渉をする必要はあまりない。面接官は、他にオファーがあるか、他で面接しているかを尋ねてくる。私のアドバイスに従っていれば、両方の質問にイエスと答え、他のオファーの詳細と、自分があるオファーを他より選ぶかもしれない理由を伝えられるはずだ。

実際には本当のオファーは要らない、と反論したくなるかもしれないが、上に書いた「真実を語る」点を参照されたい。掛けるブラフがなければ、採用者にもブラフを暴くことはできない。

複数のオファーを得るという行為そのものが、より多くを教えてくれる。 応募した会社のタイプにもよるが、三回の面接を経た時点で、三つの異なる組織のシニアな技術スタッフと一時間の対面会議を持ったことになる。

面接中に的を射た質問をする機会を活かしていれば、異なるタイプの開発チームの働き方について、それだけ多くの技術的なコンテキストを得ているはずだ。これは確実に自分にとって良いことだ。

何があっても、最初に来たオファーをすぐに受けないこと。考えるのに最低でも数週間欲しいと伝え、相手が投げてくる高圧的な営業手法（「明日までに決断が必要です！」）は無視する。本当に採用したいなら、向こうが待つ。

オファーを手にしたら、あとはこのプロセスの最初に挙げた基準に照らしてそれらを比較するだけだ。

もちろん、ここで基準を見直す自由はある。（私のように）幅広い給料のオファーが揃ったなら、やはりお金のほうがもっと大事だと結論付けることもあるかもしれない。

逆に、提示されているオファーの何分の一かの収入で生活が回るなら、無難なEコマースのサイトより、NLP分析プラットフォームを作るリスクの高いスタートアップに行くほうを好むかもしれない。

まとめ

これが、フルタイムの仕事を探し始めた、この業界の新人ウェブ開発者へのアドバイスの、おおよそすべてだ。

私自身まだ多くを試行錯誤しているところだが、長期で見れば、仕事を探すときに頼れる他の開発者や潜在的なクライアントのネットワークに勝るものはない。今日から始めて、そのネットワークを築き、その中の全員を純金のように大切に扱うべきだ。