ライオンと魔女、そしてリクルーターの厚かましさ
(hauleth.dev)- 求職者が2社の採用プロセスを経験し、役割のミスマッチとフィードバックの非対称性が候補者の時間をどのように消耗させるかを批判
- Hop.NSは「Senior Elixir Developer」ポジションとして1週間のtrial contractを実施したが、実際の課題はTypeScriptブラウザ拡張の保守とUI機能追加だった
- trial weekの序盤はSlack、GitHub、設計テンプレートへのアクセス権の確保に時間を取られ、約10〜12時間が経ってようやく拡張機能をローカルで実行できた
- PerhapsMaybeは5時間以上の技術面接を行った後、個別フィードバックを拒否したが、1週間後に候補者体験アンケートを送り、候補者にだけフィードバックを求めた
- 企業が長い時間と誠意を求めるなら、役割説明の正確さ、個別化された不採用理由、候補者への敬意もあわせて提供すべき
Hop.NS: Elixirポジションがブラウザ拡張の課題に変わったtrial week
- 求職者はLinkedInで、以前の同僚が働いているHop.NSの求人を見て応募した
- 会社名と一部の詳細は、法的問題を避けるために変更された名称である
- 以前は1週間のtake-home projectを求め、その時間に対して報酬を支払っていた会社だった
- 募集はSenior Elixir Developerで、CTOとの通話でもElixir開発者の役割、チーム、プロセスについて話し合われた
- CTOは、1週間のtrial contractの間に「採用された場合に担当する作業」を行うことになると説明した
- 契約書類は問題なく進み、月曜日09:00にtrial weekが始まった
Day 1: アクセス権の問題と実際の課題の開示
- 初日に一時的な会社メールの認証情報は受け取ったが、Slack workspaceには入れず、管理者に問い合わせるようにというメッセージだけが表示された
- 連絡手段がなかったため、LinkedInで社内の知人にメッセージを送り、アクセス権の依頼を頼んだ
- 40時間契約のうち2〜3時間がSlackへのアクセス問題で消費された
- その後、GitHubのアクセス権も追加依頼と待機の末に得られ、リポジトリをcloneできるようになった
- 監督者が南米にいたため、課題説明の通話は18:00に設定され、それまではElixirコードベースを眺めながら小さな修正PRを開いた
- 夕方の通話で、trial weekの課題はTypeScriptブラウザ拡張の保守と新機能・UIデザインの追加だと判明した
- 求職者はその領域の経験が少ないと確認したが、担当者はその課題で間違いないと答えた
- 担当者は「バックエンド作業はすでにすべて終わっているので心配する必要はない」と述べた
- 求職者は、自分が望んでいたバックエンド/Elixirの仕事はすでに終わっており、望んでいないフロントエンド寄りの作業をしなければならない状況だと受け止めた
Day 2: 実行環境の構築と役割ミスマッチの確認
- 2日目には、ブラウザ拡張を実行して理解するためにGoogle Chromeのインストールが必要だった
- 求職者は普段SafariとFirefoxを好み、Chromeの使用を避けていた
- ローカルビルドと実行方法を把握するのに数時間かかり、追加の認証情報とアクセス権を得るために他の人たちと連絡を取り続ける必要があった
- 推薦してくれた知人との会話で、trial weekの課題が候補者の専門領域と完全に異なることがあり得るのかを尋ねた
- 知人は、候補者をcomfort zoneの外に置くことはあるが、バックエンド開発者に純粋なフロントエンド作業が与えられるなら何か問題が起きていると答えた
- 自分なら同じ状況ですぐに中断していただろうとも述べた
- 求職者は、推薦してくれた2人への敬意からプロセスを続けることにした
- 採用専用のSlackチャンネルで「採用されたらこのプロジェクトを引き続き担当するのか、それとも別の仕事をするのか」と尋ねたところ、回答は「常にそうとは限らない」だった
- 設計テンプレートを受け取るために再び担当者を追いかける必要があり、trial weekの40時間中10〜12時間が過ぎてようやくブラウザ拡張をローカルで実行できた
Day 3: 課題範囲の拡大とtrialの中断
- 3日目には作業の進め方と必要なことをある程度理解していたが、ブラウザ拡張のデバッグ知識は依然として不足していた
- trial weekの中間にあたる3日目の正午ごろ、会社は課題範囲をさらに拡大した
- 求職者は、課題が採用プロセスで説明された内容とまったく合っていないと長文のメッセージで抗議した
- 職務説明にはTypeScriptやブラウザ拡張に関する内容がなかった
- 本人は自分が「backend-and-ops」志向のエンジニアだと何度も強調していた
- この課題は自分の時間も会社の時間も無駄にすると考えた
- すぐに中断しなかった唯一の理由は、自分を推薦してくれた知人たちへの敬意だったと明かした
- CTOは「文化に合うか」を確認しようとしたのだと答え、会社が間違ったことをしたとは感じていないとして、記事を公開しないでほしいと求めた
- Hop.NSは苦痛だった約20時間の作業については費用を支払った
- 3〜4週間後、CTOはLinkedInでStaff Software Engineerポジションに興味があるかを尋ね、求職者はまだbait-and-switch戦術を使っているのかと聞き返した
PerhapsMaybe: 長い面接の後にフィードバックはなく、アンケートは求める
- PerhapsMaybeにはSoftware Engineer with Elixirポジションがあり、会社に知人がいたため応募した
- ある知人が、そのポジションのhiring managerと思われるVP of Infrastructureの前に応募書類を上げてくれたが、プロセスは速くなかった
- 応募情報は2026年5月27日に送った
- 採用チームからの最初の連絡は2026年6月11日で、2週間以上後だった
- LinkedInでVPに招待を送ってようやく採用担当者から連絡が来た
- VPとの1時間の通話は順調で、役割への関心がさらに高まった
- その後、技術面接の日程調整が続き、面接全体は5時間30分の予定になった
PerhapsMaybeの面接構成と不採用通知
- 面接は1日で行われ、各セッションの間に30分と2時間の休憩があった
- 構成は3つの部分だった
- Systems Design 1時間: 同期式決済ゲートウェイを使う非同期決済システムの設計
- Coding Interview 1時間: cross productと、キーパッド上でのチェスの駒の移動のようなLeetCode風の課題
- Technical Deep Dive 1時間: 過去のプロジェクトであるUltravisorの技術的詳細の説明
- 求職者はコーディング面接の2つ目の課題でbig-O複雑度分析のミスをしたが、全体として解法は悪くなかったと感じた
- Technical Deep Diveでは本人としては問題ないと感じたが、相手が感銘を受けていないか、別のものを期待していたようだという直感を得た
- 面接後2日目が終わるころに採用担当者へアップデートを尋ね、不採用通知を受け取った
- 不採用メールには「応募者が多いため個別フィードバックは提供しない」という文が含まれていた
候補者体験アンケートが生んだフィードバックの非対称性
- 不採用から1週間後、PerhapsMaybe Hiring TeamはCandidate Experience Surveyのメールを送った
- メールでは、採用プロセスが効率的で候補者体験が良いものかを確認したいとして、最近の面接体験について率直なフィードバックと改善点を求めていた
- 求職者は、会社が約5時間分の録画と自動会議メモを持っている可能性があると見ていた
- 本人は会議メモにAIを使うことを禁じられていたと述べた
- 会社は3〜4文の個別化された不採用理由を提供しない一方で、候補者にはプロセス改善のフィードバックを求めていると批判した
- 求職者は、自分が候補者ではなく採用プロセスを評価する契約者のように扱われたと考え、契約者レートで請求書を送るためのbilling detailsを求めた
採用市場への批判と例外的に好意的だった事例
- 求職者は、現在の採用市場は壊れていると表現した
- 一部のrecruiterは、応募プロセスでのLLM使用を非難すると言及した
- 応募書類には「なぜXYZで働きたいのか」「XYZで働くことの何が最も興味深いのか」といった質問がよく含まれると批判した
- 求職者は、会社の製品をその会社に売り返すように説明するのは自分の仕事ではないと考えている
- 自分は興味のある仕事をし、その対価としてお金を受け取りたいのだと述べた
- 会社の製品に本当に興奮できるのは創業者だけであり、IPO後は株主も価値の上昇だけを望むと表現した
- 例外的にFreshaの応募プロセスでは、Christine Wongが好意的な事例だった
- 不採用理由は「coding agentsの経験不足」だった
- Christine Wongは、個別化されたフィードバックを直接伝えるために通話を設定したいと申し出た
- 求職者は、候補者に敬意を示す実在の人を見られたのは良かったし、その経験に感謝していると述べた
1件のコメント
Lobste.rs の意見
候補者をコンフォートゾーンの外へ押し出すやり方だという話は、結局のところ、欲しい人を選ぶための口実を作って他の要素は無視するという意味に聞こえる
バックエンド開発者に純粋なフロントエンドの仕事をやらせたうえで「カルチャーフィット」を見るというのは、魚に木に登れないと文句を言うようなものだ
チームの採用と解雇を労働者たちが、少なくとも自分のチームについてでも、コントロールできない限り、こういうふざけたことは続くのだろう
この記事の筆者にはそこまで強く共感しなかった
企業環境では、アクセス権を得たり別のタイムゾーンの人と話したりするのに1日かかることはそれほど衝撃的ではなく、こういう状況にどう反応するかはカルチャーフィットを見るうえで良いシグナルになる
最優先の仕事があらかじめ決めていた役割の範囲外にあることも珍しくなく、自分の範囲を越えて働ける候補者は、特定の範囲にだけとどまる人より会社にとって価値が高い
もちろん専門外の仕事をさせれば進みは遅くなり、結果も悪くなりがちだが、会社は outright に断るよりはそちらを好む可能性が高い
採用担当者が面接日程を組むのに何週間もかかったり、LinkedIn で副社長に連絡したら手続きが早まったりするのも、企業環境では不自然ではない。いつ副社長に連絡すべきかを知っていることも仕事の一部だ
候補者にはフィードバックを与えないのに採用担当者がフィードバックを求めてきたなら、その点がいちばん印象に残ったと伝えること自体が良いフィードバックになりうる
いちばん引っかかったのは、冒頭の取り消し線付きの「bitch」という表現だった。同僚や将来の同僚をそう呼ぶのは絶対に許されない。意見の衝突はあっていいが、性別を狙った人格攻撃はだめだ
求人票には純粋なバックエンド業務と書かれていて、私もほぼバックエンドとシステム運用しかやってこなかったと伝えていた
それなのに純粋なバックエンドの仕事を提案しておいて、突然こちらがまったく知らない課題を出し、最大32時間以内に「システムの残りと整合する設計」の動く解法を期待するなら、それは私の経験と知識への無礼としか思えない
バックエンド開発者として10年以上働き、そのうち7年ほどは可観測性とパフォーマンスを扱ってきた。フロントエンドを比較的多くやったのは、8年前に既存の Vue アプリケーションへ機能を追加した程度だった
こんな課題で私の経験や知識を評価しようというなら、自分は望まれていないと判断するしかない。そうと丁寧に言わず、意味のないことを強いて苦労させるのは、ほとんど侮辱に近いと思う
採用日程に何週間もかかるのも私には驚きだった。その会社のシニア／プリンシパル／スタッフ級エンジニアが2週間前にその副社長へ私を推薦していて、その副社長がそれを確認していたと知っていたからだ
フィードバックは提供したし、採用担当者に採用プロセスのコンサル費用を請求できるよう請求先情報も求めた
幸い、フィードバックを得る別の方法もある。私は EU にいるので、GDPR のおかげで自分の採用プロセスに関するすべてのメモや詳細情報を請求できる
企業的な話し方というのは、人生のあらゆる大きな問いで正反対にいる二人であっても、会社の目標に向かってうまく一緒に進めるようにするために存在する
私も同じように読んだ。友人同士での愚痴の文章だとは分かるが、面接の段階でこういう態度が少しでも見えたなら、おそらく面接は断っていただろう
自分の専門範囲の外で働こうとする姿勢は雇用主にとって価値があるだけでなく、自分の領域の中だけにとどまると分からなかったキャリアと学習の機会を開いてくれることもある
大事なのはその境界がどこにあるのかを伝えて、期待値とスケジュールを適切に合わせることであり、それができるかどうか自体が面接で強いシグナルになる
ただしバランスは必要だ。すでにキャリアの方向性が非常に明確で、求められているプロジェクトがその方向に連れていってくれないなら、時間を別のところに使ったほうがいいかもしれない
しかし自分と雇用主の目標が衝突するからといって、それを個人的な侮辱として受け取ったり、橋を焼くリスクを負ったりはしないと思う
これだけを見たら採用しないと思うし、幼稚でプロらしくないと感じる
最近かなり興味深いことがあった。ある会社の採用担当者から連絡が来て、話してみる気はあるかと聞かれたので、その会社の製品を毎日使っていた私は承諾した
通話が始まると採用担当者は「それで、何をお探しですか？」と聞いてきたが、私は何も探していなかった。向こうから声をかけてきたのだから、私が会社を説得するのではなく、会社が私を説得しようとしているのだと思っていた
それでも、ただの決まり文句だろうと思って、会社が何をしているかなどを1時間ほど話した。最後に、3回の技術面接を経てオファーにつながる可能性のあるプロセスを続ける意思があるかと聞かれ、安定した仕事がある比較的有利な立場でもあったので、面白そうだと思って承諾した
採用担当者は通話後にメールを送ると言い、挨拶を交わした
ところがほぼ1週間、メールは来なかった。結局こちらから、もしかして忘れていないかとメールを送ったところ、数日後に今度は手続きを進めないことにしたという返事が来た
応募すらしていないのに不採用通知を受けたようなもので、妙に傷ついた
しかもそれで終わりではなかった。数週間後、大きなプログラミングカンファレンスに参加していたら、その採用担当者から、自分たちもそこにいるので夕食を一緒にどうか、そして面接プロセスを再開する気はあるか、というメールが来た
向こう持ちだというので夕食には行き、会社のエンジニア数人と楽しく話した。だが、自分がプロセスを止めたわけでもないのに、なぜ再開が選択肢になるのか、なぜそれが私の責任のようになるのかは不思議だった
こういうやり取りに備えられるよう、広く読まれる企業 IT 環境ガイドのようなページが必要だと感じる
そこで起きていることを擁護したいわけではないが、多くの人は現実をよく知らない
内部でも外部でも遅延は起きる。アクセス権を得る過程で1日失うのは普通で、予想できることだ
手続きは遅れ、個人の成功や失敗ではなく全体指標を見るプロセスの中の小さな歯車になる
多くの場所ではフィードバックを一律に出さない方針を取っている。潜在的な損失は訴訟で、潜在的な利益はないからだ
コミュニケーションはしばしば悪く、職務テストが変わったり抜け落ちたりすることもある
こうしたガイドは期待値を合わせる助けになり、こういう日常に耐えたくない人をふるい分ける役割も果たせるかもしれない
その中で終わらせるには、手続きの外にいる人たちや第三者のコミュニケーションチャネルを使ってアクセス権を取る必要があった
通常業務なら待てるので遅延が普通でも、採用プロセスは私の日常業務に影響してはならない。これは大きな違いだ
フィードバックを出さない方針についても、私は EU にいて GDPR の適用を受けるので、自分に関するあらゆる詳細情報や内部メモを請求できる
結局彼らが得るのは、プロ意識がないように見えるという印象と、このプロセス全体が正当な採用ではなく採用プロセスのコンサルティングのように感じられるということだけだ
期待値を合わせ、人をふるいにかけるのはよいかもしれないが、私がもっと時間が必要だと言った場合に、彼らにも同じ基準が適用されるのかは大いに疑わしい。だから不公平な優位が生まれる
今振り返ると、何もせず、アクセス権を求めて急かすこともせず、週末まで彼らのマシンが動き出すのを待って手当だけ受け取るべきだったのかもしれない。そうしていれば、そこまで気に病まずに済んだ気がする"}】【。json to=functions.submit_translation 彩神争霸下载 ＿色ি? սխալ