راهنمای مصاحبه شغلی مهندس یادگیری ماشین و پرسش‌های فنی

معرفی

فرایند مصاحبه مهندس یادگیری ماشین (Machine Learning Engineer) به شرکت، سطح موقعیت و نوع محصول بستگی دارد. مصاحبه ممکن است با بررسی رزومه و نمونه‌کار آغاز شود و در ادامه به گفت‌وگوی فنی، حل مسئله، بررسی کد یا تکلیف عملی برسد. در این مراحل، توانایی کار با داده، کدنویسی Python و توضیح تصمیم‌های فنی اهمیت دارد. صرف اشاره به ابزارها بدون پروژه قابل‌بررسی، تصویر کاملی از توانایی اجرایی شما ارائه نمی‌دهد.

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

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

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

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

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

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

  • صورت‌بندی مسئله و انتخاب معیار

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

  • کیفیت داده و جلوگیری از نشتی

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

  • مدل‌سازی و ارزیابی

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

  • برنامه‌نویسی Python و کار با داده

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

  • SQL و شناخت منبع داده

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

  • استقرار و عملیات یادگیری ماشین (MLOps)

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

  • تکرارپذیری و مهندسی نرم‌افزار

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

  • ارتباط با تیم محصول و مهندسی

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

  • مسئولیت‌پذیری در داده و مدل

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

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

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

  • مرور چرخه کامل یک پروژه

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

  • ارزیابی مدل و تقسیم داده

    تفاوت داده آموزش، اعتبارسنجی و آزمون را مرور کنید. برای داده‌های زمانی، تقسیم‌بندی زمانی را تمرین کنید و توضیح دهید چرا تقسیم تصادفی می‌تواند باعث نشتی داده شود. معیارهای Precision، Recall، F1، ROC-AUC، PR-AUC و معیارهای رگرسیون را با مثال کاربرد هرکدام مرور کنید.

    برای مرور معیارها و روش‌های اعتبارسنجی، مستندات ارزیابی مدل در scikit-learn و اعتبارسنجی متقابل در scikit-learn را مطالعه کنید.

  • کیفیت داده و مهندسی ویژگی

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

  • Python، Pandas و SQL

    با Python تابعی برای پردازش داده بنویسید که ورودی نامعتبر را مدیریت کند. در Pandas، گروه‌بندی، ادغام و بررسی مقادیر گمشده را تمرین کنید. در SQL نیز Join، CTE، تابع پنجره‌ای و فیلتر تاریخ را مرور کنید و هنگام Join مراقب تکثیر ناخواسته ردیف‌ها باشید.

    برای مرور این مباحث، راهنمای رسمی Join در PostgreSQL، Window Function در PostgreSQL و راهنمای ادغام داده در pandas مفید هستند.

  • مدل پایه و تحلیل خطا

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

    مستندات ماتریس درهم‌ریختگی در scikit-learn را برای مرور تحلیل خطا ببینید.

  • استقرار و پایش مدل

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

    برای مرور ساخت API و اعتبارسنجی ورودی، آموزش رسمی FastAPI را بخوانید. برای ساخت تصویر قابل‌بازتولید و اجرای کانتینر نیز از مستندات Docker استفاده کنید. مفاهیم پایش مدل در مستندات MLflow Tracking قابل‌مرور است.

  • آزمایش‌های تکرارپذیر

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

    برای مرور ثبت پارامتر، معیار و خروجی مدل، مستندات MLflow Tracking و برای نسخه‌بندی کد، مستندات Git را ببینید.

  • پرسش‌های سناریومحور محصول

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

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

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

  • می‌توانم یک پروژه را از تعریف مسئله تا ارزیابی و پایش مدل در ۵ دقیقه توضیح دهم.
  • خط پایه و معیار اصلی پروژه را مشخص کرده‌ام و دلیل انتخاب آن را می‌دانم.
  • محدودیت‌های داده و منابع احتمالی نشتی را شناسایی کرده‌ام.
  • می‌توانم تفاوت Precision، Recall و F1 و کاربرد هرکدام را توضیح دهم.
  • یک تمرین عملی Python برای پاک‌سازی و تحلیل داده انجام داده‌ام.
  • Join، CTE و توابع پنجره‌ای SQL را مرور کرده‌ام.
  • مخزن کد پروژه را اجرا کرده‌ام و می‌توانم فایل راهنمای اجرای آن را توضیح دهم.
  • نسخه داده، مدل و پارامترهای آزمایش پروژه را می‌توانم توضیح دهم.
  • می‌توانم قرارداد ورودی و خروجی یک سرویس پیش‌بینی را طراحی کنم.
  • شاخص‌های مناسب برای پایش مدل پس از انتشار را مشخص کرده‌ام.
  • شرح وظایف آگهی را با تجربه خود در مدل‌سازی، داده و استقرار مقایسه کرده‌ام.
  • پرسش‌های مشخصی درباره داده، استقرار مدل و مسئولیت‌های تیم آماده کرده‌ام.

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

  • فنی

    چرا داده را به آموزش، اعتبارسنجی و آزمون تقسیم می‌کنیم؟

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

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

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

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

  • فنی

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

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

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

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

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

  • فنی

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

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

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

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

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

  • فنی

    چگونه تشخیص می‌دهید مدل بیش‌برازش دارد؟

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

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

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

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

  • فنی

    کد Python زیر چه خطری برای داده آزمون دارد و چگونه آن را اصلاح می‌کنید: scaler.fit_transform(df[features])؟

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

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

    بگویید scaler روی همه ردیف‌ها، از جمله اعتبارسنجی و آزمون، برازش می‌شود و میانگین یا واریانس آن داده‌ها وارد آموزش می‌شود. ابتدا داده را تقسیم کنید، سپس scaler.fit_transform را فقط روی X_train اجرا و scaler.transform را برای X_valid و X_test استفاده کنید. خطای رایج این است که تقسیم داده را پس از پاک‌سازی یا مقیاس‌بندی سراسری انجام دهند.

    ابتدا داده را به X_train، X_valid و X_test تقسیم می‌کنم. سپس scaler را فقط روی X_train برازش می‌دهم. برای داده آموزش از fit_transform و برای اعتبارسنجی و آزمون از transform استفاده می‌کنم. اگر داده زمانی باشد، خود تقسیم داده نیز باید بر اساس زمان انجام شود.

  • فنی

    در یک Join بین سفارش‌ها و رویدادهای کاربر، تعداد ردیف‌ها ناگهان چند برابر شده است. چگونه علت را پیدا و اصلاح می‌کنید؟

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

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

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

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

  • فنی

    چه زمانی مدل ساده‌تر را به یک مدل پیچیده‌تر ترجیح می‌دهید؟

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

    راهنمای پاسخ

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

  • موقعیتی

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

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

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

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

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

  • موقعیتی

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

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

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

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

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

  • نمونه‌کار

    در مهم‌ترین پروژه یادگیری ماشین خود، چرا این معیار و این مدل را انتخاب کردید؟

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

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

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

    در پروژه پیش‌بینی ریزش، ابتدا Logistic Regression را به‌عنوان خط مبنا قرار دادم تا کیفیت ویژگی‌ها و معیار را بررسی کنیم. چون کلاس ریزش نامتوازن بود، Recall و Precision را همراه با آستانه تصمیم بررسی کردم و به Accuracy اکتفا نکردم. سپس یک مدل درختی را آزمایش کردم و بهبود محدودی به دست آمد. با توجه به نیاز تیم به توضیح عوامل مؤثر و تفاوت کم عملکرد، مدل ساده‌تر را انتخاب کردم و محدودیت‌های آن را در مستندات ثبت کردم.

  • نمونه‌کار

    اگر بخواهید پروژه نوت‌بوکی خود را به سرویس قابل‌استفاده تبدیل کنید، چه چیزهایی را تغییر می‌دهید؟

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

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

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

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

  • رفتاری

    نمونه‌ای بگویید که کیفیت داده، نتیجه پروژه مدل‌سازی را تغییر داد.

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

    راهنمای پاسخ

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

  • رفتاری

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

    این پرسش توانایی شما را در مدیریت انتظارات محصول و توضیح محدودیت مدل بدون متوقف‌کردن تصمیم‌گیری می‌سنجد.

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

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

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

  • فرهنگی

    در همکاری با مهندس بک‌اند، چه اطلاعاتی برای اتصال مدل به محصول ارائه می‌کنید؟

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

    راهنمای پاسخ

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

  • فرهنگی

    درباره استفاده مسئولانه از داده در یک پروژه یادگیری ماشین چه ملاحظاتی دارید؟

    این پرسش حساسیت شما را نسبت به محرمانگی، کنترل دسترسی، سوگیری و اثر تصمیم‌های مدل بر کاربران می‌سنجد.

    راهنمای پاسخ

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

  • فنی

    چگونه آزمایش‌های مدل را قابل‌بازتولید می‌کنید؟

    بررسی نظم مهندسی در ردیابی داده، کد، پارامترها، محیط اجرا و خروجی مدل.

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

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

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

  • موقعیتی

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

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

    راهنمای پاسخ

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

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

  • مدل‌های این تیم اکنون بیشتر در سرویس آنلاین اجرا می‌شوند یا پردازش دسته‌ای؟

    پاسخ این پرسش مشخص می‌کند که نقش موردنظر تا چه اندازه با محدودیت تأخیر، سرویس‌دهی آنلاین و همکاری با تیم‌های بک‌اند و زیرساخت درگیر است.

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

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

  • برای هر مدل، معیار موفقیت محصولی و معیار فنی چگونه تعیین می‌شود؟

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

  • فرایند ثبت آزمایش‌ها، نسخه‌بندی داده و انتشار مدل در تیم چگونه است؟

    پاسخ این پرسش میزان بلوغ عملیاتی تیم و انتظارات آن از مهارت‌های MLOps را روشن می‌کند.

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

    این پرسش مسئولیت واقعی نقش را فراتر از آموزش مدل مشخص می‌کند.

  • مهم‌ترین مسئله فنی مدل‌های فعلی چیست: کیفیت داده، تأخیر، هزینه زیرساخت یا ارزیابی؟

    نشان می‌دهد چالش اصلی تیم کجاست و آیا تجربه شما با آن هم‌راستا است.

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

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

  • آیا تیم برای مدل‌های حساس، بازبینی انسانی یا محدودیت‌های استفاده از خروجی مدل دارد؟

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

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

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

  • تمرکز بر نام الگوریتم‌ها به‌جای مسئله

    پاسخ این پرسش رویکرد تیم به ریسک، مسئولیت‌پذیری و اثر مدل بر کاربران را روشن می‌کند.

  • استفاده از Accuracy برای هر مسئله طبقه‌بندی

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

  • نادیده‌گرفتن نشتی داده

    زمان پیش‌بینی و زمان دسترسی به هر ویژگی را بررسی کنید. تبدیل‌های آماری مانند مقیاس‌بندی نیز باید فقط روی داده آموزش برازش شوند.

  • ارائه نوت‌بوک به‌عنوان محصول کامل

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

  • ادعای تجربه ابزار بدون توانایی توضیح تصمیم‌ها

    اگر نام ابزارهایی مانند MLflow، Docker یا PyTorch را مطرح می‌کنید، بتوانید یک کاربرد مشخص، مسئله‌ای که با آن حل کرده‌اید و محدودیت استفاده از آن را توضیح دهید.

  • پیشنهاد بازآموزی بدون تشخیص علت افت

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

  • بی‌توجهی به زمان پاسخ و هزینه اجرا

    هنگام انتخاب مدل، علاوه بر معیارهای دقت، تأخیر، حجم ترافیک، مصرف حافظه، هزینه زیرساخت و امکان استفاده از مسیر جایگزین را نیز در نظر بگیرید.

  • توضیح‌ندادن محدودیت مدل به تیم محصول

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

پس از مصاحبه

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

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

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

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

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

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

آیا در مصاحبه مهندس یادگیری ماشین الگوریتم و ساختمان داده هم می‌پرسند؟

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

آیا باید همه ابزارهای PyTorch و TensorFlow را بلد باشم؟

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

برای مصاحبه جونیور، داشتن تجربه استقرار مدل ضروری است؟

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

اگر پاسخ یک پرسش فنی را ندانم، چه کار کنم؟

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

در مصاحبه پروژه‌محور چه چیزی از GitHub مهم‌تر است؟

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

آیا پرسش درباره حقوق در مصاحبه فنی مناسب است؟

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

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

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

برچسب‌ها و کلیدواژه‌ها