راهنمای مصاحبه شغلی توسعه‌دهنده بک‌اند؛ پرسش‌ها و آمادگی فنی

معرفی

شایستگی‌های مورد سنجش

برای آشنایی بهتر با این راهنما، توجه به موارد زیر می‌تواند مفید باشد.

• طراحی و توسعه API

  توانایی تعریف مسیرها، قرارداد درخواست و پاسخ، اعتبارسنجی ورودی، کدهای وضعیت HTTP، صفحه‌بندی و مدیریت خطا در APIهای قابل استفاده برای فرانت‌اند یا موبایل

• مدل‌سازی داده و SQL

  توانایی تبدیل نیازمندی محصول به جدول‌ها و ارتباط‌ها، نوشتن پرس‌وجو، تشخیص پرس‌وجوی پرهزینه و توضیح نقش شاخص‌ها در پایگاه داده

• منطق کسب‌وکار و سناریوهای لبه

  توانایی تشخیص قوانین دامنه، وضعیت‌های نامعتبر، تکرار درخواست، خطای سرویس بیرونی و اثر هم‌زمانی بر داده‌های تراکنشی

• امنیت سرویس و کنترل دسترسی

  درک تفاوت احراز هویت و مجوزدهی، اعتبارسنجی داده، محافظت از اطلاعات حساس و محدودکردن دسترسی هر کاربر به منابع مجاز

• تست و خطایابی

  توانایی نوشتن یا توضیح تست برای منطق مهم، بازتولید باگ، خواندن لاگ، بررسی درخواست‌ها و محدودکردن علت خطا

• کار با کد موجود و Git

  توانایی خواندن ساختار سرویس، ایجاد تغییر کوچک و قابل بازبینی، کار با شاخه‌ها و توضیح تصمیم‌های گرفته شده در بازبینی کد

• عملکرد و پایداری سرویس

  توانایی تشخیص ابتدایی گلوگاه API یا پایگاه داده و توضیح زمان مناسب استفاده از کش، صف، شاخص یا اصلاح پرس‌وجو

• همکاری بین‌تیمی

  توانایی شفاف‌کردن قرارداد API با فرانت‌اند، مطرح‌کردن ابهام نیازمندی با محصول و هماهنگی تغییرات با تیم دواپس

برنامه آماده‌سازی

در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.

• مرور پروژه اصلی خود

  پروژه قابل اجرایی انتخاب کنید که در آن بخش‌های API، پایگاه داده، احراز هویت و مدیریت خطا را پیاده‌سازی کرده‌اید. برای هر بخش، موارد زیر را یادداشت کنید.

  • مسئله

  • تصمیم‌های اتخاذ شده

  • گزینه رد شده

  • و محدودیت‌ها

  باید بتوانید ساختار داده، مسیرهای مهم API، روش اعتبارسنجی و یک باگ واقعی را بدون تکیه بر کد توضیح دهید.

• API و قرارداد HTTP

  سبک «انتقال حالت بازنمایی» (Representational State Transfer | REST)، مسیرهای REST، تفاوت POST و PUT یا PATCH، کدهای وضعیت رایج، اعتبارسنجی ورودی، پاسخ خطا، صفحه‌بندی، فیلتر و نسخه‌بندی API را مرور کنید. با ابزار Postman یک API کوچک را آزمایش کنید و پاسخ‌های موفق، نامعتبر، بدون مجوز و یافت‌نشدن منبع را بررسی کنید.

  برای مرور معنای روش‌ها و کدهای وضعیت، از RFC 9110: HTTP Semantics استفاده کنید.

• SQL و طراحی پایگاه داده

  برای سامانه سفارش یا رزرو، جدول‌ها و ارتباط میان کاربر، سفارش و آیتم را طراحی کنید. عملگرهای JOIN و GROUP BY، تراکنش‌ها، شاخص‌ها و تفاوت جست‌وجوی ساده با پرس‌وجوی پرتکرار را تمرین کنید. آماده باشید تا توضیح دهید چرا شاخص خاصی ساخته‌اید و هزینه نوشتن داده را نیز در نظر گرفته‌اید.

  برای تمرین مفاهیم SQL، مستندات رسمی پایگاه داده همان آگهی را مطالعه کنید، از جمله مستندات PostgreSQL یا مستندات MySQL.

