Help us understand the problem. What is going on with this article?

エンジニアが転職する時に考えることを採用面接官をしてる立場から書いてみた

More than 1 year has passed since last update.

エンジニアの転職メモ を読んで、刺激を受けたので書いてみました。

非常に共感しました!
自分的にちょっと気になるところ+αを書こうかなと。

書かれたことは会社的な方針ではなく、個人としての観点です。

自分誰よ

とある企業で採用の一次面接に呼ばれたりする現場のエンジニアです。
Javaエンジニアです。Scalaもたまに書いてました。
転職回数は片手では足りないくらいの回数をしています。

最近はエンジニアマネジメントの比重が多く、ほとんどコード書いてないです。
コードは書いていませんがレビューや調査では読んだりします。
アーキテクチャ、フレームワーク選定、インフラ方針などの決定権は持っていて、
ビジネスバランスを取りながら実装の方針などを決めます。

採用面接官のエンジニアは現場エンジニアが多い

人事によるピックアップとは別

前提として技術力はエンジニアしか判断できないと思っています。
でも、採用のフロントに出て調整してくれたり、人材候補を見つけるのは人事の仕事になります。
人事は技術そのものが理解できるわけではないので高性能なキーワードフィルターのような捌き方になるのかなーと想像しています。

フィルタを通過した人に対して、現場のエンジニアに判定をアサインします。
現場エンジニアの採用への意欲や人事とエンジニアの連携の度合いは会社や部署によります。
その前提で・・・

URL共有について思うところ

URL共有はメリットは大きいですが、人事判定を行うには扱うのが難しいのではと想像しています。
現場エンジニアとの連携力の高い会社で無ければ、弾かれてしまう可能性はあります。
スカウトなどで会社側からアプローチされている場合には問題がないとおもいます。
個人的には表現のサブツールとして使うのがベストじゃないかと思っています。

ちなみにウチはURL共有でも全然気にしません。

履歴書

ほとんど見ません。年齢と通勤時間くらい。中途の場合、学歴より実力と実績なので。
アピールしたいことがあれば職務経歴書の方に枠を作って書いたほうが良いです。
動機やPRの項目ですが、実際に実績をPRするには通常の履歴書フォーマットの枠では足りないです。
職務履歴書などの最初や最後に追加で自分で枠を作ったほうが良いです。

手書きの必要は全く無いです。
僕も転職のときには全てデジタルでした。

職務履歴書のOSS管理について

面白いと思います!自分は人事フィルタで除外されない自信がある人だけ行って下さい。

なぜなら

1つめに
Webは1ページリンクごとしか見れず、人事の人がまとめて扱いにくいので、大抵プリントアウトして使います。
そうするとWebのページはたいてい見づらいです。文脈に従ってページ送りされるわけではないですし、リンクも死にます。
僕も印刷したものを渡される時もあるんですが、見づらいです。
1人に対してのみ吟味する感覚のときは悪くはないと思います。

2つめに
ただし、ユーザ企業のいるSI系や開発中のプロジェクトだと、プロジェクトの全てをオープンな場で書くわけにはいかないことがあると思うので、自分の職歴と相談してみて下さい。
直近やってることが一番自分のレベルが高いはずなので、非公開の開発情報は強いんじゃないのかな・・・?

3つめに
職務履歴書はフォーマットは無いです。WebでもOK。
その辺の落ちているものを使っても良いですが、自分の仕事をうまく説明出来るフォーマットを自由にExcelなどで作ってしまえば良いです。
僕の場合もどこかの経歴書を参考に自分でほしい項目を足して、いらない項目は消しました。

OSS管理は自分での管理と一本釣りに近い形の採用には向いていますが、まとめてリサーチされるときには気をつけて欲しいかなと思います。

エンジニアが転職するときの強みになること

転職したい時にスキルを整理するのでは少し遅いケースがあります。
中級エンジニアになったならば、自分の強みをどこにもつのかをしっかり定義して、実務のレベルをあげるとともに戦略的に自分の実力が分かる見栄えのある技術アピール方法を考えて、積み重ねておくべきかと思います。

実力と表現は両軸で持つことで自分のやりたいことに近い会社を選ぶことが出来ると思います。

転職を決める前にしてほしいこと

◯ 自分の実力表現の実績の積み上げ

社内勉強会や社外勉強会、カンファレンスでの発表

資料があると、どんなことに興味があるか、どんなレベルで調べるかが分かります。
カンファレンスはよほどの勇気と実力がないと厳しいですが、小さな勉強会のLTはいつでも募集されていますし、社内で有志のチームで勉強会をしても良いです。
技術者にとって発信力も力の一つです

Qiitaなどへの技術メモ

Qiitaなどへ技術メモがあると興味分野が分かります
実力が分かるレベルで深いことを書いている人は少ない
自主学習力などの一部は分かる

社内での技術採用やプロジェクト立ち上げ、役回りの獲得

