ジョブを選択する際の体積テストタスクの問題

テストタスクの履歴を見ると、同僚に警告したいパターンがあります。そのようなケースは、開発の専門化に関係なく定期的に発生する可能性が高いためです。 たとえば、私はそのような結論に至りました。私のアカウントでは、異なる年にそれぞれ2〜5営業日のボリュームで12以上のタスクを実行していました。 そして、結論は非常に逆説的であり、成功しなかった人々の間で論争と驚きを引き起こすでしょう。 開始の主な結論を定式化し、その後、実践からの例によってその理論的根拠を示します。



結論 ：（ソフィズム）1日以上のボリュームがあり、主な目標（仕事に就く）を持つテストタスクは採算が取れません。



雇用市場（ケースの5〜10％）では、企業から「ホーム」テストタスクを実行するよう申し出があります。 通常、少なくとも数時間かかります。彼らは単純なタスクを与えないようにします。 申請者にとって、このタスクがいつ、どのようなコミュニケーションのフェーズで提供され、どれだけの金額であるかが非常に重要であることがわかります。 タスクが完了するのに合理的または有益であることを常に意味するわけではありません。 非常に多くの場合、タスクには声明に欠陥が含まれており、テストを提供しない、または複雑で高速なテストを提供しない企業間で分離できない求人検索の戦略よりも、その実装の方が収益性が低くなります（たとえば、直接インタビューやSkypeオンライン経由で）。



Webフロントエンドでの数年間の作業の過程で、実行することが必ずしも有益ではないタスクが時々ありました。 私もこれを言います：テストタスクでの雇用の単一のケースは、いずれの側にとっても成功しませんでした-私にとっても雇用主にとっても。 同時に、わずかに異なる原則に基づいて構築された採用は成功しました。 理論的には、反対側が彼らの中で見ている目標ではない仕事、つまり雇用主を見ることに慣れています。 実際、彼らは主な機能を果たしていません。 ほとんどの場合、タスクの主な機能（8時間以上のボリューム）は機能しません。



1）エラーのない実行の場合でも、費やされた時間の正当化を保証しない;

2）この欠員に対して不均衡に大きな努力をする。

3）雇用主の立場から無責任を示す場合があります：テスト結果についてHRに通知しなかった。



そして、求人の数は全体の10％以下であるため、それらを満たさないという戦略でさえも理にかなっています！ しかし、私はこれを求めていません。「芸術への愛」からタスクを実行することが必要な場合もありますが、同時に（パラドックス！）成功した​​レセプション、つまり、 雇用のために行うべきではありません。

ソフィズムのデコード

このパラドックスを理解した上で、異なる年に実行されたこのような美しい例をいくつか見てみましょう。 つまり 私はこれらの特定のタスクを、雇用のためではなく、2番目または3番目の目標、つまり自分のためにポートフォリオを作成し、自分のために有用なユーティリティを作成するために実行しました。 課題の完了経験がこのような結論につながった理由-レビュープロセスで説明します。



経験はJavascript / CSS / HTMLの開発分野に限られていますが、開発とプログラミングの他の分野でも結論は当てはまると思います。



いずれにせよ、テストタスクの使用は素晴らしい芸術であり、誰もがそれを所有しているわけではありません。 タスクは、場合によっては有償でさえも、プラスの結果につながらなかったが、それ自体は能力や仕事ができないことを検出しなかった練習から、いくつかの鮮やかな例を示したいと思います。



長いタスクのパラドックスはずっと前に気づきました：実装の成功に関係なく、タスクがあったすべての空席は私のものではありませんでした（またはそうではない、1つの会社がありましたが、私は必要な時間よりもタスクに4倍多くの時間を費やしましたCSSはブラウザーの互換性の概念であり、質の高い結果を得るには多くのテストが必要です。 結局、私はそれらを比較的不十分に実行したからではなく、次のタスクが「良い」たびに​​「成功した」誰かが実行したからだと思います。 理由はより深い-心理学、システム、執筆タスクの分野。



2011年のある時点で、インタビューの1つで、雇用者と料金については面接しませんでした（インタビュー後、給与問題の議論中）。そして、サードパーティ組織からのHRの前で、彼は予期しない決定をしました：テストタスクを策定し、支払います。 ボリューム-約3日間。 彼らは契約書を書き、私もやり始めました。 タスクとサンプルのスクリーンショットに正確に従って、グラフを備えたこのような美しいウィジェットが見つかりました。 しかし、驚くことではないので、心理学の落とし穴がここに形成されました。

タスク-グラフウィジェット

デモへのリンク。

タスクの定式化には、さまざまなブラウザーのサポートが必要でした。 そして、ご存知のように、美しいウィジェットの角の丸い部分はIE6-8ブラウザーではサポートされていませんでした。 しかし、PIEライブラリは使用できませんでした-エンジンに大きな負荷がかかります。