• امنیت و دسترسی

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

  فهرست خطرها و راهکارهای مرتبط با API را در OWASP API Security Project مطالعه کنید.

• تست، لاگ و خطایابی

  برای قانون کسب‌وکار مانند جلوگیری از ثبت سفارش تکراری، چند سناریوی تست بنویسید. مسیر بررسی خطا را تمرین کنید که شامل بازتولید، بررسی ورودی و خروجی، خواندن لاگ، محدودکردن فرضیه‌ها و اصلاح همراه با تستی برای جلوگیری از بازگشت باگ است. مستندات ابزار تست و فریم‌ورک پروژه خود را مبنا قرار دهید.

• فناوری درج‌شده در آگهی

  فقط پشته موردنیاز همان موقعیت را به صورت عمیق مرور کنید. برای ابزارهایی مانند Node.js و Laravel و ASP.NET Core یا Spring Boot، ساختار پروژه، مدیریت وابستگی، مسیر درخواست، تنظیمات محیطی و شیوه تست همان فریم‌ورک را بشناسید. ادعای تسلط بر چند پشته بدون داشتن پروژه قابل دفاع، در مصاحبه آشکار می‌شود.

  مستندات رسمی فناوری آگهی را بخوانید: Node.js، Laravel، ASP.NET Core و Spring Boot.

چک‌لیست آماده‌سازی

پیش از ادامه، فهرست زیر را مرور کنید و مطمئن شوید همه موارد را پوشش داده‌اید:

• پروژه بک‌اند قابل اجرایی با README کوتاه انتخاب کرده‌ام.
• مسیرهای اصلی API و قرارداد درخواست و پاسخ پروژه را مرور کرده‌ام.
• مدل داده، ارتباط جدول‌ها و یکی از کوئری‌های مهم پروژه را توضیح می‌دهم.
• سناریوی احراز هویت و کنترل دسترسی پروژه را می‌شناسم.
• حداقل یکی از باگ‌های واقعی و روش پیدا و رفع‌کردن آن را آماده کرده‌ام.
• برای منطق حساس پروژه، سناریوهای تست را مرور کرده‌ام.
• فناوری‌های صریح آگهی را با تجربه واقعی خود تطبیق داده‌ام.
• لینک مخزن یا پروفایل قابل نمایش در GitHub/GitLab را پیش از جلسه بررسی کرده‌ام.
• درباره نوع استقرار، دسترسی محیط‌ها و پشتیبانی عملیاتی پرسش آماده کرده‌ام.
• شرایط قرارداد، محل کار، ساعت همکاری و تاریخ شروع مورد انتظار را خوانده‌ام.

سئوالاتی که از شما می‌پرسند

• فنی

  برای ساخت API ایجاد سفارش، چه اعتبارسنجی‌هایی انجام می‌دهید و چه پاسخ‌هایی برمی‌گردانید؟

  بررسی درک شما از قرارداد API، اعتبارسنجی سمت سرور، خطاهای قابل پیش‌بینی و جداسازی مسئولیت API از فرانت‌اند.

  راهنمای پاسخ و نمونه پاسخ

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

  • موجودی

  • وضعیت فعال‌بودن کالا

  • مجازبودن کاربر

  پاسخ موفق، خطای ورودی، نبودن منبع، نبودن موجودی و خطای غیرمنتظره را با کد وضعیت مناسب از هم جدا کنید. توضیح دهید که جزئیات داخلی خطا یا اطلاعات حساس در پاسخ عمومی نمایش داده نمی‌شوند.

  ابتدا هویت کاربر را از درخواست بررسی می‌کنم. سپس قالب و مقدار فیلدها، وجود کالاها، تعداد مثبت و وضعیت قابل فروش کالا را اعتبارسنجی می‌نمایم. ایجاد سفارش و کاهش موجودی را در تراکنش ثابتی انجام می‌دهم تا ثبت ناقص رخ ندهد. در صورت موفقیت پاسخ 201 برمی‌گردانم. برای ورودی نامعتبر 400، برای کالای ناموجود یا سفارش نامعتبر 404 یا 422 بر اساس قرارداد تیم، و برای خطای داخلی پاسخ عمومی 500 همراه با ثبت جزئیات در لاگ در نظر می‌گیرم.

