就活

2次で落ちた会社のフォロー面談を受けた。メモを取っていたので、その内容を振り返ってみる。 いきなり話題がそれるけど、落ちた人に対してフォロー面談をしてくれる企業の目的ってなんなんだろうな？ 落ちて落ち込んでいる人を相手にするのってただでさえシンドそうだし、何十人かに一人は感情的に食ってかかる人もいるんじゃないかな？ 担当者のメンタルは結構キツそう。 ただ、落ちた身からするとフィードバックがもらえるのはめちゃくちゃありがたい。 「手応えあったのになんで落ちたんだろう？」みたいなことって割とあるし、そういうときに落ちた理由を知ることができたらめちゃくちゃ成長できると思う。今回の面談も学びが多かったので本当に感謝してる。 フィードバック 良いところ 実装の一つ一つは特に問題なし 悪いところ WikiやREADME.mdを書いていない 環境変数に対するコメントがない 保守性の観点で微妙なところがある 前職はフロントエンドもバックエンドもインフラも全部一人でやるみたいな環境だったから、こういうチームで働く上での当たり前の部分が全然身についてないんだよな。 一応Notionとかにドキュメントを書いたりはしてたんだけど、「コードを書いたら即ドキュメント」みたいな感じではなかったんだよな。 仕事が一段落して余裕のあるときに、「いけね、ドキュメント書かなきゃ！」って感じ。 今回はコーディング試験で落ちたんだけど、仕事でもドキュメント書けない人間がコーディング試験でドキュメントを書こうなんて発想になるわけないよな。これは反省だわ。 こっちからの質問1. どうすれば保守性の高いコードを書けますか？ 担当者Aさん「弊社ではオニオンアーキテクチャを採用しています。アーキテクチャに関する知識を身につけると良いかもしれないです。あとは依存性の少ないコードを意識するのも大事です。」 担当者Bさん「会社のフェーズによって保守性を大事にするかどうかって全然違います。弊社では保守性を意識するフェーズに入っていますが、そうでない会社もたくさんあります。座学で保守性を学ぶこともできますが、保守性を意識している会社に身を置かないと経験できないこともたくさんあるので、そこら辺を就活の軸にするのも良いかもしれないです。」 自分でも保守性の高いコードは書けていないんだろうなという自覚はあった。 デザインパターンみたいなのも全然知らない。ここらへんは座学すべきかな。 「保守性を意識している会社に身を置かないと経験できないこともたくさんある」って言葉はかなり響いた。今までがむしゃらに座学中心で勉強をしてきたけど、実務で経験しないと成長しない部分ってあるよなあ。 こっちからの質問2. クッキー認証の実装が自信なかったんですけど、どうでしたか？ 担当者Aさん「特に問題があるというコメントはないので大丈夫だと思います。」 やったぜ。今回のコーディング試験では仕様上クッキー認証を使う必要があったんだけど、前職ではlocalStorageにJWTを保存する認証しかやってなかったから不安が大きかった。 結構クッキー認証について調べてから実装したんだけど、特にレビューがつかなかったみたいなので嬉しい。 こっちからの質問3. テストを書こうと思ったんですが認証の部分が難しくて書きませんでした。書いたほうが評価は良かったですか？ 担当者Aさん「細かく統計を取ったわけではないですが、合格する人の多くはテストを書いている印象です。認証の部分を乗り越えるためにはE2Eのフレームワークを使ったりするなどの工夫が必要かもしれないですね。認証部分は無理でもユニットテストだけ書く方も結構いますね。」 担当者Bさん「さっき申し上げた環境変数のコメントを書いてないとかにも通じるところがあるんですけど、それぞれの会社に宗教があるので分からなかったら担当者に聞いたほうが良いと思います。ある会社ではGOODとされてたことが、ある会社ではBADと評価されるってことはよくあるので、そこは担当者とコミュニケーションを取りながら探っていくのが良いと思います。自分も聞かずに面接で落とされた経験があるので、それ以来ちゃんと聞くようにしています。」 いやー、Bさんの言葉が響いたね。 俺の場合「聞きたいけど勇気が出なくて聞けない！」とかじゃなくて、そもそも聞くという発想にすら至らない。どんだけコミュニケーション力低いんだよ！ 「聞いたほうが良いですよ」と言われて、思わず「おっしゃる通りです」と返答してしまった。 まあ、これに関しては前職でなんでもかんでも自分でやりまくっていたというのも大きいかな。壁にぶつかったら自力で乗り越えるっていうのが当たり前になっていたから、他人に聞くとか他人に頼るみたいな発想がコマンドの1ページ目に出てこないんだよな。 一応SIerに就職が決まっているんだけど、SIerは顧客折衝が大事な仕事だからコミュニケーション能力の低さは改善しなきゃだな。 担当者から最後の一言 担当者Aさん「個人的な印象では〇〇さんは勉強熱心でやる気もあって非常に好印象でした。技術に前のめりで向き合う姿勢も良いと思います。再チャレンジする機会があったらぜひ再チャレンジしてみてください。」 お世辞も入っているのかもしれないけど素直に嬉しい。 今回のフィードバックをもとにもっと成長していこうー！！

