شرکت‌ها به توسعه‌دهندگانی نیاز دارند که بتوانند مشکلات را حل کنند و کد خوبی بنویسند. فکر سریع تحت فشار بخشی از توصیف شغل نیست.
استخدام توسعه‌دهندگان نرم‌افزار با کیفیت سخت است. اینکه آن‌ها درخواست شغل‌های شما را بدهند نیز سخت است. اینکه با آن‌ها به مصاحبه موافقت کنند نیز سخت است. و البته، پس از مصاحبه، تصمیم‌گیری درباره اینکه آیا شایستۀ پیشنهاد هستند یا نه، سخت‌ترین مورد است. آیا می‌توانند کد خوبی بنویسند؟ آیا حتی زبان‌های برنامه‌نویسی که ادعا می‌کنند می‌دانند را می‌دانند؟ سطح تجربه‌ی آن‌ها واقعاً چقدر است؟ و موضوع فقط کد نیست — توسعه‌دهندگان باید به خوبی ارتباط برقرار کنند و با اکوسیستم دائماً در حال تغییر همراه شوند. همه این‌ها در چند مصاحبه کوتاه سنجیده سخت است.
و خطرات بسیار بالاست. اشتباه کردن و استخدام شخص نادرست می‌تواند هزینه‌بر باشد، هم از نظر زمان از دست رفته و هم از نظر کیفیت پایین کد.
یکی از روش‌هایی که بسیاری از سازمان‌ها برای پاسخ به این پرسش‌های دشوار استخدامی به کار می‌برند، این است که از نامزدها بخواهند در زمان مصاحبه برنامه‌نویسی کنند. بحث‌های زیادی دربارهٔ اینکه آیا این ایدهٔ خوبی است یا نه صورت گرفته و من هم قصد دارم دربارهٔ آن بیشتر بپردازم.
آزمون فشار
اولین تلاش‌ها برای اینکه نامزدها در مصاحبه کدنویسی کنند، مستقیماً روی تخته سفید انجام می‌شد. شما به توسعه‌دهنده یک معمای فکری می‌دادید: «یک روال برای معکوس کردن لیست پیوندی بنویسید» یا «یک جستجوی دودویی در آرایه‌ای مرتب انجام دهید». شرکت‌های بزرگ فناوری به‌قدری مشهور شدند که وب‌سایت‌هایی برای کمک به نامزدها در یادگیری حل این مشکلات ظهور کردند. مکان‌هایی مانند LeetCode و AlgoExpert دارای ده‌ها سؤال مشابه برای تمرین هستند.
تمایل قوی وجود دارد تا معماهای خلاقانه‌تر و چالش‌برانگیزتری ایجاد شود، اما این می‌تواند فرهنگی ایجاد کند که سعی در ساخت لحظات «گاتچا» ناعادلانه برای نامزدها داشته باشد. توسعه‌دهندگان کد را روی تخته سفید نمی‌نویسند — آن‌ها از IDEها استفاده می‌کنند. ناآرامی نوشتن کد با ماژیک پاک‌کننده جای خود را به کدنویسی روی صفحهٔ مشترک با ابزارهای توسعه داد، اما حتی این گام نیز اغلب سبب فشار می‌شود که به نتایج غیرقابل‌درک منجر می‌شود.
من تعداد زیادی از مصاحبه‌های کدنویسی روی تخته سفید انجام داده‌ام و بسیار از نتایج آن‌ها ناراضی شدم. تجربهٔ من نشان می‌دهد که این روش یا موفق است یا نه. برخی نامزدها عملکرد خوبی دارند و برخی دیگر دچار مشکل می‌شوند. به طور کلی، من دریافت کردم که توانایی کدنویسی خوب روی تخته سفید نشانهٔ خوبی است. به هر حال، توانایی فکر کردن در لحظه و تحت فشار مهارت ارزشمندی است.
در عین حال، من گمان می‌کردم که عدم موفقیت در چنین آزمونی به این معنی نیست که توسعه‌دهنده ماهر نیست. مطمئنم که برخی نامزدهای خوب را رد کردم چون در مسألهٔ «گاتچا» روی تخته سفید عملکرد خوبی نداشتند. علاوه بر این، اگر فرآیند مصاحبه شما حس یک دام انتظار برای گرفتار کردن نامزد را داشته باشد، چه پیامی واقعاً می‌فرستد؟
همه برنامه‌نویسان خوب نمی‌توانند در لحظه به خوبی فکر کنند. حتی مطمئن نیستم که «فکر کردن سریع تحت فشار» مهارتی باشد که باید فیلتر شود. «ارائهٔ راه‌حل عالی پس از برخورد سیستماتیک با مسأله» ویژگی بسیار بهتری در یک توسعه‌دهنده است، نه؟
آزمون خانگی
سپس به نامزدها یک آزمون خانگی دادیم. مسائلی کمی عمیق‌تر و گسترده‌تر شد: «سیستم چراغ راهنمایی ساده بسازید» یا «یک سازندهٔ میم ساده ایجاد کنید». ایده این است که توسعه‌دهنده زمان و تلاش بیشتری را به پروژه اختصاص دهد، از جمله مهارت‌های پایهٔ طراحی. سپس نامزد با یک راه‌حل باز می‌گردد، برنامهٔ خود را نشان می‌دهد و کد را توضیح می‌دهد.
من این روش را خیلی بهتر می‌پسندم. این شبیه‌سازی بسیار بهتری از نحوهٔ کار واقعی یک توسعه‌دهنده است. در دنیای واقعی، از توسعه‌دهندگان نمی‌خواهیم که بلافاصله راه‌حل‌ها را از یاد خود بیرون بکشند. ما می‌خواهیم آن‌ها تحقیق کنند و دربارهٔ یک مسأله فکر کنند و راه‌حل‌ها را بررسی کنند تا به طراحی صحیح برسند. به یک توسعه‌دهنده یک هفته یا بیشتر برای کار بر روی یک مسأله دادن، معیار بسیار بهتری برای توانایی‌های او است.
اکنون، انتقادی که دربارهٔ آزمون خانگی می‌شنوم این است که آن‌ها فقط «یک راه حل را در گوگل جستجو می‌کنند یا از هوش مصنوعی برای حل مسأله استفاده می‌کنند». در پاسخ من می‌گویم: «باشه، این برای من قابل قبول است». برای من مهم نیست توسعه‌دهنده چگونه به یک راه‌حل می‌رسد؛ مهم این است که قادر به انجام آن باشد. من کمتر نگران منبع کد هستم و به‌مراتب بیشتر به این که نامزد چگونه مالکیت کد را بر عهده می‌گیرد، علاقه‌مندم. اگر کدی که در چالش کدنویسی ارائه می‌دهند به خوبی نوشته شده باشد و شامل تست‌های واحد باشد و بتوانند توضیح دهند که چه کاری انجام می‌دهد و چگونه کار می‌کند، چرا باید برای چگونگی پیداکردن کد اهمیت قائل شوم؟
اگر شما از هوش مصنوعی استفاده نمی‌کنید این روزها، پس عقب مانده‌اید. من می‌خواهم تیم توسعه‌ام از تمام ابزارهای موجود برای انجام کار به‌سرعت و به‌درستی استفاده کند. من به چشم تردید به توسعه‌دهنده‌ای نگاه می‌کنم که از هوش مصنوعی استفاده نکرده باشد و سایر منابع برای حل پروژهٔ خانگی استفاده نکرده باشد. موفقیت یک نامزد به این بستگی ندارد که چگونه پروژه را به‌پایان رسانده، بلکه به توانایی او در ارائه و توضیح راه‌حل برای مسأله‌ای که به او داده شده است بستگی دارد. اگر بتوانند این کار را انجام دهند، چرا به چگونگی رسیدن به راه‌حل اهمیت می‌دهید؟
فرآیند مصاحبه باید به پرسش «آیا این نامزد می‌تواند کاری که از او می‌خواهیم را انجام دهد؟» پاسخ دهد. اگر آن‌ها کد تمیز و کارآمدی که نیازها را برآورده می‌کند ارائه دهند و بتوانند تفکر خود را ارتباط دهند و راه‌حل را در صورت نیاز سازگار کنند، چه کسی اهمیت می‌دهد که چگونه به آن رسیدند؟ این همان توسعه‌دهنده‌ای است که می‌خواهید در تیم خود داشته باشید.
پست های مرتبط
آیا مصاحبه‌های کدنویسی ضروری است؟
آیا مصاحبه‌های کدنویسی ضروری است؟
آیا مصاحبه‌های کدنویسی ضروری است؟