サカモト氏

外資ITのソフトウェアエンジニアで、テック企業面接対策プラットフォームInterviewCatの運営

X上でエンジニアがテック企業トップに行くためのキャリア論と面接対策情報を発信

Xアカウント
 InterviewCat

はじめに

『選考に思うように通過しない…』
『技術力以外に何か対策が必要なんだろうか…』
『そもそも何を評価されているんだろう…』

こういった悩みを持っている学生、転職中のエンジニアは多いのではないでしょうか。

選考で自分のどんな点が見られているのか分からないと不安ですよね。「そもそも何を対策すればいいか分からず、とりあえずコーディングテスト対策をしている」という声もGEEK OFFER宛に相談をいただいた中にはありました。

そこで、エンジニア就職の選考で評価されるポイントや対策、よくある失敗について、テック企業への就職を目指すエンジニアを支援するサカモト@エンジニアキャリア論（以下サカモト氏）に詳しく解説してもらいます。

サカモト氏は外資系企業に勤務している現役ソフトウェアエンジニアであり、Xでエンジニアキャリア情報を発信しています。

この記事では、社内で評価されるエンジニアの特徴から逆算的に、面接で重要視されるポイントを整理します。
その上で書類や面接など具体的な選考ステップ別の対策方法について深掘っていくことでエンジニア就活の選考対策を整理します。

本記事を通じて、エンジニア就職でやるべきことを学び、あなたの就職活動を成功させましょう！

―― サカモトさん、本日はよろしくお願いします！

サカモト：

よろしくお願いします。

社内で活躍するエンジニアとは？

―― 早速ですが、社内で活躍するエンジニアとはどのような方なのでしょうか？

サカモト：

そうですね、まずジュニアとシニアで評価ポイントは変わってきます。

ジュニアは目の前のタスクを完遂できるか？が評価ポイントだと思います。チームで戦力になっているか？と言い換えることもできそうです。

「与えられたタスクを期限内に完了できる」「エンジニアとしてディスカッションができるか」「チームの中で戦力になっているか」などはより具体的な評価ポイントになります。

一方でシニアでは、より全体を考慮した振る舞いができているか？が評価ポイントだと思います。目の前のタスクをこなすことのみならず、「チームとしての生産性を意識できているか？」のように自身の影響範囲が広がっていく点がジュニアとの違いでしょうか。

例えば私の勤めている企業だと毎期ごとにチームとしての目標を決めています。この目標に向き合えて達成できているのか？ジュニアなどチームメンバーを巻き込んでゴールに向けて取り組むことができる人が重要です。

面接で評価されるポイントとは？

―― 面接で評価されるポイントはどのようなものでしょうか？

サカモト：

一言でいうと、『エンジニアとしてのディスカッションができるか？』が一番大事な評価ポイントかと思います。

選考では、これを測るために様々な角度から質問をして総合的に判断をします。

例えばコーディング面接だと、競技プログラミングのような問題が題材として扱われることが多いです。

あの手の面接は、問題を通してどういうエンジニアとしてのディスカッションができるのか？を評価しています。

もちろん「コードとしての綺麗さ」も重要ですが、それ自体は全体の評価項目の一つでしかないと思います。

―― もう少し具体的な部分も教えていただけますか？

サカモト：

どちらを取るべきかはそのときの状況によって変わりますが、制約などの前提となる情報をもとに技術的な議論と意思決定ができることが大事になりますね。

エンジニアとして何らかの課題を解決するときのやり方は一つではありません。そのため、現状の制約などを加味した上で、納得感のある提案を届けることが非常に重要になってきます。

実務では日頃からロングタームを取るか、ショートタームを取るか？という決断をよく迫られます。時にはロングタームを犠牲にしてショートタームを取るべき時もあります。

技術的な制約やその他現実的に起こり得る状況を踏まえた上で、納得性のある選択を提案できることが重要です。

