面接で、答えられなかった
転職活動中の技術面接でのこと。Reactの関数について、次々と質問された。
「この関数は何をするものですか」「これとこれの違いは?」
答えられたものもあった。実務で何度も使った関数は、使いどころも、なぜそれを選ぶのかも、自分の言葉で話せた。
一方で、詰まったものもあった。名前は知っている。たぶん使ったこともある。でも「説明してください」と言われると、正確な挙動が出てこない。
面接が終わって調べたら、30秒でわかった。30秒でわかることを、面接では答えられなかった。この悔しさと一緒に、ひとつの疑問が残った。
——その関数、覚えとかないといけないの?
「調べればわかる」は、面接では通用しない
実務での私は、関数の細かい仕様を暗記していない。エディタの補完があり、公式ドキュメントがあり、今はAIに聞けば数秒で答えが返ってくる。6年やってきて、それで困ったことはほとんどない。
むしろ「うろ覚えの知識で書く」より「毎回ドキュメントを確認する」方が事故が少ない、とすら思っている。記憶は劣化するが、ドキュメントは(概ね)最新だからだ。
でも面接には、ドキュメントもAIもない。あるのは自分の頭だけ。普段「外部化」している知識が、その場では一切使えない。実務の戦い方と面接の戦い方が、根本的に違うのだ。
理不尽だと言いたくなる。実務で通用しているのに、なぜ暗記テストで測られるのか——と。
でも、面接官の側に立つとわかること
一晩寝て冷静になってから、面接官の意図を考えてみた。
面接官は、たぶん暗記力を測りたいわけではない。「その技術をどれだけ使い込んだか」を、短時間で推定したいのだ。
そして意地悪な話だが、この推定はけっこう当たる。本当に使い込んだ関数は、忘れない。仕様を暗記したからではなく、ハマって、調べて、直した経験が記憶に焼き付いているからだ。逆に「なんとなくコピペで動かしてきた」関数は、名前は知っていても説明できない。
つまり面接官が見ているのは知識そのものではなく、知識の裏にある経験の質だ。「説明できない」は「暗記していない」ではなく「経験が浅い」のシグナルとして受け取られる。ここに気づいたとき、悔しさの質が変わった。私が詰まった関数は、たしかに「雰囲気で使ってきた」ものだった。
全部覚える容量は、ない。だから層で分ける
とはいえ、Reactの関数をすべて説明できるように暗記するのは無理だし、無意味だ。私の脳の容量は有限で、そこには仕事の知識も、家族の予定も入っている。
だから、覚える対象を3つの層に分けることにした。
第1層:自分の言葉で「なぜ」まで語れるべきもの
実務で日常的に使うコア。ここは暗記ではなく、理解して語れる状態にする。「何をするか」だけでなく「なぜそれを選ぶのか」「使わないとどうなるか」まで。面接で聞かれるのは、ほぼこの層だ。
第2層:存在と使いどころだけ知っていればいいもの
たまにしか使わない関数。「こういう場面で使うやつ」という索引だけ頭に置いて、詳細は使うときに調べる。面接で聞かれたら「使ったことはありますが、正確な仕様はドキュメントを確認しながら書きます」と正直に言っていい層。
第3層:調べればいいもの
ニッチなAPI。覚えない。忘れることに罪悪感を持たない。
重要なのは、第1層を「暗記」で作らないことだ。第1層は、使った経験を言語化することで作る。具体的には、実務で使った関数について「なぜこれを使ったのか」を自分に問い直してみる。答えられなければ、それは第1層のフリをした第2層だ——今回の私のように。
面接対策は「暗記」ではなく「経験の棚卸し」
この整理に立つと、面接対策の正体も変わってくる。関数リファレンスを頭から暗記するのではなく、自分が書いてきたコードを振り返って、選択の理由を言語化し直すこと。それが最も効率のいい準備だ。
暗記した知識は面接が終われば消えるが、言語化した経験は次の設計にも活きる。どうせ時間を使うなら、後者がいい。
おわりに
「その関数、覚えとかないといけないの?」
面接直後の私の答えは「調べればわかるんだから、覚えなくていいだろ」だった。いまの答えは少し違う。
全部は覚えなくていい。でも、自分が使ったものについては「なぜ」を語れないといけない。 それは暗記の問題ではなく、経験をちゃんと消化してきたかの問題だから。
説明に詰まったあの関数は、もう忘れない。仕様を暗記したからではない。面接で詰まって、悔しくて、調べて、こうして記事まで書いたからだ。
……結局、いちばん記憶に焼き付くのは、ハマった経験なのだった。
転職は無事終了しましたが、同じように面接で詰まった経験のある方、コメントで供養しましょう。