راهنمای آمادگی برای مصاحبه شغلی دانشمند داده

معرفی

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

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

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

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

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

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

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

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

    توانایی تبدیل درخواست مبهمی مانند «ریزش را کم کنید» به متغیر هدف، جمعیت موردبررسی، افق زمانی، اقدام ممکن و معیار موفقیت.

  • SQL و فهم ساختار داده

    نوشتن کوئری‌های درست با join، گروه‌بندی، پنجره‌های زمانی و کنترل تکراری‌شدن رکوردها؛ همراه با درک سطح دانه‌بندی جدول‌ها.

  • پاک‌سازی و اعتبارسنجی داده

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

  • آمار کاربردی و طراحی ارزیابی

    انتخاب روش آماری، آزمون فرض یا بازه اطمینان متناسب با مسئله و تشخیص تفاوت میان هم‌بستگی، رابطه علّی و تغییرات تصادفی.

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

    ساخت خط مبنا، انتخاب مدل متناسب با مسئله، تقسیم درست داده و تفسیر معیارهایی مانند Precision، Recall، F1 و ROC-AUC.

  • مهندسی ویژگی و کنترل نشت داده

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

  • برنامه‌نویسی تحلیلی با Python

    کار با pandas و NumPy برای تبدیل، تجمیع، بررسی و آماده‌سازی داده و نوشتن کدی که قابل‌خواندن و بازتولید باشد.

  • توضیح بینش و محدودیت

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

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

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

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

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

  • مرور SQL با مسئله‌های واقعی

    روی join، CTE، GROUP BY، HAVING، توابع پنجره‌ای و کار با تاریخ تمرین کنید. در هر تمرین ابتدا دانه‌بندی خروجی را مشخص کنید؛ مثلاً «یک ردیف برای هر کاربر در هر ماه». سپس بررسی کنید join باعث تکثیر سفارش‌ها یا کاربران نشده باشد.

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

  • تحلیل اکتشافی و کیفیت داده

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

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

  • آمار و آزمایش

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

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

  • مدل‌سازی و انتخاب معیار

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

    برای ساخت و مقایسه مدل‌های پایه می‌توانید در پروژه تمرینی از scikit-learn استفاده کنید. برای مسئله عدم‌توازن کلاس، Precision، Recall، F1، ماتریس درهم‌ریختگی و آستانه تصمیم را تمرین کنید. معیار را به هزینه خطا وصل کنید؛ مثلاً در شناسایی ریزش، تماس بی‌مورد با مشتری چه هزینه‌ای دارد و از دست‌دادن مشتری پرریسک چه پیامدی دارد.

  • پروژه و نوت‌بوک قابل‌دفاع

    یکی از پروژه‌های خود را در قالب یک نوت‌بوک (Notebook) قابل‌اجرا برای ارائه‌ای ۱۰ دقیقه‌ای آماده کنید. در ارائه، مسئله، منبع و محدودیت‌های داده، مراحل پاک‌سازی و تحلیل اولیه، خط مبنا، مدل انتخاب‌شده، معیار ارزیابی، نتایج و اقدام پیشنهادی را توضیح دهید. نمودارها باید به یک پرسش پاسخ دهند، نه فقط زیبا باشند.

    مخزن Git یا فایل پروژه را بازبینی کنید. داده حساس را منتشر نکنید و راه اجرای تحلیل، وابستگی‌ها و محدودیت بازتولید را روشن بنویسید. اگر از Jupyter Notebook استفاده کرده‌اید، ترتیب اجرای سلول‌ها و خروجی‌های نهایی را نیز بررسی کنید.

  • شناخت مسئله شرکت

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

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

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

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

  • یک پروژه را در ۱۰ دقیقه، از مسئله تا محدودیت نتیجه، تمرین کرده‌ام.
  • برای هر پروژه، منبع داده و سطح دانه‌بندی جدول‌ها را می‌توانم توضیح دهم.
  • کوئری‌های join، CTE، تجمیع و توابع پنجره‌ای را تمرین کرده‌ام.
  • تفاوت داده آموزش، اعتبارسنجی و آزمون را می‌توانم توضیح دهم.
  • برای یک مسئله طبقه‌بندی، معیار ارزیابی و آستانه تصمیم را انتخاب کرده‌ام و می‌توانم دلیل انتخاب آن‌ها را توضیح دهم.
  • یک نمونه نشت داده و روش جلوگیری از آن را آماده دارم.
  • تصمیم‌های پاک‌سازی داده و اثر احتمالی آن‌ها بر نتیجه را نوشته‌ام.
  • شرح وظایف آگهی و مسئله‌های داده‌ای محتمل شرکت را بررسی کرده‌ام.
  • مخزن Git یا نوت‌بوک نمونه‌کارم بدون داده محرمانه و قابل‌خواندن است.
  • پرسش‌های خود درباره داده، تیم و انتظارهای نقش را آماده کرده‌ام.
  • تجهیزات جلسه آنلاین، اینترنت و دسترسی لازم به محیط آزمون را بررسی کرده‌ام.

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

  • فنی

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

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

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

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

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

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

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

  • فنی

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

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

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

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

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

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

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

  • فنی

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

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

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

    توضیح دهید اگر بیشتر مشتریان ریزش نمی‌کنند، مدلی که همیشه «عدم ریزش» را پیش‌بینی می‌کند Accuracy بالایی دارد، اما مشتریان در معرض ریزش را پیدا نمی‌کند. سپس Precision و Recall را تعریف کنید.

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

    اگر فقط ۱۰ درصد مشتریان ریزش کنند، مدلی که همه مشتریان را در گروه بدون ریزش قرار می‌دهد، به Accuracy برابر با ۹۰ درصد می‌رسد، اما هیچ‌یک از مشتریان واقعاً در معرض ریزش را شناسایی نمی‌کند. بنابراین Accuracy به‌تنهایی ارزش عملی مدل را نشان نمی‌دهد.

    در این مسئله Recall نشان می‌دهد چه سهمی از مشتریان واقعاً در معرض ریزش را پیدا کرده‌ایم و Precision نشان می‌دهد چه سهمی از افراد انتخاب‌شده واقعاً پرریسک بوده‌اند. اگر تیم نگهداشت فقط ظرفیت تماس با ۵۰۰ نفر را داشته باشد، خروجی مدل را به‌گونه‌ای تنظیم می‌کنم که افراد منتخب با ظرفیت تیم متناسب باشند. سپس Precision و ارزش موردانتظار اقدام برای این گروه را بررسی می‌کنم.

  • فنی

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

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

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

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

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

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

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

  • فنی

    برای ارزیابی یک مدل با داده‌های زمانی چه نوع تقسیم داده‌ای انتخاب می‌کنید؟

    سنجش توانایی جلوگیری از انتقال اطلاعات آینده به گذشته و ارزیابی نزدیک به شرایط عملیاتی.

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

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

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

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

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

  • نمونه‌کار

    در پروژه نمونه‌کارتان، مسئله اصلی چه بود و نتیجه چگونه می‌توانست تصمیمی را تغییر دهد؟

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

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

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

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

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

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

  • نمونه‌کار

    کدام تصمیم پروژه‌تان اگر امروز تکرار شود، تغییر می‌کند؟

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

    راهنمای پاسخ

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

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

  • موقعیتی

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

    سنجش مدیریت اختلاف با ذی‌نفع و توانایی بازگرداندن گفت‌وگو به مسئله قابل‌اندازه‌گیری.

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

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

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

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

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

  • موقعیتی

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

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

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

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

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

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

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

  • رفتاری

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

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

    راهنمای پاسخ

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

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

  • رفتاری

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

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

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

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

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

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

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

  • فرهنگی

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

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

    راهنمای پاسخ

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

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

  • فرهنگی

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

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

    راهنمای پاسخ

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

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

  • فنی

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

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

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

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

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

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

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

  • موقعیتی

    دو درخواست فوری دارید: ساخت مدل پیش‌بینی فروش و بررسی خطای گزارش درآمد. چگونه اولویت‌بندی می‌کنید؟

    سنجش قضاوت درباره ریسک تصمیم، وابستگی داده و مدیریت انتظار ذی‌نفعان.

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

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

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

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

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

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

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

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

  • در شش ماه گذشته، آخرین پروژه داده‌ای از مسئله تا اقدام عملی چه مسیری داشته است؟

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

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

    دسترسی، کیفیت و تأخیر داده مستقیماً بر امکان انجام وظایف دانشمند داده اثر دارد.

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

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

  • موفقیت این نقش با چه خروجی یا اثری سنجیده می‌شود؟

    کمک می‌کند میان انتظار از مدل، تحلیل، گزارش و اثر کسب‌وکار تمایز بگذارید.

  • آیا برای داده‌های محصول، تعریف رویدادها و بررسی کیفیت داده مالک مشخصی وجود دارد؟

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

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

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

  • چه محدودیت‌هایی برای کار با داده حساس، کار غیرحضوری یا استفاده از محیط‌های تحلیلی وجود دارد؟

    برای برنامه‌ریزی شیوه همکاری و رعایت محرمانگی داده ضروری است.

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

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

  • تمرکز بر دقت مدل بدون تعریف مسئله

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

  • نادیده‌گرفتن دانه‌بندی داده در SQL

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

  • انتخاب معیار نامتناسب با مسئله

    برای طبقه‌بندی نامتوازن فقط Accuracy نگویید. هزینه مثبت کاذب و منفی کاذب، ظرفیت اقدام و آستانه تصمیم را در انتخاب معیار وارد کنید.

  • پنهان‌کردن کیفیت پایین داده

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

  • ارائه نوت‌بوک بدون روایت پروژه

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

  • ادعای تسلط بر ابزار بدون توانایی دفاع از تصمیم‌ها

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

  • بی‌توجهی به نشت داده و ترتیب زمانی

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

  • پذیرفتن تمرین خانگی با داده یا دامنه نامشخص

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

پس از مصاحبه

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

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

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

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

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

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

در مصاحبه دانشمند داده بیشتر SQL می‌پرسند یا یادگیری ماشین؟

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

برای مصاحبه دانشمند داده چند پروژه نمونه‌کار لازم است؟

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

آیا در مصاحبه باید الگوریتم‌ها را از حفظ توضیح بدهم؟

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

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

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

آیا تمرین خانگی مصاحبه دانشمند داده را باید با مدل پیچیده انجام دهم؟

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

در مصاحبه جونیور دانشمند داده چه انتظاری واقع‌بینانه است؟

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

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

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

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