逆に、最適なアルゴリズムを知っている、というのはエンジニアとして議論できるという大枠の一要素でしかないです。

―― 面接と実際の仕事との差分ってどのようなものですか？

「調べることができるか」と「問題の特性」が違うかと思います。

業務においてコーディング面接で扱うような問題を改めて解決することはほぼないです。

―― なるほど。実際に選考ではどのようにそれが測られているのでしょうか？

サカモト：

レジュメやコーディングテスト、面接など様々な形式で総合的に評価されます。

例えば、面接では技術的な理解や興味、過去のプロジェクト経験などについて質問しながら総合的に「どの程度エンジニアとして議論できるか？」を評価します。

選考別の詳細

ここまで、エンジニアとして評価される人の特徴、選考での評価ポイントについてお話いただきました。

―― 各選考の詳細について、まずはレジュメ選考（書類選考）からお願いします。

サカモト：

レジュメ選考は「候補者として正しいのか？」を見るものです。

特に新卒エンジニアの点で言うと、「エンジニアとしての経験を本当に持っているのか？」「情報工学や研究などを通じて、エンジニアに通ずる経験があるか」などを見ています。

なので、レジュメ自体にもその経験は当然盛り込まれているべきだと思いますね。

レジュメのポイントとしては、技術スタックなどは書いたほうがいいですし、何のためにそのタスクを取り込んだのか、どんなことに役立ったのかについて結果を書けるといいですよね。パフォーマンスの数字も含めて記述できるといいです。

記載する内容がインターンではなく研究であったとしても、自身の取り組みが何の目的で、その結果がどうなったのか？を意識する点は全く同じです。

少し補足すると、研究はソロプレイであることが多いので、研究だけやっていた場合チームワークに関する情報をレジュメで補足できるといいと思います。研究室の中でチームワークを発揮した内容などを記載すると、一人で働かない人、協調性を持って解決に取り組める人材であることをアピールできて良いと思います。

―― レジュメ選考におけるよくある失敗はありますか？

よくある失敗として、「相手のことを十分考えられていない」という点はありそうです。

『自分が書きたいことだけを書く』というやり方にしてしまうと、相手がどう思うか？相手がどんな人材を探しているのか？という視点が抜け落ちてしまいます。

就活でいい成績を修めるという点にあえてフォーカスすると、自分に視点を向けて「〇〇という結果を残したから認めてください」という姿勢よりは柔軟に振る舞った方がより多くのチャンスを獲得できるのではないでしょうか。

実際私も応募するポジションによって記載する内容を変えて出すようにしています。

コーディング選考

―― オンラインのコーディング選考についてもお願いします

サカモト：

この形式の選考はAtCoderのような競技プログラミングや、LeetCodeのようなアルゴリズムとデータ構造系の問題が出題されていて、特に出やすい問題の傾向は確実にあると思います。

こちらもレジュメと同様で「候補者として適切か」を見極める足切り的な位置付けの要素が強いです。

対策としては、LeetCodeやAtCoderなどを活用して練習の数をこなしていくと良いです。

例えば、ArrayやHashmapなどベーシックなものを理解してコードに落とせるようになると良いと思います。

―― いわゆる競プロ的な問題が出されるのはなぜでしょうか？

サカモト：

あくまで個人的なイメージですが候補者のドメイン知識に関わらず評価を実施するためだと思います。

コーディング面接で扱う問題がドメインに偏っていると全ての候補者を平等に評価できなくなってしまいますよね。

しかし、アルゴリズムとデータ構造に関する内容であれば大半の人が触れている内容なので面接の題材として扱われているのかなと思います。

競プロのような問題は、バックエンドエンジニア、組み込みエンジニア、機械学習エンジニアなどポジションに関係なく押さえている内容ですし。

技術面接

―― まずそもそもですが、面接対策の重要性について教えてください

サカモト：

面接と実務の大きな違いとして、面接は時間中にググれない（検索できない）というものがあります。一方で、普段の仕事では何か解決策を探す時にググるのは当たり前です。

