ライブコーディング面接はコーディングスキルではなくストレスを測る

297日前原文(hadid.dev)

概要

ライブコーディング面接 が苦手なエンジニアの体験談
ストレス が認知機能に与える影響の科学的根拠
公開実験 でのパフォーマンス低下とその不公平性
ストレス下での 適性評価の問題点
ストレス軽減や対策方法の提案

ライブコーディング面接の苦手意識と実体験

ライブコーディング面接 を楽しむ人もいるが、自分はそうではないという立場
Toptal の選考で、非公開テストは合格、ライブコーディングで失敗した経験
後で同じ問題を簡単に解けたことから、根本原因に疑問を持つ
問題自体は簡単だったが、 ライブコーディングの場 で解けなかった混乱
これをきっかけに ストレスとパフォーマンス の関係を調査

ストレスが脳に与える影響

高ストレス・時間制限下 では脳が「脅威」と認識し、 扁桃体 が活性化
コルチゾール （ストレスホルモン）分泌増加
前頭前野 （複雑な思考・ワーキングメモリ担当）が機能低下
ワーキングメモリ低下により、 流動性知能 （新しい問題解決能力）が著しく減少
軽度の パフォーマンス不安 でも思考が狭まり、記憶力や集中力が極端に落ちる

科学的研究と不公平性

Microsoft研究者らによる論文「Does Stress Impact Technical Interview Performance?」の紹介
プライベート環境 （一人で解答）と 公開環境 （監督者の前で解答）での比較実験
- 公開環境では 得点が半分 に低下
- パフォーマンスの分布も広がり、一部の人が極端に影響を受ける
特に女性は、 公開環境で全員不合格、逆にプライベートでは全員合格という衝撃的な結果
ライブコーディングは ストレス耐性フィルター として機能し、不公平性を助長

ストレス下でのパフォーマンス評価の問題

一部企業は「 プレッシャー下でのパフォーマンス」を重視するが、ほとんどの求人は明記しない
多くの職場では ストレス耐性 よりも、普段のエンジニアリングスキルが重要
ライブコーディングで失敗した人 も、日常業務では高い成果を出せる場合が多い
ライブコーディングは「 コーディング能力 のテスト」として不適切で、実際は ストレス反応 の測定になっている

ストレスへの対策と緩和方法

ライブコーディング面接 が一般的である現状は変えにくいが、 ストレス軽減策 は可能
模擬面接 （Pramp、Interviewing.io、LeetCodeの模擬試験など）で繰り返し練習
- タイマー使用や録画、他人の前での練習で実際のプレッシャーを再現
サプリメント の活用検討（個人差あり・自己責任）
- L-tyrosine ：ストレス下での神経伝達物質補充
- L-theanine ：リラックス促進・集中力向上
サプリメントは 実際の面接前に練習で試す ことが重要
ライブコーディングが苦手 ＝悪いエンジニアではなく、「普通の人間」であることの再認識

ライブコーディング評価の再考

ライブコーディング面接 は本来の目的（コーディング能力測定）を果たしていない可能性
ストレス耐性 よりも 日常業務での実力 を重視する評価方法の必要性
公平な採用プロセス実現のための見直し提案

Hackerたちの意見

とてもよく書かれていて、すごく真実だね。普通のストレスじゃなくて、高いリスクのストレスだし、時には侮辱されながら働かなきゃいけないこともある。昔、Googleの面接に行ったことがあるんだけど、オランダの最初のローカル検索エンジンの一つを作ったんだ。でも、カウボーイハットをかぶったGoogleの人にホワイトボードにバイナリサーチを書けって言われたんだ。手で書くことなんてほとんどないし、いつもキーボードを使ってるのに。しかも、検索インデックスや検索エンジンを設計・構築したのに、バイナリサーチを書くように侮辱されるなんて。バイナリサーチはやったけど、全体のプロセスには全然満足できなかった。だって、実際に自分がやったことを見ようともしないんだもん。それを見ちゃうと、彼らが求めてた基準が崩れちゃうからね。多分、彼らはカウボーイを探してたんだろうな。面接のコツとしては、カウボーイハットを持って行くといいかもね。

