現在、エンジニアとしての再就職かもしくは、PMとしての再就職の両面から活動しています。
そしてエンジニアとしての入社試験を受ける場合、避けて通ることができないのが、コーディング試験 です。
GAFA系の会社のエンジニアの入社試験では、5回面接試験があるとしたら4回はコーディング試験(あるいは超テクニカルな質問のみの面接)であると考えるべきだということです![]()
ただ、そのコーディング試験では、プログラミング言語の文法とか演算子の記号などを正確に覚えている必要は全くなく、完全にロジックを考える思考能力と、それを正確にトレースする能力、計算量などを見極める能力が試されるので、「ソフトウェアエンジニアとしての根本的な能力」を問われることになるそうです![]()
さて、そのコーディング試験で出題される問題は、アルゴリズム構築力を問われるものが多く、例えば「その文字列が、右から読んでも左から読んでも同じになる類のものかどうかを調べるプログラムをかけ」みたいなものがほとんどのようで、
正直なところ、本当の現場で使うようなことはまずないようなトリッキーなものが多いそうです![]()
したがって、いくら今までソフトウェア開発エンジニアとしてやってきた熟練のエンジニアであっても、「コーディング試験専用のトレーニング」をしていないとまず厳しいそうです。
おそらくこの類の試験に強いのは、大学や大学院で散々アカデミックなプログラムを書いてきたり、「プログラミングコンテスト」みたいなところでいかに早くコードを書くかを競い合ったりしてきたような、
頭の柔らかい新卒系の若い子たちだろうと思われます![]()

しかし我々だって、無数のプログラムを書いてあらゆる問題を解決してきました![]()
さらに私事で言えば、高校生の時にソフトウェアエンジニアの国家資格である「第二種情報処理技術者試験」に合格し、20代で「第一種情報処理技術者試験」に合格(今では名前が変わっていますが)して、はたまた「月刊合格情報処理」という月刊誌にアルゴリズム問題関連の連載記事を書いたりもしていました。本来は得意分野です。
・・負けられません![]()
では、どうやって対策するか、ということですが、
現在では有難いことに、そういうコーディング試験で出題されやすい問題が大量に掲載されているサイトがあります。例えばLeetCode。
https://leetcode.com

・・先日話を伺った、アメリカでエンジニアとしての転職経験のある方から、「こういったサイトでとりあえず100問くらい解けば、慣れると思います」とおっしゃっていただき、
とりあえず現在15問くらいやりました。。(まだまだですね
)
でも半年も就活期間があれば、軽く100問以上解けますね![]()
レイオフにしてもらったおかげで、こういうことをじっくりやる時間が取れます![]()
さて、そのコーディング試験に関してもう一つ、重要な事実を知りました![]()
それは、「単にその場で出題されたコードを無言でテキパキと完ぺきに書いても、まず受からない」という衝撃的な事実でした![]()
どういうことかと言いますと、
この試験のもう一つの大きな狙いは、「果たしてこの人と一緒に、同じチームでソフトウェア開発を協業しながらやっていけるかどうか」を見極めるところにあるのだそうで、
つまり、現場ではコミュニケーションをしながら開発を進めていく必要があると思いますが、
出題後、すぐにコーディングに取り掛かるようなワンマンタイプは大抵敬遠されてしまうそうで、
そうではなく、
「引数にマイナスの値はあるのですか?」とか「エラーハンドリングはどこまでやりますか?」といったように、まずクリアではない部分をきっちりと話し合ってクリアにした上で取り掛かるべきであり、
また、無言でガンガンコードを書いていくのではなく、
「私の方針はこうです。まず引数がNullであるか判定して・・」みたいに説明しながら、今何をやろうとしてそのコードを書いているのかを相手に分かりやすく伝える技術が求められ、
そして、書き終えても「はいできました。どうでしょうか?」ではなく、
テストデータをいくつか用意して(テストデータについても面接官と話し合いながら、出題意図とすり合わせつつ用意すべき)、トレースして見せるステップが不可欠だということでした。
(そういえば6年前にコーディング試験を受けた時には、私はトレースする前に「はい、できました」と言ってしまいましたが、その時の試験官は「では、こういうデータがきたらどうなりますか?」などと質問してくださり、トレースせざるをえない状態にしてくれました。今にして思えばあれは 親切な試験官だったのですね
)
また、現状の計算量(例えば一重ループならO(n)、二重ループならO(nの2乗)のような)を示して、パフォーマンスを上げるにはどういう変更が必要かなどを説明することが期待されているということで、
結局、ただコードが書ければいいということではなく、必要なコミュニケーションがきっちりできて、現場では効果的に協業して理想的なソリューションに近づけていくエンジニアが、採用されやすいのだということでした。
なるほど、確かに大規模ソフトウェア開発をドライブできるエンジニアかどうか見極めるには、必要不可欠な試験ですね
。
とりあえず、まずは100問解いて、少しでもエンジニアリングスキルの底上げをしながら並行してJob searchを続けたいと思います。