私も仕事でコードレビューをする時も当たり前にググってこの書き方がベストプラクティスなのか？という点を調べますし、他人の書いているコードを参考にすることもあります。

しかし、面接はそのように調べた内容をもとに面接官と議論することはできませんよね。

なので、事前に徹底的に準備することが重要になります。準備できる面接だとしたら徹底的に準備したほうがいいです。

面接では、自分の経験に対して質問がされるのは明白なので、「長期インターンでタスクを任された時に〇〇という設計にした理由は何か？」など事前に考察を徹底的にやっておくべきだと思います。

―― ありがとうございます。次は「コーディングテスト」についてお願いします

コーディングテストは、ホワイトボードを活用して実装を説明したり、電話上で何らかの実装問題について面接官とディスカッションする形式の面接です。

コーディングテスト評価ポイントでよく言われているのは、「Problem Solving」「Coding」「Communication」「Testing」の4つです。

1. Problem Solving

問題を理解して「こういうアプローチがあるよ」や「こういうトレードオフがあるよ」という点を適切に説明して議論できるかという点が

2. Coding

コードの見やすさや再利用性、変数名や関数の正しい付け方など

3. Communication

普段の同僚と働いているかのようなコミュニケーションが取れるか？が重要です。

Problem Solvingと近いですが、こちらは面接官の質問やフォローアップに対して不確かなことがあれば相手に聞けるかなど、問題を解決するために面接官と適切にコミュニケーションができるのかという点を評価します。

よくあるケースだと、問題を解いた後にフォローアップで「〇〇というケースになったらどう解きますか？」というのはあります。

例えば、

「今まではデータが全てメモリに載っていたが、使う端末の性能が低くメモリにデータが載らない可能性があります。この場合どうしますか？」

のような問題があります。

4. Testing

実装し終わった後に面接官からいくつかのテストケースを使ってあなたがコーディングしたコードをテストしてください、というような指示がされることがあります。

「こういうケースになった時にどうしますか？」という類のフォローアップ問題を出してどのように解決に向かうかを見ることで評価をしています。

また、いくつかのテストケースを準備して、書いたコードが正しく動作しているかを確認するフェーズがあります。

その中で「コードの一つ一つの意味を説明できるか」などが重要なポイントになっています。

この時、問題の解法をコピペで覚えていた場合など、ふわっとしか説明できないと評価が落ちてしまいます。

例えば、二分木の探索で in-order と pre-orderで、どのように動いているのか説明できないと面接官からは「書いているコードの意味を分かっていない」と判断されてしまいます。

―― コーディングテストというと、どうしても競プロのイメージが強くて論理的に正しい挙動をするコードを書けるか？を目的にしがちですが実際はそうではなさそうですね。

サカモト：

一個のひらめきで解けるかどうかが決まってしまう類の問題はコーディング試験としては最悪です。それ知ってたら解けるけど解けなかったらそれで終わりというゼロイチの問題ですね。

そうではなく、多くの解法が存在して、なおかつフォローアップもできるような問題が良いです。

コーディングテストは競プロではないので、解けるか解けないかのゼロイチの評価ではないです。

解いていく中でどこまでできているか？を見たり、何を知っていて何を知らないか？を通じて候補者の素養を測っています。

一つの解法しか知らない人よりも、複数の解き方を知っているほうが評価されます。

この手の選考を全く受けたことがない人は「解けなかったらどうしよう」となるかもしれませんが、この選考ステップまで進んだ方は全く手が出ないような問題が出ることはほとんどないと思います。

びっくりするくらい解けない問題は中々出ないだろうという想定でいいです。

そもそも面接官はこの人は募集しているポジションにマッチしているのか？というシグナルを見つけたいと思っているので、その観点からもゼロイチで評価できる問題は出にくいと考えています。

