インターンは通ったのに本選考で落ちる？エンジニア選考の評価軸の変化を解説

• インターン選考と本選考で、企業が見ているものは違う

• ES：コミュニケーション能力や思考体力があるか

• 技術面接：技術選定の理由を語れるか（思考の過程が分かるか）

• 現場社員面接：自社のチームに貢献できるか

• 最終面接：価値観や人柄が企業と一致するか

• 完璧主義でタイミングを逃さないように注意しよう

• まとめ

インターン選考と本選考で、企業が見ているものは違う

インターンの選考と本選考で、企業が確認したい内容は異なります。まずは、この違いを押さえておきましょう。

インターンの選考で確認しているのは技術力

インターンの段階では、企業もそこまで強い志望動機や興味を学生に求めていません。

もちろん熱意のある学生にアプローチしたいと考えてはいますが、まずは自社の採用要件に合うスキルをもった学生と幅広く出会いたいと考えています。

そのため、自社開発企業のインターン選考は、技術力に関するスクリーニングの性格が強くなります。5日間のワークを問題なく行えるか、企業が求める最低限の技術的な土台があるかといった確認が中心です。

コーディングテストやポートフォリオの提出が課されるのは、この技術力を測るためです。裏を返せば、ここを通過した時点で、技術力の確認はいったん終わっていると考えられます。

オープンカンパニーは、さらに基準が緩やかになる

1〜3daysのプログラムになると、選考の性格はさらに変わります。企業側の目的が、就業体験よりも自社を知ってもらうことに寄るためです。

自社に興味のある学生を集めることが主な狙いになるため、技術に触れた経験があり、ITやその企業に興味を持っていると伝わる程度で通過するケースも見られます。この段階の通過は、技術力を高く評価された証拠とは限らないといえます。

インターン選考の通過をそのまま実力の証明として受け取っていると、本選考との落差が大きくなります。まずは、自分が通ったのがどの性格のプログラムだったのかを切り分けておきたいところです。

本選考で確認しているのは人柄やキャリア観

本選考で企業が見ているのは、「その人を企業に迎え入れられるか」という点です。インターンの選考よりも「なぜ弊社なのか」「どのようなキャリアを目指したいのか」を深く問われることになります。企業はこの人と長く働けるか、成長やキャリアの方向が組織と合っているかを確かめているのです。

そのため、インターン選考では通用した技術力の提示が、本選考では材料として足りなくなる場面が出てきます。

評価軸は4段階で移動する

選考が進むにつれて、企業が確かめたいことは次のように移っていきます。

• ・①Can：何ができるか

• ・②Why：なぜその技術や設計を選んだか

• ・③How with others：誰とどう作るか

• ・④Will：これからどこへ行きたいか

Canの確認は書類選考やコーディングテスト、技術面接など選考の前半でおおむね終わります。そこから先は、Why、How with others、Willの順に比重が移っていく流れです。

本記事の読み方

以降は、選考の順番に沿って評価される点を並べています。ESから最終面接まで、それぞれのフェーズで何を見られるのかを先に把握しておくと、いまから準備する優先順位を決めやすくなります。

これから自分が通るフェーズを思い浮かべながら、そこで問われるものを1つずつ確認していきましょう。

ES：コミュニケーション能力や思考体力があるか

最初の関門であるESで見られているのは、研究や制作物の高度さそのものではありません。専門外の相手に伝わる形へ置き換えられるかという点です。

学会要旨をそのまま貼ろうとしていないか

研究概要の欄に、専門用語を並べた要旨をそのまま転記してしまうパターンがあります。面接でも、技術の成果だけを細かく話して相手を置き去りにする状態が起こりやすくなります。

本選考のESを書き始める前に、この点を確認しておきたいところです。書き上げてから直すよりも、書き出す前に方針を決めておくほうが早く済みます。

インターン選考では、ここが問われないことも多い

インターンの応募では、研究概要が軽く扱われるケースもあります。また、そもそも研究室の配属前であることがほとんどで、問われないことも多いです。だからこそ、この観点が抜けたまま本選考へ進んでしまいます。

これは準備が足りなかったという話ではなく、確認される内容が入れ替わったと捉えると整理しやすくなります。

企業が見ているのは、専門知識の高度さではない

プロダクト開発は、エンジニアだけで完結しません。プロダクトマネージャーやデザイナー、マーケター、カスタマーサポートなどといった職種と、同じチームで動く場面が日常的にあります。

そうした環境では、技術的な内容を必要に応じて専門外のメンバーにも伝わる言葉へ置き換え、分かりやすく説明できるかが問われます。仕様の相談や優先順位の決定に技術的な判断が絡むため、伝わらないままだと開発そのものが滞ってしまうからです。

あわせて、正解のない問いに対してどう仮説を立て、検証し、修正したのかという思考の過程も見られています。システム開発は正解がない問に回答を出していくことの連続であるため、研究の経験を通じて粘り強く取り組めるかを見極める狙いがあります。結果の報告で終わってしまうと、その過程が伝わりません。研究の成果が優れていても、評価が伸びにくいのはこのためです。

