うん、そうでもあり、そうでもないかな。こういう質問を面接でしたことがあるけど、候補者が制約ソルバーを使おうとしたらプラスだと思う。実際のソフトウェアエンジニアリングでは全然使われてないから、これを使うことで候補者が時間を無駄にせずに正しい答えを早く得られるってことが分かる。もし制約ソルバーで答えたら、実際にコーディングできるか確認するために、ホワイトボードでフォローアップの質問をするかもしれないけど、制約ソルバーを答えとして出すのは全然悪くないよ。

これだね。NPのすべての問題は制約問題として表現できる。ソルバーが正しい解決策かどうかはアプリケーションによって大きく変わるし、面接ではほぼ定義上正しい解決策ではない。単純な動的プログラムと比べると、制約ソルバーはひどく遅いこともあるし、たいていそうだよ。

誰かが制約ソルバーを使ってLeetCodeの難しい問題を解いたのに、あなたがその人を雇わなかったら、マジでバカだよ。世の中で制約ソルバーが何か知ってる人がどれだけ少ないか、わかる？それを正しく問題に定義することができる人なんて、さらに少ないんだから。俺も大学の3年生の時に宿題で制約ソルバーを使ったことがあるけど、制約を書くのが本当に大変だった！

あなたの言う通りだけど、それがこの面接アプローチの根本的なバカバカしさを示してるよね。実際のエンジニアリングの状況では、これらの問題を100%解決できる。だって、コーヒーを飲んだり、論文を読んだり、教科書を見たり、緑の場所を散歩して考えたり、制約ソルバーみたいなツールを使ったりできるから。でも面接では、こういう問題を0%解決できる。俺の頭はそういう風には働かないから。少なくとも、そう思ってる。LeetCodeの面接を受けることは考えたこともないんだ。

これはいくつかの面接では当てはまるけど、全てではないよ。僕は一般的に面接でのleetcodeの使用には反対なんだけど、使われるところを見たときは、たいてい一つの理由だけなんだ。それは、機能不全な採用プロセスが知られているから。こういうプロセスでは、採用プロセスの参加者がその機能不全を認識しているけど、力がなかったり、もっと多くの場合は、適切にプロセスを改革するための組織が整っていないんだ。時には、半技術的なディレクターがHRを利用して、広範囲なチームで同じ質問をすることで面接技術を「標準化」しようとすることもある。他の時は、リソースが不足している小さなチームが急いでオンラインリソースから面接質問を集めていることもある。こういう場合、leetcode面接に賛成しない技術面接官とやり取りする可能性が高くて、標準化された面接スコアリングアプローチを「回避」して、革新的な候補者を見つけようとしているんだ。多くの場合、ソルバーに興味を示したり、少しでも知識があることが、君にとって大きなプラスになると思うよ。

重要なのは、あなたが一般的なパターンを磨くためにどれだけ時間をかけたか、そしてコミュニケーション能力を試すことだよ。

「これらの問題のポイントは、あなたの賢さを試すことだ。」 いや、それは12個くらいの特定のパターンを暗記するだけだよ。リスクが高すぎて、ほとんどの人は自分の問題解決能力を賭けることはない。LeetCodeは完全にゲーム化されてしまって、準備する意欲以外の差別化の役割を失ってしまった。

問題解決の問題で面接をする時、候補者がどう考え、コミュニケーションし、問題を分解するかを理解するのが目的だよ。重要なのは、問題解決の質問には難易度や複雑さを段階的に上げたり下げたりする方法があって、全ての候補者が「勝ち」を得られるようにしないといけない。そうしないと、誰も「ダンクシュート」を決められない。面接官は、瞬時のひらめきからは何も学べないし、誰かが詰まってしまうことからもほとんど何も学べない。残念ながら、これがいいものを持てない理由なんだ。面接での問題解決の質問は非常に有用なツールになり得るけど、悲しいことに、あまりうまく使われていないんだよね。

これらの問題の目的は、あなたの賢さを試すことだよ。前回Metaで受けたときは、特定の問題セットを何度も繰り返し解かせて、考えずに再現できるかを試すためだった。面接官がいつも驚くのは、LeetCodeや彼らが勉強した面接ガイドのテキストブックアプローチ以外の答えを出すからだよ。賢さは、彼らが求めているもののリストにはあまり入ってないね。

これらの問題の目的は、あなたの賢さを試すことだよ。俺の経験では、面接官はLeetCodeの「トップインタビュー150」リストに行って、「配列」と「文字列」カテゴリーの問題を使うのが好きだね。俺が受けた仕事（主にバックエンドのPython）には、こういう問題はあまり好きじゃない。ほとんどが「この配列に対してO(n)のランタイム、O(1)のメモリアルゴリズムを教えて」っていう挑戦で、日常の仕事とは全然似てないから。Pythonではインプレースの配列アルゴリズムをあまりやらないんだ。そういう問題は、パフォーマンスが重要な他の言語（CやRustなど）でほとんど処理されるからね。PythonやJavaScriptなどの言語で面接をするなら、「ハッシュマップ」セクションに行ってほしいな。そっちの方が賢さよりも、適切なツールを使って問題を解決できるかどうかに重点が置かれてるから。難易度の調整にも問題があるし、問題169（過半数要素）がO(n)のランタイム、O(1)のメモリ解法で「簡単」とされてるのは、俺には笑える。1981年に最初に説明されたアルゴリズム（ボイヤー–ムーア過半数投票アルゴリズム）にはウィキペディアのページもあるし、実装や理解は難しくないけど、その正しさは考えないとわからない。そうなると、ウィキペディアに載るような「賢さ」を持ってるってことだよね。これが「簡単」な問題だなんて、ちょっと過剰だと思う。