複数の解法を知っていたり、各解法の理解度が重要なので、LeetCodeには複数回答が載っていますし、コンピュータサイエンスの基礎的なバックグラウンドの理解をしておくと汎用性が効いてくると思います。

―― どのように対策するといいでしょうか？

サカモト：

まずはアルゴリズムの基礎を押さえることですよね。

クイックソートなど少し応用的な解法を押さえるというより、DFS、BFS、Hashmapや連結リスト、ツリーなどもっと基本的なデータ構造やアルゴリズムの理解と実装ができるようになりましょう。

また、コーディング面接で使用するプログラミング言語の特性についても十分理解しておきたいです。

もし面接でJavaを使用する場合、ArrayListはどのように実装されているのか？などは当然押さえておくようにしましょう。

その上でLeetCodeで問題を解く練習を重ねていくのがいいです。

できれば、同じエンジニア就活を進めている仲間をみつけて2人1組でpeer review（相互レビュー）をしながら進めることをお勧めします。

―― これはどういった理由でしょうか？

サカモト：

私が運営するCoding Interview Catを書いた方で、東大の情報理工から外資ITのエンジニア職に新卒で内定した方が実践していて非常に理にかなっているなと思ったのでここでも共有しています。

同じ志を持つ方が近くにいるのであればやらない手はないと思います。

模擬面接のやり方自体はネットで探せばやり方自体はあるのでそれを真似しながら実践していくといいです。

やはりフィードバックは非常に大切だと思っていて、基本的に自分がどう見られているのかは自分自身では判断できません。かくいう私自身もそうです。

どんな小さなことであれフィードバックをもらえること自体に価値があります。

―― 慣れていない人同士だとしてもフィードバックを得られる環境を作ることが大事ということですね。

サカモト：

もちろん熟練した人からフィードバックをもらえる方がよりいいですが、全員がその環境に入れるとは限らないです。

相手が経験が少ない方であったとしても「ここが分からなかった」とか「ここの説明が足りなかったね」などのフィードバックをもらうことで自分の説明がどう相手に伝わっているのかを知ること自体大きな価値があります。

―― 一問一答の質問も出ると思います。これはどう対策していくといいですか？

基本的に足切りとしての認識だと思います。

もう一つは、候補者はどの領域に詳しいのかに当たりをつける目的です。

例えば、「メモリとCPUって何でしょうか？」のようにエンジニアとして最低限知っておくべき項目をわかっているか？を確かめつつ、候補者がどの領域に詳しいのかを探索しているイメージです。

可能なら全て答えられた方が良いですが、知らない場合は正直に「知らない」と答えて良いと思います。

例えば、クイックソートのように特定のアルゴリズムを詳しく知らなかったとしても、即アウトになるわけではないです。

先ほども言ったように、ゼロかイチかの判断ではなく複数の角度から質問する中で、エンジニアとしてのディスカッションができる人材か？を見極めていくので仮に一つ答えられなかったから全てダメになることはないと思います。

―― そういう点だと、答えられない時にどういう振る舞いをするのか？も重要そうに感じました

おっしゃる通りだと思います。

あくまで例ですが、クイックソートの説明ができなかった時に「分かりません」だけでなく「マージソートについてなら説明できます」のように答えてもいいと思いますね。

その場合、面接官としては「この方はクイックソートではなくマージソートについては詳しいのか」という印象になります。

面接はテストのようなイメージを持ちがちですが、テストではないのでそこを意識したほうがいいです。

―― 技術プロジェクトの経験に関する質問についても伺いたいです。

サカモト：

過去の開発経験や技術プロジェクトについて、なぜその実装をしたのか？技術を使ったのか？などの質問を通じて候補者を評価していく形式です。

この質問を通じて面接官は、候補者が技術的にどういう意思決定をするのか？を見たいと思っています。

例えばJavaを使って開発した場合、「なぜこのサービスでJavaを採用したのですか？」という質問がされることがあります。