書き直すときの3つの観点

研究概要や制作物の説明を整えるときは、以下の観点で見直してみましょう。

• ・専門外の人に読んでもらい、伝わるかどうかを確かめる

• ・「何が優れているか」ではなく「何を解こうとして、どう詰まって、どう抜けたか」を書く

• ・専門用語を使う場合は、直後に1行で言い換えを添える

3つ目については、用語を避けるという意味ではありません。使ったうえで補足を置くと、専門性と伝達力の両方を示せます。

技術面接：技術選定の理由を語れるか（思考の過程が分かるか）

技術面接で評価が分かれるのは、使った技術の種類ではなく、その技術を選んだ理由を説明できるかどうかです。

「Pythonを使いました」で止まっていないか

使用した技術の列挙や、競技プログラミングのレートの提示、ハッカソン参加の事実を伝えて終わってしまうパターンがあります。「なぜその技術を選んだのですか」と聞かれた瞬間に、答えが出てこない状態です。

技術スタックの説明をすること自体は間違っていません。ただし、それは前提の共有にあたる部分で、評価が始まるのはその先からだと考えられます。

インターン選考では、Whatの提示で通過できる

インターン選考のコーディングテストや技術チェックは、書けるかどうかを測るものです。何を使ったかというWhatの情報だけで、下限のスクリーニングは通過できてしまいます。

そのため、技術選定の理由を言葉にする機会が、本選考まで訪れないまま進んでしまうことがあります。

本選考で問われるのは、意思決定のプロセス

評価が伸びにくいのは、「流行っているから」「チュートリアルがそうだったから」という受け身の選択です。実務で求められるのは、要件に対してトレードオフをどう考慮したかという判断の跡だからです。

手段が目的化していて、プロダクトの要件との接続を語れないと、技術そのものへの興味が先に立っている人だと受け取られる可能性があります。その場合、決まった仕様を実装する役割は任せられても、設計から関わる候補としては見られにくくなるでしょう。

自社開発企業では、何をどう作るかの議論にエンジニアが入る場面が多くあります。だからこそ、判断のプロセスを再現できるかが確かめられます。

語れる状態にするための3つの問い

自分の制作物1つひとつについて、以下に答えられるかを確認してみましょう。

• ・なぜその言語やライブラリを選んだのか。ほかに候補は何があったか

• ・その選択で何を捨てたか。捨てたもののデメリットはどう埋めたか

• ・別の要件だったら、選択は変わっていたか

3つ目に答えられると、意思決定が再現可能なものとして伝わります。ひとつの結果を説明できる状態から、判断の基準を持っている状態へ、伝わり方が変わるためです。

「なんとなく選んだ」場合はどうするか

当時の選択に強い理由がなかった場合は、正直に振り返るほうが安全です。「当時は考慮しきれていなかったが、今は○○を知っているのでこうする」など、今考えるならどう選ぶかを語れれば、問題になりにくいでしょう。

取り繕った理由を後付けすると、深掘りの段階で崩れます。実際に手を動かした人であれば、いまの視点から語り直すほうが説得力が出ます。

現場社員面接：自社のチームに貢献できるか

現場の社員が出てくる面接では、技術力の高さと並んで、同じチームで働く姿を想像できるかが見られています。

語る内容が「自分の成果」に偏っていないか

個人開発やハッカソンでの自分の成果物、自身の技術的な成長ばかりを語ってしまうパターンがあります。結果として、一人で完結する働き方を好む人という印象になりかねません。

実力があること自体は伝わるため、面接の場では手応えを感じやすい点が、このつまずきの厄介なところです。

インターン選考では、個人の実績で足りた

インターン選考の段階では、チーム開発の経験を問われないことも少なくありません。個人開発の実績だけで通過できるため、この観点が抜けたまま本選考へ進んでしまいます。

チームで動いた経験があっても、それを語る場面が選考のなかになかった場合も同じです。

企業は「同じチームで働けそうか」を見ている

開発は組織で進めるものなので、企業は「この人を自分たちのチームに迎え入れられるか」という観点で見ています。技術力の高さと同じくらい、チーム全体の生産性に寄与できるかが問われる部分です。

具体的に見られているのは、他人が読みやすいコードを書く配慮やコミュニケーション能力です。LinterやFormatterの設定、Gitのコミット粒度、READMEの整備などに、その姿勢が表れます。

こうした配慮は、技術力とは別の軸で評価されます。自分が書きやすいコードと、他人が読みやすいコードは一致しないためです。

エピソードの棚卸しをする

チーム開発での課題解決や合意形成、ペアプログラミングやレビューを通じた協調のエピソードがあると、一緒に働く姿を想像してもらいやすくなります。以下の観点で、自分の経験を洗い出してみましょう。

• ・レビューで指摘を受けて、設計を変えた経験

• ・自分より詳しくないメンバーに、技術的な判断を説明した経験

