مصاحبه یکی از مهمترین جنبه های شغل هر توسعه دهنده ای است. کارفرما و همکاران شما تصمیم گرفتند با در نظر گرفتن نه تنها مهارت ها و دانش فنی، بلکه مهارت های نرم، اشتیاق آنها برای کمک و یادگیری و تناسب آنها با سازمان موجود، به توانایی شما برای شناسایی استخدام بعدی خود اعتماد کنند. .
من در هر دو طرف میز بوده‌ام، مصاحبه‌های عالی و نه چندان عالی داشته‌ام، و دوست دارم فکر کنم در آن خیلی خوب بوده‌ام. به همین دلیل، اگر تازه شروع به مصاحبه با توسعه دهندگان کرده اید، یا شاید مدتی است که این کار را انجام می دهید اما می خواهید ورودی های جدیدی داشته باشید، تصمیم گرفتم برخی از آنچه را که یاد گرفتم به اشتراک بگذارم.
چرا به من گوش می دهی؟ من از سال 2013 با توسعه‌دهندگان مصاحبه می‌کنم، با ده‌ها نامزد در شرکت‌هایی مانند King، Foxglove و Yager صحبت می‌کنم، مشخصات شغلی برای نقش‌های مختلف را می‌نویسم و تصمیمات استخدامی را ارائه می‌دهم. در یک نقطه به کینگ کمک کردم دفتر خود را در برلین باز کند و با اعضای بالقوه تیم توسعه دهنده اولیه آنها مصاحبه کردم.
درک نحوه برخورد کاندید با مشکلات
مهندسی یک بخش متنوع و همیشه در حال تغییر است. ابزارهایی که امروز استفاده می کنید ممکن است در عرض چند سال قدیمی و فراموش شوند.
به جای تمرکز بر دانش خاص فناوری یا موتور مربوطه ای که در حال حاضر از آن استفاده می کنید، می خواهید سؤالاتی بپرسید که نشان می دهد داوطلب چگونه مشکلات را حل می کند، چگونه اطلاعات مربوطه را پیدا می کند و ابهامات را روشن می کند و چگونه مهارت های جدید را یاد می گیرد و به کار می گیرد. به روز باشید
بهترین مهندسان آنهایی هستند که قادر به کار با رشته های دیگر (مانند طراحان، تولید و QA) هستند، کنجکاو هستند و از یادگیری نمی ترسند و با ابزارها و فناوری های جدید کار خود را کثیف می کنند و به اندازه کافی مطمئن هستند که به شما پاسخ دهند. سوالاتی با “نمی دانم، اما می توانم آن را بفهمم”.
یک مثال خوب برای یک سوال باز و جالب این خواهد بود:
تیم شما در حال کار بر روی یک تیرانداز آنلاین است که به تازگی وارد تولید شده است. مدیر بازی از شما خواسته است که معماری پشتیبان و زیرساختی را تعریف کنید که از بازی در طول توسعه و انتشار زنده پشتیبانی می کند. در سطح بالا، بدون نیاز به انتخاب محصولات خاص، چگونه آن را طراحی می کنید و از چه پارادایم هایی پیروی می کنید؟
در اینجا، نامزد احتمالاً با سؤالاتی باز خواهد گشت تا عمیق‌تر به سناریو بپردازد، مانند اینکه آیا جهانی پایدار یا مسابقات کوتاه وجود دارد، یا شاید بپرسند که در یک مسابقه چند بازیکن انتظار می‌رود، یا اینکه آیا یک مسابقه وجود دارد یا خیر. بودجه ای که امکان استفاده از سرورهای اختصاصی را فراهم می کند. شاید آنها بپرسند که آیا بازی روی یک پلتفرم است یا انتظار می‌رود روی کنسول‌های مختلف باشد، آیا انتظار می‌رود که بازی متقاطع باشد یا اینکه آیا شرکت زیرساختی در محل دارد یا ترجیح می‌دهد در فضای ابری باشد. همه اینها سؤالات معتبری هستند که قبلاً توانایی داوطلب را در تجزیه و تحلیل انتقادی یک مسئله به اجزای کوچکتر آن برجسته می کند.
توجه به این نکته مهم است که در اینجا هیچ پاسخ درست یا غلطی وجود ندارد. آیا آنها با میکروسرویس ها، بدون سرور، یا شاید یکپارچه پیش می روند؟ آیا آنها داده های کاربر را در پایگاه داده SQL یا NoSQL ذخیره می کنند؟ آیا آنها خودشان بک‌اند را می‌سازند یا از BaaS استفاده می‌کنند؟ راه حل آنها چقدر امن است؟ آیا آنها به‌روزرسانی‌ها را از طریق یک وب‌سوکت به مشتریان ارسال می‌کنند؟ همه این رویکردها موافقان و مخالفان خود را دارند و جنبه کلیدی در اینجا توانایی داوطلب برای توضیح استدلال خود و مقایسه گزینه های مختلف موجود است.
برای جالب نگه داشتن موارد، می‌توانید سناریو را در حالی که نامزد از طریق آن کار می‌کند، گسترش دهید و جزئیات و محدودیت‌های بیشتری را اضافه کنید تا ببینید چگونه پیشنهاد خود را با شرایط تطبیق می‌دهند.
این هم یک مثال دیگر:
“شما مهندس اصلی بازی زنده ای هستید که به تازگی منتشر شده است. اوضاع نسبتاً ثابت بوده است و زیرساخت ها تا کنون متوقف شده است. در آخر هفته اول، در حین شیفت کاری شما، یک هشدار فعال می شود و بازیکنان نمی توانند وارد بازی شوید. چگونه به این موضوع نزدیک می شوید؟”
این سوال مبتنی بر سناریو جنبه‌های مختلف کار بر روی یک بازی زنده را پوشش می‌دهد، از جمله بررسی مفاهیم رایج مقیاس‌بندی زیرساخت، برقراری ارتباط با سایر اعضای تیم، و حفظ آرامش و کار کردن تحت فشار زمان بر روی بازی‌ای که دچار اختلال می‌شود.
یکی از مشاهدات ممکن این است که در آخر هفته شمارنده CCU بالاتر باشد، زیرا افراد بیشتری برای بازی وقت دارند، بنابراین برخی از اجزای زیرساخت ممکن است آنطور که انتظار می‌رود مقیاس‌پذیر نباشند. شاید پایگاه داده به یک یا چند نسخه Read نیاز داشته باشد؟ آیا مقیاس خودکار backend بر اساس یک متریک است؟ آیا ما محدودیت های سهمیه ای را برای یک سرویس خاص اعمال می کنیم؟
از سوالات بی اهمیت خودداری کنید
مهندسی در هسته خود حل مشکلات و کشف چیزهای جدید است. پرسیدن سؤالات خیلی خاص، به جز توانایی آنها در به خاطر سپردن حقایق و آمار، ارزش زیادی در مورد نامزد نشان نمی دهد.
حتی با تجربه ترین توسعه دهنده هم همه چیز را نمی داند، و با تمرکز بر اطلاعات عمومی، مصاحبه به جای فرو رفتن عمیق در تجربه و انگیزه نامزد، به یک بازی شانس تبدیل می شود.
چند نمونه از سوالات بی اهمیت که باید از آنها اجتناب کرد عبارتند از:
هنگام استفاده از بازیابی نقطه در زمان DynamoDB، حداکثر بازه زمانی در چند روز که می توانید جدول خود را بازیابی کنید چقدر است؟ (35 روز)
در AWS، سهمیه پیش‌فرض VPC در هر منطقه چقدر است؟ (5)
هنگام استفاده از PlayFab، چند درخواست موجودی در ثانیه برای هر کاربر عنوان مجاز است؟
نامزد را راحت کنید
شرکت در مصاحبه آسان نیست و می تواند ترسناک باشد. نامزدها احتمالا تحت فشار و استرس خواهند بود و ممکن است خطرات زیادی برای آنها وجود داشته باشد.
به عنوان مصاحبه کننده، حفظ یک فضای دوستانه و راحت، ایجاد آرامش در آنها و اجازه دادن به آنها برای بهترین عملکرد ضروری است. وقتی مصاحبه شروع شد، خود را معرفی کنید و از آنها دعوت کنید که همین کار را انجام دهند. دوستانه باشید و لبخند بزنید.
اگر پاسخ اشتباه دادند یا جوابی ندادند تند نباشید. تعداد بسیار کمی از کاندیداها قادر خواهند بود به تمام سوالاتی که شما به آنها می گویید به درستی پاسخ دهند و تنظیم لحن اشتباه احتمالاً نتیجه را در آینده بدتر می کند.
مصاحبه را با موضوعات سبک تر، مانند بحث در مورد پروژه ای که قرار است روی آن کار کنند (در صورت امکان) پایان دهید و به آنها فرصت دهید تا سؤال بپرسند. اطمینان حاصل کنید که جزئیات مراحل بعدی را به اشتراک بگذارید، از جمله زمانی که آنها می توانند منتظر دریافت پاسخ از تیم استخدام شوند.
آنچه را در CV می بینید تأیید کنید
برخی از داوطلبان متأسفانه در مورد تجربه و مهارت خود دروغ می گویند. این به ندرت اتفاق می افتد، و خوشبختانه با پرسیدن چند سوال هدفمند اینجا و آنجا تشخیص آن نسبتاً آسان است. نیازی به پوشش هر بخش از فناوری و ابزار ذکر شده در CV نیست، انتخاب کوچکی از آن ها کافی است.
در اینجا چند نمونه هستند:
شما در رزومه خود به تجربه گسترده خود با Terraform اشاره می کنید، می توانید به طور خلاصه توضیح دهید که Terraform State چیست؟
به نظر می رسد شما تجربه زیادی با C# و DotNet دارید، می توانید توضیح دهید که زباله جمع کننده چیست؟
احتمالاً فکر می کنید این سؤالات خیلی آسان هستند و من با شما موافقم. از سوی دیگر، آنها به من کمک کردند تا بیش از یک نامزد را شناسایی کنم که ادعا می کردند چندین سال در آن فناوری ها تجربه دارند، اما قادر به پاسخگویی به آنها نبودند.
فراتر از جنبه های فنی بروید
مهندسی یک تلاش اجتماعی است که مستلزم کار در تیم و همکاری با همتایان و سایر رشته‌ها است. به همین دلیل، بخش مهمی از مصاحبه باید ارزیابی تناسب تیم و فرهنگ باشد.
به یاد داشته باشید که اگر همه چیز خوب پیش برود، در آینده ای قابل پیش بینی با این شخص کار خواهید کرد و هیچ مهارت و دانشی وجود ندارد که جایگزین ارتباط موثر و همکاری در یک تیم شود.
برای ارزیابی این موضوع، ممکن است بخواهید در مورد تجربه آنها در مشاوره مهندسین دیگر بپرسید (در صورت وجود)، یا چند سناریو ارائه دهید که در آن مشکل ذاتاً فنی نیست.
یک مثال می تواند این باشد:
پروژه ای که در حال حاضر در حال انجام آن هستید به اولین آزمایش بتا نزدیک می شود و شما به تازگی اجرای یک سیستم بازی مهم، درخت مهارت را به پایان رسانده اید. در طول جلسه Play Testing بعدی، طراح بازی تحت تأثیر وضعیت فعلی قرار نگرفته و ویژگی‌های گمشده را ذکر می‌کند. چگونه به این موضوع نزدیک می شوید؟
نامزد باید عمیق‌تر در مورد آنچه که ممکن است باعث این ناهماهنگی شده است کاوش کند. آیا GDD در محل وجود داشت؟ آیا به روز نگه داشته شد؟ آیا قبل از شروع توسعه ویژگی جلسه شروع مشترکی وجود داشت؟ آیا تیم توسعه برای به‌روزرسانی وضعیت و تکرار آن، با تیم طراحی همگام‌سازی مکرر داشته است؟ همه این سؤالات به آنها اجازه می دهد تا مشخص کنند که منشأ این موضوع کجاست و اقدامات لازم و تدابیر حفاظتی را برای جلوگیری از تکرار آن برنامه ریزی کنند.
به وقت آنها احترام بگذارید
تست های فنی یک موضوع بزرگ و اغلب بحث برانگیز است که پست وبلاگ خود را تضمین می کند. صرف نظر از اینکه آنها ضروری هستند یا نه، درخواست از نامزدهای خود برای گذراندن چند روز در یک پروژه، آنهایی را که قبلاً شغلی دارند یا به دلیل تعهدات دیگر وقت خالی کمی دارند، فیلتر می کند.
اگر فکر می کنید آزمون ضروری است، مطمئن شوید که آن را مختصر و متمرکز نگه دارید و حداکثر چند ساعت وقت بگذارید و نتیجه را با داوطلب بررسی کنید تا به آنها اجازه دهید رویکرد خود را توضیح دهند و تفکر خود را درک کنند.
امیدوارم از این مقاله چیزهای ارزشمندی یاد گرفته باشید و در مصاحبه بعدی خود از این نکات استفاده کنید.
لطفاً نظرات خود را در این مورد به اشتراک بگذارید، و اگر پیشنهاد دیگری دارید، خوشحال می شوم آنها را بشنوم.
