通勤中でもなく お風呂の中でもなく 寝る直前のベッドの中でもない閃き

結論：

久しぶりに実行時間というのを気にしながらコードを書いてみてやっぱり問題を解くためのコードって最高に面白いなって思った。

お話：

プログラマ（もといソフトウェアエンジニア）としてお仕事で書くコードは雑に言えばテストが通ってプロダクション環境で十分早ければわりとOKなことが多い。

後々「そう言えばあそこもっと高速化できるな」などと思っても、コードが既にコミットされている場合Issueやバグをファイルして『後でやる』リストに入るだけということが多い。

それとは違ってプログラミングコンテストやテクニカル面接などで要求されるのは制限時間内に最適解を見つけること。本当の最適解なのか時間制限を鑑みて適切な答えなのかはそこまで重要ではなく、面接官や審査員が「最適」と考えるものを提出できないといけない。

最近ウェブ上のコーディング試験を受けてこれと対峙した。

かんたんにルールを説明すると。コードは何度も”テスト”可能で、このテストはソースをコンパイル（ビルド）し自分が定義したテストインプットと向こうが用意したいくつかのインプットを走らせる。必ずしもそのテストインプットは見えない。そして結果が表示される。それとはべつに”提出”すると、結果は見えないが、さらに多くのテストが走る。一度提出してしまえばもうコードはいじれない。という感じ。

まずO(N^3)のコードをテストする。おそすぎるというお達し。

↓

O(N^2)にするのに成功。

結論から言えば、ここで思考停止してしまったのが悪かった。O(N^2)で十分早いんだなという錯覚に陥った。６０分中残り３０分も余ってたので適当にコメントでも入れて自分のロジックがあってるか確認して提出。

提出した直後は「楽勝だな」とるんるんだった。るんるんでピアノの練習をした。

プログラマにとってもっとも閃きが起きやすいシチュエーショントップ３が「通勤、お風呂（シャワー）、寝る直前のベッドの中」なんてジョークがあるぐらい、特に何も考えなくていい時間でなおかつメモを取りづらい状況で閃きが起きる。

答えを提出して数時間後、食事を作ってるときに「そういえば、ああいうのって絶対早い最適解があるんだろうな」とふとおもった瞬間に線形時間の解が頭に浮かんだ。

もう悔しい。すぐに実装を初めて20分でできあがって悔しい。O(N)で実行できるのは明らかだし自分で書いたテストも通る。悔しい。20分でできてしまったのも悔しい。30分も余ってたならできるじゃん！さらにもし今の会社で自分が面接官としてこの問題をだしたなら、自分の提出した答えでは受からないだろうということがわかっているのでなおさら悔しい。

課題を提出したあとに「あれもっとうまくできるじゃん」ってことが学生のころは度々あったけどアレよりもっと悔しい。学生のころは「成績に若干響くかもしれないけど他の課題もあるししゃーない」で済ませられた。今回はそうでもない。ずっと悔しがっていられる！ふしぎ！！

でもやっぱり自分はこういうのが好きだなってのが再認識できた、やっぱりアルゴリズムって面白いなって。あとこれに限っては『最適解がある』という状況が楽しい。一種のパズルを解いているような気持ちになる。でも今回はルービックキューブの1面だけ色を揃えたのに満足してしまって、他の面を見ることさえ忘れていたようなもやもやが残ってる。でもパズル楽しい！

そんな、比較的涼しい夏の日の出来事でした。

P.S.

コーディングのテクニカル面接だけを受けて食っていけないかなってちょっと思ったけどそういうビジネスモデルはないのだろうか。