どうも、管理人のコンです。
ちょっと前に転職活動で、「生成AIを使ってもOK」というルールのコーディングテストを受けたことがあります。しかも面接官がずっと隣で画面を見ているライブコーディング形式。
受けたのは2025年4月ごろですが、AI可のコーディングテストはこれから増えていくと思うので、体験と反省をまとめておきます。
これから同じような形式を受ける人の、ほんの少しのヒントになれば良い感じにハッピーです。
前提:どんなテストだったか
まず条件を整理するとこんな感じでした。
- お題:在庫管理アプリを作る
- 形式:テストの問題用紙のように小問が複数あり、「この機能を作ってください」と順番に指示される
- 言語:Ruby(正直、あまり慣れていない言語でした)
- 時間:1時間
- 生成AIの使用はOK
- 面接官がずっとそばにいて、画面を見ている
- 事前対策:なんもしていない(本当に何も…)
Rubyについては、以前Ruby Silverを受験したことはあったものの、業務でガッツリ書いているわけではない状態でした。
想定外その1:お題は簡単なのに、コードが汚くなる
「在庫管理アプリ」と聞くと、正直「それなら作れるでしょ」と思いますよね。私も思いました。
ところが実際にやってみると、普段の業務では考えないような仕様を理解することに脳のリソースがどんどん持っていかれるんです。「在庫って個数管理だけでいいんだっけ?」「この小問の条件、さっきの機能と矛盾しない?」と考えているうちに、コードを整える余裕がなくなっていく。
結果、普段なら書かないような、少し汚いコードになりました。お題の難易度とコードの品質は別物なんだな、というのが気づきでした。脳の作業メモリの奪い合いにが悪く影響したなという感覚です。
体感をイメージにするとこんな配分でした。整理に回すリソースが半分以下になれば、そりゃ汚くなりますよね…。
想定外その2:「問題用紙ドリブン開発」で設計が崩れた
小問が順番に並んでいると、当然のように上から順に解きたくなります。私はこれを勝手に「問題用紙ドリブン開発」と呼んでいるのですが、これが良くなかった。
小問1を解き、小問2で機能を継ぎ足し、小問3でまた継ぎ足し……とやっていくと、全体の設計をしないまま増築を繰り返した温泉旅館のようなコードが出来上がります。あとから「最初にデータ構造をちゃんと決めておけば」と思っても、残り時間が許してくれません。
いま思えば、最初の数分で小問を全部読み、全体像を掴んでから書き始めるべきでした。テクニックとしては当たり前なのに、人生を賭けた面接・コーディングテストになると忘れたなって感じでした。
想定外その3:面接官が隣にいると、下手に出過ぎる
ライブコーディング形式で一番効いてきたのは、技術ではなくメンタルでした。面接の緊張というか、萎縮というか、必要以上に下手に出過ぎた自覚があります。
あとから振り返ると、コーディングテストは「書いたコード」だけでなく、面接官とのコミュニケーションも見られていると感じました。わからないことを確認する、方針を口に出して説明する、というやりとりも評価の一部だったように思います。黙って画面と戦うより、「先にデータ構造を決めてから小問に入りますね」と一言宣言するだけでも、印象は違ったはずです。
生成AIはどう使えたか:正直、「辞書」止まりでした
ここが一番書きたかった部分です。せっかくAI使用OKのテストだったのに、当時の私はAIを「わからない文法を聞く辞書」としてしか使えませんでした。慣れないRubyの書き方を聞いて、出てきたコードを参考に自分で書く。使い方としてはそれだけです。
2025年4月当時は、「設計を人間が考えて、実装をAIに任せる」という開発スタイルがまだ自分の中になかったです。それから1年ちょっと経って、いまはClaude CodeのようなAIエージェントと毎日一緒に開発していますが、当時の自分に会えるなら伝えたいです。
AI可のコーディングテストで問われているのは、コードを書く速さではなく、AIに的確な指示を出すための設計力と言語化力だと。
いまの自分が同じテストを受けるなら、最初に小問を全部読んで設計を面接官に説明し、実装の大部分はAIに任せて、自分はレビューと軌道修正に回ると思います。1年でここまで戦い方が変わるのは、ちょっと面白いです。
意外と守れたこと:変数の命名
逆に、緊張していても崩れなかったものもあります。変数名・関数名の付け方です。普段からチーム開発でレビューを受けているおかげで、適当な名前を付けることには抵抗があり、配列は複数形にするなどの一貫性は最後まで保てていたと思います。
付け焼き刃が効かない部分こそ、普段の開発習慣がそのまま出る。ここは面接官にも伝わりやすいポイントな気がします。
個人的な反省と、次に受けるならやること
- 最初に小問を全部読む。「問題用紙ドリブン開発」をしない。設計に最初の数分を使う
- 方針を口に出す。「まずデータ構造を決めます」と宣言するだけでコミュニケーションの評価が変わる(はず)
- 下手に出過ぎない。面接官は敵ではなく、当日いちばん近くにいる仕事相手だと思って対等に話す
- AIの役割分担を決めておく。辞書ではなく実装パートナーとして使う練習を、普段の開発でしておく
まとめ
結果は、無事に通過していました。手応えとしては反省だらけだったので、正直ホッとしたのを覚えています(笑)
コーディングテストというと「アルゴリズムを解けるか」のイメージが強いですが、実際に受けてみると、仕様理解・設計・コミュニケーション・AIとの付き合い方という、普段の開発でやっていることがそのまま問われる場でした。初めてコーディング面接を受けたときの体験記もあわせて読んでいただくと、変化がわかって面白いかもしれません。
ここまで読んでいただきありがとうございました。この経験が誰かの参考になれば幸いです。