└

バイナリサーチを書くように言われて侮辱されたと感じるなら、ちょっと自分のエゴが強すぎるかもね。

└

残念ながら、これは意図した通りに機能したね。こういう会社は、そこに入りたくて必死な人を求めていて、何でもして入ってくるような人を探してる。今回のケースでは、双方ともに良いフィットではないことを確認できたってわけ。

└

最後にGoogleで面接を受けたとき（向こうから声をかけられて、仕方なくリクルーターに今回は違うと言いくるめられた）、面接官がひどすぎて、リクルーターが技術面接を無視して管理面接に進むことに同意しても、私はそのプロセスを続けるのを断った。それ以降、Googleのリクルーターからの電話には、前回の出来事と、もう興味がなくなったことを説明してる。出された問題は全部「引っかけ」タイプで、解決策を読んでないとまともな代替案しか出せないか、リクルーターが完全に時代遅れのことについて知識を求めてきた（例：UNIX v6のinodeの構造について聞かれたけど、知らないと答えて、Unix系システムがinodeに保持する情報の種類について一般的な返答をした。さらに、今回の役職にはファイルシステムの詳細の知識は関係なかった）。企業は面接官のプールをしっかりトレーニングして、どんな質問がされるかを追跡し、フィードバックを提供する必要がある。私が見てきたほとんどの企業は、技術的な質問が面接官やそのマネージャーの好みになってしまっている採用プロセスを持っている。

└

[遅延]

その説明は相反するものじゃないと思うよ。確かに、実際にはコードが書けない「シニア」ソフトウェアエンジニアの大きなグループがいる。彼らはクソみたいなことを言って仕事を得て、解雇されるまで続けて、次の仕事に応募するんだ。そういう人たちをライブコーディングでフィルタリングしたいんだよね。でも、ライブコーディングの面接で失敗する理由は、そのグループに属している以外にもあるからね。

└

もっと効果的にフィルタリングするには、彼らを一人で部屋に座らせてコードを書かせるといいよ。そうすれば、異常なストレスの下で機能できない良い候補者を逃すこともないしね（実際の仕事とは関係ないストレスだけど）。

└

なぜ、無意味で非常に短い締切を設けて、誰かにホワイトボードの前に立たせながら問題を解決させて、「思考過程を説明させる」必要があるの？それでコードが書けない人をフィルタリングするの？

└

ライブコーディングの面接をうまくこなせる開発者はたくさんいるけど、スケールでのエンジニアリングシステムの理解が欠けている人も多いから、彼らが時間とともにコードベースを悪化させてしまうことがある。こういう人たちは本当に避けたい人たちだけど、そういう人をフィルタリングするための面接プロセスはほとんどないんだ。会社の既存のシニアアーキテクトや開発者が新しい人がコードを悪化させるのを止めるだろうという前提があるけど、どの会社の開発者も自分のコードベースがひどいと思ってるから、明らかにうまくいってないよね。

└

君の意見には同意だけど、最近のライブコーディングはプログラミングスキルをテストする以上のものになってるよね。最も一般的なアルゴリズムを暗記して、30分で問題を解くために2つか3つ使った解決策を考える必要がある。時には、パズルを解く方法を考えるのに時間を使いすぎて、実際にコードを書く時間がなくなっちゃうこともある。

└

面接には2つの方法があるよ。1つ目は、良い候補者を全員選ぶけど、悪い候補者もいくつか通っちゃう。2つ目は、悪い候補者を全員落とすけど、良い候補者もいくつか落ちちゃう。候補者は1つ目のプロセスを望んでるけど、企業はそれを推進する理由がないんだ。悪い社員をうっかり雇っちゃうコストは、良い社員を拒否するよりもずっと高いからね。今のシステムは2つ目を優先してる。そう、素晴らしい候補者を拒否してることは分かってるんだ。