• ・チーム内で意見が割れたときに、どう合意を作ったか

• ・後から入る人のために、ドキュメントや環境構築を整えた経験

個人開発しか経験がない場合も、語れる材料はあります。READMEやコミットログの整え方を、他人が読む前提で作った証拠として説明する方法です。

最終面接：価値観や人柄が企業と一致するか

最終面接では、技術力の確認はすでに終わっています。ここで見られているのは、お互いの価値観がすり合うかどうかです。

「御社の技術力が素晴らしいから」で止まっていないか

企業へのファン目線や教育体制、モダンな環境を求める姿勢で話してしまうパターンがあります。志望度の高さを伝えようとして、かえって受け身に見えてしまう構造です。

内容そのものは事実かもしれません。ただし、最終面接で企業が確かめたいこととは、少しずれています。

最終面接は、技術チェックの場ではない

1次や2次の段階で、何ができるかの確認は済んでいます。CTOや経営層が出てくる最終面接は、技術の深さを測る場ではなく、価値観をすり合わせる場です。

そのため、技術の話を続けても、この面接では評価が積み上がりにくくなります。同じ内容で前の面接を通過してきている分、切り替えに気づきにくい点が難しいところです。

「成長させてもらう前提」に見えてしまう構造

主語が「御社」ばかりになると、自分が将来どうなりたいのか、そのためになぜこの環境が必要なのかという部分が見えません。結果として、環境を享受しに来た人、あるいは育ててもらう前提で来た人だと受け取られる可能性があります。

最終面接で確かめられているのは、同じ方向を見られるかどうかです。学ぶ意欲そのものは評価されますが、それだけでは判断の材料になりにくいといえます。

言い方の違いを比べてみましょう。「御社は技術力が高く、成長環境も整っているので志望しました」という形は、企業を評価する立場からの発言です。一方、「3年後に設計から任される状態になりたいので、若手が設計に関わる機会がある環境を選びたい」という形であれば、自分の目的から逆算した説明になります。

Willは壮大でなくていい

Willと聞くと構えてしまいますが、世界を変えたいという規模の話である必要はありません。3～5年後にどういうエンジニアになっていたいか、そのために何を経験したいか、こういう理由で御社でなくては経験できないという粒度で十分です。

まだ固まっていない場合の扱いも押さえておきましょう。無理に固めた答えを用意するよりも、今何に興味があって、何を確かめたいのかを話すほうが誠実に伝わります。

完璧主義でタイミングを逃さないように注意しよう

最後に、どのフェーズでも共通して注意しておきたい観点を扱います。

「整理してから出そう」で出遅れがち

コードが汚いから整理してから、ポートフォリオが完成してからと、エントリーを後ろ倒しにするパターンがあります。技術力が高い人ほど、自分の制作物に対する基準が厳しくなるため、この状態に入りやすくなります。

準備そのものは真面目な行動です。ただし、選考には時期の要素があるため、採用枠が埋まってしまうなど意図せず不利な状況になってしまうことがあります。

企業は、なぜその設計にしているのかというプロセスを評価します。見られているのは完成度ではなく判断の跡なので、未完成でも判断の根拠を語れる状態であればエントリーする価値があるといえます。

今エントリーできる状態かを判断する基準

エントリーするかどうかを迷ったときは、以下の3点で判断してみましょう。

• ・READMEに、何を作ったのかと、なぜその設計にしたのかが書いてある

• ・動く状態でデプロイされているか、動かし方が書いてある

• ・未完成の部分について、なぜ未完成なのかを説明できる

この3つを満たしていれば、エントリーして問題のないラインだと考えられます。3つ目は特に重要で、未完成であることを認識して言葉にできていれば、それ自体が判断力の証明として働きます。

まとめ

自社開発企業のエンジニア選考では、フェーズが進むにつれて評価軸が変わっていきます。何ができるかの確認はサマーインターンの選考など最初の関門でおおむね終わり、そこから先は技術選定の理由、チームでの動き方、エンジニアとしてのキャリア観という順に比重が移っていきます。

インターン選考を通過した実力があっても本選考でつまずくのは、この切り替わりが外から見えにくいためです。技術力を上げる方向に努力を向けても、解決しない場合があります。

まだ本選考を受けていない今の段階であれば、十分に準備ができます。研究概要を専門外の人に読んでもらう、制作物の技術選定の理由を書き出す、チーム開発のエピソードを洗い出すなど、できることから着手しましょう。

ITエンジニアを目指す新卒学生向け就活エージェントならレバテックルーキー

レバテックルーキーは、レバテックが運営するITエンジニア専門の就活エージェントです。多数のITエンジニアのキャリア支援経験のあるアドバイザーが、あなたのスキルと希望に合わせた企業の紹介から、人事目線での面接対策など、就職までを一貫してサポートします。ES添削、面接対策、ポートフォリオ作成サポートなども実施していますので、まずは一度カウンセリングにお越しください。

就活アドバイザーに相談してみる