この記事は？
Androidエンジニア2年目の高卒がメガベンから内定をもらうまでに行った対策を記したものです。
なるべく再現性高く書いたつもりです！
筆者のスペック(内定当時)
年齢：24歳
学歴：地方の工業高校卒(偏差値50未満の高校かつ成績中位だったので頭はよくない)
IT業界経験：新卒からずっと
Androidエンジニア：2年目
資格：
・基本情報技術者試験
・応用情報技術者試験
・情報処理安全確保支援士
・Google Cloud Digital Leader
・Google Cloud Associate Cloud Engineer
・Google Cloud Professional Security Engineer
・TOEIC LR 795点
実績：
・iOSの個人開発アプリリリース経験あり
・LeetCode: Solved 88問(Easy63問, Medium25問)、後述します
・技術負債の返済経験あり
・技術選定経験(アーキテクチャ・ライブラリ)あり
・プロジェクトリーダー経験あり
・上流〜リリース後運用(いわゆるSDLC)一通りの機能開発経験
・ストアアプリのレビューの向上に貢献した経験あり
・メンバーのメンタリングなどソフトスキル面
想定読者
- 実務経験が弱い
- CS学位未取得など学術的バックグラウンドが弱い
本記事の読者は上記のような人がメガベンを目指しているという前提で書いていきます。
対策(精神・マインド面)
メタ認知を徹底する
抽象的ですが非常に大切なことなので先頭に。
まず、メガベンに受かるまではそれなりに長い道のりとなります。
ですから、自分自身を振り返って下記を整理してください。
- どういう時に勉強のモチベーションが上がるか
- モチベーションの維持はどうやればいいか
- 落ち込んだりイライラした時の対処法はなにか
これらは非常に大事でメガベン転職は長い期間を要します。
ですから、モチベーションが低下した際にどうしたら建て直せるか？を言語化することが大切です。
そのために過去の体験などを振り返って自分の特性を見抜くことが大切です。AIを使ってメタ認知のお手伝いをしてもらうのも良いでしょう。
「強制される努力」は効果が薄いため避ける
常にJD(求人票)から逆算して積む経験を選ぶ
行きたい企業の求人を探しましょう。
JDは 「企業が欲しい人材を明記してくれている有り難い資料」 です。
例えば、Androidエンジニアだと下記のような記載があります。
- UI/UX設計・開発（独自ビューやインタラクションの対応など）の知識や経験
- アーキテクチャ設計・ライブラリ選定経験
- Kotlin/Jetpack Composeの実務経験
積みたい経験が把握できたら「率先してこういった経験を積みたい」と上長に依頼、または現在の案件に良い効果をもたらせるのであれば主体的に提案して行動するのも良いでしょう。それ自体が良い経験になります。
ここで、実績作りに翻弄されてチームに迷惑をかけるのはNGです。チームとして動いてますからプロジェクトとしての利益は損なってはいけません。
可能であれば両方発生するように動きたいところです。(それが難しいわけですが...！)
このような経験は一朝一夕で積めるものではありません。
ですから早めに行動することが大切です。
- 必要な経験をJDから逆算して長期的視野で考える
- 実績作りのための自己中心的な行動は避ける(プロジェクトの利益が最優先)
強みを言語化する
メタ認知と関連します。
転職活動における自分の強みは何か？を理解し活かす戦略を取りましょう。
私の場合は下記です。
- 年齢(若さ)
- 学習能力
- プロダクト思考
この中で軸は年齢でした。
私の場合、学歴は不利ですがその分実務経験は多いです。
しかし、仮に10年も働けば重要度は経験年数 < 経験内容になるでしょう。
ですから、高卒としての強みを持っている時期に動く必要がありました。
そして、若い場合同様に重視されるのが「ポテンシャル(伸び代や可能性)」です。
ですから、レジュメや面接では高度な技術力の話は一切せず
- なぜこのような実績を出せたか
- どう考えて行動したか
など思考回路やプロセスにフォーカスしたお話をしました。
結果、内定をいただいた企業からは「ポテンシャルが高かったため採用した」とフィードバックをいただけました。
逆に技術力メインの企業は不採用でした。
開発で使用していたUIフレームワークがレガシー気味だったためですね。(Jetpack Compose未経験)
ただし、普段触っている技術はしっかり理解を深めていました！(後述します)
- 強みを言語化すること
- 強みを活かした戦略(レジュメ作成や面接対策)を行うこと
志望企業で求められるマインドは常に意識する
JDには必要な経験だけでなくマインド面についても書かれてることが多いです。
- ユーザーへの価値提供のために行動できる方
- テスタビリティを意識した設計をされる方
- 問題解決のためにステークホルダーを巻き込んで行動できる方
この辺りでしょうか。
多くの方は面接対策時に初めて、求められるマインドを回答にどうにか盛り込むのではないでしょうか？
これは決して最悪手だとは思いませんが面接官は全員非常に鋭い方々ですから表面的な回答はボロが出ます。
様々な観点(技術力・コミュニケーション力・PJ管理など)から一貫した価値観を持っているか暗に確認してきます。
そのため、様々なJDを見て求められやすいマインドの特徴をリスト化して日頃の仕事に対する姿勢にどう組み込むかを意識して実際に行動してみましょう。
私の場合は、「ユーザーファーストなマインド」を取り入れるために日頃から下記のようなことを意識してました。
- このUIはユーザーにとって良いUXを提供しているか？
- この画面や機能はユーザーに対して何を目的として作っているのか？
- ユーザーは何を求めているのかXやストアで確認してみよう
これを繰り返すと本当にマインドが定着するため一貫性を持った回答ができます。
マインド面は表面的な理解に留めず実際に仕事で行動してみること
転職準備は８0点で動く
転職、大変ですから時間かけて胸張って活動できるタイミングまで自己研鑽してから行きたいですよね。
私も同じでしたが実はそんなタイミングってほとんど来ないんです...。
正確にいうと、努力するたびに100点の位置がどんどん遠くなってしまいます。
- 個人開発の実績だけでも作っておこう！
- GitHubにコード上げてるとはいえリリースはしないと！
- リリースしたけどユーザーいないと訴求力弱いかも
- これだけではCS知識が偏っちゃってると思われるから基本情報だけでも取ろうかな
完璧主義の人ほどこの心情の変化に共感できるのではないでしょうか。
これは避けたいところです。
転職というのは実力も大事ですが運も非常に絡んでいます。
- 志望企業が求人を出しているか
- 自分に適したレベル(ジュニア〜シニア)の求人が出されているか
- 自分より優秀な候補者がいるか
レジュメや実績は自身でコントロールできますが、運は当然無理です。
ですから、運の要素が味方してくれている限り80点でどんどん応募しましょう。
その代わり、求人が出ていないときは徹底的に日頃から実績作りに勤しみましょう。
- 求人が出ている時はどんどん応募
- 求人が出ていない時は徹底的に実績作り
- 100点の転職準備は存在しない
対策(技術面)
コーディング試験
多くのメガベン企業ではコーディング試験が行われます。
大きく分けると種類は3つ。
- データ構造とアルゴリズム
- ポジション特有の実装問題(モバイルアプリ開発やWebアプリ開発など)
- L●NEヤフーのような複雑な要求仕様の実装
データ構造とアルゴリズム
おそらくこれが最も出題されやすいです。
私の場合は「LeetCode's Interview Crash Course Data Structures and Algorithms」+ AIを活用して苦手問題をLeetCodeから選んでもらいました。
当該コース、内容は全て英語ですが翻訳を使えば問題ありません。
私の場合は自力で読みましたが、TOEIC795点の基礎力+本サイトで頻繁に使用される単語(consequtive, subsequenceなど)さえ覚えればある程度理解できました。
- Arrays and strings(⭐️⭐️⭐️)
- Two pointers
- Sliding window(尺取法かな？)
- Prefix sum(累積和) ←これは不要かも
- HashMap and HashSet(⭐️⭐️⭐️)
- 重複検出
- 出現回数カウント
- アナグラム判定
- Linked list(⭐️⭐️)
- Floyd's cycle detection(フロイドの循環検出法)
- 中央ノードの位置計算
- Linked list全体の反転
- Linked list一部の反転
- Stacks and queues(⭐️⭐️)
- 括弧のマッチング
- 逆ポーランド記法の解釈
- 隣接重複削除
- Trees and Graphs(⭐️)
- DFS(深さ優先探索)
- BFS(幅優先探索)
- 走査(inorder, preorder, postorder)
- Dynamic Programming(⭐️)
- 階段問題
- コイン交換問題
- Kadane's algorithm
- その他(⭐️)
- XOR
- Boyer-Moore majority vote
この辺りは対策をしました。(星の数が多い分野ほど徹底的に)
余談：問題を解くフレームワーク(自己流)
本セクションは下記理由から飛ばしてもOKです。
- 抽象度が高いため分かりにくい
- これが正解ではない
- 趣旨から逸れるので軽めに書いてる
私は普段下記の思考フレームワークに沿って問題を解いていました。
- 部分問題は何か？
- 漸化式(簡単に言えば状態変化を式にしたもの)
- 例外は何か？(forの先頭や最後だけ特殊処理が欲しい、とか)
それぞれ説明します。
1. 部分問題は何か？
LeetCodeに登場する多くの問題ではfor文を使うことになります。
これは、「全体問題(問題の答え)を解くために部分問題を連続して解いている」 と言い換えることができます。
「全体問題という抽象」 を解決するために 「部分問題という具体」 を利用しているということですね。
そのため、まず部分問題が何か？を考える必要があるということですね。
フィボナッチ数列が良い例です。
「1, 1, 2, 3, 5, 8, 13...」と続きますが例えば4番目の"3"という数字を求めるとします。これを全体問題と定義します。
この場合、部分問題はn番目時点(n=1~3)の数字を求めることになります。何故なら4番目の数字は2番目及び3番目の数字を求めることで分かるからです。
部分問題(n番目時点の数字の計算)を繰り返すことで全体問題(4番目の数字)が求まります。
2. 漸化式(簡単に言えば状態変化を式にしたもの)
部分問題から次の部分問題へ遷移するときの状態変化です。
この辺りは数学で習った概念と同じです。
フィボナッチ数列で表現すれば、F(n) = F(n-1) + F(n-2)ですね。
F(n)：現在の部分問題の答え
F(n-1)：１つ前の部分問題の答え
F(n-2)：2つ前の部分問題の答え
何の情報を使えば現在の部分問題が求められるか？を言語化しましょう。
3. 例外は何か？(forの先頭や最後だけ特殊処理が欲しい、とか)
これも大切です。
特にコーディング試験本番では「隠しテストケース」と呼ばれている、極端に値が大きいケースや意識しないと見逃すケースが用意されています。
フィボナッチ数列でも漸化式に当てはめられるnは必ず2以上となっていますね。
処理を書き終わった後、必ず下記の観点でコードを読み返しましょう
- どういう値が入力されたらこのコードはクラッシュする可能性があるか？
- 問題の制約の最小値、最大値でも成立するか？(特に実行時間計算量及び空間計算量)
ポジション特有の実装問題
これは対策していません。
一度受けたことがありますが、TODOアプリ開発のようなシンプルなものでした。
複雑な要求仕様の実装
この類の問題は受けた経験がありません。
練習問題が公開されています。
読んで設計が一切思い浮かばなければ解いた方が良いです。
個人的にはDDDを意識した設計(特に"区切られた文脈"辺りの概念かな？)の知識があると解きやすいです。
こちらは、複雑なビジネス要求をどう区切り簡潔にして堅牢に設計するか？をみられているのでしょう。
技術面接
ポジション柄、具体例はAndroid知識に偏ります。
普段業務で触っている技術やアーキテクチャについて再度深掘りをしました。
何気なく曖昧になっている技術は特に理解を深めるようにしました。
- 汎用的なお話
- Kotlinのメリット・デメリット
- アーキテクチャのメリット・デメリット(MVVM、Clean Architecture辺り)
- Kotlinのお話
- data class vs classの違い
- スコープ関数(apply, also, let, run, with)の使い分け
- sealed interface vs data classの使い分けと特徴
- DIのメリット・デメリット
- Androidのお話
- メモリリークの原因、対策、検知方法
- ANRとは何か、どう防ぐか
- ライフサイクル
- Observable系
- Observerとは
- Observableとは
- Subscriberとは
- メリット・デメリット
この辺りでしょうか、他にもあった気がしますが忘れてしまいました。
また、AIを使った模擬技術面接も非常に有効でした。
- 曖昧にしがちな部分を再度学習
- AIと模擬技術面接
まとめ
様々書きましたが結局のところ企業がチェックしてくる観点は抽象的に分解すると下記の二つです。
- 一緒に働きたいか(ソフトスキル)
- 応募ポジションに見合った最低限のスキルがあるか(ハードスキル)
基本的な対策はこの2点を根として行っていけば問題ありません。
また、途中でも書きましたが転職活動は結局のところ運ゲーです。
- 人材需要
- 面接官との相性
- 他候補者の存在
自身では見えない要素ばかりです。
ですから、「不合格=自分が弱い」ではないことは意識してください。