非現実的なコーディング課題をやめてほしい
(blackentropy.bearblog.dev)- 一部の技術面接における非現実的なコーディング課題は、実務とは異なるプレッシャーのある状況を作り出し、開発者の実務能力を正しく測定できない
- 単独で行う高圧的な課題は、協業や支援のある職場環境を反映できず、ドキュメントやチームの助けなしに古いコードベースをデバッグするような流れになりがち
- 企業が言う「4時間の課題」も、会社調査、職務要件の確認、成果物の仕上げまで含めると8〜10時間以上に膨らむことがある
- 役割と関係のない技術スタックの課題は、適応力評価という名目を持つが、Ruby開発者にPHPのデバッグを求める方法は、実際の適性とずれる可能性がある
- 採用は恣意的で高圧的な課題よりも、関連技術、問題解決、協業、成長可能性に集中すべきであり、過度な課題は優秀な候補者を疲弊させ、遠ざけてしまう可能性がある
実務とかけ離れた面接課題
- 一部の技術面接では、開発者に数時間以内でのレガシーPHPのデバッグやミニアプリ制作のような課題を求める
- こうした単独課題は、実際の仕事の進め方とは異なる
- 業務では通常、チームと協業し、必要な支援を受けられる
- ドキュメントやチームの助けなしに、古いコードベースを一人で素早くデバッグする状況は、一般的な開発環境に合わない
- 企業はこれを「問題解決能力」の評価と見なすが、課題が役割の実際の要件と結びついていなければ、候補者の実務適性を見極めるのは難しい
隠れた時間コストと候補者の負担
- コーディング課題の推奨時間は、候補者が実際に使う時間を十分に反映していない
- 課題の前には会社を調べ、職務要件を確認する必要がある
- 提出物を良い状態に仕上げるため、プロジェクトを整える時間も必要になる
- 「4時間」の課題が8時間、10時間、あるいはそれ以上に膨らむことがある
- 仕事と生活を両立している開発者にとっては、まだ得ていない職のために無給労働をしているように感じられることがある
適応力評価が外れるポイント
- 関係のない技術スタックの課題は、「適応力」の評価として正当化されることもある
- Ruby開発者にPHPのデバッグを求めるやり方は、適応力の重要性とは別に、候補者の価値を判断する基準として不適切な場合がある
- 曖昧で無関係な課題を素早く処理する能力だけでは、実際の役割に合うかどうかを判断しにくい
- 一部の課題は、候補者の適性評価というより、企業の「エリート」基準を誇示する方法のように感じられることがある
- すべての採用で「上位1%」式のハードルを作ると、実際の業務をうまくこなせる熟練候補者も、人為的で高圧的な状況のために離脱する可能性がある
採用課題が評価すべきこと
- 採用プロセスは、役割に必要な具体的な技術を中心に設計されるべき
- 実際の業務要件と無関係なコーディングブートキャンプ式の課題は避けるべき
- 問題解決、協業、関連領域での成長可能性に焦点を当てるべき
- 適応力は、恣意的な課題をどれだけ速く処理するかではなく、長期的に学べる能力として評価すべき
1件のコメント
Hacker Newsの意見
最後に、ドキュメントもチームの助けもない古いコードベースをデバッグしたのはいつかって？ いつもそうだった。C++ 30〜40万行規模で、レガシーというのはテストがまったくないという意味で、ドキュメントもほとんどなく、小さな会社の唯一の開発者として何万人ものユーザーにサービスを提供し続けながら、バグを直して機能を追加していた
最近の例では、1年以上放置されていた中核機能のパッチがあり、元の作者はもういなかったので、コードを最初から書き直すか、masterに合わせてそのパッチを復活させる必要があった
プロジェクトに飛び込んで人々を目標へ導く能力は、シニア開発者にとって間違いなく必要なスキルであり、問題解決力をテストすべきだという結論には同意する。ただし技術面接の内容は役割によって変えるべきで、ジュニアのWeb開発者にホワイトボードでグラフアルゴリズムを問う必要はないが、ソーシャルネットワーク製品のシニア開発者やアーキテクトなら深く理解しているべきだ
先週は同じくコメントもドキュメントもない2020年製のGoコードをデバッグしたが、これもシステムの中核部分で、狂った人たちが書いたように見えた。つらい
問題を適切な層で解決するために下へ掘っていく意志は、シニアエンジニアを分ける大きなソフトスキルの一つだと思う。低い層のバグや欠けている機能を自分のコードで事後的な回避策としてごまかすのではなく、正しい層で直せば、システム全体はスタックの上下の変化や予期しない将来のユースケースに対してより堅牢になる
逆にこうしたアプローチを取らないと、シニアエンジニアが去ったりジュニアに置き換えられたりしたあと、コードベースは腐り始める。たとえば入力解析の境界ケースごとに、恐ろしく不透明なパーサの前へ素朴な検証用正規表現を一つずつ積み増し、パーサの文法そのものを直さないなら、コードベースは泥の塊へと進化していく
もちろん正しい層で修正すると、会社がスタック内で使っているエコシステムソフトウェアについて、些細な非公開の長期ホットフィックスブランチを維持しなければならないことが多い。アップストリームはたいていその問題を問題だと見なさないので、パッチを受け入れてくれず、自分たちだけで持ち続けることになる
冗談めかして言えば、GitHubプロフィールで認証して、こうした長期の非公開ホットフィックスブランチを作った回数や維持した回数を数えれば、エンジニアのシニオリティをコーディングテストよりずっと簡単に測れるかもしれない
現実で役に立たないと振る舞っても意味がない。現実は汚く、ドキュメントはしばしば存在しないか信用できず、元のコードを書いた人やチームはすでにいないかもしれない
ちょっとした逸話がある。友人の配偶者が今年初めに退職したあと、Big Tech各社ごとに4〜6週間ずつ面接準備をしていた。Metaに4〜6週間、Stripeに4〜6週間という具合に準備し、その合間に模擬面接も受けながら練習と筋肉記憶を積み、各社で出そうな問題を調べたうえでLeetCodeを毎日数時間ずつ解いていた
結果的にうまくいって、MAANGのL6/staffオファーを受諾した。ところが今週話してみると、まだ新しい役割を始めてもいないのに、練習していた細かな内容の大半はすでに忘れたと言っていた。システム設計の経験がなかったので、システム設計の準備がいちばん大変だったそうだが、今ではMAANGのstaff engになった。一緒に小さなプロジェクトをやってみた現実の姿は立派だったが、例外的にずば抜けたエンジニアというわけではなかった
本当に奇妙で、採用の好況・不況のサイクルをよく説明しているように思える。システム設計の面接準備動画を見ると、ほとんど台本のようだ。面接に入って台本どおりにやるだけでよく、実際に似たような、あるいはもっと複雑なシステムを設計したことがあるかは重要ではないように見える。システム設計面接の目的は、結局のところ「台本を知っているか」らしい
この2本の動画を2倍速で続けて見ると、どれほど台本どおりに進んでいるかに驚く: https://www.youtube.com/watch?v=4_qu1F9BXow, https://www.youtube.com/watch?v=_K-eupuDVEc
両親は2人とも1980〜90年代のSanta Cruzの技術業界にいて、当時は人材プールが大きくなかったので、開発者として育てられる人を見つけるための包摂的な道具だった。今の業界はその慣行を取り入れたが、正反対に排他的なものへ変えてしまった
私が採用した人の1人は物理学者だったが、専門用語をまったく知らず、初めてホワイトボード問題を見たときはおびえていた。安心できるところまで導くと、物理作業を助けるために作ったツールの話をし始めたのだが、開発の知識なしで作ったそのツールがソフトウェアだと伝えると驚いていた。それは本物のソフトウェアだっただけでなく非常に印象的で、ホワイトボード問題は潜在力を明らかにする道具だった
大企業が人の代わりにそのまま差し込めるウィジェットを欲しがるのは分かるが、本来は正反対の目的のために作られたものを使っているのが滑稽だ。こうしたコードチャレンジをやる格好いい会社に入る望みがないほど自分は年を取っていて、むしろよかったとさえ思う
どの大学を出たか、どんな授業を受けたか、どんな有利不利があったかに関係なく、その役割に必要な資質があれば数カ月で学べる内容だ、という理屈だ。技術が非常に標準化されているため、プロセスもかなり客観的になる
実務でその特定の技術を使うことを期待しているわけではない。むしろ、そうした種類の技術を学び、ストレスの大きい面接状況で高いレベルの成果を出せることを示すものだ。これは、あとで割り当てられるプロジェクトに必要な技術を学び、大きな締め切り圧力の中で遂行できるかを示す良いシグナルだ、という理屈である
このシステムを擁護しているわけではないが、その背後に明確な論理はある
本人は忘れたと言っているが、そのポジションを得たなら、おそらく中程度の難易度のLeetCode問題は解けたはずだ。すべて忘れたとまでは考えにくく、たいていの人がその場では解けないような簡単な問題も、依然として解ける可能性が高い。検索、ソート、配列やハッシュの参照、木やグラフの走査といった基本的なバックエンド作業の複雑度も、まだ分かっているはずだ
そして演技の才能は、プログラミングの才能よりも人口全体に広く存在するのかもしれない
最近、小規模スタートアップで比較的シニアなエンジニア職の面接プロセスを運用した。人によってより合う面接方式は違うと考えているので、全員に選択肢を用意した
課題テストへの怒りをよく見かけるので、3つの選択肢に均等に分かれると思っていたが、驚いたことに候補者の約**90〜95%**が課題テストを選んだ。自分が応募者でも好む方式なので興味深いデータではあったが、大半がそれを好んだのはかなり意外だった
対面面接は会社側にもかなりのコストがかかるので、自分の時間が無駄になる可能性は低いと見なせる。求職プロセスの非対称性はすでに大きくなっており、課題型はそれをさらに加速させる流れだ
以前、ある課題を最後までやらなかったことで非技術職の友人が今でも私を快く思っていないのだが、核心となる要件は明らかに些細だった一方で、指示が十分に曖昧だったため、提出してよいほど良い出来かどうか判断するのに何時間も費やせた。しかも、求められていたのは狭い技術スタックで、難しくはなくても、「技術人材が見つからない」と言う会社に、もしかしたら役立てる機会のために学びたいとは思わなかった
私は1と2を3より好むと思う。自分が解く問題を面接官が理解してこそ、自分のアプローチをよりよく評価できるからだ
自宅でやって後で提出する形なら、面接官は私の解法を自分のものや他の解法と比較しながら、同じ課題を基準に私のコーディングスタイルをよりよく把握できる
ペアリングで一緒に作業すれば、私の思考過程を見ることができるし、特定のイディオムを選んだ理由もよりうまく説明できる
過去のコードにはほとんど文脈がない。別のプロジェクトのために書かれたコードにすぎない。初期段階で履歴書と一緒に送り、実際にコードが書けることを確認する用途としては有用だが、その後の段階では、動くアプリがあって特定の機能のコードを案内できるときにだけ印象的だろう。だが、動くソフトウェアをそのまま持っている人がどれだけいるだろうか。普通は、いくつかの小手先でどうにか動いているコードがあるだけだ
私は2より1を好む。ミスをする確率が下がるからだ。現場で2時間、プレッシャーとマーフィーの法則で失敗するリスクを負うより、自宅であと2時間使って、分からないことを自由に調べる時間を持つほうが当然よいと思う
課題テストを評価する側にもいたことがあるが、それで誰かが強い印象を残すのがどれほど難しいか知っている
最後に実際のコーディング面接を受けたときは、どのプログラミング言語でも選べて、解く問題も3問の中から選べた。かなり気に入ったし、オファーももらった。時間制限のある面接でC++ではなくPythonを選べるのは、ほとんどチートのように感じられた
オンラインでコーディング面接への不満が増えるほど、ソフトウェア開発職の候補者をふるいにかける手段としてコーディング面接が絶対的に最良の方式だという確信が強まる。業界全体には口先だけの人、なりすまし、会議を設定する人が多すぎて、袖をまくってコードに飛び込み、実際に仕事を終わらせる人が足りない
この問題はレベルが上がるほどさらに深刻になる。いくら不満を言ってもよいが、快適なFAANGの年収50万ドルの仕事が当然のように与えられるわけではない。基本的なプログラミングを見直して for ループをいくつか書く気すらないなら、会社はただそれをやる人に流れるだけだ
面接が本当に袖をまくってコードに飛び込む力を試しているのなら、なぜ新卒で入った私が長くいる人たちにソフトウェアエンジニアリングやデバッグの慣行をあれほど多く説明しなければならないのか分からない
大企業で実際に働いたことがあるなら、本当の仕事の90%は5%以下の人がやっていると分かるはずだ。面接がきちんと機能しているなら、この比率はもっと良くなっているはずだ
Cracking the Coding Interview、Elements of Programming Interviews in Java/Python/その他の言語、LeetCodeと有料プレミアム購読サイト、模擬面接ブートキャンプまである。もはや実力ではなく、システムを攻略する問題に近い
コーディング面接が標準的な採用方式だという前提と、その結果がこれほどひどいという現実のあいだの認知的不協和がまったくないのが驚きだ
問題がLLMのトークナイゼーションのようなものだとしたら、「ML-LeetCode」問題でLLMの使用をどうやって禁止できるのだろう？
候補者がCursorとClaudeを巧みに使ってコーディングする専門家で、3つのプロンプトと簡単に見つかったエラー2つの修正だけで10分で解き、さらにNeurIPS級の論文とオープンソースコードまであるなら、私は偽の詐欺師をふるい落としたのか、それとも最上位候補を落としたのか？
LLMに関わる仕事をする人にLeetCode式の問題が意味を持つとは思わない。良くも悪くも、今後は快適なFAANG+の年収50万ドルの仕事のうち、ますます多くの部分がLLMに関わるようになるだろう
Ruby開発者に柔軟性のテストとしてPHPのデバッグをさせるのは、妥当なテストのように聞こえる。優秀な、特にシニア開発者ならそういうことができるべきだ。自分を「Ruby開発者」とだけ分類するのはキャリア上の罠だ
古いベンダー特化のDSLや、フレームワークと標準が古すぎてほとんど別言語になったようなコードをデバッグしなければならないことがある
バックポートされた機能のサポートを追加したり、古いクライアントやレガシースタックのセキュリティホールを塞いだりすることもある。大企業では、ずっと小さいパートナーのエスクローコードをこちらが引き受けることになったこともある
まともにデバッグできるよう環境を整える作業の方が、実際の修正より大仕事なことも多い。それでもシニア以上向けの良いテストではある
面接官が「この配列を逆順にしてください」と言ったので、私は「Pythonなら
array.reverse()かreversed(array)を使うし、JSにもそのどちらかはあるはずだから、たぶん.reverseメソッドだと思います」と答えた。面接官は「良い推測です」と言った本当に楽しかったし、いくつか学べた気がして終えられたし、相手も私が新しい問題をどう推論するかを見ることができた
ドキュメントもチームの助けもない古いコードベースをデバッグしたことは何度もある。作った人が誰も残っておらず、ドキュメントもないか見つからないシステムは実在する。だからこの例はあまり良くない。プログラムをデバッグしてリクエストの流れを追い、何が起きているかを見る能力は良いスキルだ
ただ、この例で本当にまずい点は、開発者を特定技術にハト小屋のように押し込めることだ。レガシーPHPアプリケーションがあると、Java、Python、Ruby、Goの開発者のうち、そうしたデバッグ能力はあるがPHPを知らないために遅い人たちをふるい落としてしまう。数か月PHPを触れば、より強い開発者になるかもしれないのに、だ
「4時間の課題」が、良い成果物を作るために8時間、10時間以上へ簡単に膨らむ点には同意する。提示時間は簡単にゲーム化できるので、時間がより多くある人の方が良い候補者に見えてしまう
ドキュメントもチームの助けもない古いコードベースをいつデバッグしたかって？ 今週毎日だ
ドキュメントについて言えば、コードは6月に最後に更新され、ドキュメントは2022年1月に最後に更新された
チームについて言えば、2年前のレイオフを免れた半分も、みんなもっと良い場所へ去っていった。もちろんこのプロジェクトを持っているチームはあるが、他の3つのプロジェクトも抱えていて、この1年でここに貢献したのは十数行ほど、そのうち11行は依存関係の更新だった
「Ruby開発者にPHPをデバッグさせるみたいだ」「職務に特定技術が必要ならその技術をテストしろ」というのは、コーディングチャレンジで落ちた人の言い分のように聞こえる
真面目な話、会社が採用慣行を単なる面白半分で導入することはまれだ。たいていは、その集団知が考えついた最善のやり方だ。彼らが解決しようとしている問題が何かを理解しようともせず、代案も示さずにやめろと言うのは生産的ではない
ソフトウェア開発では、他の職業の慣行を借りてくるよりも、車輪の再発明をしすぎていると思う。土木技師がソフトウェア開発者の半分の給料を得るためにどんな採用プロセスを経ているのか見て、それを我々の慣行に統合しよう。そうすれば皆が幸せな兵士になれるだろう
実際に何を達成しようとしているのかを内省した可能性はかなり低いと思う。単にみんながやっているから真似していて、誰かがどこかで意図を持って作った手順なのだと信じているだけだ
技術採用は道に迷いすぎていて、せいぜい局所最適に見える場所に落ち着いてしまった感じがする
コーディングテストをまったくしない会社で、とても悪い経験をしたことがある。面接2〜3回がすべてだった
問題は、データエンジニアリングチームで一緒に働き始めてから明らかになった。スタックの大半はHadoop, Kubernetes, Ruby, Pythonといくつかの技術に基づいていて、クラウドコンピューティングの基本理解も必要だった
ところが、業務経験や背景があまりにバラバラで、私は自分が採用された仕事をする代わりに、他の人たちの穴埋めをすることが多くなった。同僚の中には、Dockerを使ったPython CLIのパッケージングやHadoopジョブの点検といった基本作業すらできない人もいて、それを補うつなぎの作業をたくさんやることになった
結局辞めた。自分が特別だと思ったからではなく、同じレベルかそれ以上のレベルで採用された人たちを支えるのに時間の80%を使うことにうんざりしたからだ。その会社の採用慣行が非常に悪かったことは認めるが、何らかの形で基本的な技術テストは必要だ
もう一つ重要なのは、同じ人に同じことを繰り返し説明しなければならなかったのか、という点だ。知らないことは許容できるが、学ぼうとしないことは許容しがたい
課題型テストの厄介な点は、「X時間だけ使ってください」と言われても、より多くの時間を使うよう誘発するモラルハザードがあることです。会社に聞かれたとき、実際に使った時間について嘘をつく誘因も生まれます。
推奨時間内に収めることを重視しつつ、問題を適切に解いて課題を提出したことが何度もありますが、その後の面接で「なぜXは実装しなかったのですか？」と責められたことがあります。
その意味でも、過度にオープンな課題型テストは悪い課題です。自由時間が多く、より丁寧に取り組める人に有利だからです。最終成果物としてPowerPointのプレゼン資料を要求するデータサイエンスの課題型テストにもよろしく伝えてください。