採用
試用期間
#WIP
素直さ
モチベーションの根源
自分で考える力
評価の基準の例
採用の本
面接時に聞いてはいけないこと
企業への逆質問
https://archive.md/CJHvq
マネーフォワードのエンジニア採用の、採用する側のフロー
ポートフォリオをうごかす
@shokai: レジュメにgithubのURL書いてある人に関しては、ローカルでちゃんと動かしてなんでこれはこういう実装にしたのとか議論したりしてるので対戦よろしくおねがいします
https://t.co/7KztGTiygu
コーディング面接
『ITエンジニア採用入門』
https://aws.amazon.com/jp/careers/culture/
AWSカルチャー
リファラル採用
/mrsekut-book-4866802065/4つの階層
/mrsekut-book-4866802065/大きな三つの行動特性
/mrsekut-book-4866802065/ポテンシャル・モデル
https://note.com/stam_mat2/n/n6dcf9acda98d
https://anond.hatelabo.jp/20210111163141
https://note.com/iwark02/n/n9712d4d3f2d0
https://note.com/hishinuma_t/n/ncc3ab3d17bb3
https://speakerdeck.com/honchang/shu-zi-dezhen-rifan-ruhelpfeelenziniacai-yong-2023-2024
Helpfeel
https://baigie.me/officialblog/2020/04/07/photo-direction/
採用サイトのための撮影術
https://qiita.com/newta/items/bc97ec9c668e4a13e4a2
どんな人を採用したいか
採用する側の目線としては、
誰かを採用したことがなく、
故に採用によって失敗したこともないので、
具体的な「指標」と、それを測るための「方策」が見えていない
一方で、採用される側の目線として、評価されるために生きているわけではないが、評価されないと生きていけない問題が依然として存在している
この一見相容れないものに、立ち向かわないといけない。
今のチームのノリと調和が取れる人
カルチャーフィット
自分がすごいと思える点があること
承認欲求が低い人
sumiren (@sumiren_t)
強いエンジニアを採りたいスタートアップをご支援してるとき、成長とか評価とかいう言葉を使うのはやめるようアドバイスしている。スタートアップに来る強いエンジニアというのは、「俺がお前を評価するんだよカス」って気持ちで来るもんなので。「助けてください」以外言わなくていい
人を増やすことのデメリット
コミュニケーション問題
お金の問題
教育にかける時間
いろいろパラメータはありそう
技術の能力
人間としてチームに調和するか
良い刺激をもたらすか
ドメイン知識がある
扱っているビジネスに関する知見が深い
「経営理念への共感」の重視は、mrsekut.iconも前から疑問に感じてはいた
感じる側の観点
そもそもなぜ、経営理念への共感を重視するのか
共感している場合としていない場合にその会社の何が変わるのか
安易に思いつく発想
モチベーションが高いので、事業に取り組んでくれる
ユーザーの求めるものが見えるので、良い提案ができる
関係ある?
果たして本当か
P: 経営理念への共感がある
Q: 会社に対する良いパフォーマンスを出す
のとき、P→Qは真なのか、そしてそれ以外に真となるものはないのか?
それに対する反論
「経営理念への共感が不要」というのは、その経営理念が練り込まれていないから。
もしくは、経営理念そのものは会社のものであるので、「エンジニアチームとしての経営理念」が別途必要
で、それにそぐう人を採用する必要がある
と、言われそうmrsekut.icon
なぜ、この会社を選ぶか
「経営理念への共感を重視しない」ならば、「なぜ弊社を選ぶか」があまり明確にならない気もする
しかし、実際問題、そこまで経営理念で転職先選ぶか??って気もする
実際よく見る指標って
安易なものであれば
年収、休暇、就労時間、福利厚生、名声
のような、いかに楽して金を得るかみたいたもの
エンジニアっぽいものなら
強い(とは)エンジニアがいる
そこでしか触れない技術がある
福利厚生
技術書を買ってもらえるなど
のような、利己主義に、技術力を上げる、キャリアに繋がる、のようなもの
思想によるものなら、
自分には叶えたい思想があり、この会社がそれを体現している
そこのサービスが好きなので、自分も作りたい
あまり聞かないが、こういうのものありそう
これに関しては、経営理念共感に近い
こういうふうにみると、「経営理念への共感」って、言っているだけで、そんなに価値のあるものなのか?という目で見てしまう
というか、めちゃくちゃ前提として、自分の中に邪道をゆく経営者みたいな舐めた発想が存在する
つまり、言うて金でしょ?になってくる
「技術力は必要だ」とか「学ぶ意識が高いほうがいい」みたいなよくあるエンジニアの理想像は、たしかにそうだと思うが
そこを最も優先順位高く見てしまっていいのだろうか、という気もする
mrsekut.icon個人的には
モチベーションの根源を知りたい
だいたいこれに尽きると思っている
「理念への共感」とか「プログラミングが好き」とかはその具体例に過ぎない
金駆動でもいいし、名声駆動でもなんでもいいから、そこに自覚的であることと、それの正確性が重要だと思っている
モチベーションの根源がわかっていれば、自分でも、他者からもやる気を促進しやすい
「この人は金が得るのがモチベに繋がるのだな」とわかれば、利益が出るけど大変なことをやらせれば都合がいい
「金もらえるけど、ツライのはやだな」となればそれは多分金駆動ではない
モチベの根源を見間違えている
HRT原則
ってなに
テックブログに何を書くか
洗脳できればなんでもいい、か
会社にいて、人の距離が近ければ、少なからず互いに影響を受ける
であれば、極論を言えば、入社当初の性質はそこまで重視しなくてもいい
洗脳力があるならば、どんな人も、カルチャーに染めることができる
強いて言うなら、「洗脳しやすい人」を入社させればいいことになる
「洗脳するコスト」 v.s. 「良い人を探すコスト」の対立構造になる
「何を大事にしているのか」は聞きたい
プログラミングについてでも仕事についてでも
e.g.
プログラミングは楽しいのが大事
プログラミングは正しいのが大事
プログラミングはユーザーが大事
仕事なら何でもやるべき
楽して生きたい
「こう答えたら正解」みたいなのはないけど、ソレを聞いた上で合ってるかどうかは判断できそう
採用側の視野の狭さによって、重視すべき視点が全く異なる
例えばmrsekut.iconは
チームが複数あるような職場で働いたことがない
エンジニアがめちゃくちゃ多いような環境に身をおいていない
「人数が増えること」に対する危うさを理解していない
「採用面接」をした回数が少ない
というか0である
人の見定めに対するtry-and-errorの経験がない
採用に失敗した経験がない
採用面接
採用のためにSNSアカウントを見る
gituhbとか
/mrsekut-b/採用のためにSNSアカウントを見る
言うて、GitHubやプロダクトは結果に過ぎない
どちらかと言うと、ブログやScrapboxのような過程を見れたほうが良い
shinichiro hamaji (@shinh)
これはなんか僕の良い面接イメージとは違う気がする?一緒に問題を解いてくれそうか、困った時にどう対処するか、を見たいという気持ちが強いので、問題は相手にとって難しければなんでも良くて、自分が答えを知ってる必要もないと思っている。解けた解けないは重視しすぎないようにしているというか
shinichiro hamaji (@shinh)
解けてなくても、途中の考察や分岐のアイデアが良くて大満足、ってことも多いし、なんかそもそも話の流れで別の話になる場合もあるし。面接する側からすると時間内で情報をなるべく集めるゲームになってるので、出した問題が苦もなく解かれたり、手も足も出ない状態になるのは失敗、みたいに考えてる
採用ペルソナ
https://www.m3tech.blog/entry/2020/08/31/140000
どうなんだろ
面接対応する人が複数人いるなら有用かもしれん
1人で成し遂げるということについて|Keisuke69|note
「一人で作りました」をどう評価するか
https://blog.tinect.jp/?p=67893
『Learn or Die』にもなんか書いてたな
https://tech.smartcamp.co.jp/entry/started-technical-test
https://qiita.com/dorarep/items/b9f7f6ff6e1bc344cf0a
https://konifar-zatsu.hatenadiary.jp/entry/2020/10/27/223600
https://onk.hatenablog.jp/entry/2019/11/29/080831
https://medium.com/soelu-developers/エンジニアの採用基準について-5fbd8571bf33
https://anagrams.jp/blog/recruitment-process-optimization/
アナグラム株式会社