学生などでまだ経験が少ない場合は、「なぜこの言語を使ったのですか」という質問に対して「当時使える技術がそれだけだった」というケースが特に多いと思います。

「当時使える技術がそれだけだった」ということ自体は何の問題もないです。現在は新しい言語を習得していたり、新しいフレームワークの特性を知っていたりすると思うので、「今だったらこうします」という回答ができれば100点だと思いますね。

逆に、学部一年生のタイミングで技術プロジェクトをやった時に各言語の特性を理解して技術選定をやりきっていたらそれはそれで怖いですよね（笑）

なので、その時はこれだけしか知識がなかった中で現在はここまでできるようになりましたという成長幅を見せられるとすごくいいと思います。

―― やっている内容を適切な形で相手に届ける練習が重要になりそうですね。

サカモト：

そうですね、私も言葉ではわかっていてもその通りに動けないことが多々あるのでそこは訓練、練習をしておいた方がいいと思いますね。

もし可能であれば模擬面接やpeer reviewをすることで周りからフィードバックを受ける環境も同時に作れると良いです。

ただし、自分の経験を話すという意味では、まだお互いのやっていることを深く知らない人のほうが効果が高いと思います。

実際の面接でも前提知識がない相手に自分のことを話すので、それに近い環境を意識した方が良いインサイトが得られると思います。

―― そのような環境を作れるかが重要になりそうですね。

サカモト：

そこはGEEK OFFERさんのプラットフォームが解決してくれることを期待しています。

―― 次はシステムデザイン面接についてもお願いします。

サカモト：

システムデザイン面接は、広範囲の知識の総合格闘技のようなものだと思っています。

正解がないというのがシステムデザイン面接のミソで、色んな解法を知っておいた方がいいです。

多くの解法が存在する中で、それぞれのプロコン（利点欠点）を見極めて提案できることが非常に重要です。

ただし、上記が重要だとは言いつつも、自分が知っている範囲の中で回答するべきです。

どこかで聞きかじった内容をそのまま話してしまうのは危険ですね。それは深く突っ込まれた時に回答できなくなってしまうので、ワードを知っているだけのものは、言わない方がましです。

又聞きした内容を話すよりは、「深く知らないので、普段から使い慣れているこちらの技術を使用します」と回答する方が良いです。

「正しい解答をする」ということにフォーカスしてしまうと、そのような形になってしまいます。

実際の仕事でも、自身使ったことないものを、チームに使ってみましょうと提案しても基本的に通用しないと思います。

―― ジュニアレベルの場合、特に意識することはありますか？

サカモト：

新卒だからこうすべき、という対策方法は変わらないと思います。選考通過のベースラインがジュニアとシニアで異なるぐらいでしょうか。シニアと比較して知識や経験の幅と深さが足りなくとも通過しうるといったイメージです。

おわりに

―― 今のうちから経験しておくといいことはありますか？

サカモト：

教科書的な勉強以外で、インターンなどを活用してWeb APIを作る経験を持っているといいです。

やはり実務と勉強を結びつけないと上手く話せないと思うので、何らかのAPIとその裏のデータベースが連動しているシステムの開発に関われると良いと思います。

私が運営している Interview Catでもそれに関するコンテンツの開発を進めているところです。

サカモトさんはエンジニアの就職・転職に関する対策サービス InteviewCat 運営されていますよね。どのようなものか教えていただけますか？

サカモト：

テック企業のエンジニアとしての就職を目指す方向けのサービス「InterviewCat」を運営しています。

新卒向けだと、コーディング面接対策の教材の Coding InterviewCat や、外資系やメガベンチャーなどに内定した方が、どのように内定を取ったのかを見れる InsideStory InterviewCat を提供しています。

こういったサービスを通じてエンジニアのキャリアを充実するための取り組みを今後も続けていく予定です。

取材、執筆、編集：小路光（GEEK OFFER運営）

【外資系現役エンジニア直伝】エンジニア就活でテック企業が求める評価ポイントと差がつく対策法を解説