これで、andな雇用者を演じました。 より正確には、彼でなく、私を監督した労働者です。彼が契約を明らかに不利なものに変えなければならなかった理由を私は知りません。 彼らはブラウザの互換性と契約の行を思い出した。「ウィジェットはすべてのブラウザで同じように動作するはずだ」。IE6-8の丸いコーナーをサポートすることを正式に意味した（2011年、彼はまだ生きていた！）作業量を約40％増やす必要がある、丸みを帯びたすべてのコーナーで画像をカットし、さらに2日間の明らかに粗い作業を行います。確かに誰も必要とせず、ウィジェットコンシューマのみが使用できます（PIEは使用できません）。 彼女はスキルからは何も見せず、顧客が本当にウィジェットを必要とすると仮定し、彼は仕事のこの部分を通常の仕事に（受けた後）移したくありませんでした。



申し出の最終金額がまだ不明だった瞬間を思い出してみましょう。したがって、仕事をやったとしても、申し分のない申し出を受けなかったかもしれません。 解決策は自然に生まれました。 仕事を終えることを約束したとしても、私はそれを終える理由を見つけることができませんでした。 2日後、1回のインタビューの後、テストタスクなしで大企業から求人が表示され、3日目に仕事をしました。 公式に完了したテストタスクを完了し、給与レベルでほぼ2倍を失いましたが、意味がありませんでした。 同時に、顧客はテストタスクの無料の部分を受け取り、それで満足することができましたが、テストページを受け取りました。これは私の仕事の例として示すことができます。 これを費やした時間としますが、その結果によると：



1）ウィジェットと設定の3つのインスタンスを持つ設計されたテストページ。

2）DOMオブジェクトとHTMLテンプレートエンジンの継承を適用​​した経験。

3）グラフ作成のためのライブラリの使用。

4）JSONおよびXMLを入力として使用する例。



テストタスクの潜在的な報酬は、タスクを実行するためにまったく価値がないことが判明しました。 したがって、タスクはそのような機能を果たしませんでした。



1）実行に実質的に興味がない;

2）顧客による契約の解釈は、それを財政的に不利なカテゴリーに移しました。

3）メインタスクから注意をそらす-検索と動作するデバイス。

4）後続のオファーの条件の不確実性の条件で実行（オファー）。



作業が私にとって個人的に有用であることが判明したという事実は、私がこの問題を唯一の目的ではなく、書かれたコードを再利用する目的で解決しようとした結果です。 テストタスクに二重の目標を設定すると、多くの場合、その無料実行に同意できます。



この事件の後、その後数年間にさまざまな種類のテストタスクが少なくとも12個ありました。 以前のように、課題の通過とともに仕事をする必要はありませんでした-課題を与えたい人の10％以下でした。 怠zyな求職者にとっては、決してタスクを完了しないように冷笑的にアドバイスすることもできます-これで、彼は多くを失うことはありません。 しかし、それにもかかわらず、商業ソフトウェアの世界でのオープンソースとして、彼らは時々有用な組織化の役割を果たします。



タスクが申請者の自己教育を目的とし、開発者にとって有用な問題を解決する場合、そのようなタスクを実行することは、「名誉の問題」であり、個人的な成長の道と見なされることがあります。 時間が許せば、ためらうことなくタスクを実行することが可能であり、タスクは権威ある組織の環境から来ます。それはいずれの場合でも代表者と話すのに役立ちます。 2013年にmail.ruを使用しました。

タスク-テキストフィルター

デモ1へのリンク。

デモ2へのリンク（単語の強調表示）。



最初の会議の前に、彼らは2つのタスクの美しく定式化されたテストタスクを送信しましたが、その解決時間は約1営業日または少し長いようでした。 2番目の用途が何であるかはすぐに明らかでした。 完全に些細なタスク（2つ）ではない彼のコードの例に加えて、大きなテキストデータ配列に対する高速JSフィルターの例が得られます。 作業の速度を説明するために、約10万個のランダムな単語のセットを生成し、ユーザーが入力した単語のサンプルに従って単語を検索しました。 最初のタスクでは、それらは強調表示され、2番目では-見つかったフラグメントを含む行のみが表示されました。 1000行のうち、5行、2行、またはまったく行がなく、ゼロ行が即座に画面に残りました。



タスクの主な実際の使用法も奇妙に消えます。 はい、私はこの後にインタビューに招待され、成功し、誰もがすべてが好きでしたが、mail.ruにはいくつかのインタビューがあり、翌日、Skypeでの不在インタビューの後、2回、別の会社で仕事を提供されました自宅に近く、間違いなく悪い状態ではありません。 繰り返しますが、テストタスクの短命の可能性を実際に実現することはできませんでしたが、それらは今後も非コア目標を達成するために残りました。

不合理なタスク

最後に、このようなタスク（テストタスク）を思い出します。短い分析（20〜30分）で、それらを実行するのは絶対に利益がないという結論に至りました。 通常、雇用主への手紙はこれについて書かれており、そのようなタスクの実施に不当に長い時間が必要であり、申請者として不当に低い選択の機会を与える理由を正当化します。 これについてはさらに30分間の執筆が意識的に費やされますが、雇用主が間違っていることを正当化する厄介な立場に置かれなければならないという事実を除き、ほぼ正しい分離が得られます。 通常、雇用主は新しいアイデアなしでタスクをキャンセルしたか、または応答しませんでした。