• فنی

  تفاوت احراز هویت و مجوزدهی چیست؟

  بررسی درک پایه از امنیت سرویس و کنترل دسترسی به منابع.

  راهنمای پاسخ و نمونه پاسخ

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

  • کاربر ممکن است وارد شده باشد، اما حق مشاهده یا ویرایش سفارش کاربر دیگر را نداشته باشد.

  احراز هویت پاسخ می‌دهد «این درخواست از طرف چه کسی است؟» و مجوزدهی پاسخ می‌دهد «این شخص چه کاری می‌تواند انجام دهد؟». مثلاً توکن معتبر هویت کاربر را مشخص می‌کند، اما هنگام دریافت سفارش باید بررسی کنم شناسه مالک سفارش با کاربر درخواست‌کننده برابر است یا او نقش مجاز دارد. صرف معتبر بودن توکن برای دسترسی به هر منبعی کافی نیست.

• فنی

  API فهرست سفارش‌ها کند شده است. چگونه علت را پیدا می‌کنید؟

  بررسی روش خطایابی عملکرد، توانایی تفکیک گلوگاه برنامه، پایگاه داده و سرویس‌های وابسته.

  راهنمای پاسخ و نمونه پاسخ

  از حدس‌زدن مستقیم شاخص یا Redis پرهیز کنید. ابتدا زمان پاسخ، حجم داده، مسیرهای پرتکرار، لاگ و سنجه‌های موجود را بررسی کنید. سپس زمان اجرای پرس‌وجوها، تعداد درخواست‌های پایگاه داده، صفحه‌بندی، الگوی N+1 و تماس با سرویس بیرونی را جداگانه بسنجید. راه‌حل باید با علت اثبات شده متناسب باشد.

  ابتدا بررسی می‌کنم کندی برای همه کاربران است یا فقط در فیلتر یا بازه زمانی خاص رخ می‌دهد. زمان هر بخش درخواست و پرس‌وجوهای اجرا شده را از لاگ یا ابزار پایش می‌سنجم. اگر پرس‌وجو کند باشد، طرح اجرا، شرط‌ها، JOIN-ها و شاخص‌های مرتبط را بررسی می‌کنم. اگر حجم پاسخ زیاد باشد، صفحه‌بندی و انتخاب فیلدهای لازم را اصلاح می‌نمایم. اگر الگوی N+1 وجود داشته باشد، بارگذاری داده را تغییر می‌دهم. پس از اصلاح، زمان پاسخ و اثر آن بر بار نوشتن یا حافظه را دوباره اندازه می‌گیرم.

• فنی

  شاخص پایگاه داده چه کمکی می‌کند و چه زمانی می‌تواند انتخاب نامناسبی باشد؟

  سنجش درک مزایا و هزینه‌های نگهداری شاخص‌ها در پایگاه داده‌های رابطه‌ای

  راهنمای پاسخ و نمونه پاسخ

  شاخص می‌تواند سرعت جست‌وجو یا مرتب‌سازی داده‌ها را برای الگوهای پرس‌وجوی مشخص افزایش دهد. با این حال، هر شاخص هنگام اجرای دستورات INSERT و UPDATE و DELETE به نگهداری نیاز دارد و فضای ذخیره‌سازی بیشتری مصرف می‌کند. بنابراین، پیش از ایجاد شاخص، باید پرس‌وجوی واقعی، شرط‌های جست‌وجو، ترتیب مرتب‌سازی و طرح اجرای پرس‌وجو را بررسی کنید.

  اگر سفارش‌های کاربری را به طور مکرر بر اساس تاریخ دریافت کنم، ایجاد شاخصی روی ستون‌های شناسه کاربر و تاریخ می‌تواند مفید باشد. با این حال، ایجاد شاخص روی همه ستون‌ها راه‌حل مناسبی نیست، زیرا هزینه ثبت سفارش جدید و تغییر داده‌ها را افزایش می‌دهد. ابتدا پرس‌وجوی پرتکرار و طرح اجرای آن را بررسی می‌کنم. سپس، متناسب با شرط‌ها و ترتیب پرس‌وجو، شاخص مناسب را می‌سازم و تاثیر آن را اندازه می‌گیرم.

