فرق مصاحبه جونیور، میدل و سینیور: از هر سطح چه انتظاری دارند؟

در مصاحبه جونیور، میدل و سینیور معمولاً همان موضوع‌ها پرسیده می‌شود: React، دیتابیس، کش، API. چیزی که فرق می‌کند عمق سؤال‌هاست و اینکه مصاحبه‌کننده واقعاً دنبال سنجیدن چه چیزی است. اگر بدانید هر سطح بر اساس چه چیزی سنجیده می‌شود، هم درست‌تر آماده می‌شوید و هم برای سطحی اپلای می‌کنید که واقعاً از پسش برمی‌آیید.

هر سطح در عمل یعنی چه؟

عنوان‌های شغلی از شرکتی به شرکت دیگر فرق زیادی دارند، ولی منظور بیشتر مدیران فنی تقریباً این است:

• جونیور (Junior): تسکی را که دقیق تعریف شده با راهنمایی تمام می‌کند. کس دیگری کار را خرد می‌کند، رویکرد را بررسی می‌کند و Edge Caseها را می‌گیرد. مهم‌ترین چیزی که از او سنجیده می‌شود سرعت یادگیری است.
• میدل (Middle / Mid-level): یک فیچر را بدون نظارت نزدیک از اول تا آخر جلو می‌برد. تیکت مبهم را به تسک‌های مشخص تبدیل می‌کند، تصمیم‌های معقول در محدوده خودش می‌گیرد و درست به‌موقع کمک می‌خواهد، نه زود و نه دیر. چیزی که سنجیده می‌شود تحویل قابل‌اعتماد است.
• سینیور (Senior): مسئول نتیجه است، نه فقط تسک. جهت فنی یک سیستم یا تیم را شکل می‌دهد، ریسک‌ها را قبل از اینکه Incident شوند می‌بیند، بقیه را مؤثرتر می‌کند و می‌تواند Trade-offها را برای آدم‌های غیرفنی هم توضیح دهد. چیزی که سنجیده می‌شود قضاوت فنی و اثری فراتر از کد خودش است.

ساده‌ترین معیار برای جدا کردن سطح‌ها اندازه ابهامی است که می‌توانید تنهایی از پسش بربیایید: جونیور از پس تسک مشخص برمی‌آید، میدل از پس یک فیچر و سینیور از پس مسئله‌ای که هنوز کسی صورت‌بندی‌اش نکرده.

جدول مقایسه

یک مفهوم، سه سطح

فرق سطح‌ها اینجا از همه‌جا واضح‌تر است. مصاحبه‌کننده‌ها خیلی وقت‌ها یک موضوع را می‌پرسند و آن‌قدر سؤال پشت سؤال می‌آورند تا به جایی برسند که فهم شما تمام می‌شود.

Re-render در React

• جونیور: «کامپوننت React کی Re-render می‌شود؟» جواب خوب: وقتی State خودش عوض شود، والدش Re-render شود یا Contextی که استفاده می‌کند تغییر کند. اگر بدانید Re-render شدن والد باعث Re-render فرزند می‌شود حتی اگر Propsها عوض نشده باشند، امتیاز اضافه می‌گیرید.
• میدل: «یک لیست ۲۰۰۰ ردیفی با هر بار تایپ در سرچ‌باکس بالایش کند می‌شود. چه می‌کنی؟» اینجا انتظار دارند اول مشکل را تشخیص بدهید و بعد بهینه کنید: React Profiler، نزدیک کردن State به جایی که استفاده می‌شود، React.memo روی ردیف‌ها با Callbackهای پایدار، و در نظر گرفتن Virtualization یا useDeferredValue.
• سینیور: «داشبورد ما کند است و تیم همه‌جا useMemo اضافه می‌کند. چطور با این مسئله برخورد می‌کنی؟» حالا سؤال درباره استراتژی است: اول اندازه‌گیری، تصمیم درباره اینکه State کجا باشد (Server Cache یا Client State)، اینکه کجا Memoization بیشتر از سودش هزینه دارد، تعریف Performance Budget، و راه‌حلی که برای کل تیم قابل نگهداری بماند.

