ライブコーディング面接はコーディング能力ではなくストレスを測っているにすぎない
(hadid.dev)- ライブコーディング面接は、実際にはエンジニアのコーディング能力よりもストレス反応をより強く測定している
- 科学研究によれば、リアルタイムで見られている環境では認知能力の低下と大きな成績変動が現れる
- 特に女性応募者の場合、公開環境では全員が不合格だった一方、個人環境では全員が合格する現象も確認された
- 多くの企業ではストレス適応力を求めていないにもかかわらず、コーディングテストでそれを誤って評価しているという問題がある
- 模擬テスト、段階的エクスポージャー、そして補助的な栄養素などがストレス緩和に役立つ可能性がある
ライブコーディング面接に関する個人的な経験
- ライブコーディング面接を楽しめる人もいるが、筆者はそうではない
- 筆者は Toptal の選考過程でライブコーディングテストには失敗したが、一人で改めて解いたときにはすぐに解決できた
- この経験を通じて、リアルタイムで監視される状況ではストレスによって本来の能力を発揮できないことを認識するようになった
ストレスに反応する脳
- 高リスク・時間的プレッシャーのかかる状況では、脳の扁桃体が活性化し、コルチゾール値が上昇する
- その結果、複雑な推論や記憶を担う前頭前野の機能が損なわれる
- ワーキングメモリは新しい問題を解く能力を判断する最も重要な指標であり、これはリアルタイムのコーディング状況で大きく低下する
- 軽いパフォーマンス不安がある場合でも、明晰に考えることはほとんど不可能になる
- 集中しづらくなり、複数の手順を同時に覚えておけず、自分が「普段よりずっとできない人」になったように感じる
決定的な研究結果
- Microsoft の研究チームによる論文では、同じコーディング問題を個人環境と公開環境でそれぞれ解かせて比較した
- 個人環境では一人の部屋で実施し、公開環境では監督者の前で思考過程を話しながら解かせた
- その結果、見られている環境では成績が半分に低下し、特に成績のばらつきが大きくなることが示された
- 男性応募者とは異なり、公開環境ではすべての女性応募者が不合格となり、個人環境では全員が合格した
- ライブコーディング環境は、有能なエンジニアを落とす科学的に実証された排除フィルターとして機能している
ストレス下の成果という現実
- ライブコーディングは結局、ストレス状況でのパフォーマンスを見るための代理指標にすぎない
- 実際にストレス環境でうまく働ける人を求める企業もあるが、大半の企業はそれを応募時に明確にしていない
- ほとんどの業務がリアルタイムのストレスをそれほど伴わないことを考えると、ライブコーディングでミスをしたという理由だけで優秀なエンジニアを落とすことは不適切である
- ライブコーディングはコーディング能力よりもストレスホルモンの値を測っていると見るのが妥当だ
ストレス緩和のための方法
- ライブコーディングは業界で一般的であるため、ストレス適応トレーニングが必要になる
- 実際に近い環境での反復練習（Pramp、Interviewing.io、LeetCode の模擬テストなど）によって、脳をストレスに慣れさせることができる
- タイマーを設定したり、自分を録画したり、友人に見てもらったりして、段階的にプレッシャーを高める練習が効果的だ
- 追加的に、L-tyrosine（ストレス下での神経伝達物質を補う）や L-theanine（リラックスと集中力の改善）といった栄養素の摂取も試してみる価値がある
- 実際の面接の前には、自分に合った方法かどうかを必ず模擬練習で確認しておくべきだ
結論
- ライブコーディングが苦手だからといって、それはエンジニアとしての資質不足ではなく、人間に一般的な特性である
1件のコメント
Hacker Newsの意見
自分のケースを一般化するつもりはないが、個人的な経験を共有したい。今は成功した自営業のindie developerだ。苦しい時期にもindie開発を諦めなかった大きな理由の一つは、事実上雇われない状態になっていたからだ。私は技術業界で年齢差別を強く受ける中年で、コンピュータサイエンスの学位もなく、ライブコーディング面接では頭が真っ白になる症状がある。すべてのストレスが同じではないことを指摘したい。消防士は燃えている建物に飛び込むが、見知らぬ人の前で発表することにはむしろ恐怖を感じる。私も日常業務のストレスには強いが、他人が肩越しに監視しながら自分の金銭的な将来を決めるという状況は、消化できないほどの負担だ。面接が終わるとコーディング問題はたいてい解ける。面接官は私を詐欺師だと思うかもしれないが、20年近いキャリアが反証だ。多くの人は"false negative"をまるでランダムのように扱っているようだが、私のように常に落とされる人もいる。私はオーディション形式の面接ではいつも落ちるし、舞台の上で演技するタイプではない。
他人に見られている状況で審査されるという点には本当に共感する。私は60代前半だ。20〜30代の頃は面接をそこそこうまくこなしていたが、時間が経つほど面接そのものがどんどん対立的になったと感じる。以前は「何とか採用しよう」という雰囲気だったのに、今は「採用しない理由」を探している感じだ。これは年齢差別のせいかもしれないが、業界全体の空気の変化でもあると思う。この15年ほどで面接経験はますます不快になり、面接中にパニックを起こしたこともある。それでも何とか採用はされたし、実績のおかげで面接なしの契約仕事をしたこともあった。最後にいたスタートアップが22年末に資金切れになり、そこで退職を決めた。仕事そのものは本当に好きだったし、最新技術も扱っていたが、もう面接に耐えられなかったというのが一番大きい。
この仕組み自体が問題だと思う。最近のコーディング面接は、若い人がCSのデータ構造課題をやったかどうかを確かめるために作られているように見える。2010年代のFAANGのような大量採用ではそれなりに意味があったのだろうが、中小規模の会社では、実際にコードを読んだりedge caseを議論したりするなど、実務の状況に集中したほうがずっと良い。20年以上スタートアップで働いてきたが、こういうテストはいまだに通らない。無理に暗記するのも拒否したい。これが合わない会社なら、むしろ落ちたほうがいい。CTOもやったし、会社を何度も立ち上げ、チーム管理もうまくやってきたのに、今回も新卒のように扱われる。以前、LRUキャッシュを素早くきれいに作れなかったことで落とされたが、今どきのスタートアップでそれがどれほど必要なのか疑問だ。最近使ったこともない。こういう問題をその場で解けなかったからといって無能に見えるかもしれないが、実務で使わないものをわざわざ問う意味がわからない。まるで建築家を計算尺の腕前で採用しようとするようなものだ。こうした採用方法は結局複雑なコードベースを生み、本当に必要なのは複雑さではなくビジネス目標の達成だ。私は問題を分解し、論理と構造をシンプルに保てる同僚と働きたい。leetcodeで賢い人を選ぶ利点はあるが、現実の問題を着実かつ効果的に解く人のほうがいい。
採用する側としてこういう状況を経験したことがある。プロジェクトに長く参加していた学生と電話面接をしたが、さまざまなストレスや言語の壁のせいで、実力をきちんと出せていないように見えた。形式を変える気もあったが、候補者自身がもう試さないと言った。とはいえ非同期のコーディング面接に切り替えると、今度はLLMを使うかどうかだけを試すことになりかねない。結局、面接で固まる人を落とすか、まったく能力のない詐欺師を落とすかの二択なら、私は前者をフィルタするほうがより良い選択だと思う。
こういう気質のミスマッチは会社でよく見る。多くのプログラマは内向的なのに、採用する側は外向的なことが多い。この違いをうまく扱わないと、内向的な人材が排除されたり理解されなかったりする問題が生じる。オープンシート環境（共有席の空間）も似た問題だ。マネージャーはコラボレーションを好んでも、内向的な人にはとてもつらい環境だ。
indie開発で成功し始めたきっかけが気になる。私ももうすぐ40歳で、長いことプログラミングを趣味にしてきたが、去年から本格的に職業にしようと決めた。Githubに公開プロジェクトも多く、他分野での成功経験も豊富で、コミュニケーション能力も悪くない。ただライブコーディングで苦労している。本当の実力を示せるindependent contributionのルートについてどう考えているのか聞きたい。本当に実力があるなら、それでお金を稼ぎたいと思っている。
今週Data Engineering候補者を面接した。非常に基本的な4つのSQL文を出したところ、問題を声に出して読んで、すぐに正しい構文で答えを出した。最後は少し難易度が上がったが詰まった。「結果を確認してみて」と言っても理解できず、防御的になった。「テーブルをダンプしてみて」と言ってもまったく理解できず、言い訳ばかりだった。最終的に貼り付けられたSQLには[redacted].aiの出力が含まれていた。おそらく前の問題はAIで解いていて、最後の問題でそれが露呈したのだろう。こういう技術的な問題がなければ、不正は見抜けなかったはずだ。
AI面接不正ツールは若い層で非常に広がっている。すぐ見抜ける場合もあるが、経験のある候補者はAI活用と合間の「音が聞こえません」などで隙を隠すこともある。私が所属するマネージャーのグループでも、これは最近もっとも多く議論される採用トピックだ。余力のある会社は最終面接を対面で行う。リモート画面ではまともに見えても、実際に会うと基本的な質問にも答えられず、結局落とすケースがある。時間と金の無駄ではあるが、採用ミスのコストよりはましだと判断している。AI利用は技術面接だけでなく、履歴書、行動質問、さらにはChatGPTが作ったS.T.A.R.形式の回答まで全体に広がっている。信頼できるリファレンス確認がこれまで以上に重要になっている。以前の上司が語る仕事内容と履歴書に書かれた内容が完全に違うことも何度もあった。最初からそのドメインの直接経験がないと正直に言っていれば採用していたかもしれないが、ここまで嘘が強いとまったく信頼できない。
最近候補者を面接していて、およそ50%がlive GenAIをリアルタイムで使っていた。今のところ誰がAIを使っているかを見抜くのは非常に簡単だ。自然な会話の中で簡単に露呈する。皮肉なことに、最後の候補者も問題を毎回言い直したあと、10〜15秒ずつ待っていた。こうしたテスト自体が根本問題の解決策ではないことを示している。むしろ新しい問題を生み、優秀な候補者を落とす原因になっている。
「AIを使うのは不正ではなく、実際の現場でやることを先にやっているだけだとしたら？」という見方をすれば、その面接は実際には非常に効果的な小規模の<i>要件解釈</i>の例だ。結局、現場で使うツールを自由に使わせたうえで、その中で職務と言語そのものの理解を試す方向のほうが前向きだと思う。単にLeetcodeから離れるだけでなく、もっと良い方法を探す必要がある。
すべては結局「ケースバイケース」だ。ライブコーディング面接も同じだ。候補者にとって最高の体験ではないが、MetaやGoogleのような大規模企業では、他の方式よりfalse positive（実力のない人を採用してしまう誤り）率をよりうまく下げる。ただし、面接官の訓練が不十分で、問題が過度にパズル寄りなことが多いため、LeetCodeをかなり練習しているか、学界にいるか、卒業直後でない限り厳しい。私は6年間assessment分野で働き、Fortune 10からスタートアップまでさまざまな採用プロセスを直接見てきた。候補者には実際の仕事に近い評価を勧めるが、unpaid laborに近い「実務そのもの」という表現は今では好まない。評価は、会社が高額年収を安心して提示できるようにするための手段であるべきだ。AIの登場で、短いtake-home課題も公平性を保つのが難しくなった。だから再びオンサイト面接やリアルタイム監視のような極端な方法に頼る企業もある。私が考える完璧な解決策は、すべての候補者が同じ時間、環境、ツールの中で自分の最高の力を発揮できるようにすることだ。ずっとこの問題を考えているが、まだ答えは見つかっていない。
「MetaやGoogleレベルではうまく機能する」と言うが、実際にはデータがない。FacebookやGoogle出身のF級開発者と働いた経験がある。実際にはこうした大企業も3〜5%の人員を解雇しており、面接だけではfalse positiveをきちんと抑えられていない証拠だ。面接官が費やした時間に対して3%の誤り率は高すぎると思う。事実上、昔の「Fizzbuzz」レベルと大差ない。
レンガ職人に実際に壁を作らせるのではなく、資格証明だけ確認してすぐ採用しているようなものだ。多くの職業がこういう方式だ。実力が合わなければ採用後に辞めてもらえばいい。わざわざ屈辱的な企業面接プロセスを経る必要はない。
私が見てきた最高のエンジニアたちは、しばしばfalse negativeに分類されていた。ライブコーディング面接で緊張して実力を出せない。こういう面接が「うまく機能する」と断言はできないと思う。
「ケースバイケース」と言ったあとで「ライブコーディング面接はうまくいく」と断言するのは筋が通らない。逆に私は「ケースバイケースだが、ライブコーディング面接は機能しない」と主張することもできる。論理的な差はない。
leet-codeを通過できることは、本当に問題解決能力のない人をふるい落とすのには使える。最高の解決策は、候補者が自分の持つツールと環境で最大限の力を出せる場を作ることだ。しかし実際には、leetcodeをオフラインでホワイトボードを使い、面接官とペアプログラミングしながら解くのがいちばん公平なのかもしれない。それが本当に快適な環境だ。
両方の説明は同時に正しいと思う。実際、仕事ができない「シニア」開発者は存在し、そういう人をふるい落とすのにライブコーディングは役立つ。しかし別の理由で面接に失敗することもある。
ライブコーディングはできても、大規模システム設計の経験が不足している開発者は多い。そういう人たちは技術的負債やanti-pattern、不整合などを持ち込み、コードベースをさらに悪化させることが多い。事実上、本当に避けるべきタイプだ。会社は既存のシニアが新卒をコントロールすると信じているが、どの会社でも「うちのコードベースはゴミだ」と言うのだから、この対策も実効性がないように見える。
一人で部屋に座ってコーディングさせれば、異常な環境でだけ能力を発揮できない優秀な人材を取りこぼさずに済むはずだ。
最近のライブコーディングは単なるコーディングテストを超えて、多くのアルゴリズムを暗記し、30分で2〜3種類のアルゴリズムを組み合わせて問題を解くレベルになっている。問題を解くだけで時間を使い切ってしまい、むしろ本当のコーディング力を示す時間がない。
20年間現場で働いてきて、そういう「実力のないシニア」と実際に一緒に働いたことはない。履歴書と15分の会話だけで十分見分けられた。逆にホワイトボード面接に合格したのに、チームの生産性に悪影響を与えた人ははるかに多く見てきた。
なぜ短い制限時間と、ホワイトボードの前で同時に考え説明することを求める環境が必須なのか理解できない。本当に仕事のできない人を見分けるのが目的なら、わざわざそこまでやる必要はない。
私が思うに、ある職務の遂行能力をきちんと確認できる唯一の方法は、実際にその仕事をさせてみることだ。仮に代替評価法があったとしても、実際の作業をやらせられるなら、他の方法を使う理由はない。もし会社の仕事が複雑すぎて切り出して面接でやらせられないなら、その会社は不必要に複雑なことばかりしている可能性も高い。たとえば10キログラムの重さを持ち上げられるか確認したいなら、実際に10キログラムの荷物を持ち上げさせればいい。なのに「力を評価する」と言って「ズボンを脱いで1kgのバケツを尻で挟んで持ち上げろ」みたいな奇妙な試験をしているようなものだ。結局、実際の業務に必要なスキルだけをきちんと見ればいい。たとえばシェフなら実際の厨房で料理させればよく、相談員なら模擬状況でコミュニケーションを見ればいい。電話スクリーニングでもリアルタイムの画面を見せればいい。
「面接で実際に作業させると不正や賃金搾取の問題が出ないか」という反論がある。面接課題を会社が活用するなら、法的な問題になりうる。
1日、1週間、1か月単位で直接雇って試し、合えば採用する方式の提案もある。ただし、この方式はアメリカ型のemployer healthcare systemとは相性が悪い。
会社側にとって時間がかかりすぎるからだ。だからfalse positiveよりfalse negative（誤って落とすこと）に偏ったproxyを使う。
実際の作業を面接でやらせると「無料労働」を求めているという懸念についてはどう思うか気になる。
新しい組織に適応するには時間がかかるので、実務でテストするほうがむしろ非効率かもしれない。ライブコーディング評価でコミュニケーション、問題解決、純粋なコーディング力を測るほうが良いと思う。
子どもを持ってから面接コーディング能力が大きく落ちた。以前は一度もこんなことはなかったのに、今は面接にあまりにも多くのものが懸かっているように感じる。健康保険、ローン、退職後の生活などを思うとプレッシャーが大きい。面接中に完全に止まってしまい、終わったあとでようやく解決策が思い浮かぶのがつらい。練習に時間をかけるほど、むしろ実力が落ちる。扶養家族がいるので、練習すればするほど罪悪感も大きい。学習効果も薄く、むしろ萎縮していく。ビッグテックで働いて感じたのは、こうした面接方式は極めて「全員を平等にテストする」という発想で導入されたが、実際にはそれぞれの状況の変化や不均衡をまったく反映できていないことだ。ストレスに強い同僚でも数年後には変わるかもしれない。偏見をなくす名目で始まったのだろうが、方式は変えるべきだと思う。
そういう感情を抱いているのはあなただけではない。年を取るにつれて学習速度は落ち、自由時間も減るので、leetcode練習の効率が下がる。ただ時間に余裕のある人がより報われる現実に腹が立つ。
ストレス軽減法として、瞑想、呼吸法、L-Theanine、ベータブロッカーなどを試すことを勧める。スマートウォッチで心拍数と血圧をモニタリングしてみることもすすめたい。実際にこういう方法がストレスの悪循環を減らしてくれる。
現場のストレスとは質的に異なる、非常に高強度のストレス環境だ。Google面接での経験を共有すると、私はオランダ初の地域検索エンジンを作った人間なのに、Googleではカウボーイハットをかぶった面接官に、ホワイトボードへマーカーでバイナリサーチのコードを書けと言われた。私は普段手書きをせずキーボードしか使わないし、自分が設計した検索インデックスの経験をまったく見ようともしなかった。たぶんGoogleは「カウボーイ」マインドを求めていたのだろう。
私も昔Googleのリクルーターに口説かれて面接を受けたが、面接官があまりにひどかったので、技術面接を飛ばしたにもかかわらず、その後Googleからのどんな提案も断っている。問題の大半が「ひっかけ」スタイルか、現実と無関係な非常に古いUNIXの構造（例: inode構造）を問うものだった。その役割とはまったく関係ない内容だった。企業は必ず面接質問を追跡し、フィードバックするプロセスと、面接官教育を持つべきだ。いまだに面接官個人の趣味で質問が決まる会社が非常に多い。
こういう仕組みは実際に意図どおりに機能している。こういう会社は、その会社でどんな屈辱にも耐えられる人を求めている。お互いfitしなかったのだから、双方にとって成功だったのだ。
バイナリサーチをやらされることに屈辱を感じたのなら、プライドが高すぎるのではないかと思う。
年25万ドルと追加のGoogle株式オプションがかかっているなら、1日くらいの「屈辱」は喜んで受け入れられる。
私はlive coding screeningを「コードについての対話」として扱っている。候補者には、面接の目的が互いにうまくコミュニケーションできるかを確認することだと明確に伝える。実力があるだけでは不十分で、一緒に協業できなければならない。たとえば会話の過程で誤解して間違った実装をしたり、どれほどコードが書けても技術的な会話ができない候補者なら問題だ。だからFizzbuzz系の質問が重要なのは、単に実力ではなく「技術的議論」の能力を試す役割があるからだ。
その通り。live coding面接の本質は「問題を解けるかどうか」ではなく、「どう解くかを説明できるか」だ。多少の技術的基礎とコミュニケーション能力が核心だ。実際の仕事のかなりの部分は、非技術のマネージャーに説明することなので、これを試していると考えればよい。
こういうやり方は良い。私はFizzBuzzを最低3言語で、4つの方法で解けるし、その12通りすべてを説明する自信がある。
私もこの問題を認識しているし、これといった代案がないことにも同意する。キャリアの中で、本当に「エンジニアのように話し振る舞うのに、実際にはコーディングできない人」を何度も見てきた。面接でコーディング力を無視して採用してしまい、後悔したことも多い。若い開発者には、採用プロセスのいくつかの段階が年配の応募者をより有利にしていることも理解してほしい。中身のない「専門家」らしさにだまされて、実際のコーディング能力がないエンジニアが業界には多いと知っている。実際にコーディングの様子を一度も見ずに採用するのは、履歴書と会話とリファレンスだけでバンドにギタリストを採るようなものだ。実際にはギターを弾いたことのないギター専門家が、それでも採用されうる。特別な資格がなくても、こうやって通ってしまう人はいる。面接で直接の証拠なしに推測するしかなくなれば、結局は偏見と先入観が入り込まざるを得ない。
「問題はあるが代案がない」という話への答えとして、医師や弁護士のように資格を基準にする制度もある。手術の前に実演を求めたりはしない。リスクはもっと高いのに。実際には、下位職ほど検証手続きが厳しく、実際にはより大きな影響力を持つマネージャーや上級職ほど簡単に通過する。
私はホワイトボードにpseudocodeを書かせるほうが良いと思う。文法のストレスが減り、問題解決の論理をよりよく見られる。同時に、私の協業スタイル（ホワイトボードで一緒にアイデア交換すること）にも合っている。
「ストレスは実力と別物」という現象が繰り返されている。Microsoftの論文もひどかった。大半の助言は「LeetCodeをひたすら解け」というものだが、ストレス（コルチゾール）を見落としている。私はストレス環境そのものに自分を慣らす練習をしている。友人たちはそこまで強く鍛えてくれないし、コーチは時給が高すぎる。そこで最近、Tough Tongue AIというサイドプロジェクトを開発している。声で答えるライブコードエディタの中で、リアルタイムの質問、妨害、即時フィードバックを提供する。この訓練によって、「誰かが自分を見ている」という緊張感に少しずつ慣れていく。ライブコーディング面接が続くなら、アルゴリズムではなく、生理反応（ストレス）そのものを訓練する方法が必要だ。