肩書きって実力や実務ではあんまり関係ないです。
偉くなってもコードが上手く書けるようになるわけじゃないので。
でも、転職のときには他者へどのレベルなのかを証明しやすい目安になります。
人事の人でもなんとなく分かる。
チャンスがあったら実務は変わらないけど、肩書きがもらえるケースは表明してしまう旨さがあったら良いかもです。
現場リーダー、サーバーサイドアーキテクト、マネージャ、フロントリードエンジニア、など。

説明しやすい現場事例

  • 改善の導入提案と導入実績
    • 提案と実際に導入のために動くのは、実は雲泥の差があるので導入して欲しい。
    • どうしても提案しか出来ない現場だったら、どこまで自分で他者の立場と技術メリットを理解して提案したかを説明出来るレベルに。
    • フレームワークなど技術系とアジャイルエッセンスなどの開発プロセス系などの両軸であると思う
  • 開発チーム立ち上げ、プロジェクト初期エンジニア
    • 技術選定やチームでの方針決定のルール決めなど沢山の問題が山積みになる
    • 自分の存在感を出したエピソードを
  • 他にもまだまだありそう
    • 今ちょっと思いつかないけど

◯ 自分の実力の積み上げ

情報アンテナの追加

  • Twitterのスペシャリストのフォロー,Facebookなど
  • 勉強会
  • AWS、GCP、各種プログラミング言語、フレームワークなどの公式サイト
  • 技術系ニュースサイト Qiita、TechCrunch、CodeZineなど
  • 企業技術ブログ

利用技術幅を広げる

  • 複数の言語
  • クライアントサイド(HTML,CSS,JS)、サーバサイド、インフラ、ミドルウェア
  • パブリッククラウド
  • 大規模データ、機械学習
  • ちなみに機械学習はちょっと出来ますくらいだと、あんまり仕事増えないです(強みにするには数学的な知識が必要)

強みの部分を極める、深く理解する

  • 得意言語のフレームワークを複数理解して選択出来るようにする
  • 言語の特徴と強みを理解して、仕様やリファレンスもなるべく網羅する

プログラミングや開発の原則やデザインの理解

  • プログラミングの原則
  • GoFのデザインパターン
  • 関数型でデザインパターン
  • テスト駆動開発
  • クラウドデザインパターン

開発プロセスの効率化

  • アジャイル開発の概念
  • 手法の勉強 - スクラム、XP、リーン
  • プロセス適応の導入実績

たぶん実力の方は履歴書や職歴書などの紙の情報で説明するのは難しい。
でも、面接などで技術に対する一問一答でその深さは測ったりするので、これがないと書類に通っても面接には通らなかったりする。
適当なとこだと通ってしまうけど、実務でどうせ使うので実力は上げたいよね。

転職におけるやりたいことの明確化

年齢にあった実力とあったやりたいことである必要がある。

20代であれば、ヤル気と行動がちゃんと揃っているか。
XXX言語に興味があってやりたいです!って言った時に、その環境をやるのに障害になっているものになっているものは何か?
無料で全部揃えられるはずなのに、何も手を付けていなければ、残念ながら興味があるとは言えないです。

30代であれば、例えば技術を伸ばしていきたいと言っても、30代になってくると誰かに教えると言うことが当然に出てくる。
その時に発信力があるか、リーダーシップを発揮できるかを見る。
もしくは1人で作りきった技術の高さ。それは海外の一次情報などにアクセスして作るレベルじゃないと、技術レベルが高いとは言えないです。
マネジメント系がやりたいのであれば開発プロセスの知識を勉強しているかを問います。
これも興味があっても、なんの勉強もしていなければ20代の人と同じです。
実務経験は会社の環境によって出来ないことがあるので、出来る範囲でどこまで自分が知識を得ているかです。

次にビジネスや事業の改善に興味がありますと言う人が居ます。
そのときに、市場の成長感や同じ業種の上場企業のP/LやB/Sを見て、その感覚を少しでも得ようとしているでしょうか?
受ける会社の機能や競合の企業の機能は一通り見ているのでしょうか?

エンジニアが他の領域の話をしようと思ったら気をつけて下さい。
技術を極めていないのに、ビジネスに興味があると言っているが、何の数字も感覚も出てこないのであれば
平凡なエンジニアという判断になってしまうかもしれません。

まとめ(まとまってない)

なんとなく普段から思ってることを書いてみました。

採用側も全てがパーフェクトな人間では無いです。
人事は技術が分からず、採用に出てくる現場エンジニアは面接官のプロではなく、採用エンジニア専任は現場のニーズを全て理解してるわけではないです。

その中で、自分を一番伝えれる形を模索して行くしか無いです。
採用としても出来るだけ強みを引き出したくて話を聞いていて、会社で活躍してくれる人を探しています。

他にも何か質問等があったらなんでも答えます。

いいねされると嬉しいです。ぜひ良いねしていって下さい。

newta
Java、Scalaなどの堅めの型が好き アジャイル関係、エンジニアマネジメント関係、エンジニア人事採用周り プロダクトサービスとエンジニアを横断した価値あるエンジニアを考えることが好き 何かご相談があればこちらまで t.newtaro+qiita@gmail.com
mercari
フリマアプリ「メルカリ」を、グローバルで開発しています。
https://tech.mercari.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした