harryのブログ

ロードバイクとか模型とかゲームについて何か書いてあるかもしれません

求職活動で面接に向けてやったこと

日記 ポエム

某転職媒体経由で内定(オファー)を2件頂いて求職活動が終わったので、メモ代わりに使っていた下書きを公開する。

人によって何をやるか(すべきか)はマチマチだと思う。

コンテキスト

  • アラフォー
  • Web系
  • 3年弱無職だった

やったこと

インプット

読書

設計

システム設計の面接試験

システム設計の面接試験

Amazon

システム設計の面接試験

  • 名著/バイブルではないが、良書ではある
    • タイトルを無視すれば名著かもしれない(?)
    • 抽象的なシステム設計の参考になる
      • 詳細に踏み込んだ瞬間、本のページ数が2倍以上になりそう
      • 引用されてる記事や論文まで全部目を通す必要がありそうな気はする（つらい）*1
    • 原著の初版が2017年であることも考慮に入れる必要がある?
      • 本は1日で書き終えて即出版されるわけではないため
      • 例えば ID 生成では Snowflake が推されている
  • これが面接試験対策になるかどうかは、エンジニア自身のバックグラウンドによる
    • 読み終わっただけでは、具体的なことに一切言及できない
      • 実際どのサービス/ライブラリを使うのが良いのか
        • メリット/デメリット、ハマリどころは？
      • マイクロサービスのオーケストレーションはどうするのか
      • Infrastructure as Code のベストプラクティス
      • ロギングや監視の勘所
      • システムを徐々にスケーリングさせていく設計/運用ノウハウ
      • etc. etc. etc. ...
    • 結局のところ、「では実務での具体例を話してください」と聞かれても、やってないことには答えようがない
  • URL パラメーターで auth_token 渡してる例あるが、認証後に Access Token (認可)使うこと多い気がしている(?)
    • 関連しそうな 記事 とか 動画 をチェックした
    • routing のある SPA で URL 共有できなくなるし*2、URL 長の問題もあるし、まぁやらんかな…
    • というか URL パラメーターだとアクセスログ解析が滅茶苦茶しんどそう
      • 目grepするな（はい）
    • URL 設計だけでも考えることは無限にある

DDD

実践ドメイン駆動設計

実践ドメイン駆動設計

Amazon

実践ドメイン駆動設計: エリック・エヴァンスが確立した理論を実際の設計に応用する

  • 俗に言う IDDD*3 本
  • 「カウボーイの声」は全般的に読み飛ばす
    • 日本人が読んで理解できるコンテキストでない上に、大して重要でない
  • キーワード
    • ユビキタス言語
    • 境界づけられたコンテキスト
    • コンテキストマップ
  • 序盤の方を読んでるうちに、体験入社(2社)が始まってしまい、読む時間が無くなってしまった

記事

設計

DB

DDD

ツール/ライブラリ

以下、読んだというかメモ

セキュリティ

以下、読んだというかメモ

面接

  • Google re:Work - ガイド: 構造化面接を実施する
    • 企業毎に求めている人物像が異なる (はずな) ので、「良い質問」の予測がしづらいな、となってしまった（バカ）
    • 働いてたのが昔過ぎて「行動についての質問」が来たら厳しいな…となってしまった（痴呆）
      • 普通は自分が働いてた時のタスクに対する目標/計画/行動/周りの反応/結果などについてスラスラ引き出せるように洗い出しておくべき

その他

  • CxOやボードメンバーが投稿した note などの記事
    • CxO面接前に必ず目を通しておく
    • ここで得られた範囲の情報については面接で質問しない

動画

セキュリティ

アウトプット

AtCoder Beginner Contest

  • 趣味になりつつある
  • コーディング面接では役に立ったけど、コーディング試験では落とされた（バカ）

ブログ

求職活動的に意味があったのかは謎。勉強にはなった。

反省点

