【海外就活】Amazonでインターンした学び・体験・感想
こんにちはお茶会と申します(@techkai_)。
北米の大学で情報科学を専攻している者です。
2022年の夏、カナダのバンクーバーのAmazonにて12週間、ソフトウェアエンジニア(SDE)としてインターンをし、無事フルタイムのオファーをもらうことができました。私は今まで、
日本のスタートアップ
日本の上場企業
カナダのゲーム開発会社
大学の研究室
シリコンバレーのスタートアップ
でインターンしてきました。その中でも特に、Amazonでのインターンは短期間にもかかわらず最大級の学びがあったと言えます。あなたがもし学生なら、Amazonでインターンすればたくさんのことを学べるに違いありません。
本記事ではAmazonでの自分のインターン体験、学び、インタビュープロセスについて書いていきます。
こんな方に読んで欲しい
本記事は次のようなターゲットに絞って書いた記事なので、少々テクニカルな内容が含まれています。
Amazonインターンに興味があるエンジニアの方
コンピューターサイエンスを志す学生
エンジニアとして就活中の方
自己紹介
名前：お茶会
大学：ブリティッシュコロンビア大学(UBC)
学年：新4年
専攻：コンピューターサイエンス
趣味：将棋・芸人のラジオ・怪談など
高校卒業まで日本で育ち、大学進学のためカナダに来ました。
インターン プロジェクト
Amazonインターンはプロジェクトベースで、一人一つ、デザインからEnd-to-endテストまで完遂しそれをDeliverすることを目標にします。
メンターのガイダンスはあるものの、プロジェクトはチームのプロダクトのサイドプロジェクトのようなもので、タスクなどは全てチームから独立しています（インターン後にプロダクトにマージされるのでインパクトは残せます）。なので、かなりの自走力が問われるインターンシップでした。この「自走力」は、Amazonの社訓である”Ownership"というところにも反映されています。「自走力」というのは例えば、
必要であれば自分からチームメイトとのミーティングを予約し、知識の穴を埋めたりアイデアの共有をする自発性
何かのタスクにブロックされたらある程度は自力で解決する能力
プロジェクトが期間内に終わるようなセルフマネジメント
などが挙げられます。
私のプロジェクトは、「データベースプロキシーが過負荷でリクエストをリジェクトしたときに自動的にロードバランスするようにする」というものでした。詳しくは企業機密があり、記事の主題からも逸れるため説明しません。
タイムライン
まずは、タイムラインから紹介しますが、これはあくまでも自分のケースです。サマーインターンは基本的に１２週間です。
1週目：Onboarding Trainings & Tasks
2~3週目：Design Docと呼ばれるプロジェクトデザインを書く
4~9週目：開発
10~11週目：End-to-End テスト
12週目：プレゼンテーション、Off boarding
1週目：Onboarding Trainings & Tasks
トレーニングの内容は、
内部ツールの使い方
Code reviewの時に何をみるか
Gitベストプラクティス
Testベストプラクティス
アイデアの作り方
GTD(Getting things done) という有名なタスク管理法
などなど、Team specificではなく、ソフトスキルに関するものも多くインターン後にも役立つような印象です。
動画の教材で進めていくのですが、AmazonのPrincipal EngineerやDistinct Engineerといった、トップエンジニアからのアドバイスを直接聞けるのはとても貴重な経験でした。特にテストに関する考えは衝撃的でした。
「Code reviewerはコードが正しくバグなく作動するかは、コードを見てもわからない。その代わりに、テストを見て、正しいテストが正しくパスしていることを確認することによってコードの正当性を判断する。」
自分が過去にインターンした企業では、Unit testすら書かない会社もあったのでこれは eye openingでした。もちろん開発速度が求められるスタートアップでは、これは机上の空論になるかもしれませんが、Unit test以外にもIntegration testやLoad test, Canary test, Chaos testなど多種多様なテストフェイズが存在することを鑑みると、一番初歩段階であるUnit testくらいは最低でも書いてもいいのかなと思いました。
内部ツールの使い方では、実際に簡単な割り算をするプログラムを書いてCode Review(CR)を提出し、会社の人にApproveされるまでを体験したり、そのプログラムのCI/CDパイプラインを作ってみたりなど、かなり実践的な内容に作り込まれた教材でした。
2~3週目：Design Docと呼ばれるプロジェクトデザインを書く
Amazonインターンの他社インターンと大きく異なる点は、インターンがデザインを担当するという点だと思います。自分がいままで経験した他社では、インターンは他のエンジニアと同じようにチームのタスクやチケットに取り組む形でした。Amazonでは、チームの大規模なプロジェクトの中の一つのモジュールを、チームとは独立のプロジェクトとして取り組むという形でした（サイドプロジェクトと言えど、のちにプロダクトブランチにマージされるのでインパクトは残せます)。
Design Docを書くというのは、Amazonの正社員もみんな行っていることです。開発段階に入る第一段階でDesign Docを書くと言うのはAmazonでは基本とされていました。また、友人のAmazonで正社員として2年間勤務しているエンジニアの方は、「2年間働いていて、まだDesign Docを書く機会はなかった」と言っていたので、インターンの段階その機会があるというのは価値のあることだと思いました。
チームメイトの一人がメンターとして、インターンシップを通して面倒を見てくれます。メンターはプロジェクトで次何をすればいいかなど、ガイダンスをくれます。また、デザインのフィードバックなどテクニカルなサポートもしてくれます。
Design Docは結構Low levelな実装のデザインまで書きました。例えば、どのようなクラスを作りどのようなプロパティをもたせるかや、Sequence diagramを書いて自分の書いたコードがどのように既存のコードと連携するかなどまで書く必要がありました。なので、インターン２週目にしてチームの大規模プロダクトのソースコードをある程度理解する必要がありました。これは正直簡単ではなく、大学の授業などで培ったDesign Patternなどの知識が自分にはたまたまあったので理解することはできました。ココらへんの知識がそこまでない状態だと、コードを抽象的に理解するのが難しくなるので、今までの自分の経験に感謝しました。
１週間かけてメンターとDesign Docを書きあえげた後、チーム全体にDesign Doc Reviewというミーティングでプレゼンテーションします。ここではチームメイトからデザインのフィードバックをもらったり、別のソリューションの提案などをされます。Amazonのインターン生に見られるものの一つとして「Backboneを持っているか」や「Coachableであるか」などがあります。なので、チームメイトの提案をどの程度受け入れ、どの程度自分のアイデアをDefendするかというのが大切になってきます。私は自分のデザインをチームメイトにチャレンジされましたが、データを用いてその場でDefendすることができ、これは後のマネージャーとの最終面談のときなどにも良かった点の一つとしてあげてもらえました。
Design Doc Reviewのあと、チームのシニアエンジニアと1on1でデザインのフィードバックを貰い、最終的なデザインを固めました。
また、この段階でデザインをタスクレベルまで細分化し、それぞれにかかる時間の推定までします。開発段階では、これを用いてスケジュール通りに進んでいるかなどを逐一メンターやマネージャーと確認しながら進んでいきます。そして、スケジュールから遅れているのであれば、その都度プロダクトのRequirementを変更したりする必要があります。
4~9週目：開発
ここから先は
¥ 500
この記事が気に入ったらチップで応援してみませんか？