ガチ三流エンジニアが米国マイクロソフトのドリームチームのメンバーになれた話とそのためにやった事
私は卑下しているわけではなく、ガチでプログラミングの才能が無い。他に才能があるといわれる分野は持っているが、プログラマとしてはガチで三流だ。
そんな私が、今でも夢のようなのだけど、長年あこがれた米国マイクロソフトのドリームチームのポジションを得ることができた。今回はどうやってそのポジションをゲットすることができたかについてシェアしてみたい。
ガチの三流プログラマ
私はガチでプログラミングの才能が無い。プログラミングを始めたのは確か、１０歳ぐらいだろうか？だからキャリアはスーパー長い。三流というのは謙遜ではなくて、自分と過去に仕事したことがある人なら知っていることだと思う。私には人より出来ることもある。それはコンサルティングだったり、アジャイルや、DevOps のコーチ、そしてエヴァンジェリストだ。日本のマイクロソフトではプレゼンは必ず上位だった。私は過去を振り返ると、何回もプログラマになろうとして、失敗したり挫折したりしている。つまり、人にやってもらうことは得意だけど、自分でやることに関しては暗黒だ。
最初の大手ＳＩに勤務したときも、あまりのプログラミングのできなさ加減に、先輩に見捨てられて、しばらく営業になっていたし、プロジェクトを自分で営業してとってきてやったりしたけど、プログラマとしてアサインされることはほぼほぼなく、スタートアップでも、「牛尾さんは、プロマネ力凄いねんから、プロマネやりはなれ。プログラマとしては才能無いですわ」とガチに好意でいってもらえたこともある。他にも自分が才能無いことを見せつけられるケースはそれこそ山のようにあれど、プログラミングで私が能力を示すことはなかった。
マイクロソフトに入ったのも、自分の技術力のなさからくる「偽物感」がものすごく嫌だった。友人のアジャイルコーチとかも、そもそも基本的な技術者としての実力がある人ばかりなのに、自分は偽物やなぁ、、、ってずっと思ってた。だから、マイクロソフトにエバンジェリストで入ると、プレゼンとかは得意なので、コントリビュートしつつクラウドコンピューティングが学べると思ったのだ。
Serverless の Azure Functions チーム
日本にいる時代から、自分にはあこがれのチームがあった。Azure Functions チームだ。明らかに才能ありまくりの人がそろっていて、イノベーティブなサーバーレスのプロダクトをガンガンに作って運用している。Serverless が大好きだったので、めっちゃくちゃ時間をかけてリポジトリにコントリビュートしたり、公式ドキュメントやＰＲでコントリビュートをしたりしていた。Durable Functions を発明した Chris を含めて、めっちゃくちゃ優秀な人がいて、Serverless のプラットフォームを作ってるチームにいつか Join したい！と思っていたけど、自分も心のなかで、何年かかることやら、、、と思っていた。
自分は自分の実力を知っているし、自分でも、友達の Chris に、「わしが君やったら絶対自分を雇えへんわ」とよく言っていた。そういうことを複数のプロダクトチームの友人に言うと、「Tsuyoshi は才能あるねんから、CAがいいよ」と複数の人から言われていた。CA は、日本だとちょまどさんや、寺田さんがやっているアドボケートのポジションで一握りの人しかなることができません。たしかにそこは自分でも才能あると思うし、実際に友人のアドバイス通り声をかけてみたけど、英語の環境では、日本語のトークがうまいという利点はないも同然なので、アジアの担当の人を紹介するわ。と言われたりしていました。いや、わしシアトルに住んでるんすけど、、、
自分ってホンマ米国に来ると価値無いなぁ、、、ってガッカリしたりもした。 しかし、自分の唯一のいいところはあきらめが悪いところなので継続してプロダクトチーム（クラウドサービス自体を作っているチーム）に参加できる実力になることを心に決めてそれに向かって行動しました。しかも私のロールは、DevOps なので、コーディングよりコンフィグレーションや、Pipeline の構築が主な仕事で、コーディング仕事はそんなありませんし、あったとしてもそんなに難しくありません。だから、私の同僚も、DevOps チームからプログラマ系の職を得るのは非常に難しそうでした。「君はプログラマやなくて DevOpsやろ？」ってよく言われていたらしいです。むずいのはわかったけど、やるだけやと思って計画を始めることにしました。
プロダクトチームの人に話を聞く
最初にやったことは、既にプロダクトチームの一員になった友達や、プログラマや研究職の日本人の人に話を聞いてみました。私はリロケーションでアメリカに来たので、こちらでのジョブインタビューは受けたことがありません。マイクロソフトの中での転職作業でも、外部からの転職と変わりありませんので、がっつりジョブインタビューがあります。具体的にはコーディングインタビューだったり、アーキテクチャディスカッションだったりします。私が個人的にとても役にたったものが３つあります。最初は LeetCode です。コーディング面接用のサービスらしいですが、アルゴリズムやデータ構造の勉強になるので、とてもいい感じです。私は教えてもらったこのブログの６０問を２週して、考え方をしっかり吸収しようとしました。実はコーディング面接には全然でなかったのですが、プログラマとしての実力を上げるのに役立ちました。
アメリカでの就職事情を学ぶ
この本、アメリカに来る前に買っていたのですが、なんと、この著者の竜さんが当時マイクロソフトで働いていて、友達になれたので本も熟読したし、本人にもお話をお伺いすることができました。竜さんは、マイクロソフトだけではなく、Amazon, Google (現在) にもお勤めで、面接を受けるだけではなく、面接をする側も何回も体験されている方なので、内容がガチでリアルです。勉強になりまくることばかりだったのですが、特に印象に残っているのは「コーディング面接は、結果というよりも、過程や、考え方、面接官とのコミュニケーションを見ている」という部分です。
問題がさっととけるのに越したことはないですが、例えば問題をたまたま知ってたら解けるわけで、問題を解けるかどうかはある意味重要ではありません。その人が同僚になって働いたときに、面接官がこの人と働きたいなと思ってもらうことが重要なので、自分が解答がわからなくても、ガッカリせずに面接官に質問したりコミュニケーションをとりながら自分の考え方を口にだしながらコーディング問題を考えていくのがよいようです。事実、私は２つのプロダクトチームのコーディング面接を受けました。両方通りましたが、１つは正直ガチで落ちたと思っていました。それぐらい問題はあまりできませんでした。でも蓋を開けたら合格していました。たぶんこの本や竜さんのアドバイスが無ければ、そんな状態になったら、焦るばかりで何もできなくなっていたかもしれません。それぐらいこの本は本当に有用でした。この話に関しては竜さん以外からも複数の人が言っていました。
Applyすること
３つ目は希望のポジションがあったらApplyすることです。当たり前に聞こえるかもしれませんが、Applyしなければ絶対受かりません。しかし、今になって思いますが、これが最も重要です。私の Azure Functions チームは、AppService チームというグループに所属するのですが、そこに所属する唯一の日本人が先輩の河野さんです。本当に素晴らしい人で技術者としても半端ないので、よくたくさんの人から質問を受けています。みなさんこう聞きます。「河野さん、どうやったらマイクロソフトの本社でクラウドを作るプロダクトチームに入れるのですか？」、河野さんはこう返すそうです。「受けたから。受けましょうよ！」
しかし、誰一人として Apply した日本人はいなかったそうです。たぶん多くの人は「あんなハイレベルなところは受かりっこない」「実力をつけてから受けよう」と思ったのかもしれません。しかし、自分が満足できる実力になる瞬間は永遠に来ません。今受かった私が思うのは、「受けないと受からない」というシンプルな事実です。明らかにプログラマとして実力が大したことない私でも受かるのですから。
じゃあなぜ受かったんだろう？
事実、Azure Functions チームのプログラマは半端ない人が多いです。でも、雇う側から見たら、「凄腕プログラマしか雇わない」と思っているとは限りません。その時々の事情によって欲しい人は変わります。そりゃできたほうがいいに決まっていますが、「ここのコードベースのことを知っていて、チームビルディングがうまい人が欲しい」とたまたま思っていたタイミングがあったらどうでしょう？雇う側の人もスーパー賢いひとなので、私のプログラミング力が大したこと無いことは当然見抜いていると思います。その上で私をやとったのは、たまたま、チームの事情と、私がマッチングしてたからで、「プログラマとして凄腕だったから」ではないのです。
私は元アジャイルコーチですし、Kubernetes や Go の経験がありますし、Azure Functions のリポジトリにコントリビュートしていたので、コードベースを知っていたわけです。凄腕だからじゃないのです。こんなことは、当然受けるまでわかりませんでした。でも、ポジションの応募がかかったから受けたら、本当にたまたま受かったのだと思います。タイミングが良くて。事実私より１０００倍ぐらい凄腕のプログラマがこのポジションを落ちているのです。でもそんなチームの事情など外部から知ることが出来るはずがありません。だから、本当に受かった理由は、「受けたから」です。河野さんが、みんなにアドバイスをした「受けましょうよ」で、実際に受けたのが私だけで、私が受かったのです。皆さんもいろいろ考える前に「受けて」みませんか？もし、落ちたとしてもそこからフィードバックが得られて面接がうまくなるし、将来再チャレンジするときも、参考になるはずなので、マイナスなど一切ありません。
コーディング面接、アーキテクチャ面接はどんなものだったか？
どんな問題が出ていたか？はお話しできませんが、残念ながら LeetCode の問題は一切出ませんでした。私は２つのチームを受けて両方受かりましたが、２つの設問に対して共通する傾向を発見しました。それは、「そのチームが欲しい技術分野が試される」ということです。基本的にプログラミングがちゃんと出来る人、だからまずはアルゴリズムとデータ構造に強い人が欲しいと思う人が居たら、LeetCode の問題が出ると思います。他に何かのプロダクトを作っているチームだとすると、そのチームのつくってるものに必須となる素養が試されるという感じでした。
例えば、プロダクトのアプリケーションのアーキテクチャが重要なプロダクトでは、オブジェクト指向の問題が出るかもしれませんし、高度な並列処理を行うのであれば、コンカレントプログラミングについて問われるかもしれません。また、大量のデータを受け付けて処理するようなアプリケーションでは、データストアを効率よく操作するための設問がでるかもしれません。つまり、そのチームが欲しい人がもっていてほしい技術が問わるかもしれません。コーディング面接はチームによって全く異なると思っていた方が良さげかもしれません。
先にプロダクトチームにいったブラジルの友達が言っていました。「自分はめっちゃたくさん面接受けたけど、どれも全然違った。あるチームでは、お前はジュニアの力しかないといわれたけど、別のチームでは、実力があるから、アップグレードしてシニアとして採用しようと言われた。評価も含めて全然ちがうのが普通。自分は同じなのにね」ここでも、やっぱり受けないと始まらないことがわかります。受けて落ちても得ることがあるので、受けて損することはありません。
やったことで、役立ったことのまとめ
既に書いたもの含めて今回のポジションをゲットするために役立ったものをリストアップしておきます。就職のために意識してやったわけではありませんが、後になって思って効果的だったことも書いています。
情報を得る
- プロダクトチームの人に話を聞く
- 書籍
- ブログ
実力をつける
- LeetCode
- プログラミング師匠を持つ（わたしの場合かずきさん）
- 技術を学んだら、ブログに書く
Visibility を上げる
- リポジトリにコントリビュートする
- オフィシャルドキュメントに寄稿してコントリビュートする
- 英語でブログを書く
- Azure Functions のプロジェクトを実施して、チームとコミュニケーションをとる
- チームの人と Serverless のイベントをつなぐ
- Linked In をアップデート
スペシャリティ
- DevOps, Agile (技術と、チームビルディング、マインドセット)
- Kubernetes, Go
- パッション
情報を得るに関しては先にはなしてありますので、話してないことを。受かった後でOfferLetterを受け取る前のタイミングでは、わたしはこのブログを書いているゆうさんにお世話になりました。この記事も大変有用でした。
僕がAmazonの英語面接を突破できたのって、ぶっちゃけアホみたいに準備したからだけなんですよね。
— ゆう🇺🇸本気のアメリカ就職 (@honkiku1) April 15, 2020
というわけで僕がどんな準備をしたか公開します。
これだけやれば誰でも通るんじゃないかな😊😺#本気のアメリカ就職 は、アメリカ就職したい人を本気で応援しています！https://t.co/ihBzuPMK8C
三流プログラマなので、素直に実力をつける努力を継続して行っていました。LeetCode は役に立ちました。アルゴリズムやデータ構造などは、三流プログラマでも、学んで実践したらコーディング力が上がる実感があったので、よかったです。また、私にはラッキーなことにコーディング師匠のかずきさんがいます。よく助けてくださって、ここまでこれたのも彼のおかげですが、彼のアドバイスとして、学んだらブログを書くことといわれていて、実際に彼もやっています。彼は自分が見た中で１，２を争うぐらいコードが書ける人で。彼のようになるためには、そういうシンプルで小さな積み重ねが重要みたいです。私も継続しています。
Visibility は、チームの人から見た、私の存在感です。雇う側としても「この人実力あるのかな、、、無いのかな、、、」と面接で判別する必要があります。ところが、実際にコントリビュートとかしている人がいたら、少なくともこの人は知っているし、実際にコントリビュートもしているのだから、役に立つ確率は相当高いと雇う側からすると思えると思います。GitHubのプロジェクトにコントリビュートするといいことづくめです。レビューされるので実力が付きますし、コードベースを学ぶこともできます。
普段の学び用のブログはこことは別で Qiita に書いていて、内容は既にどこかにあったりしても、自分が知らなかったら書くようにしています。つまり自分用です。中身をみると、なんと内容の無い、どこでもあるような内容だと思うかもしれませんが、それでよいみたいです。師匠曰く、複雑なプログラミングの中で知らないことが出てきたら、必ず小さなサンプルを作って動かして、ブログに書くこと。
でも、たまにこの情報はシェアしたほうがいいんじゃないか？と思ったときは、英語でブログを書くようにしています。大したアクセス数はありませんが、そんなものでも、「Tsuyoshi ブログ見てるよ。この前やくだったわ」とか知らん人から言われることもよくあります。先日もお客さんからフォローしたと言われてびっくりしました。
あとは、面接の直前ですが、Linked In の情報をターゲットのチーム向けに書き換えました。彼らが関心ありそうなことがわかるようにしています。アメリカの面接の場合、Linked In は完全に楽です。こいつをアップデートしておけば、履歴書が必要ありません。もう絶対これしかない。
https://www.linkedin.com/in/tsuyoshi-ushio-34458a19/
最後のスペシャリティは、自分がもともとやっていただけで、今回のチームには関係ないと思っていたけど、プラスに働いたことです。つまり何が言いたいか？というと、自分では関係ないと思っている事でも、チームにとっては欲しい要素があるかもしれないということです。私は DevOps とかは、マイナスでしかないと思っていました。プログラミングをする機会もプログラマよりずっと少ないからです。つまり事前にはわからないので、今自分がやっていることは手を抜かずしっかりやっておくのがいいと思います。
おわりに
大変ラッキーなことに、アメリカに来て目標にしていたドリームジョブをゲットできたので、自分がやったこと、体験したことをシェアしようと思いました。 とりとめもありませんが、この記事が誰かの役に少しでも立てたらうれしく思います。
これからは、Serverless の世界をよりよくするのに貢献していきたいと思います！