این مسیر را تمرین کنید: React جونیور، React میدل و React سینیور.

ایندکس دیتابیس

• جونیور: «ایندکس چیست و چرا کوئری را سریع می‌کند؟» یک ساختار داده (معمولاً B-tree) که دیتابیس با آن ردیف‌ها را بدون اسکن کل جدول پیدا می‌کند.
• میدل: «این کوئری روی user_id فیلتر و روی created_at مرتب می‌کند و کند است. چه ایندکسی اضافه می‌کنی؟» یک Composite Index روی (user_id, created_at). باید توضیح بدهید چرا ترتیب ستون‌ها مهم است و چطور با EXPLAIN مطمئن می‌شوید مشکل حل شده.
• سینیور: «بعد از اضافه کردن چند ایندکس، نوشتن روی جدول اصلی کند شده و Replicaها عقب افتاده‌اند. حالا چه؟» درباره Write Amplification، ایندکس‌های بلااستفاده یا تکراری، ساختن ایندکس به‌صورت Online بدون قفل کردن جدول، جدا کردن Read از Write، و اینکه کجا راه‌حل واقعی تغییر Data Model یا Partitioning است نه یک ایندکس دیگر.

-- جواب سطح میدل: به‌جای حدس، بررسی کن
CREATE INDEX idx_orders_user_created ON orders (user_id, created_at DESC);
EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 20;

خودتان را بسنجید: دیتابیس میدل و دیتابیس سینیور.

کش (Caching)

• جونیور: «کش چیست؟» یک حافظه سریع که نتیجه‌ای را نگه می‌دارد که در غیر این صورت باید دوباره محاسبه یا دوباره Fetch می‌شد. باید Hit و Miss و TTL را بشناسید.
• میدل: «جلوی Endpoint جزئیات محصول یک کش Redis بگذار.» الگوی Cache-aside، انتخاب Key، تعیین TTL و Invalidation موقع آپدیت. اشاره کنید کاربر در فاصله‌ای که داده Stale است چه می‌بیند.
• سینیور: «یک Key پرطرفدار Expire می‌شود و دیتابیس از کار می‌افتد. راه‌حل را طراحی کن.» Cache Stampede و Thundering Herd، Request Coalescing، TTL با Jitter، الگوی Stale-while-revalidate، کش به‌عنوان Single Point of Failure، و اینکه اگر خود Redis از کار بیفتد چه اتفاقی می‌افتد.

تمرین: کش سینیور.

انتظارات System Design در هر سطح

• جونیور: اغلب پرسیده نمی‌شود. اگر بپرسند، چیزی مثل «یک Request از مرورگر تا دیتابیس و برگشت چه مسیری را طی می‌کند؟» است. می‌خواهند ببینند تصویر ذهنی درستی از Client، Server، دیتابیس و HTTP دارید.
• میدل: طراحی یک سرویس، مثلاً URL Shortener یا API نوتیفیکیشن. انتظار: API شفاف، Schema معقول، یک لایه کش، مقیاس‌پذیری پایه (App Serverهای Stateless پشت Load Balancer) و شناخت گلوگاه‌ها.
• سینیور: هدایت جلسه دست شماست. اول نیازمندی‌ها و عددها را روشن کنید (ترافیک، حجم داده، نسبت خواندن به نوشتن)، طرح بدهید و بعد خودتان آن را زیر فشار ببرید: چه چیزی خراب می‌شود، سیستم چطور Degrade می‌شود، چطور Rollout می‌کنید، هزینه‌اش چقدر است و در ترافیک ۱۰ برابر چه تغییری لازم است. برای مصاحبه‌کننده استدلال شما خیلی مهم‌تر از دیاگرام نهایی است.

