必須要件を満たしているのに通らないとき、求人票に書いていないもの

必須要件に並んでいる言語もフレームワークも使える。それで応募して、通らない。何が足りなかったのかを求人票で確かめようとしても、そこには書かれていない。

私は、その求人票を書いている側にいます。エンジニアのポジションで必須要件と歓迎要件を決め、そのうえで応募してきた方の書類を読み、面接を担当しています。

その立場から書くと、求人票に書いてあることは、期待していることの全部ではありません。書かないまま期待しているものがあります。

以下はすべて、私が担当している範囲での話です。求人票に何を書いて何を書かずに済ませるかは、会社や部署によって違います。

求人票に書くのは、キーポイントだけ

まず、なぜ書いていないのかから書きます。

書けるなら書けるだけ書いたほうがいい、とは思っています。ただ、「1+1ができますか」とは書かないですよね。

キーポイントが書かれるべきかな、という気がしています。

つまり、書かれていないものは、期待されていないものではありません。書かれていないだけです。

要件を満たしていない側から見たときに何が起きているかは、必須要件を満たしていないとき、書いた側が代わりに見ているものに書きました。この記事は、その反対側の話です。

具体的に書きます。

言語やフレームワークを使ってWebアプリケーションが作れる。 それだけできていればいい、という話ではありません。

パフォーマンスについて考えられるか。可読性やメンテナンス性を考えられるか。DB設計を含めて、複合的に考えられるか。 ここが求められています。

オブジェクト指向や、基本的なソフトウェアエンジニアリングの素地についても同じです。要件の欄には出てきませんが、期待はしています。

技術の名前が並んでいるだけでは、そこまでは読み取れません。そのことはスキルシートに技術名を並べても、深さは伝わらないに書きました。

技術面だけの話ではありません。

オーナーシップや、リードできるかどうかは、あるに越したことはないと思っています。

コミュニケーション、外部とのコミュニケーション、プロジェクトマネジメント、タスクマネジメント。これらについても、基本的な理解はあるべきかな、と思っています。

いずれも求人票には書いていません。

ここは分けて書きます。

素地が足りないときは、見送りの判断としてステークホルダーに伝えます。

ただし、合否は一人の判断では進みません。 別の観点で採りたいと考える人がいれば、議論になる可能性もあります。

一方で、スキルは十分で、チームやポジションにフィットしないだけの場合は、別のチームやグループを提案することがあります。

この二つは別のものです。

見ている場所も分かれています。

技術面接では、技術的に求めていることをスキャンできます。

レジュメの段階では、基本的にチームや経験にフィットするかを確認しています。

選考が始まった後の話は他社も受けていると伝えたとき、変わるのは合否ではなく進め方ですに書きました。

求人票に書いてあるのはキーポイントだけ。 「1+1ができますか」とは書きません。書かれないまま残るものがありますが、それは期待されていないという意味ではありません
言語やフレームワークが使えることと、求められている素地は別。 パフォーマンス、可読性とメンテナンス性、DB設計を含めて複合的に考えられるかを見ています。技術以外でも、オーナーシップやマネジメントの基本的な理解は期待しています
足りなかったときの扱いは二つに分かれる。 素地が足りないときは見送りとして伝えます。ただし合否は一人では決まらないので、別の観点で採りたいという人がいれば議論になる可能性もあります。スキルは十分でチームやポジションに合わないだけなら、別のチームやグループの提案になることがあります

繰り返しになりますが、これは私が担当している範囲での話です。