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

معرفی

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

موارد زیر تصویری کلی از این بخش برای این راهنما ارائه می‌کنند.

• پیاده‌سازی قابلیت در دو سمت محصول

  توانایی تبدیل نیازی مانند ثبت سفارش یا مدیریت پروفایل به اجزای رابط، API، مدل داده و سناریوهای خطا

• درک زبان و محیط اجرای پشته

  تسلط بر مفاهیم پایه، چرخه حیات و نحوه اجرای کد در فرانت‌اند و بک‌اند

• توسعه رابط کاربری قابل‌نگهداری

  ساخت کامپوننت‌های منسجم و مدیریت وضعیت کارآمد

• طراحی و مصرف API

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

• مدل‌سازی و پرس‌وجوی داده

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

• رفع اشکال چندلایه

  توانایی دنبال‌کردن خطا از رابط کاربری و درخواست شبکه تا لاگ سرور و داده پایگاه داده

• تست و تحویل تغییر

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

• کنترل نسخه و بازبینی کد

  استفاده درست از Git و مشارکت موثر در بازبینی کدهای تیم

• همکاری با محصول و طراحی

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

• قضاوت درباره محدودیت‌ها

  اتخاذ تصمیم‌های فنی متناسب با زمان، هزینه و نیازهای پروژه

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

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

• انتخاب محور آمادگی بر اساس آگهی

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

  • قرارداد API

  • داده

  • اعتبارسنجی

  • تست

  • کنترل نسخه

  • و رفع اشکال

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

• مرور پروژه‌های یکپارچه

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

  مرز دقیق مسئولیت خود را در پروژه‌های گروهی مشخص کنید و کامپوننت‌ها، «نقاط پایانی» (Endpoints)، کوئری‌ها یا رفع اشکال‌های انجام‌شده توسط خود را نام ببرید.

• مفاهیم زبان و رابط کاربری پشته آگهی

  مفاهیم زبان و فریم‌ورک موردنیاز آگهی را مرور کنید. از بین مفاهیم و تکنولوژی‌های JavaScript موراد زیر را تمرین کنید.

  • مفاهیم Promise

  • Async/Await

  • Scope

  • تفاوت Reference و Value

  • چرخه خطا در درخواست شبکه

  • و مدیریت وضعیت

  حالت‌های بارگذاری، خطای اعتبارسنجی، خطای شبکه و ارسال تکراری را در فرم‌ها بررسی کنید. تب‌های Network و Console را در Chrome DevTools تمرین کنید.

• API، احراز هویت و خطا

  برای منبعd مشخص، قرارداد API شامل مسیرها، روش‌های HTTP، بدنه درخواست، پاسخ موفق و خطاهای مختلف را طراحی کرده و تفاوت احراز هویت و مجوزدهی را مشخص کنید. نحوه تبدیل خطاهای ۴۰۰، ۴۰۱، ۴۰۳ و ۵۰۰ را به رفتار قابل‌فهم برای کاربر در فرانت‌اند تمرین کنید. قراردادها را با Postman آزمایش کنید.

• SQL و اثر تغییرات داده

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

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

• تست، Git و بازبینی تغییرات

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

  • سناریوهای موفق

  • ورودی‌های نامعتبر

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

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

  توضیح دهید که کدام سناریوها را با تست واحد، کدام را با تست یکپارچه و کدام را با بررسی دستی ارزیابی می‌کنید.

  تاریخچه Git پروژه را مرتب نگه دارید. درباره «درخواست‌های ادغام» (Pull Request) توضیح دهید. دلیل تقسیم تغییرات به ثبت‌های کوچک (Commit) را مشخص کنید. همچنین نحوه برخورد با نظر بازبین را در پروژه توضیح دهید.

• تمرین رفع اشکال سرتاسری

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

• خواندن آگهی و پشته فنی شرکت

  آگهی را به سه بخش تقسیم کنید:

  • فناوری‌های ضروری

  • فناوری‌های ترجیحی

  • مسئولیت‌های واقعی نقش

  اگر شرکت از React و Node.js استفاده می‌کند، پروژه خود را با همان پشته توضیح دهید. اگر از Vue.js، Next.js، PHP، Java، .NET یا پشته دیگری استفاده می‌کند، روی مفاهیم مشترک مانند قرارداد API، داده و تست تمرکز کنید.

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

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

چک‌لیست زیر کمک می‌کند هیچ نکته مهمی را از قلم نیندازید:

