کدام تمرین ارزش وقتت را دارد؟Which exercises deserve your time?
۴۷ تمرین DDIA با صورت مصاحبه‌ای، آزمایشگاه تکمیلی و حل آموزشی؛ برای هر تمرین، فرض‌ها، معیار پاسخ و دلیل تصمیم‌ها را در پاسخ دنبال کن.47 DDIA exercises with focused interview briefs, optional laboratories and worked solutions. Follow each answer for assumptions, evaluation criteria and the reasoning behind decisions.
ممیزی اولیه: ۱۴ اکتبر ۲۰۲۶ · اصلاح فنی: ۱۵ اکتبر ۲۰۲۶ · Backend / Distributed SystemsInitial review: 14 October 2026 · Technical corrections: 15 October 2026 · Backend / Distributed Systems
راهنمای استفاده از تمرین‌هاHow to use the exercises
ابتدا صورت مصاحبه‌ای را در زمان پیشنهادی حل کن و تصمیم‌هایت را با معیار پاسخ بسنج؛ سپس حل آموزشی و آزمایشگاه همان تمرین را بخوان. فرض‌ها و مرز تضمین هر مسئله در متن آن آمده‌اند و نکته‌های فنیِ اصلاح‌شده در بخش بعد به سؤال و پاسخ مربوط لینک دارند.Solve the interview brief within its suggested time, evaluate your decisions against the criteria, then study the worked solution and optional lab. Each exercise states its assumptions and guarantee boundaries; the resolved technical points below link to the corresponding question and answer.
در راهنماهای رسمی Amazon و Atlassian، توضیح نیازها، انتخاب، تریدآف، مقیاس، هزینه و قابلیت اطمینان مبنای ارزیابی‌اند. راهنمای Microsoft نیز حل مسئله، تست و طراحی سیستم‌های توزیع‌شده را نام می‌برد. بنابراین برای هر تمرین، یک صورت‌سؤال با زمان محدود و نشانه‌های پاسخ خوب نوشته شده است. این نگاشت و برچسب‌ها استنباط آموزشی ما هستند.Amazon and Atlassian emphasize requirements, design choices, trade-offs, scale, cost and reliability; Microsoft also names testing and distributed-system design. Each exercise therefore has a bounded discussion brief and answer criteria. This mapping and the labels are our editorial inference.
تمرکز این ممیزی Senior/Staff در Backend و سیستم‌های توزیع‌شده است. برای نقش Data، Storage، SRE، Payments یا ML، اولویت تمرین‌های تخصصی تغییر می‌کند. این مجموعه به‌تنهایی آمادگی coding/DSA، product architecture، project deep dive و رفتار/رهبری را پوشش نمی‌دهد.The target is Senior/Staff backend and distributed systems. Data, storage, SRE, payments and ML roles change the specialist priorities. This set alone does not cover coding/DSA, product architecture, project deep dives or behavioral/leadership interviews.
این نمودار اولویت آموزشی ما را نشان می‌دهد، نه احتمال طرح سؤال.This chart shows our study priorities, not the probability of an interview question.SVG
معنای برچسب‌هاHow to read the labels
سطحLevel
انتظار از نسخهٔ مصاحبه‌ایExpected interview reasoning
L1 · Foundations
محاسبه و فهم دقیق یک مفهوم؛ پیش‌نیاز پاسخ‌های لول بالا است.Accurate calculations and one concept: prerequisites for advanced answers.
L2 · Senior
نیاز و invariant، طراحی قابل اجرا، trade-off، failure و معیار صحت/عملکرد.Requirements, invariants, practical design, trade-offs, failures and measurable correctness/performance.
L3 · Staff / Principal
مرز تضمین‌ها، چند failure domain، migration/recovery، هزینه و اثر تصمیم بین اجزا یا تیم‌ها. حل این تمرین به‌تنهایی معادل احراز عنوان شغلی نیست.Guarantee boundaries, multiple failure domains, migration/recovery, cost and cross-component/team consequences. Solving an exercise alone does not establish a job level.
اولویت اصلی: ابتدا برای این مسیر بخوان. وابسته به نقش: در deep dive همان تخصص سرمایه‌گذاری کن. مکمل: برای آگاهی و بحث مرتبط، پس از هسته. زمان‌ها تخمین ما برای بحث‌اند؛ ساخت آزمایشگاه جدا و طولانی‌تر است.Core: study first for this track. Role-specific: invest when aligned with the target specialty. Supplementary: deepen relevant discussion after the core. Times are our discussion estimates; full implementation labs are separate and longer.
امتیاز دادن به پاسخScoring a response
برای هر کدام از پنج محورِ «روشن کردن مسئله و invariant»، «طراحی»، «trade-off و عدد»، «خرابی و recovery» و «آزمون و توضیح روشن» از صفر تا دو امتیاز بده: صفر=غایب/غلط، یک=ناقص، دو=دقیق و قابل دفاع. این rubric آموزشی است؛ حد قبولی شرکت‌ها را ادعا نمی‌کند. معیارهای اختصاصی زیر هر تمرین را هم بررسی کن.Score five dimensions from 0–2: requirements/invariants, design, quantified trade-offs, failure/recovery, and testing/clear communication. Zero means absent or incorrect, one incomplete, two precise and defensible. This is a practice rubric, not a company hiring threshold; also check each exercise’s specific criteria.
نکته‌های فنیِ اعمال‌شده در تمرین‌هاTechnical clarifications applied to the exercises
فصل 2 · تمرین 1Chapter 2 · Exercise 1: روز آموزشی ۸۶۴۰۰ ثانیه و ضریب اوج ۱۰ است؛ هر سفارش سه پیام اعلان می‌سازد. کش، یک سطر خلاصهٔ سفارش با کلید order_id در k مقصد منطقی است؛ k را جدا از سه سرویس تعیین کن.A teaching day has 86400 seconds and the peak factor is 10; each order emits three notifications. The cache stores an order-summary row keyed by order_id in k logical destinations; k is independent of the three services. · دلیل و حل آموزشیReasoning and worked solution
فصل 4 · تمرین 3Chapter 4 · Exercise 3: الگوی /appl./ دو trigram ثابت app و ppl دارد؛ اشتراک postingها فقط نامزد می‌سازد و regex نتیجه را تأیید می‌کند. recall@k با exact top-k مقایسه می‌شود.The pattern /appl./ requires app and ppl; intersect their postings to find candidates, then verify the regex. Recall@k compares approximate results with exact top-k. · دلیل و حل آموزشیReasoning and worked solution
فصل 6 · تمرین 2Chapter 6 · Exercise 2: هر دو دستگاه ابتدا milk:t1 و bread:t2 را دیده‌اند؛ فاز اول add تازه ندارد. حذف tag مشاهده‌شده با حذف یک add هم‌زمان فرق دارد.Both devices initially observed milk:t1 and bread:t2; phase one has no fresh adds. Removing observed tags differs from removing a concurrent new add. · دلیل و حل آموزشیReasoning and worked solution
فصل 6 · تمرین 3Chapter 6 · Exercise 3: برای membership ثابت، هر write quorum سه‌عضوی با هر read quorum سه‌عضوی از پنج عضو اشتراک دارد؛ تازگی به نسخه‌ها، دوام و عضویت نیز وابسته است.With fixed membership, every three-node write quorum intersects every three-node read quorum among five nodes; freshness also needs version, durability and membership assumptions. · دلیل و حل آموزشیReasoning and worked solution
فصل 8 · تمرین 1Chapter 8 · Exercise 1: آزمایش‌ها برای PostgreSQL 18 هستند: READ UNCOMMITTED مانند READ COMMITTED است، RR جلوی phantom را می‌گیرد و write skew هنوز ممکن است.Tests target PostgreSQL 18: READ UNCOMMITTED behaves as READ COMMITTED, RR prevents phantoms, and write skew can still occur. · دلیل و حل آموزشیReasoning and worked solution
فصل 8 · تمرین 2Chapter 8 · Exercise 2: رزروها بازهٔ نیمه‌باز [start,end) دارند؛ قفل روی سطر موجود اتاق در همان تراکنش گرفته می‌شود و بررسی overlap بعد از اخذ قفل است.Bookings use half-open intervals [start,end); lock the existing room row within the transaction and check overlap after acquiring it. · دلیل و حل آموزشیReasoning and worked solution
فصل 8 · تمرین 3Chapter 8 · Exercise 3: اثر محلی و کلید dedup در یک تراکنش‌اند؛ ACK بعد از commit است و رکورد dedup تا پایان افق معتبر replay حفظ می‌شود.The local effect and dedup key share one transaction; ACK follows commit and dedup records survive the supported replay horizon. · دلیل و حل آموزشیReasoning and worked solution
فصل 9 · تمرین 2Chapter 9 · Exercise 2: اختلاف CLOCK_REALTIME روی دو host/VM مستقل با بازهٔ عدم‌قطعیت سنجیده می‌شود؛ CLOCK_MONOTONIC فقط مدت روی همان host را می‌سنجد.Measure CLOCK_REALTIME offset across independent hosts/VMs with uncertainty; CLOCK_MONOTONIC measures durations on one host only. · دلیل و حل آموزشیReasoning and worked solution
فصل 9 · تمرین 3Chapter 9 · Exercise 3: epoch هر lease افزایش می‌یابد؛ storage مقادیر کمتر از بیشینهٔ پذیرفته‌شده را اتمیک رد می‌کند. op_id مستقل، retry را تشخیص می‌دهد.Epoch increases per lease; storage atomically rejects values below its highest accepted epoch. An independent op_id identifies retries. · دلیل و حل آموزشیReasoning and worked solution
فصل 10 · تمرین 2Chapter 10 · Exercise 2: write با هدف w=3 هنوز کامل نشده و فقط یک replica مقدار تازه را دارد؛ read باید پیش از پاسخ، بیشینهٔ نسخه را به quorum برگرداند.The write targeting w=3 is incomplete with one updated replica; reads must write the maximum version back to a quorum before replying. · دلیل و حل آموزشیReasoning and worked solution
فصل 11 · تمرین 2Chapter 11 · Exercise 2: دو جریان جدا فقط با user_id مرتب می‌شوند و یک پروفایل یکتا به‌ازای کاربر دارند؛ mixed reducer به profile-first یا buffering نیاز دارد.Two separate streams need user_id sorting and one unique profile per user; a mixed reducer needs profile-first ordering or buffering. · دلیل و حل آموزشیReasoning and worked solution
فصل 12 · تمرین 3Chapter 12 · Exercise 3: snapshot سازگار باید با مرز لاگِ معتبر هماهنگ شود؛ event topic و state topic کلید و retention متفاوت دارند و bootstrap هزینهٔ قابل‌اندازه‌گیری دارد.A consistent snapshot must align with a valid log boundary; event and state topics have different keys/retention and bootstrap has measurable cost. · دلیل و حل آموزشیReasoning and worked solution
فصل 13 · تمرین 3Chapter 13 · Exercise 3: رکورد فایل framing/checksum و fsync دارد؛ تصمیم و تعهد انتشار پایدارند. pending و اثر هر leg باید با مرز مشاهده مشخص حساب شوند.File records need framing/checksum and fsync; decisions and publication obligations are durable. Account for pending funds and each leg at a defined observation boundary. · دلیل و حل آموزشیReasoning and worked solution
مسیر پیشنهادی مطالعهSuggested study path
فصل ۲: محاسبهٔ بار، SLO و failure domain؛ سپس فصل‌های ۱ و ۳: مرجع و مدل داده.Chapter 2: capacity, SLOs and failure domains; then chapters 1 and 3: authority and data models.
فصل ۸ و ۹: concurrency، idempotency، timeout و fencing؛ این‌ها را با history و invariant توضیح بده.Chapters 8 and 9: concurrency, idempotency, timeouts and fencing; practice histories and invariants.
فصل ۶ و ۷: freshness و hotspot؛ فصل ۵: rollout سازگار و workflow recovery.Chapters 6 and 7: freshness and hotspots; chapter 5: compatible rollout and workflow recovery.
فصل ۱۲ و ۱۳: offset/outbox، migration و reconciliation؛ بعد deep diveهای تخصصی فصل ۴، ۱۰ و ۱۱.Chapters 12 and 13: offsets/outbox, migration and reconciliation; then specialist deep dives in chapters 4, 10 and 11.
تمرین تکمیلی در دل همین مسئله‌هاOperational follow-ups in the worked solutions
برای Staff/Principal، روایت پروژهٔ واقعی با شواهد impact و همکاری بین تیم‌ها را جدا تمرین کن. هر پاسخ اکنون بخش «چرا این روش و این عددها؟» دارد؛ عدد آموزشی نقطهٔ شروع تحلیل است و باید با دادهٔ محصول جایگزین شود.For Staff/Principal, separately practice a real project narrative with evidence of impact and cross-team work. Every answer includes “Why this method and these numbers?”; teaching inputs start the analysis and must be replaced by product evidence.
ارزیابی تک‌تک ۴۷ تمرینAll 47 exercise assessments
47 / 47
تمرینی با این فیلترها پیدا نشد. فیلترها را پاک کن.No matching exercises. Clear the filters to see all exercises.
مرجع داده، مشتق‌ها و انتشار تغییر، مسئلهٔ واقعی طراحی است؛ صرف نام‌گذاری اجزا عمق کافی ندارد.Record and derived data are useful, but classification alone is too shallow.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
فروشگاهی را طراحی کن که سفارش را ثبت می‌کند و کش، جست‌وجو، گزارش و پیشنهاد محصول دارد. مرجع هر واقعیت را مشخص کن. اگر سفارش commit شود ولی انتشار رویداد شکست بخورد چه می‌کنی؟ قرارداد تازگی هر نما، مسیر بازسازی و هزینهٔ حداقل معماری را توضیح بده.Design order storage and its cache, search, reporting and recommendation views. Explain commit-without-publication, freshness contracts, rebuilding and minimum cost.
معیار پاسخ خوبWhat a good answer demonstrates
مرجع و مشتق را برای هر واقعیت جدا می‌کندAuthority per fact
dual write، outbox/CDC و idempotency را تحلیل می‌کندAtomic publication and idempotence
برای تازگی و بازسازی معیار قابل سنجش داردFreshness and rebuild criteria
پیگیری مصاحبه:Interview follow-up:اگر مشتری بلافاصله بعد از ثبت سفارش آن را در جست‌وجو نبیند، تجربهٔ کاربر را چطور حفظ می‌کنی؟How do you preserve the user experience if a new order is not yet visible in search?
برآورد بار و انتخاب کمترین توزیع مفید است؛ تعداد سفارش روزانه به‌تنهایی دلیل sharding نیست.Capacity estimates should justify distribution rather than assume it.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
روزانه دو میلیون سفارش، اوج ده‌برابری، گزارش فروش و الزام نگهداری داده در یک کشور داریم. ابتدا اندازهٔ رکورد، read/write ratio، SLO و رشد را روشن کن. سه طرح تک‌گره، primary+replica و sharding را با شواهد ظرفیت مقایسه کن؛ بکاپ، failover و محل داده را هم پوشش بده.Compare single-node, primary/replica and sharded designs for two million daily orders, tenfold peaks, analytics and in-country storage. Specify workload, SLOs, growth, failover, backup and migration thresholds.
معیار پاسخ خوبWhat a good answer demonstrates
میانگین را با peak اشتباه نمی‌گیردAverage versus peak
residency را با لزوم sharding یکی نمی‌گیردResidency versus sharding
threshold مهاجرت و هزینهٔ عملیاتی را مشخص می‌کندMigration thresholds and cost
پیگیری مصاحبه:Interview follow-up:با پنج برابر شدن حجم و نصف شدن بودجه، کدام بخش را اول تغییر می‌دهی؟With fivefold data growth and half the budget, which component do you change first?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific35 دقیقه بحث35 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
حذف داده در سامانه‌های لاگ‌محور برای پلتفرم و حریم خصوصی مهم است؛ انتظار حفظ متن قانون برای همهٔ نقش‌ها مناسب نیست.Important for privacy/platform roles; legal memorization is not a general backend requirement.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
درخواست حذف یک کاربر را از مرجع تا کش، ایندکس، لاگ، بکاپ و مجموعهٔ آموزش دنبال کن. گزینه‌های جداسازی PII، retention، بازنویسی سگمنت و حذف کلید رمز را مقایسه کن. بگو چه چیزی در restore نباید دوباره زنده شود و کدام تصمیم نیازمند تفسیر حقوقی است.Trace deletion through the record, cache, index, log, backup and training data. Compare PII separation, retention, rewriting and key deletion. Prevent resurrection after restore and identify legal uncertainties.
معیار پاسخ خوبWhat a good answer demonstrates
همهٔ کپی‌ها و restore را پوشش می‌دهدDerived copies and restore
محدودیت crypto-shredding و لینک‌پذیری را می‌بیندKey-deletion limitations
تأیید حذف را با مدرک و SLA داخلی طراحی می‌کندDeletion evidence and deadlines
پیگیری مصاحبه:Interview follow-up:اگر یک مصرف‌کنندهٔ قدیمی هنگام حذف آفلاین باشد چه تضمینی داری؟What happens when an old consumer is offline throughout a deletion?
روز آموزشی ۸۶۴۰۰ ثانیه و ضریب اوج ۱۰ است؛ هر سفارش سه پیام اعلان می‌سازد. کش، یک سطر خلاصهٔ سفارش با کلید order_id در k مقصد منطقی است؛ k را جدا از سه سرویس تعیین کن.A teaching day has 86400 seconds and the peak factor is 10; each order emits three notifications. The cache stores an order-summary row keyed by order_id in k logical destinations; k is independent of the three services.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای دو میلیون سفارش در روز و اوج ده‌برابری، RPS و تعداد سه پیام داخلی به‌ازای هر سفارش را حساب کن. سپس یک view مشخص تعریف کن که هر سفارش در k مقصد آن نوشته می‌شود؛ write amplification، نرخ خواندن، اندازهٔ payload و lag را مقایسه کن و دربارهٔ materialization تصمیم بگیر.Calculate average and peak orders/s and three internal notifications per order. Define a materialized view with k destinations, then compare extra writes, read savings, payload size and freshness.
معیار پاسخ خوبWhat a good answer demonstrates
۲۳٫۱۵ و ۲۳۱٫۵ سفارش در ثانیه را درست محاسبه می‌کندCorrect average/peak math
سه پیام را با k نوشتن کش یکی نمی‌گیردNotification versus view fan-out
فرض‌ها و نقطهٔ سربه‌سر را بیان می‌کندExplicit break-even assumptions
پیگیری مصاحبه:Interview follow-up:اگر یک مشتری بزرگ k را صد برابر کند چه اتفاقی برای tail latency می‌افتد؟What happens to tail latency when one large customer increases k by a factor of 100?
SLO، تجربهٔ کاربر و پیامد خرابی از کاربردی‌ترین بخش‌های این مجموعه‌اند؛ داشبورد باید به اقدام وصل شود.A strong operational exercise when monitoring leads to action.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای استعلام وضعیت سفارش SLI و SLO با بازهٔ اندازه‌گیری، latency percentile و availability تعریف کن. مرز success، timeout و خطای وابستگی را روشن کن. error budget و هشدار burn rate را طراحی کن و SLO داخلی را از تعهد قراردادی SLA جدا کن.Define order-status SLIs, latency and availability SLOs, measurement windows, error budget and burn-rate alerts. Distinguish internal objectives from contractual SLA remedies.
معیار پاسخ خوبWhat a good answer demonstrates
صورت و مخرج SLI روشن استSLI numerator and denominator
percentile و availability دو معیار مستقل‌اندLatency versus availability
هشدار، rollback و تصمیم انتشار به budget وصل‌اندBudget-driven alerts and rollback
پیگیری مصاحبه:Interview follow-up:میانگین عالی است ولی p99 خراب؛ کدام گروه کاربران را بررسی می‌کنی؟The average latency is excellent but p99 is poor. Which user groups do you investigate?
multi-AZ و rolling upgrade مهم‌اند؛ داشتن دو ماشین به‌تنهایی SPOFهای کنترل، state و شبکه را حذف نمی‌کند.Two machines do not eliminate every single point of failure.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
یک API ثبت سفارش با پایگاه داده و صف طراحی کن که خرابی یک ماشین یا AZ را تحمل کند. failure domain، quorum، fencing، session state، health check، ظرفیت AZ باقی‌مانده و RPO/RTO را مشخص کن. انتشار سازگار و rollback بدون توقف را توضیح بده.Design an order API, database and queue that survive one host or AZ failure. Specify quorum, fencing, health checks, spare capacity, RPO/RTO, compatible rolling upgrades and rollback.
معیار پاسخ خوبWhat a good answer demonstrates
SPOFهای data plane و control plane را می‌یابدData/control-plane failure domains
HA را با backup و disaster recovery یکی نمی‌گیردHA versus backup/DR
در ظرفیت و schema rollout شرط قابل آزمون می‌دهدCapacity and rollout acceptance gates
پیگیری مصاحبه:Interview follow-up:در rolling upgrade نسخه‌های قدیم و جدید هم‌زمان فعال‌اند؛ تغییر schema را چگونه منتشر می‌کنی؟Old and new binaries coexist during rolling deployment. How do you roll out a schema change?
مدل‌سازی بر اساس query و constraint ارزشمند است؛ پاسخ «SQL یا NoSQL» بدون workload ضعیف است.Model choices should follow queries, cardinality and constraints.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
کاتالوگ محصول، برند، دسته‌بندی چندگانه و نظر کاربران را با مدل رابطه‌ای و سندی طراحی کن. سه query پرتکرار، pagination، رشد نظرات، uniqueness و تغییر برند را مشخص کن. schema و index را رسم کن و یک انتخاب متناسب با بار داشته باش.Model products, brands, multiple categories and unbounded reviews in relational and document forms. Specify three queries, pagination, indexes and uniqueness; justify a workload-specific choice.
معیار پاسخ خوبWhat a good answer demonstrates
cardinality، FK و index روشن‌اندCardinality, keys and indexes
آرایهٔ بی‌حد نظرات را در سند جا نمی‌دهدBounded document growth
انتخاب را با query و consistency توجیه می‌کندQuery-driven consistency choices
پیگیری مصاحبه:Interview follow-up:اگر محصول در چند دسته باشد و نظرات میلیون‌تایی شوند مدل چگونه تغییر می‌کند؟How does the model change when a product has multiple categories and millions of reviews?
نمونهٔ خوبی برای normalization است؛ نسخهٔ فعلی برای لول بالا باید به update propagation و cache invalidation برسد.Useful foundations; propagation failures provide the senior follow-up.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
لوگوی یک برند روی صد هزار محصول دیده می‌شود. reference، embedding و read model مشتق را مقایسه کن. هزینهٔ خواندن، fan-out تغییر، stale data و failure میان batch update را بیان کن؛ انتخابت را با حد تازگی قابل قبول توجیه کن.Compare references, embedding and a derived read model for one brand logo across 100,000 products. Analyze read cost, update fan-out, partial failure, staleness and versioning.
معیار پاسخ خوبWhat a good answer demonstrates
کپی را بدون مسیر update پیشنهاد نمی‌دهدCopy propagation
خواندن سریع را با هزینه نوشتن مبادله می‌کندRead/write cost trade-off
منبع حقیقت و نسخهٔ logo را مشخص می‌کندAuthority and versioning
پیگیری مصاحبه:Interview follow-up:با شکست به‌روزرسانی در نیمهٔ محصولات چه چیزی را retry می‌کنی؟What do you retry when a logo update fails halfway through the products?
رزرو و replay سناریوی قوی‌ای است؛ نام‌گذاری event به‌تنهایی کافی نیست و concurrency قید صندلی مهم‌تر است.Reservation invariants matter more than naming events.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
رزرو سینما را با event log و سه projection وضعیت صندلی، فروش و بلیت طراحی کن. دو درخواست هم‌زمان برای یک صندلی، انقضای hold، لغو و اصلاح رزرو را توضیح بده. invariant را در write path اعمال کن و replay را از ارسال دوبارهٔ بلیت جدا کن.Design cinema reservations with a log and seat, sales and ticket projections. Handle concurrent requests, hold expiry, cancellation and corrections. Enforce seat exclusivity at the write boundary and prevent replayed external effects.
معیار پاسخ خوبWhat a good answer demonstrates
یک صندلی دو رزرو تأییدشده نداردSeat exclusivity
command و event و compensating event را جدا می‌کندCommands versus events
projection و اثر بیرونی idempotent هستندIdempotent projections and side effects
پیگیری مصاحبه:Interview follow-up:رویداد SeatHeld دیر برسد ولی SeatReleased قبلاً پردازش شده باشد چه می‌کنی؟What happens if SeatHeld arrives after SeatReleased has already been processed?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific45 دقیقه بحث45 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
LSM/WAL برای storage/platform مفید است؛ ساخت موتور کامل و یک میلیون benchmark تمرین چندساعته است، نه سؤال معمول جلسه.A substantial storage lab rather than a normal live interview task.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای workload نوشتن‌محور با point read و range read، LSM و B-tree را مقایسه کن. مسیر write، WAL، memtable، SSTable، compaction و tombstone را رسم کن. توضیح بده crash بین flush و ثبت manifest چه می‌کند و چه زمانی write/read/space amplification بالا می‌رود.Compare LSM and B-tree for write-heavy point/range reads. Draw WAL, memtable, SSTable and compaction. Explain crash recovery, manifests, tombstones and write/read/space amplification.
معیار پاسخ خوبWhat a good answer demonstrates
durability را از index حافظه جدا می‌کندDurability versus RAM indexing
نسخهٔ جدید و tombstone درست انتخاب می‌شوندLatest versions and tombstones
benchmark دادهٔ خام، fsync و cache را مشخص می‌کندDefined fsync/cache benchmark conditions
پیگیری مصاحبه:Interview follow-up:حذف tombstone هنگام compaction چه زمانی رکورد قدیمی را زنده می‌کند؟When can dropping a tombstone during compaction resurrect an old value?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific40 دقیقه بحث40 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
column pruning، partition pruning و star schema برای data engineering مناسب‌اند؛ RLE دستی ارزش مصاحبه‌ای کمتری دارد.Strong for data engineering; manual RLE is an optional depth exercise.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
گزارش فروش هر دسته‌بندی به تفکیک روز هفته را روی fact فروش و dimension محصول و تاریخ طراحی کن. SQL، partition key، sort key و ستون‌های خوانده‌شده را مشخص کن. اثر skew، cardinality، bitmap و تغییر دسته‌بندی محصول در تاریخ را تحلیل کن.Design daily category sales analytics with fact and dimension tables. Provide SQL, partition/sort keys and read columns. Explain pruning, skew, bitmap compression and historical category semantics.
معیار پاسخ خوبWhat a good answer demonstrates
pruning را با خواندن کمتر ستون تفکیک می‌کندColumn versus block pruning
تعریف تاریخی category روشن استHistorical category semantics
compression را با cardinality و order توجیه می‌کندCompression under stated cardinality
پیگیری مصاحبه:Interview follow-up:آیا فروش سال گذشته باید با دسته‌بندی امروز گزارش شود یا دسته‌بندی زمان فروش؟Should last year’s sales use today’s category or the category at the time of sale?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific45 دقیقه بحث45 min discussion
اصلاح‌شدهCorrected
الگوی /appl./ دو trigram ثابت app و ppl دارد؛ اشتراک postingها فقط نامزد می‌سازد و regex نتیجه را تأیید می‌کند. recall@k با exact top-k مقایسه می‌شود.The pattern /appl./ requires app and ppl; intersect their postings to find candidates, then verify the regex. Recall@k compares approximate results with exact top-k.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
جست‌وجوی محصول را با inverted index، فیلتر و vector index طراحی کن. برای red AND apples اشتراک postings را توضیح بده. برای regex /appl./ ابتدا candidates با trigram و سپس تأیید regex را انجام بده. در IVF با nprobe=1، recall@k را نسبت به exact top-k و p95 latency بسنج؛ hybrid ranking و جداسازی tenant را هم تحلیل کن.Design lexical and vector product retrieval. Intersect postings for red AND apples; filter /appl./ by trigram then verify the regex. Evaluate IVF using exact top-k recall@k and p95 latency, and discuss hybrid ranking and tenant isolation.
معیار پاسخ خوبWhat a good answer demonstrates
candidate filtering را با match قطعی اشتباه نمی‌گیردCandidates versus verified matches
ANN ground truth و recall@k درست تعریف شدهExact recall ground truth
freshness، ACL و هزینه در retrieval دیده می‌شوندFreshness and authorization
پیگیری مصاحبه:Interview follow-up:اگر regex هیچ trigram ثابت نداشته باشد یا filter بسیار محدود باشد چه مسیر جایگزینی داری؟What fallback handles a regex without any fixed trigram, or a highly selective filter?
L1 · پایهL1 · Foundationsوابسته به نقشRole-specific25 دقیقه بحث25 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
wire format برای protocol/storage آموزشی است؛ حفظ ۶۶ و ۳۳ بایت اولویت عمومی ندارد. شرط حفظ unknown field باید دقیق باشد.Understanding compatibility is more valuable than memorizing byte totals.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
با یک رکورد کوچک تفاوت JSON، MessagePack و Protobuf را در schema، حجم و debugging توضیح بده. یک tag را دستی decode کن. فیلد email اضافه کن و دو مسیر binary round-trip و تبدیل به JSON را از نظر حفظ unknown field مقایسه کن.Compare JSON, MessagePack and Protobuf, decode one tag, then add email. Test unknown-field preservation in binary round-trips against JSON conversion or field-by-field copying.
معیار پاسخ خوبWhat a good answer demonstrates
tag و varint را می‌فهمد، عدد حفظ نمی‌کندTag/varint understanding
runtime و نوع تبدیل را مشخص می‌کندSpecified conversion/runtime
wire compatibility را از API compatibility جدا می‌کندWire versus application compatibility
پیگیری مصاحبه:Interview follow-up:proxy قدیمی پیام را field-by-field به پیام جدید کپی می‌کند؛ چه داده‌ای گم می‌شود؟An old proxy copies recognized fields into a fresh message. What data disappears?
جهت writer→reader، فرمت binary/JSON، tag، default و alias مشخص‌اند؛ parse شدن با حفظ همهٔ مقدارها یکسان نیست.Name writer→reader direction, binary/JSON format, tags, defaults and aliases; parseability differs from preserving all values.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای Avro و Protobuf افزودن فیلد، rename و تغییر cardinality را بررسی کن. جهت writer→reader، default، alias، tag و binary/JSON را دقیق مشخص کن. scalar-to-array را با فیلد جدید و دورهٔ dual compatibility منتشر کن؛ compatibility test و rollback داشته باش.Compare Avro and Protobuf field addition, rename and cardinality changes. Specify writer/reader direction, aliases, defaults and tags. Migrate cardinality with a new field and compatibility tests; distinguish parseability from lossless semantics.
معیار پاسخ خوبWhat a good answer demonstrates
backward یعنی reader جدید/writer قدیم را روشن می‌کندExplicit writer/reader direction
rename Avro را خودکار دوطرفه فرض نمی‌کندAsymmetric rename handling
packed numeric و lossy string repeated را می‌بیندPacking and lossy repeated fields
پیگیری مصاحبه:Interview follow-up:consumerهای قدیمی ماه‌ها عقب‌اند؛ چه زمانی tag یا فیلد قدیمی را حذف می‌کنی؟Old consumers are months behind. When can you remove the old field or tag?
durable workflow، replay و side effect برای backend جدی ارزشمندند؛ باید تصمیم قطعی و نسخه‌بندی invocation روشن باشد.Durable replay is relevant when versioning and side effects are explicit.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
workflow موجودی، پرداخت و ارسال را در برابر crash و retry طراحی کن. شناسهٔ هر گام، log پایدار، نتیجهٔ ذخیره‌شده و compensation را مشخص کن. تغییر ترتیب گام‌ها، branching و schema را برای invocationهای در جریان نسخه‌بندی کن و هزینهٔ recovery را بگو.Design inventory/payment/shipping workflow recovery with stable step IDs, durable results and compensation. Version changes to step order, branching and payloads for running invocations.
معیار پاسخ خوبWhat a good answer demonstrates
شناسه بین retry ثابت استStable retry IDs
پرداخت/ارسال بیرونی با قرارداد idempotency پوشش داده شدهExternal idempotency contract
کد جدید replay تاریخچه قدیم را نمی‌شکندVersion-safe replay
پیگیری مصاحبه:Interview follow-up:provider ارسال idempotency key ندارد؛ تضمینت چه تغییری می‌کند؟The shipping provider has no idempotency key. How does that change your guarantee?
replica lag و consistency تجربهٔ کاربر مستقیماً به طراحی مرتبط‌اند؛ نصب replica را به مسیر آزمایشگاهی منتقل می‌کنیم.A useful consistency discussion; replica setup belongs in the lab.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
بعد از ویرایش پروفایل، یک read replica مقدار قدیمی برمی‌گرداند. read-your-writes، monotonic reads و causal consistency را با history کوتاه نشان بده. routing به primary، session stickiness و version/LSN barrier را مقایسه کن و برای lag بی‌حد fallback تعریف کن.Show read-your-writes, monotonic-read and causal anomalies after profile changes. Compare primary routing, stickiness and version/LSN barriers, including fallback when lag has no known bound.
معیار پاسخ خوبWhat a good answer demonstrates
زمان ثابت sleep را تضمین consistency نمی‌داندNo fixed sleep guarantee
دو replica را با version دنبال می‌کندVersion-aware routing
قیمت تازگی را در latency و availability می‌بیندFreshness/availability trade-off
پیگیری مصاحبه:Interview follow-up:اگر primary بعد از ACK خراب شود، read-your-writes چه وابستگی‌ای به replication durability دارد؟If the primary fails after ACK, how does read-your-writes depend on replication durability?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific35 دقیقه بحث35 min discussion
اصلاح‌شدهCorrected
هر دو دستگاه ابتدا milk:t1 و bread:t2 را دیده‌اند؛ فاز اول add تازه ندارد. حذف tag مشاهده‌شده با حذف یک add هم‌زمان فرق دارد.Both devices initially observed milk:t1 and bread:t2; phase one has no fresh adds. Removing observed tags differs from removing a concurrent new add.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
دو دستگاه سبد مشترک را آفلاین ویرایش می‌کنند: هر کدام یک آیتم شناخته‌شده را حذف می‌کند و هیچ add تازه‌ای وجود ندارد. LWW، union سادهٔ siblings و OR-Set با tag/tombstone را مقایسه کن. سپس add هم‌زمان با remove را اضافه کن و semantics مطلوب محصول را انتخاب کن.Start with two offline devices removing different known cart items and no new adds. Compare LWW, sibling union and an OR-Set with tagged adds/removals. Then introduce concurrent add/remove and choose product semantics.
معیار پاسخ خوبWhat a good answer demonstrates
LWW را با clock skew و lost update تحلیل می‌کندClock skew and lost updates
remove مشاهده‌شده با concurrent add تازه فرق داردObserved removals versus fresh concurrent adds
GC tombstone را به causal stability وصل می‌کندSafe tombstone collection
پیگیری مصاحبه:Interview follow-up:دستگاهی یک سال آفلاین بوده؛ tombstone را چه زمانی می‌توان پاک کرد؟A device has been offline for a year. When is it safe to collect tombstones?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific45 دقیقه بحث45 min discussion
اصلاح‌شدهCorrected
برای membership ثابت، هر write quorum سه‌عضوی با هر read quorum سه‌عضوی از پنج عضو اشتراک دارد؛ تازگی به نسخه‌ها، دوام و عضویت نیز وابسته است.With fixed membership, every three-node write quorum intersects every three-node read quorum among five nodes; freshness also needs version, durability and membership assumptions.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
با n=5,w=3,r=3 نشان بده چه تضمینی از تقاطع مجموعه‌ها داریم و چه تضمینی نداریم. partial write، lost ACK، stale replacement و تغییر membership را تحلیل کن. مانیتور staleness را با version، probe و divergence طراحی کن؛ failure را با rollback یکی ندان.For n=5,w=3,r=3, explain quorum intersection and its limits. Analyze partial writes, lost ACKs, stale replacement and changing membership; define useful version probes and divergence monitoring.
معیار پاسخ خوبWhat a good answer demonstrates
membership و durable ACK را از نامساوی جدا می‌کندMembership and durability assumptions
نوشتن ناموفق می‌تواند قابل مشاهده باشدVisibility of partial writes
بدون ترتیب لاگ، واحد سنجش تازگی را تعریف می‌کندMeaningful staleness metrics
پیگیری مصاحبه:Interview follow-up:در rebalancing هم‌زمان، quorum قدیم و جدید چگونه باید هم‌پوشانی داشته باشند؟How should old and new quorums overlap during concurrent rebalancing?
hotspot و query-aware sharding مهم‌اند؛ hash-range بدون تعیین کلید هش پاسخ یکتایی ندارد.Hash-range needs a specified hash key; monthly totals can hide instantaneous hotspots.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای دادهٔ ماهانهٔ سنسورها، timestamp-range، sensor:timestamp range، hash(sensor_id) و hash(full_key) را مقایسه کن. هم بار لحظه‌ای و هم مجموع ماه را بسنج. مسیر query یک سنسور در یک ماه، hotspot سنسور پرنرخ و repartitioning را توضیح بده.Compare timestamp ranges, sensor:timestamp ranges, hash(sensor_id) and hash(full_key). Measure instantaneous and monthly load, query fan-out, hot sensors and repartitioning.
معیار پاسخ خوبWhat a good answer demonstrates
توزیع ماهانه hotspot لحظه‌ای را پنهان نمی‌کندInstantaneous hotspot measurement
hash sensor را با hash full key یکی نمی‌گیردSpecified hash input
query fan-out و write skew کمی شده‌اندQuery fan-out and skew
پیگیری مصاحبه:Interview follow-up:یک سنسور ۴۰٪ نوشتن‌ها را تولید کند؛ چه تغییری در کلید می‌دهی؟One sensor generates 40% of all writes. How do you change the partition key?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific35 دقیقه بحث35 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
consistent hashing مرتبط است، ولی درصد جابه‌جایی تنها معیار نیست؛ policy نگاشت fixed shard نیز باید تعریف شود.Movement percentage alone misses skew, capacity weights and migration policy.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای اضافه/حذف node، modulo، rendezvous و fixed logical shards با جدول مالکیت را مقایسه کن. درصد حرکت را برای mapping مشخص محاسبه کن و دربارهٔ skew، وزن node، failure، replication و مهاجرت تدریجی تصمیم بگیر.Compare modulo, rendezvous and fixed logical shards with an explicit ownership map. Estimate movement on joins/leaves and discuss skew, weighted nodes, replication and staged handoff.
معیار پاسخ خوبWhat a good answer demonstrates
ثبات hash در restart تضمین شدهStable hash function
حرکت داده را از تغییر routing جدا می‌کندData movement versus routing
fixed shard بدون ownership policy مقایسه نشدهExplicit shard ownership policy
پیگیری مصاحبه:Interview follow-up:node جدید دو برابر ظرفیت دارد؛ balancing را بدون جابه‌جایی همهٔ کلیدها چطور انجام می‌دهی؟A new node has twice the capacity. How do you rebalance without moving every key?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific45 دقیقه بحث45 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
global index از deep diveهای خوب است؛ latency چهار SQLite محلی پیش‌بینی شبکه و cluster واقعی نیست.A useful distributed-index deep dive; local SQLite timings do not predict networked p99.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای دادهٔ چهار shard، local و global secondary index طراحی کن. write path، تک‌شرط/دوشرط، scatter-gather، failure جزئی و lag را مقایسه کن. یک تغییر چندtermی را با outbox/version مدیریت کن و تعداد RPC، p99 و هزینهٔ consistency را مشخص کن.Design local and global secondary indexes over four shards. Compare writes, one/two predicates, scatter-gather, partial failures and lag. Specify outbox/version handling, RPC counts and consistency cost.
معیار پاسخ خوبWhat a good answer demonstrates
source shard و index shard را جدا می‌شماردBase and index shard counts
index غیراتمیک را مرجع حقیقت فرض نمی‌کندDerived-index consistency limits
benchmark محلی را به cluster تعمیم نمی‌دهدNo network conclusions from local timing
پیگیری مصاحبه:Interview follow-up:index کالا را نشان می‌دهد ولی حذف آن در مرجع ثبت شده؛ خواننده چه می‌کند؟The index returns a product already deleted from the record. What does the reader do?
آزمایش‌ها برای PostgreSQL 18 هستند: READ UNCOMMITTED مانند READ COMMITTED است، RR جلوی phantom را می‌گیرد و write skew هنوز ممکن است.Tests target PostgreSQL 18: READ UNCOMMITTED behaves as READ COMMITTED, RR prevents phantoms, and write skew can still occur.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
روی PostgreSQL مشخص، history دو اتصال برای read skew، lost update، phantom و write skew بساز و isolation را مقایسه کن. برای dirty read/write آزمون عدم وقوع و blocking بنویس. ناهنجاری را با SQL دقیق توضیح بده و رفتار محصول را از حداقل استاندارد SQL جدا کن.Create two-session SQL histories for read skew, lost update, phantom and write skew on a named PostgreSQL version. Test dirty-read/write prevention and blocking. Compare implemented guarantees with the SQL standard.
معیار پاسخ خوبWhat a good answer demonstrates
عدم وقوع هم نتیجهٔ معتبر آزمایش استValid prevention results
lost update ناشی از read-modify-write را درست نشان می‌دهدCorrect read-modify-write histories
RR در PostgreSQL phantom را حذف می‌کند ولی write skew ممکن استProduct-specific isolation guarantees
پیگیری مصاحبه:Interview follow-up:UPDATE balance=balance+1 چه تفاوتی با SELECT و UPDATE مقدار ثابت دارد؟How does UPDATE balance=balance+1 differ from SELECT followed by an absolute-value UPDATE?
رزروها بازهٔ نیمه‌باز [start,end) دارند؛ قفل روی سطر موجود اتاق در همان تراکنش گرفته می‌شود و بررسی overlap بعد از اخذ قفل است.Bookings use half-open intervals [start,end); lock the existing room row within the transaction and check overlap after acquiring it.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای رزرو بازه‌ای یک اتاق، invariant عدم overlap را تعریف کن. check+insert، READ COMMITTED، lock روی ردیف ثابت اتاق، SERIALIZABLE و exclusion constraint را مقایسه کن. برای پنجاه درخواست هم‌زمان retry، contention و p99 را طراحی کن؛ قید UNIQUE فقط برای slot ثابت کافی است.Enforce no overlapping room reservations. Compare check/insert, Read Committed, a stable room-row lock, Serializable and exclusion constraints. Design 50-way contention tests and report retry and latency; UNIQUE fits discrete fixed slots.
معیار پاسخ خوبWhat a good answer demonstrates
قفل ردیف موجود اتاق را از قفل رزرو خالی جدا می‌کندExisting room-row lock
بازه زمانی با equality اشتباه نشدهOverlap versus equality constraints
abort، retry کل تراکنش و fairness دیده شده‌اندWhole-transaction retry and contention
پیگیری مصاحبه:Interview follow-up:کاربر رزرو را تمدید کند و هم‌زمان رزرو بعدی ساخته شود؛ قیدت هنوز درست است؟A user extends a booking while another user reserves the next interval. Is the constraint still correct?
اثر محلی و کلید dedup در یک تراکنش‌اند؛ ACK بعد از commit است و رکورد dedup تا پایان افق معتبر replay حفظ می‌شود.The local effect and dedup key share one transaction; ACK follows commit and dedup records survive the supported replay horizon.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
صف و پردازشگر با processed_messages و قید UNIQUE بساز. ثبت ID و اثر محلی را در یک تراکنش و ACK را پس از commit بگذار. در سه نقطه crash تزریق کن؛ نسخهٔ بدون dedup را مقایسه کن. retention شناسه و side effect بیرونی را صریح تعیین کن.Implement an idempotent queue consumer using a unique processed-message ID and local effects in one transaction, then ACK. Inject three crash points, compare with no dedup, and define retention and external-effect boundaries.
معیار پاسخ خوبWhat a good answer demonstrates
commit-before-ack و redelivery را توضیح می‌دهدCommit before ACK
تکراری با payload متفاوت رد می‌شودPayload binding
حد تضمین محلی و افق dedup مشخص استDefined local boundary and dedup horizon
پیگیری مصاحبه:Interview follow-up:اپراتور پیام شش‌ماهه را replay کند ولی dedup بعد از یک ماه حذف شده باشد چه می‌شود؟An operator replays a six-month-old message after dedup was deleted at one month. What happens?
timeout ambiguity کاربردی است؛ نسخهٔ مصاحبه باید retry storm، deadline و overload را هم بپرسد.Add overload-aware retry policies to the timeout ambiguity example.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
شمارنده یا پرداختی داریم که درخواست، commit یا پاسخ آن ممکن است گم شود. history هر حالت را نشان بده. پروتکل با request ID، result lookup، payload binding و retention طراحی کن؛ deadline، backoff+jitter و retry budget را اضافه کن.Trace lost request, server failure and lost response. Design request ID, result lookup, payload binding and retention, then deadlines, backoff with jitter and a retry budget.
معیار پاسخ خوبWhat a good answer demonstrates
timeout را با عدم اجرا یکی نمی‌گیردTimeout remains indeterminate
ID درخواست قصد مشتری را حفظ می‌کندCaller intent in request ID
retry در همهٔ لایه‌ها بار را چندبرابر نمی‌کندBounded layered retries
پیگیری مصاحبه:Interview follow-up:سه لایه هر کدام سه بار retry کنند، حداکثر چند تلاش downstream داریم؟Three layers each make up to three attempts. What is the maximum number of downstream attempts?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific25 دقیقه بحث25 min discussion
اصلاح‌شدهCorrected
اختلاف CLOCK_REALTIME روی دو host/VM مستقل با بازهٔ عدم‌قطعیت سنجیده می‌شود؛ CLOCK_MONOTONIC فقط مدت روی همان host را می‌سنجد.Measure CLOCK_REALTIME offset across independent hosts/VMs with uncertainty; CLOCK_MONOTONIC measures durations on one host only.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
wall clock و monotonic clock را در deadline، اندازه‌گیری duration و LWW مقایسه کن. skew را با دو host/VM مستقل یا ساعت mock تزریق کن. uncertainty ناشی از زمان ارسال نمونه را گزارش کن و نشان بده timestamp آینده چگونه write واقعی بعدی را می‌پوشاند.Compare wall and monotonic clocks for durations, deadlines and LWW. Use independent hosts/VMs or explicitly mocked skew. Report sampling uncertainty and show how a future timestamp hides a later real write.
معیار پاسخ خوبWhat a good answer demonstrates
monotonic clock بین ماشین‌ها مقایسه نمی‌شودNo cross-host monotonic comparison
mock skew با اندازه‌گیری skew واقعی برچسب متفاوت داردReal versus mock skew
rollback ساعت و uncertainty دیده شده‌اندClock steps and sampling uncertainty
پیگیری مصاحبه:Interview follow-up:NTP ساعت را step کند؛ timeout و TTL برنامه کدام clock را باید استفاده کنند؟NTP steps the wall clock. Which clock should application timeouts and TTL durations use?
epoch هر lease افزایش می‌یابد؛ storage مقادیر کمتر از بیشینهٔ پذیرفته‌شده را اتمیک رد می‌کند. op_id مستقل، retry را تشخیص می‌دهد.Epoch increases per lease; storage atomically rejects values below its highest accepted epoch. An independent op_id identifies retries.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
کارگر A lease با token=7 دارد، pause می‌شود و B با token=8 می‌نویسد؛ A سپس بیدار می‌شود. storage باید stale epoch را اتمیک رد کند. چند write معتبر در یک epoch را از duplicate operation جدا کن و برای token allocation و دوام highest-seen شرط تعریف کن.Pause owner A at token 7, let B obtain token 8 and write, then resume A. Enforce atomic stale-epoch rejection in storage. Distinguish multiple legitimate same-epoch writes from duplicate operations and persist the highest token.
معیار پاسخ خوبWhat a good answer demonstrates
lease expiry به‌تنهایی جلوی stale write را نمی‌گیردLease expiry is insufficient
token کمتر رد می‌شود؛ token برابر نیازمند semantics جداستEpoch versus operation identity
بررسی token در خود storage انجام می‌شودStorage-enforced durable fencing
پیگیری مصاحبه:Interview follow-up:storage restart شود و highest token را فراموش کند، چه خطایی ممکن است؟Storage restarts and forgets the highest fencing token. What failure becomes possible?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific25 دقیقه بحث25 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
safety/liveness برای استدلال خوب است؛ مثال at-most-once delivery می‌تواند به از دست رفتن پیام منجر شود و فرض progress باید صریح باشد.Progress requires explicit recovery, network and capacity assumptions.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای صف، safety «اثر پیام بیش از یک بار اعمال نشود» و liveness «پیام معتبر تحت بازیابی شبکه بالاخره اثر کند» تعریف کن. partition دائمی، redelivery و از دست رفتن dedup را تحلیل کن. برای هر ادعا یک counterexample و فرض زمانی روشن بده.Define no duplicate application effects as safety and eventual valid-message effects under recovery as liveness. Give counterexamples for permanent partitions, redelivery and missing dedup state.
معیار پاسخ خوبWhat a good answer demonstrates
delivery را از application effect جدا می‌کندDelivery versus effects
liveness بدون فرض شبکه/ظرفیت قول داده نمی‌شودExplicit progress assumptions
مثال safety violation می‌تواند همراه progress باشدIndependent safety/liveness counterexamples
پیگیری مصاحبه:Interview follow-up:سیستم همهٔ پیام‌ها را رد کند؛ کدام خاصیت ظاهراً سالم می‌ماند؟The service rejects every message. Which property can appear healthy?
L1 · پایهL1 · Foundationsوابسته به نقشRole-specific25 دقیقه بحث25 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
Lamport پایهٔ مفید است ولی پیاده‌سازی سه پروسه برای backend عمومی اولویت نخست نیست.Useful distributed-systems foundations, with lower general-backend priority.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای سه process، send/receive و رخداد محلی را با Lamport clock شماره‌گذاری کن. با tie-breaker process ID ترتیب کامل بساز. یک مثال نشان بده که L(a)<L(b) علت‌ومعلولی بودن را اثبات نمی‌کند؛ vector clock و هزینه‌اش را مقایسه کن.Label local events and messages using Lamport clocks and process-ID tie breaking. Show why increasing timestamps do not imply causality or detect concurrency; compare vector-clock costs.
ترتیب کل را با causality یکی نمی‌گیردTotal order versus causality
concurrency از Lamport قابل تشخیص نیستConcurrency limitations
پیگیری مصاحبه:Interview follow-up:دو رخداد بدون هیچ پیام چه timestampهایی می‌توانند داشته باشند؟What timestamps can two independent events with no messages have?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific45 دقیقه بحث45 min discussion
اصلاح‌شدهCorrected
write با هدف w=3 هنوز کامل نشده و فقط یک replica مقدار تازه را دارد؛ read باید پیش از پاسخ، بیشینهٔ نسخه را به quorum برگرداند.The write targeting w=3 is incomplete with one updated replica; reads must write the maximum version back to a quorum before replying.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
با سه replica و write در جریان که هنوز فقط به یکی رسیده، دو quorum read بساز که اولی جدید و دومی قدیمی می‌خواند. سپس الگوریتم register با version مرتب و write-back به اکثریت پیش از بازگشت read را مشخص کن. برای multi-writer مرحلهٔ query پیش از write و فرض membership ثابت را تحلیل کن.Construct new-then-old quorum reads during an incomplete three-replica write. Specify ordered versions and majority write-back before returning a read. Discuss a query phase for multiple writers, fixed membership and crash assumptions.
معیار پاسخ خوبWhat a good answer demonstrates
w=3 تأییدشده روی همه را با partial write یکی نمی‌گیردPartial versus acknowledged writes
background repair را با synchronous quorum write-back جدا می‌کندBackground repair versus quorum write-back
version، crash و concurrent writer assumptions معلوم‌اندVersion and writer assumptions
پیگیری مصاحبه:Interview follow-up:اگر یک reader بعد از خواندن جدید و قبل از write-back بمیرد، کدام read باید completed حساب شود؟A reader crashes after observing the new value but before write-back. Should that read count as completed?
رزرو بادوامِ بازه پیش از صدور، یکتایی را با پذیرش gap حفظ می‌کند؛ شاردها می‌توانند بازه یا namespace جدا داشته باشند.Durably reserving ranges before issuance preserves uniqueness with gaps; shards may allocate disjoint ranges or namespaces.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
مولد ID با رزرو پایدار بازه طراحی کن و crash وسط دسته را تحلیل کن. uniqueness، gap-free، ترتیب تخصیص و ترتیب مشاهدهٔ real-time را جدا تعریف کن. طرح مرکزی، UUID و shard-prefixed ID را مقایسه کن؛ برای failover، allocator را fence کن.Persist ID-range reservations before issuing IDs and crash mid-range. Separate uniqueness, gaplessness, allocation order and real-time observation. Compare a centralized allocator, UUIDs and shard-prefixed IDs; fence failover.
معیار پاسخ خوبWhat a good answer demonstrates
high-water mark قبل از صدور ID پایدار می‌شودDurable high-water mark
gap را از duplicate جدا می‌کندGaps versus duplicate IDs
نیاز به هماهنگی را به ضمانت ordering وصل می‌کندOrdering-specific coordination
پیگیری مصاحبه:Interview follow-up:دو node بازه‌های جدا دارند؛ آیا IDهای صادرشده به ترتیب زمان جهانی افزایش می‌یابند؟Two nodes issue IDs from disjoint ranges. Do the IDs increase in global real-time order?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific40 دقیقه بحث40 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
linearizability checker برای infra/database بسیار خوب ولی در جلسه معمول بیشتر history reasoning پرسیدنی است.A specialist checker lab; small-history reasoning is the live interview version.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
یک history کوچک شامل invoke/return read و write را روی register خطی‌سنجی کن. ترتیب real-time را حفظ و عملیات هم‌پوشان را جابه‌جا کن. برای test harness bounded search طراحی کن؛ pending operation و timeout نامعلوم را درست مدل کن.Check a small register history while preserving real-time precedence and reordering overlapping operations. Design bounded search, model pending/indeterminate operations and explain the limits of sampled histories.
معیار پاسخ خوبWhat a good answer demonstrates
completion قبل از invocation بعدی تقدم اجباری داردReal-time precedence
خواندن stale بعد از write تمام‌شده رد می‌شودCompleted-write stale-read rejection
checker اثبات همهٔ اجراهای آینده نیستLimits of finite testing
پیگیری مصاحبه:Interview follow-up:timeout یک write را failed حساب می‌کنی یا indeterminate؟ چرا؟Do you model a timed-out write as failed or indeterminate, and why?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific30 دقیقه بحث30 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
memory-bounded aggregation برای data/platform کاربرد دارد؛ pipeline یونیکس ابزار آموزشی است و آستانه URL عدد عمومی ندارد.Useful data/platform work; no universal distinct-URL threshold exists.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
top URLها را برای لاگی بزرگ‌تر از RAM محاسبه کن. hash aggregation و external sort را با cardinality، RAM، spill، I/O و approximate counting مقایسه کن. benchmark را با ورودی، memory cap و خروجی برابر طراحی کن؛ آستانه شکست را برای همان محیط گزارش کن.Compute top URLs for logs larger than RAM. Compare hash aggregation, external sort, spilling and approximate counts. Benchmark equal outputs under a stated memory cap and report environment-specific limits.
معیار پاسخ خوبWhat a good answer demonstrates
working set به distinct keys و overhead وابسته استCardinality and object overhead
OOM را به کندی عادی تعبیر نمی‌کندOOM versus latency
sort spill و hash spill/partition دیده شده‌اندSpill and partition strategies
پیگیری مصاحبه:Interview follow-up:فقط top-100 تقریبی لازم باشد، کدام قید را می‌توان سبک‌تر کرد؟If only an approximate top-100 is required, which constraint can be relaxed?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific40 دقیقه بحث40 min discussion
اصلاح‌شدهCorrected
دو جریان جدا فقط با user_id مرتب می‌شوند و یک پروفایل یکتا به‌ازای کاربر دارند؛ mixed reducer به profile-first یا buffering نیاز دارد.Two separate streams need user_id sorting and one unique profile per user; a mixed reducer needs profile-first ordering or buffering.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
کلیک‌های بزرگ و یک پروفایل یکتا به‌ازای user را با external sort و streaming merge join ترکیب کن. null/missing profile و skew را تعریف کن. سپس ورودی mixed reducer را مقایسه کن که در آن profile-first secondary sort یا buffering لازم است؛ تفاوت دو قرارداد را بگو.Externally sort and merge clicks with one unique profile per user. Define missing-profile behavior and skew. Contrast this with a mixed reducer stream that needs profile-first ordering or buffering; explain the different contracts.
معیار پاسخ خوبWhat a good answer demonstrates
sort بزرگ‌تر از حافظه spill واقعی داردReal external spill
uniqueness پروفایل و join type مشخص استProfile uniqueness and join type
دو sorted stream را با mixed reducer اشتباه نمی‌گیردSeparate streams versus mixed reducer
پیگیری مصاحبه:Interview follow-up:اگر برای هر user چند نسخهٔ پروفایل تاریخی باشد، کدام نسخه باید به کلیک وصل شود؟With multiple historical profiles per user, which version belongs to a click?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific40 دقیقه بحث40 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
shuffle و skew برای data infra مفیدند؛ نوشتن همهٔ فایل‌ها از صفر برای backend عمومی بازده زمانی پایینی دارد.Useful for data infrastructure; building every file is an optional extended lab.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
shuffle برای group-by را طراحی کن: partition یکسان، sort محلی و merge در reducer. hot key، حجم شبکه، combiner و checksum فایل میانی را تحلیل کن. با خرابی خروجی یک mapper تعیین کن چه چیزی و بر اساس کدام lineage دوباره اجرا می‌شود.Design partitioning, mapper-local sorting and reducer merge for group-by. Analyze hot keys, network volume, combiners and checksums. Recompute lost intermediate output from immutable lineage using isolated attempts.
معیار پاسخ خوبWhat a good answer demonstrates
hash در workerها ثابت و مشترک استStable worker partitioning
retry mapper خروجی attempt جدا داردAttempt isolation
side effect بیرونی قرارداد replay را نقض می‌کندDeterministic side-effect-free retry
پیگیری مصاحبه:Interview follow-up:یک key نصف داده را دارد؛ چگونه reducer را از hotspot نجات می‌دهی؟One key accounts for half the records. How do you prevent a reducer hotspot?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific40 دقیقه بحث40 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
atomic publication کاربرد جدی دارد؛ rename فایل‌سیستم محلی را نباید بی‌قید به object storage تعمیم داد.Atomic publication is valuable; local rename semantics do not automatically transfer to object storage.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
job چندtaskی روی ورودی immutable را با attempt output و manifest نسخه‌دار طراحی کن. crash وسط write و پیش از publish تزریق کن. خواننده باید یک نسخهٔ کامل ثابت ببیند؛ CAS/atomic pointer، cleanup و retry را متناسب با storage انتخاب کن.Design versioned attempt outputs and a job manifest. Inject mid-write and pre-publication crashes. Readers pin one complete manifest; select a storage-appropriate atomic pointer or CAS and safe garbage collection.
معیار پاسخ خوبWhat a good answer demonstrates
task commit با job publish یکی نیستTask completion versus job publication
reader manifest را یک بار pin می‌کندPinned reader manifest
پیگیری مصاحبه:Interview follow-up:دو job هم‌زمان روی یک نام خروجی publish کنند؛ کدام نسخه برنده می‌شود؟Two jobs concurrently publish to the same output name. Which version wins?
checkpoint با کلید (topic,partition) همراه totalها commit می‌شود؛ epoch مالک در DB و در همان تراکنش بررسی می‌شود.Checkpoints keyed by (topic,partition) commit with totals; the sink database checks owner epoch within that transaction.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
Kafka با سه partition و click count در DB را طراحی کن. اثر و checkpoint هر topic/partition را در یک تراکنش ذخیره کن؛ last_offset هر کاربر فقط با key-to-partition ثابت معنا دارد. crash، ACK گم‌شده، rebalance و stale consumer را با fencing و replay منظم تحلیل کن.Count clicks from three Kafka partitions into a database. Commit effects and topic/partition checkpoints together. Explain fixed key routing for per-user offsets, crashes, lost ACKs, ordered replay, rebalances and stale-consumer fencing.
معیار پاسخ خوبWhat a good answer demonstrates
offset دو partition مقایسه نشدهPartition-scoped offsets
commit اثر و checkpoint اتمیک استAtomic output/checkpoint
پرش offset، writer هم‌زمان و rebalance پوشش داده شده‌اندOrdering, rebalance and fencing
پیگیری مصاحبه:Interview follow-up:تعداد partitionها تغییر کند و کاربر جابه‌جا شود؛ dedup key چگونه مهاجرت می‌کند؟Partition count changes and a user moves. How do you migrate the dedup identity?
L2 · SeniorL2 · Seniorوابسته به نقشRole-specific40 دقیقه بحث40 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
event-time join و late data برای streaming مناسب‌اند؛ زمان ثابت چند دقیقه بدون توزیع lateness توجیه ندارد.Lateness choices need measurements rather than an arbitrary timeout.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
search و click را با session و event time در پنجره یک‌ساعته join کن. هر دو arrival order، dedup و تعریف CTR را پوشش بده. watermark، idle partition، allowed lateness و اصلاحیه را بر اساس دادهٔ lateness انتخاب کن؛ در throughput ده‌برابری state و backpressure را برآورد کن.Join search and click by session and event time. Handle either arrival order, dedup and CTR semantics. Choose watermarks, idle-partition policy, lateness and corrections; estimate tenfold state growth and backpressure.
معیار پاسخ خوبWhat a good answer demonstrates
processing time با event time یکی نیستEvent versus processing time
join چندبه‌چند CTR را بی‌دلیل چندبرابر نمی‌کندAvoid duplicate join inflation
late-drop و correction metric دارندMeasured lateness/correction policy
پیگیری مصاحبه:Interview follow-up:یک partition بیکار watermark را نگه دارد؛ پنجره‌ها را چطور می‌بندی؟An idle partition holds back the watermark. How do you close windows safely?
snapshot سازگار باید با مرز لاگِ معتبر هماهنگ شود؛ event topic و state topic کلید و retention متفاوت دارند و bootstrap هزینهٔ قابل‌اندازه‌گیری دارد.A consistent snapshot must align with a valid log boundary; event and state topics have different keys/retention and bootstrap has measurable cost.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
ایندکس جست‌وجو را بدون dual write با قرارداد event مستقل از schema داخلی طراحی کن. تراکنش business+outbox، consistent snapshot مرجع و مرز LSN را مشخص کن. event-ID dedup را از compacted state با entity key و tombstone جدا کن؛ lag، WAL retention، rebuild و schema change را تست کن.Build a search view without dual writes or public table schemas. Specify business+outbox atomicity, a consistent record snapshot and its LSN boundary, event-ID dedup, compacted entity keys, tombstones, WAL retention and throttled rebuilding.
معیار پاسخ خوبWhat a good answer demonstrates
snapshot gap/duplicate و replay پوشش داده شده‌اندSnapshot boundary and replay
کلید compaction و delete semantics صریح استEntity key and tombstone semantics
فشار snapshot صفر فرض نشده و throttling داردBounded snapshot/WAL pressure
پیگیری مصاحبه:Interview follow-up:outbox قدیمی purge شده؛ مصرف‌کنندهٔ جدید از کجا state کامل را می‌سازد؟Old outbox rows have been purged. Where does a new consumer get complete state?
انتقال با request ID و پاسخ گم‌شده مسئلهٔ اصلی backend است؛ با فصل ۸ هم‌پوشانی دارد، اینجا endpoint و replay سرتاسری محورند.Strong endpoint exercise; distinguish it from the local consumer lab.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
API انتقال دو حساب را با request ID از client تا DB طراحی کن. payload و نتیجه را به ID bind کن؛ UNIQUE، debit/credit و log باید اتمیک باشند. پاسخ commit گم‌شده و retry را تحلیل کن و projection موجودی را مستقل از log بساز.Design a transfer API with end-to-end request IDs bound to payload and result. Commit uniqueness, debit/credit and the input log together. Recover lost commit responses and independently rebuild balances from the log.
معیار پاسخ خوبWhat a good answer demonstrates
دو transfer یکسان با ID متفاوت مجازندIndependent intentional transfers
همان ID با payload متفاوت رد می‌شودReject reused ID with different payload
balance invariant و نتیجهٔ replay حفظ می‌شوندBalances and replay invariants
پیگیری مصاحبه:Interview follow-up:دو درخواست هم‌زمان با یک ID برسند؛ پاسخ موفق یا pending را چگونه تعیین می‌کنی؟Two requests with the same ID arrive concurrently. How do you return success or pending?
migration و rollback از تمرین‌های بسیار باارزش Staff هستند؛ read traffic shifting باید با صحت و lag محدود شود.Migration and rollback are high-value staff design topics.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
schema کاتالوگ را با یک log مرجع و دو projection قدیم/جدید مهاجرت بده. backfill+catch-up، shadow read، canary، rollback و زمان حذف نسخه قدیم را تعریف کن. bug در projection جدید و lag را inject کن؛ compatibility و مالکیت write path را روشن نگه دار.Migrate a catalog with a shared input log and independent old/new projections. Specify backfill, catch-up, shadow reads, canary routing, rollback and old-view retirement. Inject projection bugs and lag; keep write ownership explicit.
معیار پاسخ خوبWhat a good answer demonstrates
درصد ترافیک با feature flag قابل بازگشت استReversible traffic routing
schema جدید قبل از آماده‌شدن خوانده نمی‌شودReadiness before cutover
چک صحت، هزینه دو نسخه و cutover criteria روشن‌اندValidation and dual-view cost
پیگیری مصاحبه:Interview follow-up:کاربر بعد از خواندن schema جدید داده‌ای بنویسد که نسخه قدیم نمی‌فهمد؛ rollback هنوز ممکن است؟A client writes data the old schema cannot represent after reading the new schema. Is rollback still possible?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific50 دقیقه بحث50 min discussion
اصلاح‌شدهCorrected
رکورد فایل framing/checksum و fsync دارد؛ تصمیم و تعهد انتشار پایدارند. pending و اثر هر leg باید با مرز مشاهده مشخص حساب شوند.File records need framing/checksum and fsync; decisions and publication obligations are durable. Account for pending funds and each leg at a defined observation boundary.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
انتقال مبدأ، مقصد و کارمزد را با سه log و پردازش قطعی طراحی کن. framed record/checksum/fsync، رزرو موجودی، تصمیم پایدار، outbox و dedup را مشخص کن. crash پس از انتشار بخشی از خروجی را بازیابی کن و تفاوت integrity نهایی، pending state و رؤیت اتمیک را بیان کن.Design source/destination/fee logs using framed checksummed durable records, reserved funds, persistent decisions, an outbox and dedup. Recover after publishing only some outputs. Distinguish pending funds, final integrity and atomic visibility.
معیار پاسخ خوبWhat a good answer demonstrates
تصمیم retry با موجودی متفاوت دوباره گرفته نمی‌شودPersistent deterministic decision
پول در حال انتقال در حسابداری دیده می‌شودAccount for pending funds
جبران یا پیشبرد تصمیم با مدرک انتخاب شدهExplicit visibility guarantees
پیگیری مصاحبه:Interview follow-up:مقصد برای همیشه بسته شده باشد؛ چگونه پرداخت pending را حل می‌کنی؟The destination account closes permanently. How do you resolve a pending transfer?
reconciliation و silent corruption عمق عملیاتی خوبی دارند؛ checker باید checkpoint برابر و فرض مستقل داشته باشد.Independent reconciliation should compare the same checkpoint, not different ages of state.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای انتقال یا projection یک auditor مستقل طراحی کن که log مرجع را تا checkpoint مشخص بازپخش کند. state واقعی را در همان مرز مقایسه کن، mismatch و lag را جدا بشمار و missing update تزریق کن. حدود تشخیص bug مشترک، هزینه و repair امن را توضیح بده.Replay the authoritative log to a stated checkpoint using an independent auditor. Compare actual state at the same boundary, distinguish lag from corruption, inject missing updates and define safe repair and shared-bug limitations.
معیار پاسخ خوبWhat a good answer demonstrates
stateهای دو زمان متفاوت مقایسه نمی‌شوندSame-checkpoint comparison
checker همان تابع buggy را بدون استقلال تکرار نمی‌کندIndependent recomputation
تشخیص با repair خودکار بی‌قید یکی نیستDetection versus safe repair
پیگیری مصاحبه:Interview follow-up:لاگ ورودی خودش ناقص باشد؛ auditor چه چیزی را نمی‌تواند ثابت کند؟The input log itself is incomplete. What can the auditor no longer prove?
L2 · SeniorL2 · SeniorمکملSupplementary35 دقیقه بحث35 min discussion
اختیاری برای این مسیرOptional for this track
برای ML/fairness ارزشمند است؛ آموزش مدل تبعیض‌آمیز مصنوعی اولویت عمومی مصاحبهٔ backend نیست.Valuable for ML/fairness roles, not a general backend prerequisite.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای مدل وام با proxyهایی مثل کدپستی، leakage و اختلاف پذیرش گروه‌ها را تحلیل کن. metric عدالت را با objective و label bias انتخاب کن؛ baseline، subgroup evaluation، appeal و monitoring را طراحی کن. روشن کن حذف ویژگی حساس چه چیزی را حل نمی‌کند.Analyze protected-group proxies and unequal acceptance in a lending model. Choose an operational fairness objective, address label bias and evaluate subgroup outcomes, utility, appeals and synthetic-data limitations.
معیار پاسخ خوبWhat a good answer demonstrates
correlation با causation یا قصد مدل یکی نیستCorrelation limitations
fairness به یک metric خلاصه نشدهMultiple fairness objectives
utility و محدودیت داده مصنوعی صریح استUtility and synthetic-data limits
پیگیری مصاحبه:Interview follow-up:ground truth وام‌های ردشده را نداریم؛ ارزیابی equal opportunity چه مشکلی دارد؟There is no outcome label for rejected loans. What problem does this cause for equal-opportunity evaluation?
feedback loop برای systems thinking آموزنده است؛ عدد ۵۰ دوره و مدل ثروت شواهد واقعی استخدام نیستند.A systems-thinking exercise; a toy wealth simulation is not empirical hiring evidence.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای score→employment→income→score یک feedback loop رسم کن. فرض‌های مدل را بگو، دو مداخله پیشنهاد بده و sensitivity analysis با seed و پارامتر مشترک طراحی کن. metric inequality، subgroup outcome و آثار ناخواسته را مشخص کن.Draw score/employment/income feedback. State assumptions, compare two interventions with matched seeds and populations, and test sensitivity, inequality and unintended subgroup effects.
معیار پاسخ خوبWhat a good answer demonstrates
شبیه‌سازی را اثبات اجتماعی معرفی نمی‌کندNo social proof from toy simulation
دو مداخله با شرایط اولیه برابر مقایسه می‌شوندMatched seeds and populations
پایداری نتیجه نسبت به پارامترها سنجیده می‌شودParameter sensitivity
پیگیری مصاحبه:Interview follow-up:مداخله میانگین ثروت را بهتر کند ولی بدترین گروه را بدتر؛ نتیجه را چگونه گزارش می‌دهی؟An intervention raises mean wealth but worsens the weakest group. How do you report it?
L2 · SeniorL2 · SeniorمکملSupplementary30 دقیقه بحث30 min discussion
اختیاری برای این مسیرOptional for this track
privacy review مفید است؛ نتیجهٔ حقوقی قطعی از یک policy عمومی یا فرض «همه‌چیز باید consent باشد» غلط است.A public privacy policy does not prove implementation; consent is not the only legal basis.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
یک policy واقعی را با تاریخ و نسخه مشخص بخوان و data flow را رسم کن. consent را از سایر مبانی پردازش تفکیک کن؛ purpose، retention، withdrawal و انتخاب کاربر را بررسی کن. ادعاهای تأییدنشده درباره implementation را unknown علامت بزن و گزارش مهندسی بده.Review a dated real policy, map purposes and retention, distinguish consent from other processing bases, assess withdrawal and user choice, and mark implementation claims unknown. Produce an engineering assessment rather than a legal verdict.
معیار پاسخ خوبWhat a good answer demonstrates
policy عمومی مدرک implementation نیستPolicy versus implementation
consent فقط یکی از مبانی حقوقی استMultiple lawful processing bases
برداشت مهندسی از رأی حقوقی جداستEngineering versus legal conclusions
پیگیری مصاحبه:Interview follow-up:رد tracking موجب از دست رفتن خدمت پایه شود؛ چه سؤال‌هایی برای بررسی رضایت آزاد لازم است؟Refusing tracking removes the basic service. What evidence is needed to assess freely given consent?
L3 · Staff / PrincipalL3 · Staff / Principalوابسته به نقشRole-specific40 دقیقه بحث40 min discussion
نسخهٔ مصاحبه‌ای آمادهInterview brief ready
data minimization، retention و حذف سرتاسری برای platform/security مهم‌اند؛ با فصل ۱ مشترک است ولی اجرای purge محور متفاوت دارد.Valuable for privacy/security/platform; deletion operations differ from the chapter-one options discussion.
صورت مصاحبه‌ای و معیار پاسخInterview brief and answer criteria
برای فروشگاه جدول data/purpose/retention/delete طراحی کن. purge دوره‌ای، legal hold، aggregate قابل بازشناسایی، backup restore و audit بدون ذخیره PII اضافه را پوشش بده. حذف را در cache، search و model data پیگیری کن و سناریوی رخنه را با موجودی واقعی داده بسنج.Design retention and purge for a shop, including legal holds, re-identifiable aggregates, backups, restores and minimal audit data. Trace deletion through derived views and evaluate breach exposure using the actual data inventory.
معیار پاسخ خوبWhat a good answer demonstrates
retention نمونه را الزام قانونی معرفی نمی‌کندIllustrative versus required retention
aggregate را خودکار ناشناس نمی‌داندAggregate re-identification risk
purge idempotent و قابل ردیابی طراحی شدهIdempotent traceable purge
پیگیری مصاحبه:Interview follow-up:restore بکاپ شش‌ماهه چگونه مانع برگشت کاربران حذف‌شده می‌شود؟How does restoring a six-month-old backup avoid resurrecting deleted users?
همه در ۱۴ اکتبر ۲۰۲۶ بررسی شده‌اند. منبع استخدام، معیار را پشتیبانی می‌کند؛ مستند فنی، ادعای فنی را. هیچ لینک استخدامی به معنی تأیید سؤال دقیق این مجموعه نیست. مطالب قدیمیِ بنیادی مثل ABD به‌صرف قدیمی بودن منسوخ نیستند.All were checked on 14 October 2026. Hiring guides support evaluation criteria; technical documentation supports technical premises. No hiring link certifies the exact exercise as a real interview question. Foundational work such as ABD is not obsolete merely because it is old.
