Fromベンチャー To大手IT企業への転職ガイド
この度ウェブアプリケーションエンジニアとして転職をしました。
自分の記録のため、そして同じバックグラウンドを持った方の参考になればと思い筆を取りました。
転職エントリのようなガイド風の何かです。
アドバイスなどももらえると幸いです。
随時更新してまいります。
略歴
新卒入社した企業でWebアプリケーションエンジニアを2年半行ってきた。
担当領域としては、フロントエンドとバックエンド。
担当工程としては、上流から下流。
開発以外の担当業務だと、エンジニアの採用・マネジメントを担当。
強みは幅の広さとソフトスキル。
弱みは浅さ
将来的にはサービスリードのポジションになりたいと考えている。
現職の状況
- 動的型付言語を使用
- 新規顧客優先で機能改善・技術的負債の解消が承認されない
- アーキテクチャとしては、MVCが守られてないところを業務外などでクリーンに寄せて行っている状況
転職に際して実践したこと
転職理由の整理
自分がなんで転職するのか。それがわかると転職先の企業のペルソナも見えてくる。
あとはそもそも、面接で必ず聞かれるのでスクリプトとして用意しておくべき。という理由もある。
職務経歴書・履歴書
転職理由が整理できたら必要書類を書いていく。職務経歴にかける実績を普段から書き留めておくと良いだろう。詳細は後述。
履歴書は書き方をググって書く。以上アピールや志望理由欄は空のままでおk。新卒の時は見られるが、中途だと見られない。
エージェント・媒体への登録
自分で企業に応募しまくるのも良いが、自分が知っている会社にも限りがあるだろう。
to Bの企業など普段接しないプロダクトを運営している企業にも目を向けられるの点でも有用。
良い担当者がつけば面接に関するアドバイスや、企業の選考フローをしてくれる。
転職に際して意識したこと
現職を批判しない
❌エンジニアを理解しようとしない!やめてやる
⭕️経営的な事情もあるとは思うが、技術的負債への理解が得られなかった。返済をすることで新規開発速度が高まる説明などもしたが現状だとその投資はできないと言われてしまった。
相手の事情を思いやる表現 + 自分がした改善の動き
これらを盛り込めると大変良い。
ネガティブなことをいう人は、うちに来ても不満抱えてやめそうだなぁと思われます。
将来どうなりたいのかを示す
後々うちの会社でどうなりたいのか、そう言ったビジョンを見せる必要がある。
会社からしたら仕事はそつなくこなすが、意欲が感じられないとか、すぐやめてしまうとかそういうのがリスク
企業から実際に聞かれた質問事項
- 志望理由
- 転職理由
- 転職理由を深ぼった質問
- 今後のキャリアでどうなって行きたいのか
- 職務経歴書に書いた職務経歴に関する深ぼった質問
- どうしてエンジニアになったのか
- 普段学習していることは何か
- どのような業種・業界に関心があるか
普段からやっておけばよかったこと
発信活動
Qiita、Zeenなんでも良いが普段学んだことを発信するのは良い。減点はされない要素なので、ガンガンすべき。
アウトプットとセットの学習が効率は高めてくれる。
ポートフォリオ作成
求められた企業があった。
ないことはマイナスにはならないが、加点要素なのでやっておくべし。
すごいものを作る必要はなさそうだった。
書籍を読んで普段学習しているなら、サンプルコードを他の言語で書いてみてそれを一つのリポジトリにする。などでも十分。
あとはアーキテクチャに興味があるのなら、そのアーキテクチャに沿った簡単なプロダクトを起こして見るのは良さそう。(自分はJavaでクリーンアーキテクチャのSNS風なものを作っている)
アルゴリズムのトレーニング
出してくるところは出してくるので、対策をしておくと良い。
外資とか行く際は有名な本があるので、それで対策すると良さそう。
職務経歴のメモ
職務経歴書に今までの仕事の成果を書く必要があるのだが、いざ書くとなっても思い出せないものである。
そのため普段からある程度大きめの案件やタスクが終わったらその振り返りを書いておくと良い。
うまくいったのか、うまくいかなかったのか。それはどうしてか。
問題に対して自分はどのように行動できたか、できなかったがどうしたらよかったか。
など書いておくととても良い。
その際の開発体制と自分のポジションや、使用技術も残しておくとより良い
以下は私の内容であるので、参考にしたい方のみ見てみてください。
転職先に求めたもの
静的型付言語が使用できること
現職がPHPで、実務で静的型付言語を使用したことがない。
異なる種類のプログラミング言語を使用した経験がないと、技術選定を行うときに困る。
(あとは、スタンダードなサーバーサイド言語を触ってPHPでついてしまった良くない癖を取りたいと言う気持ちもある)
機能改善・技術的負債の変換に理解がある
品質改善しないと当然いいプロダクトにはならないし、開発速度も上がらない。
あとは、作りっぱなしの環境だと技術力もそれ以上身に付かない。
元々エンジニアになった理由としても、プロダクト指向は強いから心情的にも重要視するポイントだった。
クリーンアーキテクチャ・DDDを導入している
息の長いプロダクトが世の中に溢れている今アーキテクチャへの知見は価値が高まっていると思えた。
また、自分がプロダクトを作る時にそう言ったものを導入したいので実務で触れたいという気持ちもあった。
自社プロダクトを有している
受託だと作って終わりなので、プロダクトの変遷を見たい自分としては自社プロダクトを有していることが重要だった。
今後の展望
今年度中にはミドルエンジニアになりたい。
一人で一定以上の品質のコードを書けるようになる。
その3年後にシニアエンジニアになって、技術的な議論に混ざったり、レビューとかできるようになっていきたい。
そしてその3年後にはサービスリードになっていきたい。(正直、ここは遠すぎて現実味がないけど)
そのために学習すること
- アーキテクチャ
- 静的型付言語
- アルゴリズム
- インフラ
- マイクロサービス
- プロダクトのマネタイズ
Discussion