└

もう20年やってるけど、あの人たちとは一度も仕事したことないんだよね。面接したこともないし、履歴書と15分の会話でフィルタリングできたと思う。ホワイトボードの面接を通過した人たちとたくさん働いたけど、結局は生産性を下げることに時間を費やしてた。

└

そう、実際にコードを書けない「シニア」ソフトウェアエンジニアの大きな群れがいるんだ。彼らは仕事に入り込むためにごまかしをして、解雇されると次の仕事に応募する。こういう人たちをライブコーディングでフィルタリングしたいんだ。正直、シリコンバレーみたいな場所で、コードが書けない人が大規模に存在するのかは疑問だ。俺が働いてきた場所では、コードが書けない人に会ったことがない。シニアエンジニアはコードを出す能力で厳しく評価されるからね。もしコードを書いてないなら、収益を生むために機能を構築する必要があるスタートアップで何をしてるんだ？

仕事ができるかどうかを測る唯一の良い指標は、実際にその仕事をすることだと強く信じてる。たとえ仕事をするための良い指標があったとしても、なぜその指標を使うの？実際に仕事をすればいいのに。もし仕事が複雑すぎて、面接でその一部を分けてやれないなら、理由もなく難しくしすぎてるかもね。例えば、10キロ持ち上げられる人が必要だとするなら： - 良い面接：「この10キロのバケツを持ち上げてみて。」 - 良くない面接：「全体的な力を測るために、ズボンを脱いで、しゃがんで、この1キロのバケツを尻で持ち上げて立ってみて。これが本当の力のテストじゃないのは分かってるけど、プレッシャーの下でどうするかを見たいんだ。」追記：私が言いたいのは、仕事をすること、つまりその仕事で使うスキルをテストすることだよ。シェフがキッチンで料理できるか確認したり、カスタマーサポートの担当者が模擬サポートで良いコミュニケーションスキルを持っているかを見たり、電話スクリーニングができるかどうかを確認したり、そういうこと。

└

それには時間がかかりすぎるから。彼らは多くの候補者をフィルタリングするために、誤った否定に偏ったプロキシを使ってる。

└

なぜプロキシを使うのか、仕事を直接やればいいのに。「ポケットマップって便利だよね！」と私は言った。「それはあなたの国から学んだことの一つだ」とMein Herrは言った。「地図作りだ。でも私たちはそれをずっと進めた。実際に役立つ地図の最大のサイズは何だと思う？」「約1マイルに6インチ。」「たった6インチ！」とMein Herrは驚いた。「私たちはすぐに1マイルに6ヤードに達した。それから1マイルに100ヤードを試みた。そして、最も素晴らしいアイデアが出てきた！実際に国全体の地図を、1マイルに1マイルのスケールで作ったんだ！」「それを使ったことはある？」と私は尋ねた。「まだ広げたことはない」とMein Herrは言った。「農民たちが反対したんだ。全土を覆ってしまって、日光を遮ると言ってね！だから今は国そのものを地図として使っているが、ほぼ同じように機能することを保証するよ。」 https://en.wikipedia.org/wiki/On_Exactitude_in_Science

└

ただ仕事をしてもらうだけでいいんじゃない？それは危険だよ。いくつかの法域では、雇う前に誰かの仕事を使うのは非常に違法と見なされることがあるからね。論理的に極端なことを言えば、誰も雇わずに面接での仕事だけで製品を作ることになるかも。多くの人はこれを賃金泥棒の一形態と考えるだろうね。

└

じゃあ、あなたの解決策は何？千人の候補者に6ヶ月間無給で働かせて、その中から一番良い人を雇うってこと？

└

面接で「ただ仕事をしてもらう」って言うことが、無給労働を求めてるって心配してる人たちにどう返すか、ちょっと気になるな。それって不公平じゃない？（この投稿、笑っちゃった、ありがとう！）