• پروژه دارای رابط، API و پایگاه داده برای ارائه انتخاب کرده‌ام.
• می‌توانم مسئولیت دقیق خودم را در هر پروژه تفکیک کنم.
• جریان هر درخواست را از مرورگر تا پایگاه داده توضیح می‌دهم.
• کدهای وضعیت HTTP و رفتار رابط در خطاهای رایج را مرور کرده‌ام.
• چند کوئری SQL مرتبط با پروژه خود را تمرین کرده‌ام.
• خطای واقعی یا تمرینی را با DevTools و لاگ‌ها ردیابی کرده‌ام.
• برای قابلیت‌های اصلی پروژه، سناریوهای تست و لبه را فهرست کرده‌ام.
• تاریخچه Git و README پروژه قابل‌خواندن است.
• آگهی شغلی، پشته فنی و مسئولیت‌های تیم را بررسی کرده‌ام.
• برای فناوری‌های ناآشنای آگهی، تجربه نزدیک یا برنامه یادگیری مشخصی دارم.
• لینک نمونه‌کار و مخزن کد را پیش از جلسه باز کرده و بررسی کرده‌ام.
• پرسش‌های مشخصی درباره API، انتشار و بازبینی کد در تیم آماده کرده‌ام.

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

• فنی

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

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

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

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

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

• فنی

  تفاوت احراز هویت و مجوزدهی چیست و در API کجا بررسی می‌شوند؟

  بررسی فهم مفاهیم پایه امنیت در قابلیت‌هایی که رابط و بک‌اند را به هم متصل می‌کنند.

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

  احراز هویت را تشخیص هویت کاربر و مجوزدهی را بررسی اجازه انجام عمل تعریف کنید. بر لزوم اعمال هر دو در سمت سرور تأکید کنید و کدهای status مرتبط (۴۰۱ و ۴۰۳) را توضیح دهید.

  احراز هویت هویت درخواست‌کننده را با Session یا Token مشخص می‌کند. مجوزدهی میزان دسترسی کاربر به منابع را بررسی می‌کند. پنهان‌کردن دکمه در فرانت‌اند فقط جنبه تجربه کاربری دارد. سرور باید برای عدم احراز هویت کد ۴۰۱ و برای عدم دسترسی کد ۴۰۳ را برگرداند.

• فنی

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

  بررسی توانایی طراحی قرارداد API، صفحه‌بندی، فیلتر، بارگذاری تدریجی و کنترل هزینه داده

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

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

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

• فنی

  چگونه منشا خطایی را پیدا می‌کنید که کاربر می‌گوید صفحه پروفایل گاهی خالی نمایش داده می‌شود؟

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

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

  بررسی را با دریافت شرایط بازتولید آغاز کنید. موارد زیر را کنترل کنید.

  • درخواست‌های Network

  • کد وضعیت

  • بدنه پاسخ

  • و خطاهای Console

  لایه‌های لاگ سرور و شرط‌های رندر را در صورت نیاز بررسی کنید.

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

• فنی

  چه زمانی تغییر در مدل داده می‌تواند قابلیت ظاهرا فرانت‌اندی را خراب کند؟

  بررسی درک وابستگی میان قرارداد API، ساختار داده و رفتار کامپوننت‌های رابط

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

  نمونه‌هایی مانند تغییر نام، حذف یا تغییر نوع فیلد را بیان کنید. اثر تغییر را روی serializer و API و تایپ‌های فرانت‌اند توضیح دهید و راهکارهای کاهش ریسک را ارائه دهید.

  تغییر نام یا نوع یک فیلد در پایگاه داده می‌تواند پاسخ API را تغییر دهد و باعث بروز خطا در فرانت‌اند شود. برای جلوگیری از این مشکل، تغییرات را به صورت مرحله‌ای انجام می‌دهم، «سازگاری عقب‌رو» (Backwards Compatibility) را حفظ می‌کنم و تست‌های یکپارچه را به کار می‌گیرم.

• نمونه‌کار

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

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

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

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

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

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

• نمونه‌کار

  اگر مخزن پروژه شما را باز کنیم، از کجا شروع کنیم و چه چیزی را بررسی کنیم؟

  بررسی آمادگی شما برای ارائه نمونه‌کار قابل‌اجرا و توانایی هدایت مصاحبه‌گر به بخش‌های مهم کار

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

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

  پیشنهاد می‌کنم بررسی پروژه را از فایل README و دستورالعمل راه‌اندازی شروع کنید. ساختار پوشه‌ها، بخش‌های فرانت‌اند و بک‌اند را از هم جدا کرده است. در ادامه، قابلیت ثبت سفارش را بررسی کنید. این قابلیت شامل فرم، API و کوئری پایگاه داده است. پوشش تست‌های یکپارچه هنوز کامل نشده است و تکمیل آن در برنامه توسعه قرار دارد.

• موقعیتی

  مدیر محصول می‌خواهد قابلیت جدید تا فردا منتشر شود، اما شما متوجه شده‌اید API موجود داده کافی برای رابط ندارد. چه می‌کنید؟

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

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

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

  • تغییر کوچک API

  • کاهش دامنه رابط

  • عقب‌انداختن بخش غیرضروری

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

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

• موقعیتی

  پس از انتشار، تغییری در API باعث خطا در نسخه قدیمی رابط شده است. واکنش شما چیست؟

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

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

  اولویت را کنترل اثر بر کاربر قرار دهید. استفاده از rollback یا حفظ سازگاری موقت را مطرح کنید و سپس فرآیند پیشگیری را توضیح دهید.

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

  بعد از پایدارشدن وضعیت، علت ناسازگاری را بررسی می‌کنیم:

  • آیا تغییر قرارداد مستند نشده بود؟

  • نسخه فعال رابط شناخته نشده بود یا تست یکپارچه نداشتیم؟

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