技術面接でクイズを出されてボコボコにされた。もちろん落ちた。 ボコボコにされたあと、「次に同じ機会があれば答えられるようにしないと！」と思って急いでクイズの内容をメモした。そのメモを見ながら面接の内容を振り返ってみる。 1. GETとPOSTの違いを説明してください。 自分: GETはリソースの取得に使い、POSTはリソースの作成に使います。 面接官: 内部的にはどう違いますか？ 自分: え…！？メソッド名が違うとかそういうことですか？ 面接官: あ、分からないなら分からないでいいですよ。 自分: すみません…。分かりません…。 ググった感じ、「内部的にはどう違いますか？」という質問に関しては、「GETはクエリパラメータにデータが含まれるのに対して、POSTはリクエストボディにデータが含まれる」的なことを答えれば良かったと推測される。 でも、それって内部的な違いって言うかな？内部的な違いと言われると、エンジニアが直接触れることのない部分での違いを問われているように感じる。 クエリパラメータとリクエストボディって割と意識的に操作していない？ 「データの渡し方の違いはどうですか？」と深堀りされていたら普通に答えられていたので、ぶっちゃけ面接官の深掘りの仕方も良くなかった気がする。 まあ、このあとにも答えられなかった質問がいくつかあるので、これに答えたところで結果は変わらないと思うけどな！ 2. N + 1問題とはなんですか？ 自分: あのー、なんかORMとかを使っているときにテーブルを結合したりするとSELECT文が大量に発行される的なやつだと思うんですが…。すみません、詳しいことは分かっていません。 やらかし。完全に忘れていて答えられなかった。 N + 1問題はテーブル結合とは関係なく発生するので的外れ。 なんで自分がN + 1問題を忘れてしまっていたのかを振り返ってみたけど、おそらく自分の脳内ではN + 1問題が なんかSELECT文が大量に発行されるやつ(超ざっくりとした概要) railsならとりあえずbulletを入れとけば大丈夫(解決策) の2つに極端に抽象化されてしまっていた。 実務では概要と解決策の2つさえ抑えておけば具体的な内容を理解していなくてもなんとかなることが多いけど、でもこれって本質を理解してないってことでもあるよな。 超反省です。 3. DBで片方のテーブルにしかない情報を取得するときに使うのはINNER JOINですか？OUTER JOINですか？ 自分: OUTER JOINです。 これは自信を持って回答できたやつ。 前職で大量に生のSQLを書いていたので、SQLのクイズに関しては大体のことに答えられる自信がある。 その分ORMの知識がおざなりになってしまったんですが…。 4. Fizz Buzzを書いてください。 これも自信を持って回答できたやつ。Pythonで書いた。AtCoderのおかげです。 5. セッションとクッキーの違いはなんですか？ 自分: セッションはサーバ側にデータを保存するのに対して、クッキーはクライアント側にデータを保存します。クッキーはサーバへのリクエスト時に自動で送信されるようになっているので、サーバ側のセッションと突き合わせることで認証などを行うことができます。 前半は良いんだけど、後半はセッションとクッキーの違いじゃなくて認証の話してるよな。 回答した直後に「あれなんか途中からズレたな？」って気づいた。 結局セッションとクッキーの違いを明確に理解してないから、なるべく自分の知っている知識に持っていこうとして回答がおかしくなってしまうんだろうな。 これも反省だな。 6. SQLインジェクションとはなんですか？ 7. XSSとはなんですか？ この2つは正しく回答できたと思うけど、なんかグダグダ説明しすぎた。もっと短文でパッと答えるべきだった。 8. CSRFとはなんですか？ 自分: 罠サイトの中に攻撃対象のサイトをめっちゃ小さいiframeで埋め込んでクッキーとかを盗むやつです。 ...