なぜそのようなタスクを実行するのが不合理なのですか？ 通常、これらは解決するのに2日以上（16営業時間以上）必要なタスクであり、時間がないか、雇用主について何も知りません。 つまり、彼は給料についても、労働条件についても話せませんでしたが、すぐにタスクを与えることができました。タスクは、しばしば「小さい」と呼ばれますが、「5分間ではありません」。 すでにそのようなフレーズで、2〜5日間のゆったりとした仕事について話していることを理解できます。 非常に多くの場合、このようなタスクにはあいまいなステートメントが付随しており、問題のステートメントの不確実性の検索で余暇を練習できます。 たとえば、境界条件（ゼロまたは大量のデータがある）の場合のWebフォームの動作については何も言われていない、フォームに記入するいくつかのケースを検証するための条件が指定されていない、意味で使用する必要がない場合は「Angularを使用する」必要がある再読み込みページ）。 これらのパズルの中には、マスター自身がやったことがないと推測されています。



そのような場合、タスクの「腐敗」（湿気）を時間内に認識し、「低品質の商品を購入しない」ことが必要です。 同時に、外交的で丁寧なアプローチは、雇用主との正しい関係を維持するのに役立ちますが、これは、候補者を見つけるための考え抜かれたキャンペーンを示唆している可能性が最も高く、空室の反対側で雇用主に教えることは不可能であり、無意味です。



過去1年間にこのような慎重に検討されていない割り当てには2つの実際的なケースがあります。 より正確には、雇用主とさらに話す権利を得るため。



ここでは、もちろん、他の雇用主の95％がそのような障害を引き起こしていないことを説明する必要はありません。 また、自由時間を自分のプロジェクトに費やしたり、履歴書で通常の就職活動やその他の自己宣伝に費やしたほうが有利です。

どんな仕事を歓迎しますか

求職者を募集する前に実際の例を見てみたい雇用主を理解できます。 相互に受け入れ可能な対話のオプションとして、Skype / Jabberを介してオンラインでタスクを完了し、思考の流れに即座にコメントを付けるなどのオプションがあります。



このようなタスクにおいて、大きな利点は、面接対象者が時間をどれだけ費やすかを気にしていないことを申請者が見ることです。 面接官自身は、仕事の過程で申請者の不十分な能力が明らかになったとしても、時間を無駄にしません。 タスクは、迅速に、条件付きで解決するか、相互に置き換えることができます。 彼らは2時間の電話インタビューについて話しますが、実際にはそのような20分間のインタビューに出くわしました。



許容可能なタスクの別のオプションは、2〜5時間程度の時間の無駄を伴う場合です。 たぶん最後にすぐに電話で。 このようなタスクを作成するには、ソリューションの複雑さのバランスを選択する特定のスキルが必要です。 タスクを難しくしすぎることはできません。 自明ではない解決策でタスクを思い付くことができません-解決策を提案する必要があります。主な目標は知識を確認することであり、申請者の時間を無駄にしないことです。 私自身は、雇用主の代わりに、空席の反対側で、そのようなタスクの例を作成しようとしました。 どうしたの？ 単純に割り当てられたタスクであっても、誰もが完了できるわけではありません。 そして、ここでは、申請者が費やすことをいとわない時間の資格があり、おそらく、このタスクを完了するための条件が不明確に定式化されています。



応募者は、どの条件でタスクに時間を費やすことに同意するかを知ることが非常に重要であることを思い出してください。 おそらく算数の知識のための最も簡単なテストを除いて、雇用の条件を明確にする前にタスクを与えることは意味がありません。



その結果、申請者のテストタスクは非常に安全な選択ツールではないと言えます。 彼らは採用キャンペーンで危害を加えることは非常に簡単であり、志願者の心理を無差別に考慮せずに行動します。 これは、まだ宣伝されていない製品に不当な価格を付ける場合と同じです。 そのような空室は単に買われません。



応募者へのヒント：

*）テストタスクについて聞いた後、問題のステートメントに基づいて実行量を推定し、実行前にそれらを明確にするために定式化のエラーと不確実性を評価します。

*）実装に時間をかけることが有益であるかどうかを評価し、受信が成功する確率を評価します。 実行が成功した場合にそのような給与を受け入れるという約束は、ほとんどの場合そうではないことに留意してください。

*）仕事やその他のインタビューを探している過程で、今すぐこのタスクを行うことが有益かどうか、そしてあなたにとって有用な製品（ポートフォリオ、オープンソースプロジェクト）になるかどうかを評価してください。

*）雇用主は、あなた自身の目的のためにあなたによる彼の問題の解決策の公表に反対するかどうかを確認してください。

*）すべての質問に対して-答えが「はい」の場合-テストタスクに進みます。