برای آمادگی: Scalability میدل و Case Studyهای سطح سینیور.

انتظارات رفتاری (Behavioral) در هر سطح

سؤال‌های رفتاری معمولاً در هر سه سطح یکی است («از یک اختلاف نظر بگو»)، ولی ابعاد داستانی که انتظار دارند بشنوند فرق می‌کند.

• جونیور: یک جا که گیر کردی و چطور راهت را پیدا کردی، برخوردت با Code Review سخت‌گیرانه، چیزی که خودت یاد گرفتی. صداقت و کنجکاوی از نتیجه چشمگیر مهم‌تر است.
• میدل: فیچری که با نیازمندی مبهم تحویل دادی، اختلاف با هم‌تیمی یا Product Manager، باگی که خودت ایجاد کردی و چطور درستش کردی. مصاحبه‌کننده دنبال «من» و کار مشخص است، نه «ما».
• سینیور: تصمیم فنی‌ای که پایش ایستادی و بعد پشیمان شدی، اینکه چطور سطح یک هم‌تیمی ضعیف‌تر را بالا بردی، اینکه چطور به یک Deadline نه گفتی، Incidentی که مدیریتش با تو بود. انتظار Trade-off، عدد و اثرات غیرمستقیم دارند («این Migration دو اسپرینت از ما گرفت، ولی هشدارهای On-call را ۶۰٪ کم کرد»).

یک ساختار ساده کافی است: موقعیت، کاری که شخصاً کردی، نتیجه قابل اندازه‌گیری، و اینکه دفعه بعد چه کار متفاوتی می‌کنی.

Red Flagهایی که مصاحبه‌کننده می‌بیند

جونیور

• تعریف را از حفظ می‌گوید ولی با اولین «چرا؟» جوابش از هم می‌پاشد.
• به‌جای بلند فکر کردن، وانمود می‌کند که می‌داند.
• هیچ نشانه‌ای از ساختن چیزی بیرون از آموزش‌ها ندارد.

میدل

• ابزاری را چون «Best Practice است» انتخاب می‌کند ولی نمی‌تواند بگوید چرا.
• بدون روشن کردن نیازمندی‌ها و Edge Caseها مستقیم شروع به کد زدن می‌کند.
• تست، Error Handling و راه بررسی درست بودن راه‌حل را نادیده می‌گیرد.

سینیور

• می‌گوید «بستگی دارد» و همان‌جا متوقف می‌شود. سینیور می‌گوید به چه چیزی بستگی دارد و بعد یک گزینه را انتخاب می‌کند.
• Over-engineering: میکروسرویس و Kafka برای مسئله‌ای که با یک جدول Postgres حل می‌شود.
• داستان‌هایی بدون Ownership شخصی، بدون شکست و بدون اثر روی آدم‌های دیگر.
• هیچ سؤالی درباره محدودیت‌ها، تیم یا Context بیزینسی نمی‌پرسد.

چطور سطح خودتان را صادقانه ارزیابی کنید

سال‌های سابقه معیار ضعیفی است. کسی که پنج سال همان یک سال را تکرار کرده سینیور نمی‌شود. به‌جایش این سؤال‌ها را از خودتان بپرسید:

1. تست تیکت: با یک تیکت یک‌خطی مبهم، می‌توانید بدون کمک گرفتن یک پلن، تخمین زمانی و فهرست ریسک‌ها بنویسید؟ اگر بله، حداقل میدل هستید.
2. تست Production: مسئول چیزی در Production بوده‌اید، برایش بیدارتان کرده‌اند، Debugش کرده‌اید و جلوی تکرار همان مشکل را گرفته‌اید؟
3. تست «چرا آن یکی نه؟»: برای سه تصمیم فنی آخرتان می‌توانید گزینه‌های دیگر را نام ببرید و بگویید چرا کنارشان گذاشتید؟
4. تست اثر روی بقیه: مهندس دیگری به خاطر Code Review، مستندات یا منتورینگ شما به‌طور محسوس بهتر شده؟ این واضح‌ترین نشانه سینیوریتی است.
5. تست کوییز: کوییزهای جونیور، میدل و سینیور را در موضوع‌هایی که هر روز با آن‌ها کار می‌کنید امتحان کنید، مثلاً JavaScript میدل. اگر در یک سطح مدام نمره خوب می‌گیرید ولی در سطح بعدی حدس می‌زنید، این فاصله از عنوان شغلی‌تان دقیق‌تر است.

