پوشش دقیق حوزههای آزمون
این بانک سوالات جامع به گونهای طراحی شده است که دقیقاً توزیع وزن فنی مصاحبههای مهندسی مدرن برای نقشهای میانرده تا ارشد جنگو را منعکس کند.
مبانی جنگو (۱۵٪): ساختارهای دایرکتوری استاندارد پروژه، تعریف مدلهای پایه، رندر کردن تمپلیتها، ویوهای تابعی و کلاسبنیاد، و مسیریابی پیچیده URLها.
مدلها و پایگاه داده جنگو (۲۰٪): الگوهای ارثبری مدل (abstract, multi-table, proxy)، تراکنشهای سطح پایین پایگاه داده، شرایط رقابتی (Race Conditions) و مسائل همروندی، کوئریهای پیچیده ORM و بهینهسازیهای پیشرفته اسکیما.
امنیت و احراز هویت جنگو (۱۸٪): بکاندهای سفارشی احراز هویت کاربر، سیستمهای مجوز سطح شیء، مکانیزمهای امن هشینگ رمز عبور، پیشگیری داخلی از SQL Injection و محافظت در برابر XSS.
تمپلیتها و فرانتاند جنگو (۱۲٪): سینتکس پیشرفته تمپلیت، لایوتهای ارثبری ساختاری، مدیریت حرفهای فایلهای استاتیک در محیط تولید، ادغام CSS و JavaScript و استراتژیهای اتصال به فریمورکهای مدرن فرانتاند.
مباحث پیشرفته جنگو (۱۵٪): سیگنالهای همزمان و ناهمزمان، خط لولههای Middleware سفارشی، استراتژیهای کشینگ چندلایه، تنظیمات Logging سازمانی و مدیریت خطاهای سراسری در سطح فریمورک.
بهترین روشها و الگوهای طراحی (۱۰٪): سازماندهی کد برای اپلیکیشنهای مقیاسپذیر، حفظ خوانایی کد، استراتژیهای جامع تست، تنظیمات CI و استراتژیهای استقرار ابری.
ابزارها و کتابخانههای جنگو (۵٪): دستورات بومی django-admin، دستورات مدیریت سفارشی، ادغام با کتابخانههای حیاتی شخص ثالث، اتصال به APIهای خارجی REST و ابزارهای خودکار مهاجرت دیتابیس.
عیبیابی و دیباگینگ جنگو (۵٪): تکنیکهای دیباگینگ پروفایل حافظه، رمزگشایی پیامهای خطای مبهم فریمورک، تحلیل ساختاریافته لاگها، شناسایی گلوگاههای عملکردی و رفع مشکلات رایج.
درباره این دوره
قبولی در مصاحبههای فنی میانرده تا ارشد جنگو، بسیار فراتر از دانستن نحوه راه اندازی یک ساختار ساده مدل-ویو-تمپلیت است. اپلیکیشنهای در مقیاس تولید (Production) نیازمند درک بینقص از مدیریت اتصال دیتابیس، طراحی Middleware سفارشی، مسیرهای امن احراز هویت و بهینهسازی پیشرفته ORM هستند. من این مخزن آزمونهای تمرینی را دقیقاً برای این ساختهام که به شما کمک کنم از کدهای تکراری آموزشها فراتر رفته و بر موارد خاص (Edge Cases)، الگوهای طراحی و مکانیسمهای داخلی فریمورک مسلط شوید؛ همان مواردی که مصاحبهکنندگان ارشد برای سنجش کاندیداها از آنها استفاده میکنند.
با ۵۵۰ سوال اصلی و با دقت طراحی شده، این منبع فشار و عمق ارزیابیهای فنی دنیای واقعی را شبیهسازی میکند. هر سناریو یک چالش توسعه منحصر به فرد، یک معمای معماری یا یک اسکریپت دیباگینگ را ارائه میدهد. من فقط یک کلید پاسخ به شما نمیدهم، بلکه برای هر سوال یک تحلیل فنی عمیق (Post-mortem) ارائه میکنم. شما خواهید آموخت که چرا راهکار بهینه در شرایط فشار بالا به درستی عمل میکند و چرا سایر انتخابهای معماری محتمل در یک استک تولیدی با همروندی بالا شکست میخورند. اگر متخصص بکاند، مهندس فولاستک یا معمار سیستم هستید و هدف شما قبولی در اولین تلاش در مصاحبههای فنی است، این محتوای آموزشی برای رسیدن شما به این هدف طراحی شده است.
نمونه سوالات تمرینی
این سه نمونه سوال را بررسی کنید تا با ساختار، عمق و جزئیات توضیحی ارائه شده در این بانک سوالات آشنا شوید.
سوال ۱: کاهش شرایط رقابتی (Race Conditions) در تراکنشهای همزمان ORM
یک میکروسرویس بانکی ساخته شده با جنگو، در هنگام بهروزرسانیهای موجودی با همروندی بالا، دچار فساد متناوب دادهها میشود. چندین Worker تلاش میکنند به طور همزمان یک نمونه مدل یکسان را بخوانند، تغییر دهند و ذخیره کنند که منجر به گم شدن بهروزرسانیها (Lost Updates) میشود. کدام متدولوژی ORM این مشکل همروندی را در لایه پایگاه داده به طور بومی حل میکند؟
الف) پیادهسازی select_related() برای ایجاد یک قفل کش داخلی هنگام بازیابی دادهها.
ب) استفاده از prefetch_related() همراه با یک هندلر سیگنال اتمیک سفارشی.
ج) فراخوانی QuerySet.select_for_update() در داخل یک بلوک متنی صریح transaction.atomic().
د) اجرای QuerySet.defer() برای جداسازی فیلدهای عددی از نمونههای استاندارد مدل.
ه) اعمال transaction.set_rollback(True) بلافاصله قبل از اجرای عملیات ذخیره سازی.
و) بازگرداندن ساختار ارثبری مدل از یک کلاس پایه انتزاعی (Abstract) به ارثبری چندجدولی.
پاسخ صحیح و توضیح:
پاسخ صحیح: ج
چرا صحیح است: select_for_update() یک QuerySet برمیگرداند که ردیفها را قفل میکند تا زمانی که تراکنش حاوی آن Commit یا Rollback شود. وقتی با transaction.atomic() جفت شود، یک دستور SQL از نوع SELECT ... FOR UPDATE را در پشت صحنه اجرا میکند و تضمین میکند که عملیاتهای همزمان دیتابیس باید منتظر بمانند تا پروسه فعال قفل را رها کند، که به طور موثری از Race Conditions و گم شدن آپدیتها جلوگیری میکند.
چرا گزینههای دیگر نادرست هستند:
گزینه الف نادرست است: select_related() صرفاً یک ابزار بهینهسازی عملکرد است که یک SQL join را برای کاهش تعداد کوئریها انجام میدهد؛ این متد هیچ قفلی روی دیتابیس اعمال نمیکند.
گزینه ب نادرست است: prefetch_related() روابط چند-به-چند و کلید خارجی معکوس را از طریق کوئریهای جداگانه مدیریت میکند و دادهها را برای ایمنی نوشتن قفل نمیکند.
گزینه د نادرست است: defer() به سادگی از بارگذاری دادههای فیلدهای خاص از دیتابیس در ابتدا برای صرفهجویی در حافظه جلوگیری میکند؛ هیچ کنترل تراکنشی ندارد.
گزینه ه نادرست است: set_rollback(True) یک تراکنش فعال را مجبور میکند پس از اتمام بازگشت (Rollback) یابد، که تراکنش را خاتمه میدهد اما دسترسی همزمان به نوشتن را حل نمیکند.
گزینه و نادرست است: استراتژیهای ارثبری مدل، پیکربندی لایوت اسکیمای دیتابیس را تعیین میکنند اما قفلهای زمان اجرا یا همروندی تراکنشی را مدیریت نمیکنند.
سوال ۲: محدوده معماری و ترتیب اجزای Middleware سفارشی
یک توسعهدهنده یک کامپوننت Middleware سفارشی برای اعتبارسنجی هدرهای مجوزهای ورودی میسازد. در محیط Staging، این Middleware نمیتواند درخواستهای غیرمجاز را که به Class-based Viewهای متکی به دکوراتورهای خاص تمپلیت میرسند، شناسایی کند. در بررسی مشخص میشود که Middleware در انتهای آرایه MIDDLEWARE در settings.py قرار دارد. مشکل ساختاری این پیکربندی چیست؟
الف) کلاسهای Middleware که در انتهای آرایه پیکربندی قرار دارند، در فاز استاندارد درخواست کاملاً نادیده گرفته میشوند.
ب) فاز درخواست (Request)، Middlewareها را از بالا به پایین پردازش میکند؛ قرار دادن بررسیهای امنیتی در انتها باعث میشود سایر منطقهای پردازشی یا تحلیلهای زودهنگام ویو، بررسی امنیتی را کاملاً دور بزنند.
ج) اعتبارسنجیهای امنیتی توسط فریمورک محدود شدهاند تا فقط در تنظیمات قدیمی MIDDLEWARE_CLASSES اجرا شوند.
د) فاز پاسخ (Response) از بالا به پایین اجرا میشود، که باعث میشود آخرین کامپوننت Middleware خروجی ویو را مسدود کند.
ه) ترتیب قرارگیری فقط بر فاز مقداردهی اولیه دستورات مدیریت جنگو تأثیر میگذارد، نه بر ترافیک فعال HTTP.
و) توالی اجرای Middleware توسط جنگو کاملاً تصادفی است، مگر اینکه وابستگیهای صریح در یک فایل migration تعریف شده باشند.
پاسخ صحیح و توضیح:
پاسخ صحیح: ب
چرا صحیح است: جنگو درخواستهای HTTP ورودی را به صورت متوالی از بالا به پایین از طریق لیست پیکربندی MIDDLEWARE پردازش میکند. اگر یک کامپوننت احراز هویت یا امنیتی در پایین قرار گیرد، هر Middleware یا دکوراتور ویویی که بالای آن تعریف شده است، ابتدا اجرا میشود. اگر یک کامپوننت بالادستی درخواست را زودتر مدیریت کند یا مسیر آن را تغییر دهد، بررسی امنیتی انتهایی کاملاً دور زده میشود. منطق امنیتی همیشه باید نزدیک به ابتدای لیست باشد.
چرا گزینههای دیگر نادرست هستند:
گزینه الف نادرست است: Middleware کاملاً نادیده گرفته نمیشود؛ بلکه صرفاً در آخرین مرحله چرخه درخواست اجرا میشود که برای محافظت از پروسههای قبلی بسیار دیر است.
گزینه ج نادرست است: MIDDLEWARE_CLASSES یک سبک پیکربندی قدیمی است که در نسخههای مدرن جنگو با MIDDLEWARE جایگزین شده است؛ استفاده از آن باعث ایجاد خطا میشود.
گزینه د نادرست است: فاز پاسخ در ترتیب معکوس (از پایین به بالا) عمل میکند؛ به این معنی که آیتم انتهایی ابتدا پاسخها را پردازش میکند، نه درخواستها را.
گزینه ه نادرست است: ترتیب Middleware به شدت بر مسیریابی فعال وب و لوپهای درخواست/پاسخ HTTP تأثیر میگذارد، در حالی که بر مقداردهیهای استاتیک دستورات تأثیری ندارد.
گزینه و نادرست است: مسیر اجرا کاملاً قطعی (Deterministic) است و دقیقاً از ایندکس لیست در فایل پیکربندی تنظیمات پیروی میکند.
سوال ۳: بهینهسازی کوئریهای چندجدولی از طریق ORM
شما در حال تحلیل نقاط انتهایی (Endpoints) کند API هستید که یک داشبورد پورتفولیو را ارائه میدهند. لاگ کوئریها یک «مشکل کوئری N+1» را نشان میدهد که در آن یک حلقه اصلی یک رکورد Profile را واکشی میکند و سپس درخواستهای جداگانهای به دیتابیس میفرستد تا یک شیء Company (کلید خارجی) و یک لیست Skill (چند-به-چند) مرتبط را دریافت کند. کوئری ORM برای به حداقل رساندن رفتوبرگشتها به دیتابیس باید چگونه باشد؟
الف) Profile.objects.all().defer('company').only('skills')
ب) Profile.objects.all().select_related('company').prefetch_related('skills')
ج) Profile.objects.all().annotate('company').aggregate('skills')
د) Profile.objects.all().using('company').filter('skills')
ه) Profile.objects.all().select_related('skills').prefetch_related('company')
و) Profile.objects.all().raw("SELECT * FROM profile_table")
پاسخ صحیح و توضیح:
پاسخ صحیح: ب
چرا صحیح است: برای حذف سربار کوئری N+1، باید دادههای مرتبط را پیش-واکشی (Pre-fetch) کنید. select_related() با اجرای یک SQL JOIN عمل میکند و برای روابط تکمقداری مانند کلید خارجی به Company ایدهآل است. در مقابل، prefetch_related() یک کوئری جستجوی جداگانه برای روابط چند-مقداری مانند فیلد skills (چند-به-چند) انجام میدهد و اتصال را در حافظه مدیریت میکند. ترکیب این دو، هر دو گلوگاه عملکردی را دقیقاً در دو کوئری حل میکند.
چرا گزینههای دیگر نادرست هستند:
گزینه الف نادرست است: defer() و only() کنترل میکنند که کدام ستونها در حافظه برای نمونه مدل هدف بارگذاری شوند، اما از کوئریهای N+1 در مدلهای مرتبط جلوگیری نمیکنند.
گزینه ج نادرست است: annotate() فیلدهای محاسباتی را به کوئریستها اضافه میکند و aggregate() کوئریستها را به مقادیر خلاصه تبدیل میکند؛ هیچکدام جستجوهای چندجدولی را بهینه نمیکنند.
گزینه د نادرست است: متد using() یک کلمه کلیدی مسیریابی دیتابیس جایگزین را مشخص میکند و نمیتواند زمینههای جداگانه جداول را به هم متصل کند.
گزینه ه نادرست است: این گزینه جای توابع را عوض کرده است. پاس دادن یک رابطه چند-به-چند مانند skills به select_related() باعث ایجاد خطای lookup نامعتبر میشود زیرا نمیتوان آن را با یک SQL join تخت حل کرد.
گزینه و نادرست است: استفاده از یک کوئری SQL خام و بهینهنشده بدون Joinها یا مپینگهای خاص، دقیقاً همان حلقه N+1 را در هنگام سریالسازی مدل دوباره فعال میکند.
چه انتظاری داشته باشید
به آزمونهای سوالات مصاحبه خوش آمدید تا شما را برای موفقیت در آزمون تمرینی سوالات مصاحبه جنگو آماده کنیم.
شما میتوانید هر تعداد بار که بخواهید در آزمونها شرکت کنید.
این یک بانک سوالات عظیم و اصلی است.
اگر سوالی داشته باشید، از پشتیبانی مدرسان بهرهمند میشوید.
هر سوال دارای یک توضیح دقیق است.
سازگار با موبایل از طریق اپلیکیشن Udemy.
امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.
Interview Questions Tests
مربی در Udemy
نمایش نظرات