Meta QAエンジニア面接体験記:自動化・パフォーマンス・品質保証の完全評価
QA経験2年でMetaのQAエンジニアに面接。1次:テスト理論+Python+API自動化、2次:パフォーマンステスト+CI/CD、3次:品質体系+プロジェクト深掘り。実際の問題と準備のアドバイス付き。
背景紹介
まず私の状況から:テスト開発2年の経験、以前は中規模インターネット企業でQAエンジニアとして勤務、主にAPI自動化とパフォーマンステストを担当していました。正直なところ、QAエンジニアという職種は多くの人にとって「スクリプトを書いてボタンをクリックするだけ」のイメージがありますが、楽天のQA面接で私の認識は完全に変わりました——彼らが求めているのはツールの使用者ではなく、品質保証体系のレベルから考えられるエンジニアなのです。面接プロセス全体を通じて、自分が一皮むけた気がしましたが、確かに多くを学びました。
応募したのは楽天のQAエンジニアポジションで、勤務地は東京。紹介経由で応募し、書類選考から1次面接まで約5日かかりました。全体のプロセスは1次+2次+3次面接で、それぞれ約1週間の間隔があり、最終的にオファーをいただきました。以下、各ラウンドを詳しく振り返ります。
面接プロセスの振り返り
1次面接:テスト理論+Python+API自動化
1次面接は親しみやすい女性の面接官でした。自己紹介の後、すぐに技術的な質問に入りました。彼女は「1次面接は主に基礎を確認します、緊張しないでください」と言いましたが、質問は決して基礎的ではありませんでした。
最初の質問は「シフトレフトestingとシフトライトテストについての理解を説明してください」。これは準備していました。シフトレフトestingは開発段階からテストに参加すること、例えばコードレビューやユニットテスト;シフトライトはリリース後の監視とフィードバックです。以前のプロジェクトの例を挙げました——CIパイプラインに静的コード分析とユニットテストカバレッジのゲートを追加したことが、シフトレフトestingの実践です。面接官は頷き、「シフトライトはどうしていますか?」と掘り下げました。本番監視アラートを統合し、問題があれば自動的に回帰テストをトリガーすると答えました。彼女は満足そうでした。
次にPython関連の質問。「PythonのGILとは何ですか?マルチスレッドにどう影響しますか?」まずまず答えられました。GILはグローバルインタプリタロックで、同時に1つのスレッドしかPythonバイトコードを実行できないため、CPU集約型タスクではマルチスレッドの加速効果がなく、マルチプロセスが必要です。面接官は「自動化フレームワークではマルチスレッドとマルチプロセスのどちらを使っていますか?」と掘り下げました。APIテストはI/O集約型ですが、GILの影響を避けるためマルチプロセスを選択したと答えました。
API自動化の部分が最も深く掘り下げられました。「API自動化フレームワークはどう設計していますか?データ駆動はどう実装していますか?」フレームワーク構造を詳しく説明しました——pytest + requests + allureを使用し、テストデータはYAMLファイルに格納し、fixtureでパラメータ化を実現。面接官は「APIがログイン状態に依存する場合、どう処理しますか?」と聞きました。conftest.pyにログインfixtureをカプセル化し、tokenの取得と更新を一元管理していると答えました。彼女はさらに「tokenが期限切れになったらどうしますか?」と聞き、tokenの有効期限検出を実装し、期限切れなら自動更新すると答えました。
最後にコーディング問題:Pythonでアサーション、ログ、レポートをサポートするシンプルなAPIテストフレームワークを実装してください。約20分で基本バージョンを書きました。面接官は見て「構造は悪くないですが、並行処理をサポートするにはどう変更しますか?」と聞きました。pytest-xdistで分散実行するか、asyncioで非同期リクエストにすると答え、「アプローチは問題ありません」と言われました。
1次面接終了後、面接官は「基礎はしっかりしています、2次面接の通知をお待ちください」と言いました。全体的に1次面接は基礎重視ですが、非常に詳細に聞かれ、表面的な質問ではありませんでした。
2次面接:パフォーマンステスト+CI/CD
2次面接の面接官はテックリードで、いきなりプロジェクトの質問から始まり、非常に深く掘り下げられました。「レジュメにパフォーマンステストとありますが、具体的にどんなパフォーマンステストをしましたか」と聞かれました。
以前のECサイトのセール時の負荷テストプロジェクトを説明しました。JMeterで10万同時ユーザーをシミュレートし、主に注文APIのTPSとレスポンスタイムをテストしました。面接官は「10万同時接続をどうシミュレートしましたか?負荷テストマシンは何台ですか?」と聞きました。5台の負荷テストマシンで分散テストを行い、各マシン2万同時接続だと答えました。彼は「JMeterの分散テストはどう設定しましたか?コントローラーとエージェントはどう通信しますか?」と掘り下げました。これはうまく答えられず、大まかな設定フローしか説明できず、詳細を覚えていませんでした。面接官は「これは後で確認してください」と言いました。
続いて「パフォーマンステストの指標は何ですか?システムが基準を満たしているかどうどう判断しますか?」主にTPS、レスポンスタイム(P50/P90/P99)、エラー率、CPU/メモリ使用率を見ていると答えました。合格基準はTPSが期待値の80%以上、P99レスポンスタイムが500ms以下、エラー率が0.1%未満です。面接官は「TPSは基準を満たしているがP99が非常に高い場合、どうトラブルシューティングしますか?」と聞きました。まずスローリクエストがないか確認し、次にGC問題やデータベースのスロークエリを調査すると答えました。彼は「アプローチは良いですが、ロングテールリクエストやホットデータの問題も考慮できます」と言いました。
CI/CDのセクションでは実践的な質問が多くありました。「CI/CDパイプラインはどう設計していますか?テストはどの段階で関与しますか?」パイプラインはコードコミット→ユニットテスト→コードスキャン→API自動化→ステージングデプロイ→パフォーマンステスト→手動確認→本番リリースだと答えました。テストは各段階で関与し、API自動化は必須のゲートです。面接官は「API自動化テストケースが1000件あって、実行に2時間かかる場合、どう最適化しますか?」と聞きました。優先度別にグループ化し、コアケースは毎回実行、非コアケースは1日1回;または分散実行で加速すると答えました。彼はさらに「CIツールは何を使っていますか?」と聞き、Jenkinsと答えると、「Jenkins Pipelineはどう書きますか?共有ライブラリは使ったことがありますか?」と続きました。簡単なPipelineの例を書き、共有ライブラリについては知っているが深くは使っていないと正直に答えました。
2次面接の最後にオープンクエスチョン:「ゼロから品質保証体系を構築するとしたら、どうしますか?」4つのレベルから構築すると答えました——コードレベル(コードスキャン、ユニットテスト)、APIレベル(API自動化、コントラクトテスト)、システムレベル(パフォーマンステスト、カオスエンジニアリング)、プロセスレベル(CI/CDゲート、品質ゲート)。面接官は「思考が明確ですが、実装時にはビジネスチームとの調整に注意が必要です——すべてのゲートを押し通せるわけではありません」と言いました。この言葉は深く印象に残りました。
2次面接後、JMeter分散テストの質問にうまく答えられなかったので不安でしたが、翌日に3次面接の通知が来ました。
3次面接:品質体系+プロジェクト深掘り
3次面接は部門責任者でした。雰囲気はリラックスしていましたが、質問はより深いものでした。まずQAエンジニアという職種に対する理解を聞かれ、「QAはテストケースを書くだけでなく、体系レベルから製品品質を保障することが重要で、ツール開発、プロセス最適化、品質指標も含みます」と答えました。彼は頷き、プロジェクトの深掘りを始めました。
「最も挑戦的だった品質保証プロジェクトは何ですか?」以前のフルチェーン負荷テストプロジェクトを説明しました——ゲートウェイからサービス、データベースまで、フルチェーンで負荷テストを行い、データベース接続プールの設定が不適切な問題を発見し、修正後TPSが40%向上しました。彼は「フルチェーンテストのデータはどう構築しましたか?本番に影響しないようにどう保証しましたか?」と掘り下げました。シャドウデータベース+データマスキングのアプローチを使用し、トラフィックマーカーでテストと本番を区別すると答えました。彼はさらに「シャドウデータベースのデータをどう本番と同期しますか?」と聞き、binlog同期を使用すると答えると、「そのアプローチは良いですが、binlog遅延の問題に注意してください」と言われました。
その後、意外な質問がありました:「QAエンジニアのキャリアの天井はどこにあると思いますか?」天井は自分をどう位置づけるかによる——ただスクリプトを書くだけなら、天井は確かに高くない;しかし品質保証体系の観点から考え、チーム全体の品質文化を推進できれば、天井は非常に高いと答えました。面接官は「良い答えですね、考えていることが分かります」と言いました。
最後はHR面接で、主に給与期望と入社日時について話しました。HRは楽天のQAチームが拡大しており、品質保証体系の構築を重視していると言い、加入により自信を持てました。
実際の面接問題
1次面接の問題
1. シフトレフトestingとシフトライトテストの理解
2. PythonのGILとは?マルチスレッドへの影響は?
3. API自動化フレームワークの設計アプローチ
4. データ駆動テストの実装方法は?
5. APIのログイン状態依存の処理方法は?token期限切れの対応は?
6. PythonでシンプルなAPIテストフレームワークを実装
7. pytestのfixtureとparametrizeの使い方は?
8. HTTPとHTTPSの違いは?
9. Cookie、Session、Tokenの違いは?
10. よく使うアサーション方法は?
2次面接の問題
1. パフォーマンステストのやり方は?指標は?
2. JMeter分散テストの設定方法は?
3. TPSは良好だがP99が高い場合のトラブルシューティングは?
4. CI/CDパイプラインの設計アプローチ
5. API自動化テストケースが多すぎる場合の最適化は?
6. Jenkins Pipelineの書き方は?
7. テストにおけるDockerの応用
8. ゼロから品質保証体系を構築する方法は?
9. カオスエンジニアリングを知っていますか?実践方法は?
10. コードスキャンツールは何を使いましたか?SonarQubeの設定は?
3次面接の問題
1. 最も挑戦的だった品質保証プロジェクト
2. フルチェーン負荷テストのやり方は?データ構築は?
3. シャドウデータベースソリューションの設計は?
4. QAエンジニアのキャリアの天井
5. 品質文化に対する理解
6. 品質ゲートの実装をどう推進するか?
7. 自動化テストのROIをどう測定するか?
8. QAエンジニアに最も重要な能力は何か?
9. 開発チームとの衝突をどう処理するか?
10. 今後3年のキャリアプラン
心得とアドバイス
第一に、QA面接はテスト理論だけでなく、エンジニアリング能力も評価します。楽天のQA面接で聞かれたPython、CI/CD、パフォーマンステストはすべて実践的なエンジニアリング問題であり、いくつかのテストケース設計方法を暗記するだけでは通りません。普段からコードを多く書き、フレームワーク開発に参加することをお勧めします。
第二に、API自動化はQAのコアスキルであり、深い理解が必要です。フレームワーク設計からデータ駆動、並行実行まで、各段階を明確に説明できる必要があります。面接官は「requestsを使えるか」ではなく「フレームワークを設計できるか」を聞いています。
第三に、パフォーマンステストには実戦経験が必要です。JMeterの使い方を知っているだけでは不十分で、パフォーマンスボトルネックの分析方法、負荷テスト計画の設計、分散テストの問題処理も知る必要があります。自分でプロジェクトを構築して練習することをお勧めします。
第四に、体系的な思考を持ってください。面接官は、個々のテストケースを書くだけでなく、体系レベルから品質保証を考えられるかを重視します。品質保証体系、品質ゲート、品質指標などの概念を理解することをお勧めします。
第五に、プロジェクト経験は深掘りできるようにしてください。面接官は非常に詳細なレベルまで掘り下げます。プロジェクト経験が捏造されたものや、ただ参加しただけの場合、すぐに露見します。1-2のコアプロジェクトを選び、すべての詳細を理解することをお勧めします。
FAQ
Q1:楽天のQA面接はプログラミング能力の要件が高いですか?
基準は低くありません。1次面接にコーディング問題があり、2次面接でもコードを書かされます。少なくともPythonを習得し、独立して自動化フレームワークを書けることをお勧めします。コードを書けないQAエンジニアは楽天では生き残れません。
Q2:パフォーマンステストの経験がない場合は?
自分でプロジェクトを構築して練習できます。DockerでWebサービスを立ち上げ、JMeterやLocustで負荷テストを行い、ボトルネックを分析します。重要なのは「負荷テスト→分析→最適化」の完全なループを持つことであり、ただスクリプトを実行するだけではありません。
Q3:QAとSDEの面接の違いは何ですか?
QA面接は品質保証の思考とエンジニアリング実践能力に重点を置き、SDE面接はアルゴリズムとシステム設計に重点を置きます。しかし楽天のQA面接もコーディングをテストするので、テスト理論だけでは不十分です。
Q4:JMeterとLocust、どちらを選ぶべきですか?
シナリオによります。JMeterは機能が豊富で複雑な負荷テストに適しています;LocustはPythonでスクリプトを書き、より柔軟でAPI負荷テストに適しています。面接では両方に言及されるので、少なくとも1つをマスターすることをお勧めします。
Q5:楽天のQAエンジニアのキャリア発展はどうですか?
楽天のQAチームは品質保証体系の構築を重視しており、伝統的な「クリックしてテスト」ではありません。キャリアパスには、品質保証エキスパート、テストツール開発、効率プラットフォーム開発などがあります。天井は技術の深さと体系的な思考にかかっています。