• رفتاری

  نمونه‌ای بگویید که بازبینی کد باعث شد راه‌حل شما تغییر کند.

  ارزیابی انعطاف‌پذیری، نقدپذیری و روحیه کار تیمی

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

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

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

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

• رفتاری

  وقتی گزارش خطا مبهم است، چگونه آن را به مسئله‌ای قابل‌پیگیری تبدیل می‌کنید؟

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

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

  پرسش‌های نقش‌محور مطرح کنید:

  • کاربر چه عملی انجام داده؟

  • انتظارش چه بوده؟

  • نتیجه چه شده؟

  • چه زمانی رخ داده؟

  • چه نوع حسابی داشته؟

  • و آیا خطا تکرار می‌شود؟

  سپس معیار پذیرش و مسیر بازتولید بنویسید.

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

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

• فرهنگی

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

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

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

  به‌جای ردکردن کلی طرح، محدودیت را مشخص کنید. برای مثال:

  • داده در دسترس نیست.

  • بارگذاری طول می‌کشد.

  • وضعیت خطا تعریف نشده است.

  • یا پیاده‌سازی با زمان تحویل سازگار نیست.

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

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

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

• فرهنگی

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

  بررسی توانایی ایجاد قراردادهای روشن، برنامه‌ریزی انتشار و حفظ استقلال نسبی تیم‌ها

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

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

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

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

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

• فنی

  برای یک قابلیت جدید، چگونه تصمیم می‌گیرید چه بخشی در کلاینت و چه بخشی در سرور اجرا شود؟

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

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

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

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

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

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

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

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

  عنوان فول‌استک در شرکت‌ها دامنه‌های متفاوتی دارد و این پرسش از انتظار نادرست درباره عمق کار جلوگیری می‌کند.

• برای قابلیت جدید، قرارداد API و طراحی رابط در چه مرحله‌ای با هم هماهنگ می‌شوند؟

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

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

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

• فرایند انتشار چگونه است و توسعه‌دهنده چه نقشی در بررسی خطاهای پس از انتشار دارد؟

  دامنه مسئولیت واقعی نقش در تحویل و پشتیبانی قابلیت‌ها را مشخص می‌کند.

• بیشترین مسئله فنی فعلی محصول در مرز فرانت‌اند، API و داده چیست؟

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

• آیا تیم تست خودکار برای مسیرهای اصلی، محصول دارد و انتظار شما از توسعه‌دهنده در این زمینه چیست؟

  سطح موردانتظار مسئولیت در کیفیت و نوع تست‌های رایج تیم را روشن می‌کند.

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

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

• آیا داده یا API-های قدیمی وجود دارند که توسعه این نقش را دشوار کنند؟

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

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

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

• معرفی خود به‌عنوان متخصص همه فناوری‌ها

  به جای ادعای تخصص کامل، بر توانایی یادگیری و مفاهیم پایه تمرکز کنید.

• توضیح پروژه بدون تفکیک مسئولیت شخصی

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

• نادیده‌گرفتن خطا و حالت‌های لبه

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

• فرض اینکه کنترل فرانت‌اند برای امنیت کافی است.

  اعتبارسنجی فرانت‌اند را کافی ندانید و بر کنترل نهایی در سرور تاکید کنید.

• پاسخ حفظی درباره فریم‌ورک بدون مثال عملی

  مفاهیم را با مثال‌های عملی از پروژه‌های خود همراه سازید.

• حدس‌زدن علت خطا پیش از بازتولید

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

• بی‌توجهی به قرارداد API

  به تاثیر تغییرات سمت سرور روی کلاینت توجه ویژه داشته باشید.

• پیشنهاد ابزار بدون در نظر گرفتن شرایط

  فناوری‌ها را متناسب با نیاز پروژه و پشته موجود انتخاب کنید.

پس از مصاحبه

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

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

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

• آموزش پروژه محور React و Node.js، رجیستریشن و ساخت پنل ادمین + گواهینامه آموزش ویدئویی
• آموزش مقدماتی نود جی اس Node.js + گواهینامه آموزش ویدئویی
• آموزش ساخت API با Express.js و Node.js + گواهینامه آموزش ویدئویی
• آموزش پروژه محور ری اکت جی اس، طراحی وب اپلیکیشن پیشرو PWA با React.js + گواهینامه آموزش ویدئویی
• آموزش تست نویسی در ری اکت React + پیاده سازی و پروژه + گواهینامه آموزش ویدئویی
• فول استک چیست و چگونه برنامه نویس فول استک شویم؟ آموزش متنی
• مصاحبه کاری به انگلیسی، راهنمای کامل رایج ترین سوالات آموزش متنی

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

• Top 50 Full Stack Developer Interview Questions وب‌سایتroadmap.sh
• Web APIs, MDN Web Docs, Mozilla مستنداتdeveloper.mozilla.org