• موقعیتی

  پرداخت‌یار، درخواست تایید پرداخت را دوبار ارسال کرده است. چگونه از ثبت دوباره سفارش جلوگیری می‌کنید؟

  بررسی درک شما از درخواست تکراری، هم‌زمانی، تراکنش و طراحی امن فرایندهای مالی.

  راهنمای پاسخ و نمونه پاسخ

  به یکتا بودن شناسه تراکنش یا کلید تکرارناپذیری درخواست (Idempotency Key)، ثبت وضعیت پرداخت، استفاده از تراکنش پایگاه داده و قابلیت اجرای تکرارپذیر عملیات اشاره کنید. پاسخ نباید فقط به بررسی درخواست در سمت فرانت‌اند متکی باشد. توضیح دهید که اگر درخواست موفقی دوباره دریافت شود، همان پاسخ سازگار قبلی را برمی‌گردانید، اما عملیات مالی یا تغییر موجودی را دوباره انجام نمی‌دهید.

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

  اگر همان درخواست دوباره دریافت شود، نتیجه ثبت شده را برمی‌گردانم و موجودی یا وضعیت سفارش را دوباره تغییر نمی‌دهم. در صورت امکان، اعتبار امضای درخواست پرداخت‌یار را نیز بررسی می‌کنم.

• نمونه‌کار

  در پروژه‌ای که ارائه کرده‌اید، چرا این ساختار داده و این مسیرهای API را انتخاب کردید؟

  بررسی مالکیت واقعی پروژه، توانایی پیوند تصمیم فنی با نیازمندی محصول و آگاهی از محدودیت‌ها

  راهنمای پاسخ و نمونه پاسخ

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

  در پروژه رزرو، هر رزرو را به یک کاربر و یک بازه زمانی متصل کردم. برای جلوگیری از تداخل رزروها، وضعیت هر رزرو را جداگانه نگه داشتم و هنگام ثبت رزرو، ظرفیت بازه زمانی را بررسی کردم. مسیرهای API را بر اساس منبع رزرو طراحی کردم تا فرانت‌اند بتواند عملیات ایجاد، مشاهده و لغو رزرو را به صورت جداگانه انجام دهد.

  این طراحی برای پروژه آموزشی کافی بود. اما برای استفاده در سامانه‌ای پرترافیک، باید کنترل هم‌زمانی و ثبت دقیق‌تر رویدادهای تغییر وضعیت را نیز اضافه کنم.

• رفتاری

  در بازبینی کد، با پیشنهادی مخالف بوده‌اید؟ چه کردید؟

  بررسی رفتار شما در دریافت بازخورد فنی و توانایی گفت‌وگو درباره کیفیت، خوانایی یا امنیت کد.

  راهنمای پاسخ و نمونه پاسخ

  یکی از موقعیت‌های واقعی مانند اختلاف درباره ساختار API، نام‌گذاری، پوشش تست یا پرس‌وجوی پایگاه داده را شرح دهید. روشن کنید که معیار تصمیم شما قرارداد تیم، مستندات، خوانایی، تست یا داده عملکردی بوده است، نه ترجیح شخصی. اگر پس از گفت‌وگو نظر خود را تغییر داده‌اید، نتیجه را بیان کنید.

  همکارم پیشنهاد داد منطق پیچیده‌ای را برای سرعت بیشتر در خود کنترلر بنویسم، اما من با انتقال آن به لایه سرویس به دلیل حفظ خوانایی و قابلیت تست‌پذیری مخالفت کردم. پس از بحث و بررسی مستندات فریم‌ورک، به توافق رسیدیم که کد در سرویس قرار بگیرد تا تست‌های واحد به راحتی روی آن اجرا شوند.

• موقعیتی

  تیم فرانت‌اند می‌گوید قرارداد API برای قابلیت جدید مبهم است و زمان انتشار نزدیک است. چگونه مسئله را مدیریت می‌کنید؟

  بررسی توانایی تبدیل نیازمندی مبهم به قرارداد قابل اجرا و جلوگیری از دوباره‌کاری بین تیم‌ها.

  راهنمای پاسخ و نمونه پاسخ

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

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

