どこでも聞かれること

経歴

かいつまんで1~2分ほどで話すことが多い。
現職でどんなプロジェクトでどんな役割をやっているかを主に答えていた

プロジェクトについて

「職能型の縦割り組織」か、「プロダクト型組織」かを答えられると良さそう。

職能型の縦割り組織

同じ専門分野のエンジニアで部署を作り、仕事を進めていくスタイル。
例) 〇〇部フロントエンドチーム

プロダクト型組織

各プロダクト毎にチームがあり、そのプロダクトを開発・運営するために様々な職能のメンバーで組織される(フロントエンド、バックエンド、デザイナー、Biz)
例) ✖️✖️プロダクトチーム

志望動機

なぜ我が社にってやつ

キャリアプラン

3~5年後のプラン。
どの役割を知っているかもありそう。

個人的にはEMかスクラムマスター(SM)に興味あり。

自分が今やっている役割はなんなのか？
興味ある役割に対してどういうアクションをしているのか。

EM

FEチームのマネジメント的なことをしていて楽しいと感じるため、EM興味あり。
チームは3人、かつ自分以外はSESや業務委託のため必然的に自分がこの役割になった。

現場で特に役職はない。

やってる事

• リファイメント前段階の企画(プランナー)との壁打ちにFEエンジニアを代表して参加する
• リファイメント後にチケット(案件)に対してサブタスクを作成する。場合によってメンバーと相談しながら、後日メンバーで見積もりが出来る状態に持っていく
• FEチーム内のスプリントレビューやれとりを実施して、POと連携する

現場は3人チームなので、スプリント内の2割ぐらいの工数をこれに割いている
将来的にチーム人数がより増えてもスケールするようにマネジメントしたい。

また、FE領域に関わらず、エンジニア組織全体に対し視野を広げて活動したい

スクラムマスター(SM)

EMと似てくるがとにかくチームとしてスクラムをうまく回せることに対して情熱があり、場合によってはエンジニアという職種を剥がしてSMでも良いと思っている。
（基本的にはエンジニア兼SMが理想）

やってきたこと

• チームへのスクラムの浸透
  • スクラム初体験メンバーを多く含むプロジェクトに対して、デモ会、レトロ、スプリントレビューなどを提案しチームへの浸透を主に図った
  • スプリント手法の振り返りをクオーター毎に設定し、プロジェクトのフェイズに合わせてスクラムイベントを調整出来るよう設計、実施
  • デイリースクラムやリファイメントなどで何を目的としているかをプロジェクトメンバー内で共有

SMに興味を持ったきっかけ

やってきた事はどれも、今までの経験でスクラム経験があるメンバーが自分含めて2人しかいない状態で、新規で15人弱のスクラムを組むことになった為、初期の設計にあたる。

2年ほど活動し、最初の半年を超えてからは特に意識して動く事は無くなったが、この経験からチームがうまくスクラムを回すためのサポートに興味を持つようになった。

今までの仕事で 1 番成果を上げられた出来事

前提条件となる状況をうまく伝えられるか。またどんな成果を上げたか

今までの仕事で 1 番上手くいかなかった出来事、また今ならどうするか

どんな失敗を経験しているか。またそれから何を学んだか

技術的な質問

フロントエンド

自分はReact、TypeScriptを触っていたので、それに対するあれこれ

ReactとVue.js、Angularの好み

違いと個人的に触った使用感など

コンポーネント設計で気にしている所

Atomic Designで感じたことや、どの単位で区切るかの考え方

コードの品質を保つためにしてること

• レビュアーの勉強会(レビュー観点など)
  • 実装力よりレビューで漏れを出さない方が成果に対して手っ取り早い
• コーディング規約の定期的な見直し
• 輪読会
  • React、Nextや関連ライブラリのドキュメントの読み合わせをチームで行い、言語としての理想と、時差師のプロジェクトへの導入の認識をチームメンバーで揃える

現在のプロジェクトに対して3ヶ月あればリファクタリングしたい場所

• 現在のプロジェクトに対してビジネス要件を抜きにどのようなコード的な負債を感じているか
• またそれがコード的にどのような恩恵を受けられるか
  • ディレクトリ構成
  • グローバルなデータの管理の整理、Redux、useContext、reactive valiablesなど
  • ユニットテストのモックの整理
    • テスト間での依存を少なくし壊れにくいテスト構造にしたい
  • ログ出力などのビジネス要件用の処理を共通化して整理する

アクセシビリティで気をつけてること

E2Eのテストでの観点

何を使ってるか
その時の観点

ユニットテストでの観点

Jest 、Testing Libraryを使えるか

TypeScriptの型に関して

• enumは使わない方が良い？
  • 数値列挙型でコンパイルエラーが出ない
  • 結論；基本的にユニオン型、オブジェクトリテラル型を使いましょう
  • https://typescriptbook.jp/reference/values-types-variables/enum/enum-problems-and-alternatives-to-enums

SSRとCSRの違い

どっちを使っているか。違いが分かっているか

バックエンド

Webアプリ全体を理解しているか

依存性注入（Dependency Injection）とは？

クッキーとセッションの違い

セキュリティ対策で何かしているか

N+1問題について

どういった問題か
対処法：Dataloder

アウトプット

zennや技術ブログへのモチベーションや狙い

見送りの理由

評価ポイント

フロントエンドのモダンな開発を経験している。技術力は好印象

コミュニケーションを重視する

今のチームメンバーと馴染めるか

見切りが早い

• 自社に対してのトライアンドエラーをどうするか
• 転職を考えたきっかけ
  • プロジェクトチームに長くいたいと懇願したが、難しかった
  • 事業フェイズ的にプロダクトを点々とする時期だった
  • 職能型ゆえにプロジェクトは点々とする

受けたポジション

現職と同じような不満が出そう
環境ミスマッチへの懸念

reduxとrecoilの比較

reduxが向いているプロジェクト

自分のプロジェクトでよくできている部分

評価点

• 技術に対しての理解
  フロントエンドの理解と知識にアップデートがで出来ている

• 現職でのUI/UXの改善やパフォーマンスの改善への提案が出来る

1つのプロダクトに長く関わるには、サーバーやインフラも必要。
プロダクトの思考性

次の面接で気をつける所

• 携わっていく事業が社会課題の解決なので、貢献したいという思い
• キャリアの指向性
  • EMへのマネジメントへの興味
• インフラとサーバーのキャッチアップが必要
• ユーザー目線、技術が目的化していないか