何事もそうだけど、結局はケースバイケースだよね。ライブコーディングの面接は機能する。候補者の体験としては最高じゃないけど、MetaやGoogleの規模では効果的で、他の形式よりも誤った合格を減らせる。ストレスの原因は、面接官のトレーニング不足と、問題が抽象的でパズルみたいなところだね。これを解くには、LeetCodeみたいに勉強したり、大学や学術界から出たばかりじゃないと難しい。私は評価の分野で6年働いてきて、Fortune 10企業からスタートアップまで、いろんな採用プロセスを見てきた。必要なシグナルの幅や、「エンジニアリングチームが候補者にどれだけ時間を使えるか」、候補者体験をどれだけ妥協できるかは大きい。私も候補者として多くのライブコーディング面接で失敗したことがあって、そのたびに自己嫌悪に陥った。最後にYcombinatorの役職で面接を受けたとき（面接官はすごく優しかったけど）。自分のプロダクトに取り組むときは、候補者が自分のスキルやポテンシャルを見せられるように考えるようにしてる。お客様には、実際の仕事に近いスキルを評価する方法を使うように勧めてる。「実際の仕事」という表現はもう好きじゃない。評価は無給の労働であるべきじゃなくて、候補者がその仕事をこなせることや、将来の仕事に対処できることを示す手段であるべきだし、採用マネージャーがテック業界でしばしば高い給料を出すことに自信を持てるようにするべき。残念ながら、AIの影響で、短いテイクホーム（私が候補者として好む、自分のツールやエディタを使うやつ）は、公平なシグナルとして維持するのが難しくなってきてる。企業が現地面接に戻ったり、競合がいろんな監視や侵入的なモニタリングを導入したりしてるのを見てきた。私の考えでは、完璧な解決策は、候補者がリラックスしてベストを尽くせる評価で、自分のエディタや設定を使い、他の候補者も時間やツールに関して同じ制約を持っていると知っていることだと思う。これは解決が難しい問題だね。毎日考えてるけど、まだ解決策は見つかってない。

└

ブロック職人は、仕事を得る前に壁を作ることを求められない。彼がその仕事を学んだことを確認する証明書があれば、企業は彼を雇うのに十分だ。他の多くの仕事も同じだ。開発者を雇って、ニーズに合わなければクビにすればいいじゃん。こんな屈辱的な企業プロセスを経る必要があるの？

└

君は競争力のあるコーダーを雇おうとしてるみたいだね、ソフトウェアエンジニアじゃなくて。

└

ストレスの原因は、面接官のトレーニングが不足していることと、問題が抽象的でパズルのような性質を持っていることだね。これらは、勉強した時間がないと解けないし（例：LeetCode）、大学や学術界を卒業したばかりの人じゃないと解けないんだ。これが年齢差別を引き起こすけど、罰則がないんだよね。

└

すべてにおいて、状況次第だよ。ライブコーディングの面接はうまくいく。「状況次第」と言ってから絶対的なことを続けるのは無理だよ。僕も同じことが言える：すべてにおいて、状況次第だ。ライブコーディングの面接はうまくいかない。何が違うの？

└

すべてにおいて、状況次第だよ。ライブコーディングの面接はうまくいく。最高の候補者体験ではないけど、MetaやGoogleの規模では、他の形式よりも偽陽性を最小限に抑えてる。ストレスの原因は、面接官のトレーニングが不足していることと、問題が抽象的でパズルのような性質を持っていることだね。これらは、勉強した時間がないと解けないし（例：LeetCode）、大学や学術界を卒業したばかりの人じゃないと解けないんだ。彼らにはうまくいく（人もいるし）、LeetCodeは本当に問題解決ができない詐欺師を排除して、何も作ったことがない人を評価することができる。買収から参加する企業にも適用できる。 > 僕の考えでは、完璧な解決策は、候補者がリラックスして最高のパフォーマンスを発揮できる評価方法だと思う。全ての候補者が時間やツールに関して同じ制約を持っていることを知っているからね。これは解決が難しい問題だ。最も公平なのは、対面でプロジェクターのホワイトボードを使って、面接官とペアプログラミングをするLeetCodeの面接だと思う。すごくリラックスできるよ。