業務上の具体的なエピソード洗い出しが甘かった

  • 面接で聞かれるの分かりきってるので
    • 構造化面接のところでも少し触れた
  • そもそも働いてたのが3年弱前だったので色々覚えてない
    • 事前に思い出しておく努力はもう少ししておいた方が良かった
      • ぶっつけ本番で思い出した時のエピソードが微妙だったときのリカバリーが効かない
    • 普通の人は3年弱も無職やったりしないはずなので、普通に洗い出しておきましょう

その他

CxO面接で共通して質問したこと

これが会社を選ぶのに良い質問だと思っているわけではなく、自分が純粋に気になって聞いていること。*5

「良い質問をしよう」と考えるより純粋に自分が気になったことを聞いた方が良いし、質問を思いつける程度には相手へ興味が湧く会社の選考を受けたほうがいいと思う。

  • CxOとして業務をされている中で気にされていること/大切にしていること
  • モチベーションや原動力
    • 会社や事業などの話をお聞きした後に「そのモチベーションや原動力となっていることはなんでしょうか？」という風に伺う
    • 実際には1社質問するのを忘れてしまい、備忘録としてここに書いた

これ以外は、会社紹介資料やCxOやボードメンバーが書かれた記事のインプットから思いついた質問をした。

リファレンスチェックでやること

生まれて初めてリファレンスチェックを受けたが、そもそも何をどのように準備すればよいのか分からなかった。反省点もあったのでまとめておく。

前提

  • ここでは、リファレンス先となる前職の上司などを「対象者」とします
    • 自分自身は「求職者」
  • 対象者の選定は、自分で2名探してきて企業へお伝えする形式
  • リファレンスチェックの実施形態は電話インタビュー

事前に確認しておきたい項目

リファレンスチェックのインタビューを前職の上司などに依頼する必要があるので、事前に色々確認しておいた方が良い。

  • 対象者を企業にお伝えする際に必要となる情報
    • 基本的に「氏名 / 所属企業 / 役職 / メアド / 電話番号 / 自身との関係性」とかになると思います
  • 対象者が所属していた企業を退職されていても問題ないか？
    • 一般的には問題ないらしいが、念のため
  • リファレンスチェックの実施時期
    • 大体、選考が始まって1～2か月後とかになるので、その時期に受けて頂けそうな方を探すため
    • 対象者へ連絡を取り始める時期も確認しておき、事前にお伝えしておく
  • 企業が対象者へメールで連絡を取る場合、企業が使用するメールアドレス
    • 迷惑メール扱いになったりとか見逃しを防ぐため
  • 対象者がインタビュー対応可能な時間帯や実施形態などの意向
    • 実際には企業と対象者の間で調整すると思うが、私の場合、対象者1名が海外在住だった
      • 連絡可能な時間帯(JST)やオンラインチャットでの実施検討*6を企業へお伝えした

その他にやっておきたいこと

  • 企業から対象者に連絡を取る直前 or 取った後、自分にも連絡してもらうようにお願いする
    • 普通は特にお願いしなくてもしてくれると思うが、念のため
    • 対象者のメールチェックの手間を省いたりメール見逃しを防ぐため
    • 自分に連絡が来たら対象者へSNSのDMなどで連絡する
      • あらかじめ自分からも連絡する旨を伝えておくとよい

おわり

結局役に立ったのかは分からないが、内定は頂けたし勉強(復習)にはなったので良かった。12/1からまた社会の歯車に戻るので頑張り過ぎない程度に頑張りたいと思う。

*1:四の五の言わずやれ（はい）

*2:URL パラメーターにフィルター条件が付与されている場合など

*3:Implementing Domain-Driven Design

*4:カジュアル面談で「フレームワークやライブラリの知識を求めている場合は業務委託でいい」と言われて納得感があった

*5:大前提として、自分が聞かれたら不快だと思うことは質問しない

*6:国際電話による電話インタビューではなく。まぁそこまでして電話インタビューにこだわるとは思わないけど…