Buzzwordに報酬しないSystem Design Rubric
Buzzwordの問題
「Redis Cacheを前に置き、User IDでShard、Event BusにKafkaを使用し、Kubernetesで実行する」と言う候補者は、シニアに聞こえます。彼らはシニアかもしれません。彼らはYouTubeビデオを記憶したかもしれません。BuzzwordでスコアするRubricは違いを見分けることができません。
修正は、言葉自体ではなく、言葉の間の推論をスコアすることです。
スコアする価値がある5つのRubric Dimensions
1. Requirements明確化
候補者は描く前に尋ねましたか？「読み取り/書き込みRatioは？ユーザー数は？Latency Budgetは？失敗モード Xはどのようなもの？」シニアエンジニアはPromptを曖昧として扱います。新人はそれをSpecとして扱います。
スコア：彼らはDesignを有意に変更する制約を少なくとも1つ発見しましたか？
2. Trade-off表明
すべてのComponentの選択について（Caching、Sharding、Consistency Model）、彼らはTrade-offを名付けましたか？「Postgresは書き込みボリュームが低く、TransactionsがほしいのでPostgresは問題ありません」は、答えが同一であっても「私たちはPostgresを使うでしょう」を打ち負かします。
スコア：陳述された別の選択肢と理由を伴うDesign Choicesの数。
3. Failure-mode推論
CacheClusterが落ちたらどうなるか？Message Queueがラグしたら？LeaderがFailoverしたら？シニアエンジニアはFailureを予測します。経験の少ないエンジニアは、Happy Pathのみを設計します。
スコア：彼らはUnprompedでシステムの最も可能性の高い失敗モードを特定しましたか？
4. Cost と Operational認識
Side Projectに月額40,000ドルの費用がかかるDesignは間違っています。100人のユーザーを持つ機能の24/7 Oncall RotationのRequireするDesignは間違っています。Cost認識（お金、複雑さ、ヘッドカウント）は、紙の上でシステムを運用したエンジニアを分離します。
スコア：彼らはUnprompedでCostまたはOperational Burdenについて推論しましたか？
5. 修正の下での通信
あなたが反論すると、「待ってください、しかし、X の場合はどうなるか？」候補者はGracefully更新するか、防御的に掘り込むか、パニックになるか？すべて3つがSignalです。Gracefullyの更新はあなたが望むものです。考え抜いた立場を防御することは問題ありません。パニックになり、Wildly枢軸は多くはありません。
スコア：1つの標的化されたPushbackに対する対応の品質。
それを使う方法
- 各Dimensionを1～4でスコアし、各レベルがどのようなものであるかの説明をアンカーにします。
- 他のInterviewersをDebriefする前にIndependentlyスコアします。
- RubricをPeerスコアを読む前に提出します。ClarityHireのInterview ReportsはRubricをロックするため、Peer Scoresを見た後は編集できません。
- DimensionsをRoleに重み付けします。StaffエンジニアLoopはFailure-mode推論とCost Awarenessに重み付けする必要があります。シニアLoopはTrade-off表明に重み付けできます。
Rubricは、記憶された候補者がパスするのを防ぎません。それは記憶された候補者が容易にパスするのを防ぎます。そしてそれはほとんどの価値です。