フィードバックの重要性
こんにちは、シニアソフトウェアエンジニアのriddleです。
こんにちは、ミドルソフトウェアエンジニアのひびのです。
今回は前回、前々回と2回にわたってお届けした、ほうれん草ボンバーさんとのコラボ回がありましたね。
今回はですね、ドキドキしますね。フィードバック回!フィードバックですよ。
僕、新卒の頃は何社か受けたんですけど、フィードバック、真面目にされたことほとんどない。
強いて言うなら、2社だけ、僕その頃学生の根性で、不合格通知を受け取りました。
食い下がって、すみません、もし良ければフィードバックくださいみたいな、ただでは起き上がらない精神で。
で、僕2社受け取って、その2社は両方ともめちゃめちゃ良い会社だなと今でも思ってます。
そうっすよね。もらうと嬉しいですよね。
でもドキドキですね。
ということで、先にほうれん草ボンバーさん、やってみてどうでしたか?全体として。
いやー、初めにも言ったんですけど、本番の面接よりも全然緊張しますね、本当に。
DeFiプロジェクトの経験
自分の音声がこの後もこれ残るんだと思いながら。
いやー、そうですよね。
おかえりします。大丈夫ですか。
途中なんか頭真っ白になった瞬間とかありました。
え、これどう答えればいいんだと思いながら。
ちなみにそれってどの辺ですか?
えっと、結構技術的に深い話を日比野さんがした時に、結構もう1年前の記憶とかだから、あれ、これどうだったっけなと、あやふやな状態で答えないといけなかった時に。
チュース担当の採用理由とか。
そうですね。
インフォとかそういうやつですかね。
そうですね。そこら辺で。
ありがとうございます。
頭が一旦真っ白になりました。
あるあるっすね。
あれ、ありますね。想定していないとか、うまく答えられるはずだけど、いや出てこないみたいな時なんだろう、頭真っ白になっちゃいますよね。
はい、そうなんです。
ちょっと自分から最初に、前半でいろいろお伺いした経歴とか、実際にやってる仕事の内容とかからちょっとフィードバックなんですけれども、こうした方がもっといいんじゃないかなみたいな話を言うと、
今直近でやられているDeFiの案件の話をしていただいて、その中で認証認可のところとUIXのところ、あとダッシュボード生成のところを作っているという話があったんですけれども、
いろいろと内容を聞いていくと、認証認可のところは最終的に社内のインフラの他の方に頼って作ってもらいましたみたいなところで、
その中で結局、じゃあ何ができなかったのか、問題だったのか、みたいなところとかの解像度がまだ残念に高くないかなというふうに思っていて、
かつ今回自分が掘り下げたのもあるんですけど、フロントエンドエンジニア的なところをPRする面接でもあるので、違うエピソードを語った方がまずいいのかなと思いました。
そうですね、おっしゃる通り。僕も。
僕らもDeFiについて深掘りしちゃったところは申し訳ないなと思ってるんですけど、
フォーレンソーボンバーさんは今の案件の他にもいくつか案件を過去担当されていたはずで、もう少しフロントエンドエンジニアとしての経験の幅が引き出せると、もっとよかったのかなと思います。
そうですね、ぱっと思いついたのが直近の案件で、
もっと別の大きなデジタル庁の案件とかも入っていたので、そこっちの話を広げた方が面白くなったなって、ちょっと反省します。
面白いというのもそうなんですけど、自分のPRに繋がるとか、あとその案件のイメージが面接官側に一発で伝わらないと、
その案件の内容を説明するのに会話が2,3往復すると、面接時間がその分少なくなっちゃうので、自分をPRする時間が減っちゃうじゃないですか。なんでそういう意味ではもったいないかなっていう感じですね。
技術的な質問と答え
そうですね。
そういう意味では、UXの向上をこっちが掘ればよかったんですけど、Defiの方がちょっとキャッチーすぎて飛びつきたくなっちゃったっていう。
面接官側もよくなかったんですけど、フックがそっちの方が強かった。
逆にあれですよね、Defiっていう具体的な文言は触れずに、AIツールのフロントエンドみたいな感じで、フロントエンドメインで自分から話しに行くとかがいいかもしれないですね。
そうですね。なんか自分が一番フロントエンドで頑張ったみたいなエピソードのところを中心に話せばよかったなと思いますね。
あと頑張ったやつで言うと、認証認可のやつはもう言わない方がいいですね、これは。
いや結構認証認可って本当大変だと思っていて、それこそ最近はパスキーの話もありますし、パスキーじゃなかったとしてもOIDCとか、
OOSみたいな話だったり、いろいろあったりして複雑ってことは理解してるので、それをやったってことはこれぐらいは理解してるだろうみたいなことを結構、
面接官側が勝手に思ってしまうので、あそこからの結局こうなりましたっていうところの落差が大きいと結構ネガティブな印象をやっぱり与えてしまうので、
大変だったと思うんですけど、別のエピソードで勝負した方がこれに関してはいいかなと思いますね。
そうですね。
正直答えちゃいすぎましたね、本当に。いやーあの時しんどかったなっていう苦労が思わずエピソードとして話したくなっちゃいましたね。
そうなんですよね。だからそこの辺はちょっとうまくね、どれ自分の武器にして持っていくのかみたいなところはチョイスしていくといいかなと思います。
一方でいいかな、いいなと思ったのは、結構企画段階、要するに立ち上げの段階から入っているっていうところはすごい良い経験をされているかなと思っていて、
かつ結構そのSESで特に入られると、実際上の方は何やってるか知らないとか、企画チームは何やってるか知らないけど、与えられたタスクを淡々とこなしていくみたいなことも多い中で、
どういう人向けに何のために作ってて、どういうフェーズでどういう感じでその収益を上げていこうかみたいなところまで理解されているのはすごいいいポイントだなというふうに思いました。
ひびおさん、技術的なところのチェックで質問した内容についてはどうでしたか。
そうですね、個人的には、ツースタンドと個人開発で使われていたユーズコンテクスト、技術選定メインに質問させていただいたんですけど、
個人的にはもう少し深掘りというか、今の技術選定の反省苦労具合が聞けると良かったかなと思います。
そうですね、ちなみにフロントエンド領域の中でいうと、この辺がフロントエンドでも特に自分の得意分野とか武器とかそういうのってありますか。
ミドルウェアというか、ソフトウェアでも良いですし、レイヤーというか、最適化が得意ですとか、UIが得意ですとか色々あると思うんですけど、それって今の自分の中でこの辺かなっていう推しポイントありますか。
推しポイントは、ネクストJSをずっと3年間ぐらい使い続けているので、ネクストJSにおけるデータフェッチングのところとあとレンダリング戦略のところは自分の強みですね。
なるほどなるほど、そうか。
そうなると、自分はフロントエンド専任じゃないんであんま分かんないんですけど、途中で複数のAPIを束ねる話が出たじゃないですか。ソフトウェアの名前忘れましたけど。
SWRです。
UseSWRの話を聞いた際に、自分からするとクライアントが勝手にAPIのデータをキャッシングして、バックエンドの知らないところでそれを最新のようにユーザーに見せる行為は割と危険だなって勝手に思っちゃうんですけど、
そこに対してどういうふうにコントロールするのかとか、どのレベルでAPIを束ねるのかみたいなところは、割とセンシティブな話なのかなって勝手に思ってしまったので、
さっきの得意分野の話からすると、そこは得意範疇なので、もうちょっと回答がもらえると嬉しかったかなっていうのは今聞いて思いましたね。
違いますか?これデータフェッチングの話じゃないですか?違います?また別ですか?
データフェッチングの話は、データフェッチング、キャッシュ戦略、ネクストジェネスのアップデータ周りの割と重要な話かなと思います。
じゃあ、システム設計に行きます?
ホワイトレスのボーガンさん的にはシステム設計の面接みたいなのがやられたことありました?
いや、初めて受けました。初めて受けて、やっぱり一番の心配はリスナーの人どう思ってるのかなと思いながら走ってました。
しかもフロントエンドやってない人だとマジで意味わからんから。
確かに。
フックスペなんだ。
フックスペなんだとか、あとは実際に見返すと変数名もたくさん出てきましたもんね。
はい。
技術選定とシステム設計
これはちょっと画像をPodcastのURLに添付して、ユーザーさんが気になったらこのURLをタップして見てくれるだろうという感じですかね。
そうだな。
本当にユーザーさんの頭の中でどういう絵が思い浮かべているのかすごく気になりますよ。全然違う絵が思い浮かんでるじゃないか。
なるほど、なるほど。そうです。
でもなんか結構初めての人は普通になんか質問に対して的確にというか回答されていて、なんか本当は初めてなのかなと個人的に思いましたけどね。見てて。
これはあれですね、技術選定の段階でメンバーの方とこういう設計でいこうよみたいな話をしたとき同じような説明しながら会話してたので、その時の技術選定のミーティングのイメージで話しましたね。
なるほど、なるほど。いいですね、そういう経験が生きてるの。
僕としてもシステム設計面接、僕は1回しか受けたことがなくて、初めてでしっかり受け答えできてるのはグッドポイントかなと思いました。
そうだな。いいところから言うと、最後の方でいいねボタンの設計があったと思うんですけど、なんというか技術的な言葉で言うと楽観的な更新かな。
最初に画面の状態を変えて、その後にAPIリクエストを送るみたいなのはユーザー体験を既存しない上で重要かなと思っていて、そこがナチュラルに出てきたのはいいポイントかなと思いました。
個人的にもったいないなって思ったのは、やっぱりアイテムがたくさんレンダリングされたときにどう最適化されるかの部分で、
個人的に用意してた質問としては、Webフロントエンドでウィンドー化みたいな戦略があって、何かと言うと、今表示されてないドムを一時的にドムツリーから外すみたいなことができるんですね。
実際にそれをナチュラルにサポートしているライブラリー、なんならもうそれの中でページングもできてしまうみたいなものがあって、そういう技術が1回で出てくるとオッてなるポイントかなとは、特にNiddleのフロントエンドエンジニアだと。
とはいえ、いろいろ画像の最適化を行うだったりとか、あとはデータ更新のレンダリング、いわゆるリアクトのコンポーネントのレンダリングをなるべく少なくするみたいなところは、すごく基本的なところではありつつも、そこが抑えられているのはなかなかいいポイントかなと思いました。
こんな感じですかね。ちなみにNiddleさんはシステム設計演説で何か気になったところとかありますか。
そうですね、フロントは全般的によくわからなかったんで、最後にした質問に限るんですけれども、最初は新しくユーザーが投稿したメッセージを他のユーザーがそれを入手してページに描画したいみたいな話、よくあるSNSの仕組みだと思うんですけれども、
あそこの回答の際にですね、5秒に1回ぐらい定期的に通信しに行くみたいなところの話をした。
いわゆるポーリングってやつですね。
そうですね、ポーリングのところで、回答としてはフォールループでスリープ入れて5秒に1回叩きに行くみたいなところだったんですけども、結構新規にフェッチを行うっていうのが、フロントエンド時にもサーバーされる時にもそれなりのコストが高いかなと思っていて、
結構利用される技術として、ロングポーリングって呼ばれる、ずっとセッションを張っておいて定期的に取りに行くみたいな仕組みだったりだとか、最近はMCPの文脈でも使われますけど、正式名称忘れた、SSなのか。
サーバーサイドイベント、SSEかな。
サーバーサイドイベントとかでサーバー側から特定のイベントを投げるみたいな、でクライアント側がそれをフックして追加するみたいなことがあったりとか、それこそWebSocketみたいな双方向の通信を張っておいて、ストリームで送るみたいな。
他にもGRPCのストリームとかいろいろありますけど、ちょっとなんかいろいろ方法があるので、それはどれがいいのかっていうのは、フロントとバックエンドとインフラの状況にもよりますけど、あるので、そういうところが回答の中で出てきて、今回は特にケースないんでどうでもいいと思いますみたいなところとか、何か言っていただけると、おおって思えたかなという感じですね。
そうですね。実際、フロントエンドエンジニアからしても選択肢が多いっていうちょっと悩みポイントでもありますよ。
なので、どれを選ぶかはちょっとケースはケースなんですけど、何があるのかっていうのは知っているといいかなという感じですね。
そうですね。ここでいくつか出せると、引き出しの幅というかうまくアピールできそうですね。
そうですね。選択肢を何個出せるかが、何か技術の幅というか知識量をアピールするポイントに確かにできるなと思って、何かこれってこうですよねって言われて、何かすぐにはいっていうんじゃなくて、まあこれとこれの選択肢もありますけどねっていう言い方ができれば良かったなーっていうのは振り返って思いますね。
そうですね。それは加点というか印象はいいポイントですね。ということで、今回は面接2回を受けていただいて、フィードバックという形でいろいろとホールエンスオーバンバーさんの来歴というかやってきたことだったり、実践面接の結果についていろいろフィードバックを話していきました。
SNSメッセージシステムの通信技術
ホールエンスオーバンバーさんありがとうございました。
ありがとうございました。
