LeetCodeスタイルの面接にうんざりしている人たち
(nelson.cloud)- 2023年11月末に健康上の問題でRobinhoodを退職した後、複数の採用プロセスを経験する中で、LeetCode式の評価は実際のソフトウェアエンジニアリング業務とかみ合っていないと感じた
- 多くの企業がGoogle、Facebook/Meta、Amazonのような大手テック企業のやり方を追随し、似たような面接を繰り返しているように見える
- エンジニアは検索できる知識を暗記する必要はないと言われる一方で、面接ではすぐに思い出しにくい検索可能な知識をクイズのように問うのはおかしいと批判している
- この種の面接で成功も失敗も経験してきたが、不満の根拠は失敗体験よりもこれまでの実務経験に近い
- AWS、Kubernetes、Ruby on Railsの経験があるエンジニアを探していて、無意味なクイズをしない会社なら連絡してほしいと付け加えている
LeetCode式面接が実務とかみ合わない点
- 2023年11月末に健康上の理由でRobinhoodを退職した後、複数の企業と面接を行った
- 採用プロセスはさまざまな理由で進まなかったが、繰り返されるLeetCodeスタイル面接そのものに疲れを感じた
- このような面接は実際のソフトウェアエンジニアリングの責務を十分に反映していないと見ている
- 多くの企業は、Google、Facebook/Meta、Amazonのような大企業が使っている方式だからという理由で、同じ評価方法を採用しているように見える
クイズ式評価と実務経験の衝突
- 普段はGoogleで簡単に調べられる知識を暗記する必要はないと言うエンジニアがいる
- しかし面接では、検索すれば分かってもその場ですぐ思い出しにくい内容を尋ねることがあり、矛盾していると感じる
- この問題に対する明確な解決策はないが、問題そのものは明白だと見ている
- この種の面接で成功も失敗も経験しており、この見解は不合格率よりも過去の専門的な実務経験からより強く影響を受けている
- AWS、Kubernetes、Ruby on Railsの経験を持つソフトウェアエンジニアが必要で、クイズ式面接をしない会社なら連絡してほしいとしている
- 関連記事として Re-imagining Technical Interviews: Valuing Experience Over Exam Skills を挙げている
1件のコメント
Hacker Newsの意見
苛立ちは理解できるが、結局こうした面接にも目的はあると思う。うまくはなくても十分に実用的で、たいていは偽陽性よりも偽陰性を多く生むという点で、会社側からすると筋が通っている
賢い人を落とすコストは低いが、見当違いの人を採用すると、数カ月かけて見極め、解雇し、また採用し直さなければならないのでコストが大きい。ただし応募者にとっては極度に苦痛なプロセスであり、優れたソフトウェアエンジニアでも緊張したり、見落としたり、運の悪い日があったりして、何度か落ちることはあり得る。面接は人生の価値を最終評価するものではなく、鈍い道具にすぎないので、受け流せばよい
「ひっかけ」質問は愚かだが、候補者が基礎を知っているかを見つつ、同時に自社がどんな場所なのかも示す必要がある。たとえば「引数を変更してもよいですか？」と聞いたり、「strlenがヌルバイトを含むか覚えていないので1を足します。普段なら調べます」と言ったりするのは良いサインだ。問題はatoiや「1組のカードをシャッフルする」のように、基本的ではあるがfizzbuzzほど完全に些細ではないレベルだった。最もうまく採用できた人の一人は根本的なミスをしたが、意図どおりに動くと思うかと聞くと「自分はとんでもないバカですね」と言ってすぐに直した。面接でそういう言い方が適切とは言えないかもしれないが、私たちは強いポジティブなシグナルと見た。逆に、文字列をパースして整数を返す質問について、すでにライブラリ関数があるのだから不当だと最後まで主張した候補者もいたが、実際に私たちのシステムの一部はライブラリのない組み込み環境だった
学校や大学のひどい試験のように、記憶力を先にテストする方式をまねしないでほしい。私は必要なときにその場で思い出すのが苦手で本当に苦労したし、私だけではないはずだ。Android開発者の面接をするときは、質問を投げて考え方を見ており、すべての答えが正確であることは期待していなかった。Androidの基本的な理解があるかを見たうえで、小さなアプリを自宅で作ってもらっていた
結局、ポジションを埋めなければならない採用では、偽陰性が増えるほど偽陽性を採用する確率も上がる。極端に言えば、地球上でその仕事に適した人が一人しかおらず、その人を偽陰性で落としてしまったら、残る選択肢は見当違いの人を採用することだけだ
知能不足が問題なのではなく、アルゴリズム問題はうまく解けてもソフトウェアエンジニアではない、あるいはそのポジションが求める能力が不足していることが問題だ。パズル系の面接で多く採用されたチームで働いているが、皆賢いもののソフトウェアエンジニアではなく、その違いが大きく表れている
誰かが解けたとしたら、本当に最適解を新たに導いたというより、練習問題を回している中で同じか似た問題を見た可能性のほうがはるかに高い
一度、かなり気に入った面接を受けたことがある。銀行だった。急いで書かれた汚いコード、ただし意図的に難読化されたわけではないコードを渡され、できる限りうまくリファクタリングするよう求められた
面接官は隣に座って全過程で対話し、実質的には候補者が主導するペアプログラミングに近かった。LeetCode面接の後だったので新鮮だった。もちろん、その銀行は使っている技術を正確に把握しており、新しい技術を学ぶ能力を測る必要があまりなかったからこそ可能な方式だった。彼らにとっては、保守可能なコードを作れるか、名前を適切に付けるか、同僚とコミュニケーションできるかのほうが重要だった
興味深いのは、基本的な質問ではほとんど失敗した人が、コードレビューでは深い専門性が表れるほど優秀な場合があったことだ。面接は人の業務能力を示すにはかなり悪い道具だが、問題を広くも狭くも見られ、コーディングも十分にこなせるなら、おおむね成功だと見ている
LeetCode式の面接は、おそらく二つの機能を果たしている。第一に、ソフトウェアエンジニアの賃金と転職可能性を抑え込む手段であること。転職するには1〜2カ月勉強しなければならないのに、誰が簡単に移れるだろうか。
運悪く、熱心に準備してきた面接官がLeetCode hard級の爆弾を投げてきたら、1年間その会社に再応募するのも難しくなる。第二に、全員に似たような明確な目標を与えたと主張しながら、プロセス上の偏りを覆い隠す手段になること。同じ学校、性別、人種なら、同じ問題を出してもヒントを与え、文法エラーを見逃し、最適なアプローチができなくても「コミュニケーション」を理由に強い採用判定を出せる。気に入らない相手なら難問を投げ、面接中ずっと沈黙していればいい。会社にとっては許容できるノイズだが、個人にとっては数十万ドルの報酬機会を失うことになる。FAANGの面接を受けたことも面接官をしたこともあるが、低い基準で採用された人たちを見る一方で、四分木や整数論のようなばかげた質問のせいで優秀なエンジニアが機会を逃すのも見てきた。
公正な面接官という前提があれば、この方式は履歴書に有名な名前が載っていない候補者にも実力を示す機会を与える。コンピュータサイエンスの学位を持たない私が得た機会の一部は、ホワイトボード面接がなければ絶対になかったはずだ。面接官が友人を採用しようとして意図的に手順をひっくり返すのを防ぐ方法は、想像しにくい。
多くの会社は、公平で、ある程度は現実の問題に関連するよう設計された問題バンクを持っている。私が面接を受けた会社もおおむねそうで、実際のLeetCode問題そのままでなくても、結局は切り離されたコーディング問題なのでLeetCode式だと見ている。この方式をうまく運用している会社の面接はかなり良かった。良い会社と面接官は最終的なコードだけでなく、より多くのものを見ており、採用評価も段階評価にして二分法を減らしている。
現実的には、FizzBuzzだけでも75%はふるい落とせた。プレッシャーがかかるとコードを書けない人は多いし、コピー＆ペーストで無理やりしのぐ人もいる。そういう人が何もできないわけではないが、遅く、奇妙な抽象化を持ち込み、使える結果を得るまでに多くの時間を食う。そしてその人たちにも数十万ドルが懸かっているので、同じように反論する。
会社の立場からすれば合理的だ。気が散らず、残業できる従業員を望んでいるのだから。
今日の技術採用慣行には妥当な批判が多いが、「魂を売らずにとてつもなく裕福にはなれない」という不満は、あまり説得力がない。
ソフトウェアエンジニアを選抜する際に重要なのは知識ではなく、問題解決力と、問題のメンタルモデルを構築する能力である。
候補者がその問題を以前に見たことがなく、面接官が何を見るべきか理解しているなら、ホワイトボード面接はこの能力を評価する良い方法だ。しかしグッドハートの法則のように、測定値が目標になると、もはや良い指標ではなくなる。問題解決力やモデリング能力が弱い人も高給のソフトウェア職を望むのでLeetCodeをやり込み、時間がたってその人たちが面接官になると、自分がされたように記憶力テストのような面接を行う。それでも、会社が抱える制約、候補者の時間の浪費を減らすこと、そしてHRが好む一貫した評価表を維持しなければならない条件の下では、より良い面接方式が提案されたのをまだ見たことがなく、当分は使われ続けるだろう。
ソフトウェアを作る仕事により近い。LeetCodeは実務からあまりに遠く、成績も実際の適性との相関が弱すぎる。
水漏れするバケツだが、会社は現状に満足しており、開発者たちはLeetCodeをやり込み続ける。すぐに変わるとは思えないが、新しい仕事を探すときにこうした面接を断れる状況にあるのは幸いだ。
友人が技術面接の途中で突然黙り込み、立ち上がって出ていったことがある。会社の人たちは「どうしたんですか、うまくやれていますよ！」と言って追いかけたが、あまりに気が滅入って、もう興味がないと言った。
ほとんどの人にとっては楽しい職業のはずなのに、悲しいことだ。
ところが面接の途中あたりでホワイトボードが出てきて、同僚たちが入ってきて、ペンで基本的なものを実装するよう求められたのだが、進むにつれてどんどん敵対的で無礼になり、儀式化された嫌がらせのように感じられた。技術的には些細な結果を出しながらも、侮辱と敵意に耐えられるかを試しているようで、結局面接を止めて「どのように働いているのか見えたので、ここで働きたいとは思わないと判断しました。機会には感謝しますし、お互いの時間を無駄にしてしまい申し訳ありません」と言って出てきた。CEOが駐車場まで追いかけてきて、なぜそうなったのかを尋ねたが、面接中に応募者が判断を下せるという事実に本当に衝撃を受けているようだった。仕事の面接は双方向だということを人々は忘れている。その日以降、自分が働くかもしれない会社のあらゆる面を見る権利があり、その過程で否定的なものを見たら妥協しなくてよいのだと悟った。翌日、競合他社で今でも良い友人であり同僚である人たちに出会ったので、正しい判断だった。この職業は楽しいが、その楽しさが農場のように収穫され搾取されるなら、他の奴隷化と何も変わらない。
「今日は私の日ではなさそうなので、面接をここで終えたいです」と言うと、そこから残り時間ずっと引き留めようとかなり頑張っていた。候補者が退出したいと言うなら、退出させるべきだと思う。
5年たった今でも、このような面接を拒否しており、二度とそのプロセスを経験したくない。人を1時間の蹴飛ばしゲームのように扱う人たちに嫌がらせや嘲笑を受け、もうこれ以上相手にしたくない
予告なしのLeetCode面接が多かったため、LinkedIn [1]とGitHub [2]のプロフィールに、何が許容され何が許容されないのかを明確に書いている。「面接中のあらゆる形態のライブコーディングやオンラインコーディングテストに反対する個人的なポリシーがあり、競技プログラミングを楽しんだり参加したりはしません。その代わり、合理的な目標と期限のあるオフラインのコーディング課題、ソフトウェアアーキテクチャや設計および関連技術についての深い技術的議論は喜んで行います。」
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
ただ、課題型面接では不正が蔓延しているという話があり、これを使おうとする雇用主の数が急激に減るのではないかと心配している
悪魔の代弁をすると、LeetCodeは平均的な個人貢献者の採用で、2つのうち一方または両方をふるい分けるために使われている。努力家か、つまり多くの問題を勉強し、解法を覚えて反復する人か。あるいは賢いか、つまりLeetCodeをやっていなくても基礎を理解し、過去の知識を組み合わせて新しい質問に答えられる人か
何の情報もなければ、LeetCodeの問題を通過できなかった人は、そのどちらでもない可能性が高いと見る。コーディングが必要な役割なら、LeetCodeの易しい〜中程度の問題を1問くらいは、面接官から多少方向づけを受けてでも解けるべきだと思う。実際、企業はよりシニアになったり、より特殊な役割に応募したりするほど、LeetCode能力の比重を下げる。バグ修正、システム設計、行動面接、課題、雑学的な質問、背景に特化した質問なども多く、初級以上の採用ではLeetCodeがすべてではない。最高のエンジニアを魔法のように選ぶ道具ではなく、採用委員会が使うもう1つのシグナルにすぎない
予算内で最後までやり切るエンジニアリング能力を見られていない。よく言っても周辺的な枝葉であり、悪く言えば19歳に近い人を好む年齢差別の代理指標だ。だからこの業界は質の高いソフトウェアを出すのにあれほど苦労しているのかもしれない。より良い方法は、壊れたビルドやクラッシュするコードのような失敗状況を与えて直させることだ。システムを探索し、欠陥を診断し、原因を見つけ、パッチを提案し、コーディングやコメントのスタイルを合わせられるなら、実際に必要な人材だ。ブランチとIssueトラッカーがあり、バグの議論がすでに進行中かもしれず、コメントに手動適用すべきパッチファイルがあるかもしれない。パッチに新しいバグがあったり、似ているが無関係な問題を触らせるおとりだったりするかもしれない。クローズ済みバグのリグレッションなのにユニットテストがないかもしれず、テストがあっても候補者が見つけなければならなかったり、テスト自体が古くバグだらけだったりするかもしれない。これが本当の仕事だ。終わってから「ユニットテストが壊れていました」と言うのと、「どう正しく実行するのか理解できなかったので飛ばしました」と言うのでは態度の差が大きく、チームプレイヤーは後者だ
だから逆に、現在の役割で優れた成果を出せていないが、余ったエネルギーをLeetCodeにつぎ込んだ候補者を得ることもあり得る
プロジェクトを数週間やるだけでも、賢い人は実際に必要な洞察を得られる。LeetCodeが投げてくる唐突なパズルは、昔の雑誌のクロスワードに近い
できる唯一の理由は、以前に勉強したことがあるからだ
2022年なら、LeetCodeが最高のエンジニアを選ぶ道具ではないことに同意しただろうが、2024年には、問題を正解しても十分に速くない、あるいはヒントなしでは解けなかったとして、より多く落とされる。私はLeetCodeの天才ではないし、勉強することも多すぎる。面接中のLeetCodeの比重は20%くらいだが、2年前よりそこまで悪くなったとは感じない。企業の期待値だけが天井知らずに上がり、15年以上の経験が必要な役割を5年目の給与で買おうとしている雰囲気だ
LeetCode式面接であまり言及されない興味深い点は、一種の知的な通過儀礼だということだ
入門儀式が過酷であるほど、その集団に入った人たちの献身が大きく高まることは何度も実証されている
資本主義の会社がプログラマーを採用するとき、「正解を信じる賢く似たような人たち」と「ランダムに混ざった熟練者たち」のどちらがより良いだろうか。後者だと答えるなら理想主義的であり、そのような意見は実際には重要ではない。自然は、より賢く現実的な人に置き換えるだろう
最近の何度かの面接では、候補者にサンプルコードを見せてレビューしてもらった。サンプルには各行に少なくとも1つのバグや問題が含まれている
その次はモデリング課題で、たいていホワイトボードで行う。ジュニアが本当にジュニアの役割を果たせるかを見るための fizzbuzz 的な簡単な演習もあり、実行時間の計算量やメモリ配置のような話題で会話を始める足がかりにもする。候補者の出来に応じて非常にインタラクティブに進め、どうにかスクリーニングを通過してきた偽物をふるい落とし、カルチャーフィットもある程度感じ取るのが目的
タイムゾーンや電話番号検証のような厄介な問題を作り、Wikipedia の記事を仕様として置く。終わったら解法を尋ね、コードレビューをする。最高のシニアは単にライブラリを使う。良い候補者は自作するが、トレードオフを説明できる。ジュニアはテストを通すだけで止まる
https://github.com/emilybache/GildedRose-Refactoring-Kata
候補者の好きな言語でやってもらい、非常に効果的なフィルターだった
理論はたくさん知っているように見えるのに、いざコードを書かせると惨憺たる結果になる開発者候補を面接したことがある。fizzbuzz も実装できず、Senior Java 開発者が調べずには HashMap を import できなかった
数学に似ている。562 * 1041 は電卓を使うのが正しいが、3 * 7 を知るために電卓を取り出すなら専門家なのか疑うことになる。多くの会社は LeetCode 面接をやりすぎているが、配列操作、フロー制御、基本的なデータ構造の使用を示すライブコーディング面接は、経験からしか生まれない筋肉記憶があるかを示す。通過するためにグラフ探索アルゴリズムを勉強しなければならないなら、おそらく LeetCode 的すぎる
だがプログラムにはそういう些細な要素がいくつも必要で、その世界観ではすべて暗記しなければならない。562 * 1041 は計算原理、つまりどうやるかは知っていると期待される。計算は間違えるかもしれないが、筆算の掛け算の考え方を間違えてはいけない。そういう文脈では、3 * 7 のような九九の一項目を忘れていても構わない。プログラマーは計算を組み立てる人であって、自分で計算する人ではなく、それはコンピュータがやる。グラフ探索アルゴリズムは解法をどこで探せばよいか分かっていればよく、すべての解法を手元に持っている必要はない、という点には同意する
どういう状況でこの人たちは手動で import しなければならなかったのか。IDE がなかったのか
面接官の固定観念を風刺したのか、よく分からない