転職選考の前半でやらかした失敗7選

1月から転職のために選考を受け始めました。しかし、まさかの 4社連続1次落ち を経験しました。そのタイミングで猛省をした結果、最終的に 4社から内定をいただきました。 (まだ1社選考残ってますが)

今回は特に転職活動の前半で「やらかしたな〜」と思った点を7つほど紹介します(多すぎる)。

(追記: 本記事は「自分のココができてなかったな〜」というのが趣旨です、特定の企業に対して落ち度があった等は思っていません。僕が選考のいろはが分かってなかったのが落ちた理由の8割だったと思ってます)

失敗7つ

• 応募先ポジションとのミスマッチ
• 自己アピール不足
• 職務経歴書を隅々まで読まれてる前提で受けていた
• フロント専門が思ってた以上に少ない
• スカウトされたという話が通ってる前提で話していた
• 退職日を先に決めた
• 手当たり次第に全部受けた

それぞれ以下に書いていきます

失敗1: 応募先ポジションとのミスマッチ

当然ですが、募集してるポジションとこっちの想定が違うと落ちます。 特に注意すべきなのは「フルスタックエンジニア」という募集です。自分はインフラやDBはほぼ触らないつもりで応募したのに、向こうは最初からインフラまでガッツリできると想定していた、みたいなミスマッチがよく起きました。

対策: カジュアル面談でポジションのすり合わせをする。

「選考に進むとしたらどういうポジションになりますか」とカジュアル面談で聞きましょう。僕の場合は「実務経験はほぼウェブフロントとサーバーのアプリコードのみです」と伝え、それでも応募可能かを聞いてました。

失敗2: 自己アピール不足

選考のどのタイミングで自己アピールするのか分かってませんでした。 まず最初に自己紹介があり、そこでアピールもすべきらしいです。これも気づくのが遅れました。愚直に職歴しか話さないのは勿体ないです。

また、次の「職務経歴書を隅々まで読まれてる前提で受けていた」とも繋がりますが、基本的な技術力があると事前に知られてると思い込んでいたのも失敗でした。職務経歴書とは被っててもいいから自己アピールをすべきです。

対策: 自己紹介ターンでしっかりアピールする。相手はなにも知らない前提で自己アピールする。

失敗3: 職務経歴書を読まれてる前提で基本的な技術力をアピールしなかった

職務経歴書、zenn、githubがすべてザックリとは見られてる前提で受けていました。 そのため、「基本的な技術力は伝わっているだろう」と過信してました。バカでした。

技術力は必ずアピールする必要があります。 最初から伝わってるなんて過信は絶対ダメです。仮に向こうが事前に読んでいて技術力を把握していても、繰り返しアピールして良いはずです。

1次面接(技術面接)では基礎的な技術力が重点的に見られる傾向があります。なのに技術力をアピールしなかったらそりゃ落ちます。提出したzennやgithubの内容と重複していても良いので、ちゃんとアピールしましょう。

チーム開発で意識してることや自分なりのバリューを出せる部分など、応用的な内容については二次以降で話せば十分です。

対策: 一次面接では基本的な技術力をアピールする。

失敗4: フロント専門が思ってた以上に少ない

ウェブフロントが一番長いので、基本的にウェブフロントで探してましたが、思ってた以上に募集が少ないです。基本的にフルスタックでの募集でした。大手にはフロント専門がありましたが、フルリモートでないことが多かったです。

対策: ウェブフロント以外の領域もしっかり伸ばしておく。 今回はなんとかなりましたが、今後を考えると、潰しが効くように他の領域もやったほうが良さそうでした。

失敗5: スカウトされたという話が通ってる前提で話していた

スカウトされて選考に進んでるという情報は、まず伝わってない前提で動いたほうが良いです(伝わってることもありますが)。なので、一次面接の時点で「誰々さんから誘われて選考を受けました」と話すと良いです。

まあ、コレは選考結果に直結するほどではなさそうなので、「話が伝わってる」という思い込みだけしてなければ問題ないと思います。

失敗6: 退職日を先に決めた

チームの事情とか組織再編の影響で、退職日を先に決めてから転職活動をしました。が、あとで調べたら転職先が決まる前にやめるのは結構リスクがありました。たとえば無職期間がマイナスに査定されたり、社会保険料を追加で払わないといけなかったり、保険の手続きを自分でしなきゃいけなかったり……