اگر بین دو سطح هستید، یا برای سطح پایین‌تر در یک شرکت قوی اپلای کنید یا برای سطح بالاتر در شرکتی که Stack آن کاملاً با شما می‌خواند. اینکه کمی پایین‌تر از سطحتان استخدام شوید و بعد ارتقا بگیرید خیلی بهتر از این است که بالاتر استخدام شوید و زیر فشار بمانید.

وقتی جواب را نمی‌دانید چه بگویید؟

در هر سطحی، «نمی‌دانم» و سکوت بعدش جواب ضعیفی است و یک جواب سرهم‌شده با اعتمادبه‌نفس از آن هم بدتر. الگوی خوب این است:

1. صریح بگویید: «مستقیم با این کار نکرده‌ام.»
2. از چیزی که می‌دانید استدلال کنید: «ولی اگر مثل X کار کند، انتظار دارم...»
3. بگویید چطور پیدایش می‌کنید: داکیومنت، یک آزمایش کوچک، Profiling، پرسیدن از کسی که مسئول آن بخش است.

در مصاحبه سینیور، مصاحبه‌کننده عمداً شما را تا جایی جلو می‌برد که دانسته‌هایتان تمام شود. اینکه آنجا چقدر آرام و ساختارمند استدلال می‌کنید خودِ آزمون است.

از جونیور به میدل

• منتظر تسکی نمانید که کامل مشخص شده باشد. تیکت‌هایتان را خودتان خرد کنید و قبل از کد زدن پلن را بنویسید.
• Debug کردن مستقل را یاد بگیرید: خواندن Stack Trace، استفاده از Debugger و Profiler، خواندن سورس کتابخانه‌ها.
• یک فیچر را تا Production جلو ببرید، همراه با تست، مانیتورینگ و رفع باگ‌های بعدی‌اش.
• مبانی را عمیق یاد بگیرید: Event Loop، Closure، HTTP، SQL. با JavaScript جونیور آن‌قدر تمرین کنید تا جواب‌ها برایتان بدیهی شوند.

از میدل به سینیور

• از «این را چطور بسازم؟» به «اصلاً باید ساخته شود؟ و یک سال دیگر چه هزینه‌ای برایمان دارد؟» برسید.
• Design Doc بنویسید و از نقد استقبال کنید. گزینه‌هایی را که کنار گذاشتید و دلیلش را هم ثبت کنید.
• کارهای کم‌زرق‌وبرق را بردارید: Incident، Migration، تست‌های Flaky، Onboarding. Ownership آنجا خودش را نشان می‌دهد.
• آگاهانه منتورینگ کنید. Code Review را برای یاد دادن انجام دهید، نه فقط برای Approve کردن.
• سیستم‌های توزیع‌شده را جدی یاد بگیرید: Consistency، Replication، صف‌ها و Failure Modeها.

جمع‌بندی

موضوع‌ها بین سطح‌ها تقریباً عوض نمی‌شوند، ولی عمق عوض می‌شود: جونیور چیستی را توضیح می‌دهد، میدل آن را در یک سناریو به کار می‌برد و سینیور Trade-offها و Failure Modeها را می‌سنجد. برای سطحی آماده شوید که زیر سؤال‌های پشت‌سرهم هم بتوانید از آن دفاع کنید. بعد خودتان را در همین موضوع‌ها در هر سه سطح روی DevTier امتحان کنید تا جاهای خالی‌تان مشخص شود.