フロントエンド開発者のコーディングテスト設計:実際の職務に反映する
ClarityHire Team(Editorial)5 min read
フロントエンド職務が実際に必要とするもの
ほとんどのフロントエンド業務はアルゴリズムではありません。それは:
- 見慣れないコンポーネントツリーを読み、状態がどこにあるかを見つける
- エッジケース(ロード中、エラー、空)を壊さずにAPI応答をUIに配線する
- デザイナーがモックアップしたより長いコンテンツで生き残るCSSを書く
- 再レンダリングがパフォーマンスバグの原因であることを認識する
- 依存関係を追加する時期と追加しない時期を知る
LeetCodeバイナリツリーを逆にする質問はこれのいずれもフィルタリングしません。さらに悪いことに、実際の職務で優れており、アルゴリズムパズルに関心がない候補者をフィルタリングアウトします。
実際の事をテストする90分テスト
候補者に3つの問題のある小さなReactアプリを提供します:
- 微妙なバグ。 リストが単一の変更で全行を再レンダリングします。キープロップが配列インデックスであるため。リストは100個以上のアイテムではラグいですが、明らかに破損していません。
- 不完全な機能。 ロード状態またはエラー状態を処理しないPOSTするフォーム。
- スタイリング問題。 タイトルが40文字より長い場合にレイアウトが壊れるカードレイアウト。
3つをすべて修正するよう求めます。実行中のアプリ、コードベース、ライブラリの追加の自由(またはそうしない)を提供します。
これは実際のスキルを測定します。見慣れないコード、認識パターン、依存関係を追加するときの判断、CSSの味、エッジケースの完全性を読むこと。
ルーブリック
1~4で4つの次元をそれぞれ採点し、固定:
- バグ診断。 修正する前に原因を特定しましたか?それとも症状にパッチを当てましたか?
- エッジケースの完全性。 ロード中、エラー、空 — 促されずにカバーしましたか?
- コード品質。 命名、構造、依存関係の選択。
- 通信。 コメントまたはトレードオフを説明する短い注記を残しましたか?
シニア候補者は定期的に4つすべての次元で3~4を採点します。テストは判別するのに難しい必要はありません — それは実際のである必要があります。
それが漏れずに管理する方法
- 3~4の破損アプリバリアント間で回転します。
- 候補者をランダムに割り当てられたバリアントに固定します。
- ClarityHireのキーストロークとコード整合性整合性シグナルを使用して、他の場所から修正をペーストした候補者がフォローアップ呼び出しでレビュアーがプローブするようにフラグが立てられます。
- 候補者が変更をウォークスルーする30分間のフォローアップと常にペアリングしてください。自分の差分を説明できないと、スコアは低下します。
絶対にしてはいけないこと
- 4時間のテイクホーム。時間を尊重する会社に最高の候補者を失うでしょう。
- オープンエンド「Xのクローンを構築します。」分散が高すぎます。ルーブリックは壊れます。
- ゼロからローカル環境をセットアップする必要があるテスト。ホストされたIDEを使用してセットアップ時間がゼロです。
正しいフロントエンドテストは90分かかり、火曜日の朝のチケットをミラーリングし、デブリーフで防御できるルーブリックスコアを生成します。
フロントエンドコーディングテスト評価設計react