結果的に退職前に内定が出たのでよかったですが、 不必要なリスクを背負わないほうがよいです。

対策: 在職中に内定を得て、そのあと退職日を決める。

失敗7: 手当たり次第に全部受けた

5社連続で落ちて「もうだめだ…」となってしまい、次に6社並行で受け始めたら、今度は6社ほぼ全部通ってしまいました。1、2社から内定来たら御の字と思ってたため「どこにしよう…」とメチャクチャ嬉しい悩みを抱えることになりました。内定4つも出たけどほんとどうしよう…

退職日を先に決めていて焦っていたのもありますが、内定が多すぎるとそれはそれでメチャクチャ困ります。 気をつけたほうが良いです。内定は意外と出ます。6社受けて0だったとしても、そこから4社連続内定とか来ます。

「選考受けるぶんには無料」と調子に乗ってはいけません。たくさん受けると時間コストが馬鹿にならないので。

対策: 選考はちゃんとスケジュールを立てて受ける。

番外編: 意外と問題なかったこと

逆に、意外と問題なかったな〜ということもいくつかあります。

• 「社会課題の解決には興味ありません」と答えた
• 服装

問題なかったこと: 「社会課題の解決には興味ありません」と答えた

「御社の医療現場の課題を解決するというところに惹かれました」みたいなのはよくありますが、僕は一貫して「課題さえ解決できればよくて、課題自体はなんでもよい」と言ってました。これでも通りました。

問題なかったこと: 服装

基本的に全部オンラインで選考を受けましたが、服装はそこまで気にされてなかったと思います。スーツを着ないで無地のTシャツなどで受けてましたが問題なく選考を通りました。最終選考までそれでいきました。そもそも面接官も同じような服装でした。

というか、仮に自分が技術面接の担当だったら服装は評価基準にしないと思います。よほどじゃなければ。

まとめ: 選考は油断してはならない

新卒選考で撃沈した苦い過去があったので働きながらどうしたら良かったかは結構考えていました。それでも前半はツンツルテンでした。難しいですね。

失敗を反省したあとは内定がドサドサと出たのでよかったですが、もう二度と転職なんてしたくないかも……

「ここの意図ってなんですか?」を柔らかく聞く

「ここの意図ってなんですか?」とテキストで尋ねると、怒っていると捉えられてしまうことがあります。コレはした側もされた側も多くの人が経験したことがあると思います。

実はこれにはメッチャ簡単な解決策があります。

解決方法: 「なぜ知りたいのか」を書く

• 「ここの意図ってなんですか? こう書いたほうが良さげなので背景が気になりました 」
• 「ここってこう書き直しても大丈夫ですか? こうなってるのって事情ありますか?」

こんな感じに、なぜ知りたいのかを書こう。 これなら回答者は「そこはこういう背景です！」とか、「確かにそのほうが良いですね、書き直しちゃって大丈夫です！」と返信することができる。

なぜ知りたいのかさえ分かれば質問者はかなり安心できる。詰問になってると感じたら、自分が相手にどうして欲しいのか、なぜ聞いているのかを添えよう。

応用例

「なぜ」を追加するテクニックはほかのシーンでも使える。

例:

• 「よく分からなかったのですが、こういう理解であってますか?」
• 「この処理の背景ってなんですか? 初見でも事情がわかるようにコメントほしいです！」
• 「この案件のためにこういう実装が必要なんですが、どうやればいいですか?」 (単に「これってどう実装したらいいですか?」と聞く場合と比べて、そもそもの実装方針からチェックしてもらえるようになる)

まとめ

ちょっと文を増やすだけで印象がずいぶん柔らかくなるので、是非やりましょう。

素数を判定する正規表現を紹介: /^.?$|^(..+?)\1+$/

先日、正規表現のネタをツイートしたら軽く拡散しました。そこで他にも面白いものあるのかなと調べてみたら素数を判定する正規表現があるという記述を見つけました。

これが実際の正規表現を使った素数判定です↓

const isPrime = (n:number) => !/^.?$|^(..+?)\1+$/.test('0'.repeat(n));

これでなぜ素数を判定できるのかを解説します。

解説

isPrime関数は「長さNの文字列が /^.?$|^(..+?)\1+$/ にマッチするか」を見ています。そして、正規表現にマッチしたらNは合成数、しなければNは素数という判定をしています。

ポイントはやはり正規表現の部分です。