• فنی

  چه زمانی استفاده از Redis را پیشنهاد می‌کنید و چه داده‌ای را در آن نگه نمی‌دارید؟

  بررسی درک کش، ناسازگاری داده و محدودیت استفاده از Redis در سامانه‌های بک‌اند

  راهنمای پاسخ و نمونه پاسخ

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

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

  استفاده از Redis را برای ذخیره توکن‌های فعال، محدودسازی نرخ درخواست‌ها و کش‌کردن فهرست دسته‌بندی‌های پرتکرار پیشنهاد می‌کنم. داده‌های مهم تراکنشی، مانند موجودی حساب یا اطلاعات قطعی سفارش را هرگز فقط در Redis ذخیره نمی‌کنم، زیرا ممکن است در اثر راه‌اندازی مجدد یا خطاهای حافظه از دست بروند.

• نمونه‌کار

  یک باگ سخت در سرویس خود را چگونه پیدا و رفع کردید؟

  بررسی تجربه عملی در بازتولید مسئله، استفاده از لاگ و ساختن راه‌حل قابل اطمینان

  راهنمای پاسخ و نمونه پاسخ

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

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

• فرهنگی

  اگر برای رفع خطای تولید به دسترسی یا اطلاعاتی نیاز داشته باشید که در اختیار شما نیست، چه می‌کنید؟

  بررسی مسئولیت‌پذیری عملیاتی، رعایت دسترسی‌ها و همکاری با تیم دواپس یا مالک سامانه

  راهنمای پاسخ و نمونه پاسخ

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

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

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

• رفتاری

  نیازمندی‌های یکی از قابلیت‌ها را ناقص دریافت کرده‌اید. پیش از شروع پیاده‌سازی چه پرسش‌هایی می‌پرسید؟

  بررسی توانایی تحلیل نیازمندی پیش از تبدیل آن به جدول، API و منطق کسب‌وکار

  راهنمای پاسخ و نمونه پاسخ

  پرسش‌ها را به موارد زیر وصل کنید.

  • جریان کاربر

  • مالک داده

  • وضعیت‌های مجاز

  • سناریوهای خطا

  • نقش‌های دسترسی

  • اثر بر داده‌های موجود

  • معیار پذیرش برای قابلیت بک‌اند

  مشخص کنید چه رویدادی داده را ایجاد یا تغییر می‌دهد، آیا عملیات برگشت‌پذیر است و کدام سرویس یا تیم مصرف‌کننده API خواهد بود.

  پیش از شروع کدنویسی، درباره وضعیت‌های مجاز موجودیت، خطاهای احتمالی، نقش‌های مجاز و اثر تغییرات بر داده‌های قبلی پرسش می‌کنم. همچنین، بررسی می‌کنم که آیا تغییر API بر کلاینت‌های دیگر اثر می‌گذارد یا خیر. در پایان، معیار پذیرش محصول را مشخص می‌کنم تا شرایط تایید نهایی تغییرات روشن باشد.

• فنی

  برای عملیات طولانی مانند ارسال اعلان به کاربران زیاد، چرا و چگونه پردازش پس‌زمینه طراحی می‌کنید؟

  بررسی درک محدودیت درخواست HTTP، صف، قابلیت تکرار، خطا و مشاهده‌پذیری عملیات پس‌زمینه

  راهنمای پاسخ و نمونه پاسخ

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

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

• فرهنگی

  چه نوع محیط کاری به شما کمک می‌کند سرویس قابل نگهداری‌تری تحویل دهید؟

  بررسی تناسب انتظار متقاضی با فرایندهای واقعی تیم، بازبینی کد، مستندسازی و مسئولیت نگهداری سرویس.

  راهنمای پاسخ و نمونه پاسخ

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

  پیش از شروع کدنویسی، درباره وضعیت‌های مجاز موجودیت، خطاهای احتمالی، نقش‌های مجاز و اثر تغییرات بر داده‌های قبلی پرسش می‌کنم. همچنین، بررسی می‌کنم که آیا تغییر API بر کلاینت‌های دیگر اثر می‌گذارد یا خیر.

  در پایان، معیار پذیرش محصول را مشخص می‌کنم تا شرایط تایید نهایی تغییرات روشن باشد.