└

ライブコーディングの面接って、実際にうまくいくの？

└

取り組み課題は、AIを使う前提で作ればいいんじゃない？

└

お客様には、実際のスキルに近い評価を使うことをお勧めしています。仕事中にコードを書くとき、他の人のために物語を作り続ける必要があるの？

└

すべてにおいて、状況による。それが問題なんだよね。もしトップ1%の給料を払うなら、トップ1%のパフォーマーを得るべきだよ。底の20%の給料を払いたいなら、ホワイトボードテストでどうやって選ぶの？

ライブコーディングのスクリーニングセッションを「コードについての会話」として扱うようにしてる。候補者に、私がコードについて話し合えるようにしていることを伝えるようにしてる。なぜなら、単に「良いプログラマー」でいるだけじゃ仕事には不十分だから。良好な作業関係を築き、コミュニケーションを取ることが重要なんだ。例えば、専門のプログラマーが議論を誤解して間違ったものを作ってしまうこともあるし、素晴らしいプログラマーでも技術的な議論を実際に行うのが難しい場合もある。つまり、これが「FizzBuzz」スタイルの質問がうまく機能する理由なんだ。実際には、優れたプログラマーかどうかをスクリーニングするのではなく、技術的な議論をする能力をスクリーニングしているんだ。

└

それはいいアプローチだと思う。FizzBuzzを4つの異なるプログラミングスタイルで、少なくとも3つの異なるプログラミング言語で書けるし、その12通りの組み合わせについて話すのも楽しいよ。

└

その通り。ライブコーディングの面接は「解けるか」じゃなくて、「どうやって解くかを説明できるか」ってことなんだよね。ちょっとした技術的な知識とコミュニケーションが必要。自分の仕事のどれだけが非技術的なマネージャーに何をするべきかを説明することか考えてみて。それがテストされてるんだよ。

問題を認識してるけど、代替案を聞いたことがない人のリストに加えて。求人情報を見てると、話せて行動できるソフトウェアエンジニアっぽい人がいるけど、コードが書けないってのがよくある。私はこの業界で約25年やってきたけど、面接でコーディングスキルを示せなかった人を見逃すことにしたチームもあった。時にはその人がコードを書けることもあったけど、そうじゃないことが多い。業界で仕事を探してる若いエンジニアは、採用プロセスの他の部分が年配のエンジニアを能力に関係なく優遇してることを考えた方がいいよ。20年前に基本的なコーディングスキルがなかった人たちが、今もそのスキルがなくて、必要な仕事に就いてるのを見てきた。彼らの履歴書や経験、発言がうまく合わさってるから、若くて能力のある人たちがその仕事を取れないんだ。コードを書くために誰かを雇うのに、実際に書いてるところを見たことがないってのは、バンドのギタリストを雇うのに、音楽理論のMFAを確認して、1時間音楽の話をして、推薦状をチェックするようなもんだ。全部はいいけど、ギターは弾けるの？他のことは全部習得できるけど、楽器に触れずに音楽理論や技術の良し悪し、過去や現在の偉大な演奏者についての知識を得ることはできる。そういう人もいるし、ギターの愛好者もいる。彼らは楽器を演奏する夢を諦めたけど、アートやサイエンスに夢中なんだ。もし彼らが健康保険のためにバンドに入る必要があって、オーディションがなかったら、きっと話術で入れる人もいるだろうね。結局、チームがコーディングが必要なポジションの面接をする時、彼らはその人ができるかどうかを判断してるわけだ。直接的な証拠なしに誰かに推測させると、偏見でそのギャップを埋めさせることになる。彼らは微妙なヒントを集めて、シャーロック・ホームズみたいに脆弱な推論をするのか？それとも、目の前の人がコーディングできそうかどうかを直感で信じるのか？どちらも偏見や問題のある先入観に満ちてることは間違いない。