素数判定の正規表現の解説

/^.?$|^(..+?)\1+$/

この正規表現は2つのパートで構成されています。

• ^.?$
• ^(..+?)\1+$

前者は0と1にマッチし、後者は任意の合成数にマッチします。そのため、コレにマッチしなければ素数となります。

以下それぞれのパートについて解説します。

^.?$ は0と1にマッチする

これは見たままです。0文字または1文字のときにマッチします。簡単ですね。

^(..+?)\1+$ は合成数にマッチする

こっちは一瞥しただけでは分かりません。ただ、ほどいていけばそこまで難しくありません。

まず (..+?) ですが、これは2文字以上にマッチします。そのあとの \1+ は、(..+?)でキャプチャしたグループが1回以上続くことを意味します。つまり、この正規表現は 2文字以上のグループの繰り返しのみで構成されているときにマッチします。

たとえば、 0000 は2つの 00 によって構成されているのでマッチします(=合成数)。逆に、00000 は2文字以上の同じ文字列の繰り返しで構成されていないのでマッチしません(=素数)。

まとめると、この正規表現は文字数が (2以上) x (2以上) で表現できるとき、つまり合成数であるときにマッチします。

まとめ

わかってしまえば案外簡単なロジックで出来ています。面白いですね。

なお、この正規表現は当然ながら効率はよくありません。そのため実用は難しいです。しかし、たった1行で素数判定ができるので、覚えておくといつか役に立つかもしれません。

alpha-nvimで表示するロゴをいい感じにしたい

ascii.nvim を使うといい感じになるよ

やり方: alpha-nvimのheaderにascii.nvimのAAを設定する

lazy.nvim の場合こんな感じ↓

opts = function()
  local dashboard = require 'alpha.themes.dashboard'
  dashboard.section.header.val = require 'ascii'.art.text.neovim.sharp
  return dashboard.opts
end,

実際の設定

ascii.nvimをインストールして、alpha-nvimのheaderに設定している。これだけ。

ほかに使えるアスキーアートを見たいときは、lua require("ascii").preview() を実行するとプレビューできて便利。ただpreviewをする場合はMunifTanjim/nui.nvimをインストールする必要がある。

useEffectにはコメントをつけよう

「なにをしたいuseEffectか」をコメントしておくと、後で読むときのコストが下がりやすい。

実際にプロダクトコードで書いたことがあるコメント↓ (簡略化してます)

// 画面内に入った動画を自動再生する+ほかの動画は停止する (すでに再生済みだったら再生しない)
useEffect(() => {
  if (inView && !hasBeenPlayed && canAutoplay) {
    /* ... */
    pauseOtherVideo();
    play();
  }
  /* ... */
});

このコンポーネントにはコレを含めて4つのコメント付きのuseEffectがあった。たびたび読み返す機会があったが、その度にこれらのコメントが大いに役立った。

なぜコメントが必要なのか?

useEffectの中身はたいてい複雑な処理になる。しかもたいてい無名関数を渡すので、実現したい仕様に関する情報がない。なので、 コメントがないと何をするuseEffectなのかが処理内容を読まないと把握できない。これはとてもめんどい。

コメントはコードを読むときだけでなく、リファクタするときにも役立つ。カスタムフックを抜き出すきっかけにもなるかもしれない。

コメントの書き方

コメントはやりたいことをベースにつける。たとえばこんな感じ↓

• APIからデータを取得する
• 5秒後にフェードアウトさせる
• オーバースクロールを制御する

後から読んだときに「なにがしたいコードなのか?」が伝わるように書こう。

別解

別解1: 関数に名前をつける

useEffect(function playWhenEnteringView() {
  // ...
});

別解2: カスタムフックに抜き出す

function usePlayWhenEnteringView() {
  useEffect(() => { /* ... */ });
}

追記: lintで縛る

Lintにしてしまうのが良さそうと思ったのでhttps://t.co/iQROX8PuAS
適当に書いた。

useEffectにはコメントをつけよう - Panda Noirhttps://t.co/Ls4cx7i4IG

— azu (@azu_re) 2025年1月30日

azuさんがリントルールを書かれたので紹介します

https://gist.github.com/azu/0dc07179f66a6471f0a0aa681709b2f5

useEffect または React.useEffect の直前にコメントがない場合にエラーを出すルールです。 この記事の内容まんまのものになってます。 よければ使ってみてください。