پرسش‌های شما از پنل مصاحبه

• پشته اصلی این سرویس چیست و کدام بخش‌ها از کد یا فناوری قدیمی استفاده می‌کنند؟

  کمک می‌کند فاصله میان فناوری آگهی و واقعیت کدبیس، همچنین حجم کار نگهداری را بسنجید.

• توسعه‌دهنده بک‌اند چگونه قرارداد API را با تیم فرانت‌اند و موبایل هماهنگ می‌کند؟

  نشان می‌دهد فرایند همکاری و میزان شفافیت قراردادهای بین سرویس‌ها چگونه است.

• استقرار تغییرات بک‌اند چگونه انجام می‌شود و مسئولیت بازگردانی نسخه در رخداد چیست؟

  برای شناخت بلوغ فرایند استقرار و مسئولیت عملیاتی نقش، اهمیت دارد.

• آیا این موقعیت شیفت پشتیبانی، پاسخ‌گویی به رخداد یا دسترسی به محیط عملیاتی دارد؟

  بار کاری و حساسیت نقش را روشن می‌کند و از غافلگیری پس از استخدام جلوگیری می‌کند.

• مهم‌ترین گلوگاه فعلی سرویس، پایگاه داده یا یکپارچه‌سازی‌های بیرونی چیست؟

  نشان می‌دهد مسئله واقعی تیم چیست و شما روی توسعه قابلیت جدید کار می‌کنید یا نگهداری سامانه حساس.

• برای تست سرویس‌ها چه پوششی انتظار دارید و بازبینی کد چگونه انجام می‌شود؟

  به شما کمک می‌کند انتظار تیم از کیفیت تحویل و فرصت یادگیری از بازخورد فنی را ارزیابی کنید.

• این نقش در سه ماه نخست، بیشتر روی کدام سرویس یا مسئله محصول متمرکز خواهد بود؟

  دامنه اولیه مسئولیت و امکان تطابق تجربه شما با نیاز فوری تیم را مشخص می‌کند.

اشتباه‌های رایج

در ادامه تعدادی از اشتباهاتی که اغلب افراد در مصاحبه شغل «توسعه‌دهنده بک‌اند» انجام می‌دهند، آمده است. پرهیز از انجام این اشتباهات، می‌تواند شانس شما را برای پذیرفته شدن از مصاحبه و استخدام نهایی بیشتر کند.

• ادعای تسلط بر چند پشته بدون تجربه قابل دفاع

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

• پاسخ‌دادن به پرسش API فقط با نام‌بردن از endpoint

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

• نادیده‌گرفتن سناریوهای هم‌زمانی و درخواست تکراری

  برای عملیات حساسی مانند پرداخت، سفارش و موجودی، تراکنش، محدودیت یکتا و رفتار Idempotent را در پاسخ‌ها در نظر بگیرید.

• معرفی Redis یا شاخص به‌عنوان راه‌حل همه کندی‌ها

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

• گفتن اینکه تست نوشته‌اید بدون توضیح سناریو

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

• مبهم‌گذاشتن مسئولیت پشتیبانی عملیاتی

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

• مقصر دانستن فرانت‌اند یا دواپس در خطاهای مشترک

  شواهد فنی، قرارداد مورد توافق و گام‌های مشترک برای محدودکردن مشکل را بیان کنید. از قضاوت درباره تیم دیگر بپرهیزید.

پس از مصاحبه

پرسش‌های پرتکرار

اگر درباره این راهنما پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.

آموزش‌های مرتبط در فرادرس

• آموزش برنامه نویسی پایتون پیشرفته، ترفندهای Python + گواهینامه آموزش ویدئویی
• سؤالات مصاحبه استخدامی برنامه نویس جاوا اسکریپت، به همراه جواب آموزش متنی

منابع پیشنهادی

• 50 Popular Backend Developer Interview Questions and ... مقالهroadmap.sh
• Backend Interview Guide مقالهcornellappdev.com