└

問題を認識してるけど、代替案を聞いたことがない人のリストに加えて。医者や弁護士のような資格。手術の前に外科医にデモを頼まないよね？リスクははるかに高いし、悪い医者もいるのは明らか。悪いマネージャーは悪い開発者よりもずっと大きなダメージを与えるし、マネージャーがチームを1時間模擬管理する必要があるって話は聞いたことがない。きっとそれも同じようにごまかしに弱いと思う。本当に見えるのは、下のポジションはジャンプするためのフープがあって、上のポジション（マネージャーや上級IC）はもっと影響力があるのに、楽にやってるってこと。

└

俺にとっては、これよりもっと深い意味があるんだ。ホワイトボードに擬似コードを書いてもらうのが好きなんだよね。文法のストレスがなくなるし、スピードも上がるし、その人がコンピューターロジックで考えられるかどうかもわかるから。面接官としての俺にとってのもう一つの利点は、こうやって他の人と一緒に働くのが好きだからなんだ。アイデアを話し合ったり交換したりするホワイトボードセッションが最高なんだよ。

自分のケースから一般化するつもりはないけど、個人的なエピソードを共有させて。今は成功した自営業のインディー開発者だよ。私が厳しい時期を乗り越えてインディー開発を続けた主な理由の一つは、ほぼ雇われなくなったから。いくつかの理由がある：年齢差別が蔓延する業界で中年だし、コンピュータサイエンスの学位もないし、ライブコーディングの面接で頭が真っ白になることがある。ストレスはすべて同じじゃないってことも言いたい。消防士は燃えてる建物に飛び込む仕事をしてるけど、何よりもストレスが高いのに、見知らぬ人の前でスピーチすることにはパニックになる人も多い。仕事中のストレスには問題ないし、キャリアの中で多くの緊急事態をうまく乗り越えてきたけど、見知らぬ人が私の肩越しに立って、私を判断して、仕事を与えるかどうかで私の経済的未来を決めるってのは、ダモクレスの剣みたいに胃がひっくり返る。記事の著者と同じように、面接が終わった後にコーディング問題を振り返って解決することはできる。面接官は私がコーディングできない詐欺師だと思ってるかもしれないけど、今までのキャリアの証拠はそうじゃない。多くのコメント者は「偽陰性」について軽く話してるけど、私を含めて、常に偽陰性である人もいる。オーディションスタイルの面接で常にフィルターにかけられてる。私はステージパフォーマーじゃないから。

└

私はステージパフォーマーじゃない。これ、めっちゃ同意。もうLeetCodeの面接はやりたくない。

└

業界の「年齢差別」は神話じゃないと感じてる。でも、もっと複雑だよね。年齢が上がってスキルと経験があれば、「持ってるべき」だから、世界は君のもの。私は51歳だけど、2023年にAmazonを辞めた後もすぐに仕事が見つかった。正直、コーディングの面接は通らないだろうけど、仕事では常にコーディングをしてきたからね。でも、51歳でホワイトボードでバイナリーツリーを反転させる能力で仕事を争ってたら、人生で何かひどいことをしてると思う。システムデザインの面接は目を閉じてでもできるけど、クライアントの前でリアルなシステムソリューションを即興で考えるのが私の$DayJobの一部だから。

└

このやり取りの反対側にいたことがあるけど、同じくらいイライラするよ。プロジェクトでランダムなことをしている学生との電話面接をしたんだけど、ストレスや電話、母国語じゃないことが重なって、全然パフォーマンスが出てなかった。状況的で一時的なものだと思ったけど、みんな彼がもっと良くできる形式を試すことにはオープンだった。でも、彼は損切りして他のところに応募することにした。残念ながら、非ライブコーディングの面接はLLMをクエリする能力を測ることになると思う。面接で固まる人をフィルタリングするか、全く能力のない詐欺師を入れるかの選択なら、前者がまだベストな選択だと思う。

└

すごく練習が必要で、それ自体がスキルだよね。ほとんどの面接官も、他の会社でのライブコーディングの演習に慣れてなければ失敗すると思う。目標は、自分を落ち着かせて、目の前の問題に集中することだよ。こういう状況で練習することはもちろん、楽になる。

└

今は成功した自営業のインディー開発者だよ。それが本当の目標。自分が独立して彼らが提示する以上の収入を得られるなら、彼らの面接ゲームに付き合う必要はない。

└

そう、これはひどいシステムだよ。子供たちが先週のCSデータ構造の宿題をやったかどうかを確認するためだけに作られてる。2010年代のFAANGでは関係があったかもしれないけど、今は小規模から中規模の会社にはほとんど必要ないし、誰かのコードを読む/レビューする能力や、機能のエッジケースについて話し合う能力をテストする方がずっと適してると思う。俺は20年以上スタートアップで働いてきて、こういうバカなテストにはいつも失敗してる。だって「詰め込み」は拒否してるからね。それでいいんだ。そういうところは俺には合わないし、CTOとして働いたり、複数の会社を立ち上げたり、チームを管理したり、チームでうまくやってきたから。だけど、ほとんどの面接では新卒扱いされるんだ。ある面接でLRUキャッシュを速くきれいに実装できなかった。これが必要なスタートアップはどれだけあるんだ？90年代以来やってないよ。最近のことのように思えるタスクを直感的にできないことで馬鹿にされることも理解できるけど、仕事で使わないなら、実際のところ何の意味があるんだ？スライドルールのスキルで建築家を雇うようなもんだよ。俺にとっては、採用に対する配慮が欠けてることを示してる。せいぜい、問題に時間をかける労働者が現れるだけだ。傭兵みたいなもんだね。でも、そんな風に採用する会社は複雑なコードを持つ傾向がある。必要だから複雑になるわけじゃなくて、会社の文化がビジネスゴールを解決するよりも巧妙な解決策に焦点を当てるからだ。俺は、問題を分解して論理と構造をできるだけシンプルに保つことに焦点を当てる人たちを雇って、一緒に働きたい。複雑さは進歩の敵だ。LeetCodeの一つの利点は、たくさんの複雑さを扱える賢い人を見つけることだよ。これは役に立つ！でも、俺はそうじゃない人を雇いたいし、できない人を雇いたい。リアルな問題を効果的に、そして一貫して解決できる人をね。変わった考えだと思うけど！

子供ができてから、コーディングの面接がめっちゃ苦手になった。以前はこんなことなかったのに。常にストレスが高いせいかな。小さい子供の健康を気にするのって、フルタイムのストレスだし（寝てる時でも止まらないし！）。面接にかかるプレッシャーも増えた気がする。若い頃は「失敗しても次がある」って思えたけど、今は健康保険や住宅ローン、退職金のことも考えなきゃいけないからね。今まで経験したことのないような詰まり方をするし、頭が働かなくなった感じ（でも「お前、失敗してるぞ！」って叫ぶ余裕はある）。電話が終わった後、静かに座ってると、急に解決策が見えてくるんだけど、それがまた特別な地獄。できるのにやらなかったって思うと、知らない誰かにバカだと思われてる気がしてさ。勉強や練習は、パートナーや子供との時間を奪うから、罪悪感が生まれる。練習すればするほど、LeetCodeの難しい問題を解いても、逆に下手になっていくっていう逆説的なことが起きた！それがまた落ち込む原因だった。これをシェアするのは、状況は変わるし、自分も変わるってことを伝えたかったから。昔は簡単だったことが、今は難しくなることもある。たぶん今だけかもしれないし、永遠に続くかもしれない。Big Co.での経験から言えるのは、この面接スタイル（小さい会社でも真似されることが多い）は、バイアスを排除するために使われているってこと。みんなを同じ「定量的」な方法でテストするっていう目標があるから。でも、私の経験からすると、そこには限界があると思う。人は変わるし、今はストレスに強い候補者でも、数年後には同じようにはいかないかもしれない。バイアスを排除することはバランスを求めることだけど、特定の面接形式は、引き起こすかもしれない不均衡に気づいていないと思う。

今週、データエンジニアリングの役割の候補者と面接したんだけど、4つの簡単なSQL文を出したら、すぐに理解してくれた。指示を声に出して読んで、ためらうことなく完璧な構文で解答を打ち込んでた。最後の問題は少し難易度を上げたら、彼はつまずいてしまった。「自分の答えを確認して」って言ったら、混乱して防御的になって「何？」を繰り返してた。「テーブルを確認して」って言ったら、また「何？」。最後に「テーブルの最初の5行を表示して」って言ったら、できなかった。彼は言い訳を始めて、出力に[redacted].aiを含むSQLを貼り付けた。最初の問題では指示をAIに読ませたんじゃないかと思う。「作業を見せて」って言った時、AIにそれをどう促すか理解してなかった。あの技術的な課題を出してよかった。そうじゃなければ、彼の不正を見抜けなかったかもしれない。

└

今、候補者の面接をしてるんだけど、今のところ約50%の人が質問に答えるのにライブのGenAIを使ってる。誰がそれを使ってるかは簡単にわかるよ。自然言語での会話で、相手が何を話してるか知ってるかどうかを見抜くのはすごく簡単なんだ。皮肉なことに、2日前に面接した最後の候補者も、全ての質問を繰り返して、各質問の後に10〜15秒考える必要があった。つまり、これらのテストはこの問題に対する最適な解決策ではないと思う。新たな問題を引き起こして、良い候補者が排除される原因にもなるからね。

└

AI面接の不正ツールが若い人たちの間で非常に人気になってる。時には簡単に見抜けるけど、他の人たちはAIを使いこなして、間の沈黙をぎこちない感じや「途切れてるよ」みたいなトリックでごまかしてる。俺が参加してるマネージャーのピアグループの採用サブフォーラムでは、これが最も一般的な話題になってる。資金に余裕のある会社は、対面での最終面接を追加してる。簡単なリモート技術スクリーニングではうまくいくけど、対面での基本的な質問に答えられない候補者は却下される。これは時間とお金の無駄だけど、悪い採用のコストよりはマシだ。AIの使用は技術スクリーニングに限らない。GenAIを使う人たちは、履歴書や行動質問、さらにはChatGPTにS.T.A.R.スタイルの回答を作らせて、それを後で繰り返すために使ってる。確認済みのリファレンスチェックが今まで以上に重要になってる。実際に悪いリファレンスチェックを出す人は少ないけど、誰かと話すことで、その人の仕事に関する非常に異なる印象が明らかになることがある。以前のマネージャーから、その人が履歴書に書いてあることとは全く違うことをやっていたと言われたこともある。残念ながら、もしその人が俺たちの分野での直接的な経験がないことを正直に言っていれば、俺はその人を雇っていたかもしれない。でも、こんなに直接的に嘘をついているのを見つけると、他のことでも信頼するのが難しくなるんだ。

現在の雇用主は、エンジニアチーム全体での面接を行ってる。俺が面接を受けたときは、まず電話でのスクリーニングがあって、その後に面接に招待された。実際には二回の面接があったんだ。一つはエンジニアとの面接で、もう一つは管理部門との面接。うちのエンジニアは事前に質問を用意してないんだ。思いついたことを聞いてきて、俺が話したストーリーを掘り下げたり、過去に解決した技術的な問題に興味を持ったりしてた。この方法論を使うことで、いくつかの危険を回避できたと思ってるし、このプロセスで選んだ人たちはかなり優秀で、チームに馴染む傾向があるんだ。

ハクソク