چالش‌های مصاحبه فنی، لایوکدینگ، AI

این توییت، مسبب نوشتن این مطلب شد!

داستان از جایی شروع شد که یک روز شلوغ کاری، مجبور شدم توی مرحله لایوکدینگ یک مصاحبه شرکت کنم، ولی بعد از ۹۰ دقیقه مصاحبه که نتیجه ناامیدکننده‌ای داشت، این توییت رو نوشتم. چند ساعت بعد، دیدم بازخورد و تعداد مشاهده‌هاش نسبت به میانگین توییت‌های من خیلی بیشتر شد! لذا به نظرم اومد که شاید موضوع بدی نباشه برای نوشتن...

به‌طور خلاصه بازخوردها حول دو محور اصلی بودن:
- چرا استفاده از AI در مصاحبه مذموم دونسته شده
- چرا لایوکدینگ داریم؟ و برخی این روش رو منسوخ می‌دونستن

مشکل اصلی نه AI است، نه لایوکدینگ، نه حتی سؤال الگوریتمی. مشکل اصلی مصاحبه‌ایه که نمی‌دونه دقیقا دنبال چه سیگنالی باید بگرده.

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

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

به صورت کلی هیچ روال جامعی که بشه در قالب یک جزوه چاپ کرد و داد دست شرکت‌ها و گفت این روش مصاحبه بهترینه، وجود نداره. لذا قبل از اینکه شیوه مصاحبه شرکتی رو قضاوت کنیم یا بهشون روشی رو پیشنهاد کنیم، باید با «نیازها» و «شرایط» اون تیم و شرکت آشنا باشیم. مثلا سایز شرکت، عامل بسیار مهمیه، شرکت کوچکی که با ۵۰ تا رزومه روبرو است و شاید سالی ۱۰ نفر استخدام داشته باشه، با شرکتی که برای یک پوزیشن، هزاران رزومه به دستش می‌رسه و ماهانه ده‌ها نفر جذب داره و نیروهای فنی‌اش هم مشغله زیادی دارن نمی‌تونن با یک روش مصاحبه و جذب نیرو داشته باشن.
حتی نسبت به گروه‌بندی شرکت‌ها بر اساس سایز هم نمیشه روش ثابتی رو پیشنهاد داد، یه وقت در حال جذب توسعه‌دهنده‌ای هستن که از پیش می‌دونن یه سری وظیفه مشخص رو قراره انجام بده و رفتن یا جایگزین کردنش چالش خاصی برای تیم و شرکت نداره؛ و گاهی هم برای یک نقش خاص با توانایی و تجربه ویژه، باید رویه‌های متفاوتی پیش بگیرن و حتی نیروها رو هم به شکل دیگه‌ای دعوت/شکار کنن.

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

روش‌های امروزی مصاحبه‌های فنی، مخصوصا مدل whiteboard و live coding، تا حد زیادی از فرهنگ شرکت‌هایی مثل Microsoft در دهه‌های ۸۰ و ۹۰ میلادی اومدن. در زمانه‌ای که بازار نرم‌افزار هنوز شکل متعارف و استانداردی نداشت، رزومه‌ها قابل اتکا نبودن، تجربه کاری نرم‌افزاری خیلی‌ها قابل مقایسه نبود، و شرکت‌ها دنبال راهی بودند که «طرز فکر» افراد رو سریع ارزیابی کنن. به همین دلیل puzzle، مسئله‌های الگوریتمی، طراحی روی تخته و بعدتر لایوکدینگ تبدیل شدن به ابزارهایی برای ارزیابی «مهارت حل مسئله»، «شفافیت»، «مهارت ارتباط» و «تحمل ابهام». منابع تاریخی (بلاگ‌ها،خاطرات و اخبارهای مرتبط با اون ایام) هم معمولا به نقش Microsoft و علاقه‌اش به puzzle و brain teaser اشاره دارن، طبیعتا این موضوع یک «اختراع رسمی با تاریخ دقیق» نیست.

اما با رشد Big Tech، دیگه این روش‌ها فقط یک ابزار سنجش نبودن، بلکه تبدیل شدن به یک سیستم مقیاس‌پذیر برای استخدام. وقتی هزاران نفر برای نقش‌های مشابه اپلای می‌کنن، شرکت‌ها نیاز دارن ارزیابی رو استاندارد کنن و هم‌زمان هزینه جذب نیرو رو کنترل کنن. مسئله‌های الگوریتمی، بررسی و فیلتر افراد (screening) از طریق تماس تلفنی، کدنویسی زنده حضوری یا آنلاین؛ به شرکت‌ها کمک می‌کردن کاندیداها رو با معیارهای تقریبا مشابه مقایسه کنن.

ولی مشکل از جایی شروع شد که این ابزار، گاهی از هدف اصلی جدا شد. یعنی به جای اینکه بفهمیم «آیا این فرد می‌تونه در این تیم نرم‌افزار خوب بسازه و ارزش واقعی ایجاد کنه؟»، شروع کردیم به سنجیدن اینکه «آیا این فرد LeetCode رو خوب تمرین کرده؟» همین چالش هم عبارت LeetCoder رو به دایره واژگانمون اضافه کرد، یعنی کسی که چند وقت نشسته مسایل ساختمان‌داده و الگوریتم رو با سایت‌هایی مثل لیت‌کد یا هکررنک یا… تمرین کرده، ولی درک عمیقی از «مهندسی نرم‌افزار» یا «مهارت حل مسئله» نداره.

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

به چه مصاحبه‌ای می‌گیم بد؟

مصاحبه بد یعنی سؤال حفظی، بدون ارتباط با نقش، بدون rubric، وابسته به سلیقه مصاحبه‌گر، با استرس مصنوعی بالا و بدون امکان مشاهده رفتار واقعی کاندیدا. در چنین مصاحبه‌ای، چه AI مجاز باشه چه نباشه، خروجی قابل اعتماد نیست؛ چه لایو‌کدینگ باشه چه گپ‌وگفت فنی چه HTA (home task assignment) باز یه جای کار می‌لنگه.

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

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

مصاحبه خوب چجوریه؟

مصاحبه خوب باید مشخص کنه دنبال چه سیگنالیه. مثلا:

– آیا این فرد می‌تونه یه مسئله‌ی مبهم رو شفاف کنه؟
– آیا می‌تونه کد قابل نگهداری بنویسه؟
– آیا edge case می‌بینه؟
– آیا تست رو بخشی از کار می‌دونه یا تزئین آخر کار؟
– آیا وقتی feedback می‌گیره تدافعی برخورد می‌کنه یا سعی می‌کنه لحاظ کنه؟
– آیا می‌تواند درباره trade-offها حرف بزنه؟
– آیا ابزار رو می‌فهمه یا فقط خروجی ابزار رو کپی می‌کنه؟ (این‌روزها این خیلی مهمه)
– آیا درک و نحوه‌ی تعاملش با AI هم‌راستا با رویکرد تیم هست؟

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

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

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

لایوکدینگ رو حذف نکنیم، یاد بگیریم چجوری ازش استفاده کنیم!
لایوکدینگ اگر تبدیل بشه به مسابقه سرعت و حافظه، ابزار ضعیفیه. اما اگر تبدیل بشه به یه جلسه کوچک pair programming، با مسئله محدود، امکان پرسیدن سؤال، امکان نوشتن تست و تمرکز روی reasoning، هنوز یکی از بهترین روش‌ها برای دیدن طرز فکر مهندسیه. برعکس حالتی که لایوکدینگ تبدیل به مصاف تماشای شیوه‌ی کدنویسی یه نفر توسط دو/سه نفر دیگه می‌شه؛ این نوع بهره‌گیری از لایوکدینگ گرچه نیاز به صرف انرژی و آمادگی بیشتر از سمت مصاحبه‌گیرنده‌ها داره، ولی خروجی دقیق‌تری می‌ده.

حالا چرا ساختمان‌داده، الگوریتم و…؟
از جنبه تاریخی، خیلی از ساختمان‌داده‌ها و الگوریتم‌ها چیزهای بدیهی یا آماده‌به‌استفاده‌ای در زبان‌ها نبودن، لذا برنامه‌نویس می‌بایست بلد می‌بود تا اون‌ها رو بنویسه و به‌جا استفاده کنه. ولی با گذر زمان، طیف وسیعی از محصولاتِ نرم‌افزاری تبدیل به قطعات پازلی شدن که کافی بود بدونیم چه زمانی با کدوم متد از کدوم آبجکت/استراکت به هم وصلشون کنیم، و اگر بخوام به زبان خودمونی و ساده بگم (در مثل مناقشه نیست)، بخش قابل‌توجهی از نرم‌افزارهای LOB (Line of Business) در بخش کدنویسی، ولو با داشتن صدها هزار خط کد، عمدتا از کار با دیتابیس و بروکر و بیزنس‌لاجیک فراتر نبودن. همین باعث می‌شه که از خودمون بپرسیم آیا همه نقش‌ها نیاز به دونستن ساختمان‌داده و الگوریتم برای مصاحبه دارن؟
پاسخ: منطقا خیر. ولی در نظر بگیریم که این‌ نوع طرح این تیپ سوالات و ارزیابی پاسخشون سریع و سرراست است. و این یعنی صرفه‌جویی در زمان برای مصاحبه‌گیرنده. از اون سمت؛ خیلی شرکت‌ها فکر نمی‌کنن که فلان شرکت چرا اینجوری مصاحبه می‌گیره، و با خودشون می‌گن «لابد خوبه که اونا اینجوری می‌گیرن، پس ما هم می‌گیریم!!» در حالیکه برخی شرکت‌ها «حقیقتا» نیاز دارن تا مهندسی رو جذب کنن که با این تیپ مسائل آشنا و دست‌به‌کد باشه تا «مسائل‌شون» رو حل کنه.
لذا نوع سوالات خیلی مهمه، مثلا من برای همه پوزیشن‌ها یک گروه مشخص از ساختمان داده یا الگوریتم رو استفاده نمی‌کنم. مثلا برخی برخی که باید برای نقششون درک عمیقی از کامپایلر داشته باشن SSA Formو Lexical Analysis با DFA/NFA رو می‌گذارم، ولی برای کسی که کارش چیز دیگه‌ایه Stereo Matching یا Harris Corner. برای برخی یه زبون خاص رو محدود میکنیم، برای برخی آزاد است تا بین هر زبون static که تجربه داره و عمیقه بنویسه.

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

یک مصاحبه فنی خوب رو چجوری طراحی کنیم؟

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

اگر قراره کسی روی یک سیستم legacy کار کنه، باید ببینیم چجوری کد ناآشنا رو می‌خونه، چطور با ابهام کنار میاد، چجوری بدون شکستن رفتار موجود، کد رو refactor می‌کنه و چطور با تست، ریسک تغییر رو کم می‌کنه.

اگر قراره کسی روی platform یا infrastructure کار کنه، باید ببینیم چجوری درباره reliability، observability، failure mode، automation و trade-off بین simplicity و scalability فکر می‌کنه.

اگر نقش senior یا staff است، فقط کدنویسی کافی نیست. باید دید فرد چجوری مسئله مبهم رو تبدیل به تصمیم فنی می‌کنه، چطور بین تیم‌ها alignment ایجاد می‌کنه، چجوری با محدودیت‌های سازمانی کنار میاد و چجوری «تصمیمی» می‌گیره که شش ماه بعد هم هنوز قابل دفاع باشه.

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

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

همچنین داشتن rubric مهمه؛ (روبریک ابزاریه برای ارزیابی و نمره‌دهی بر اساس معیارها، انتظارات و سطوح عملکرد مورد نیاز برای یک تکلیف یا پروژه یا …).
روبریک چه برای سطح‌بندی افراد (جونیور، مدیور، سنیور و…) مهمه، هم برای امتیازدهی مصاحبه، مثلا هر کدوم از معیارهای
فهم مسئله
سؤال پرسیدن
تقسیم مسئله
درستی راه‌حل
سادگی کد
تست و edge case
واکنش به feedback
توانایی توضیح trade-offها
چقدر امتیاز داره، کدومشون حیاتیه و کدومشون می‌تونه باعث حذف کاندید از چرخه‌ی مصاحبه بشه.

حتی همه مهندس‌ها رو نباید با یک قالب سنجید؛ چه فُرم، چه محتوا و چه تعداد و نوع مراحل.
– مصاحبه backend engineer با frontend engineer فرق داره.
– مصاحبه SDET با platform engineer فرق داره.
– مصاحبه junior با staff engineer فرق داره.
– مصاحبه product engineer با infra engineer فرق داره.
– برای junior شاید learning ability، پایه‌ها و ارتباط مهم‌تر باشه.
– برای senior شاید system design، ownership، debugging و trade-offها مهم‌تر باشه.
– برای staff شاید ambiguity, influence, architecture judgment و توانایی تصمیم‌سازی مهم‌تر باشه.

مثال:

برای دولوپر جونیور:
سؤال بد: «یک LRU cache بنویس.» برای نقشی که قراره فقط CRUD سازمانی بنویسه.
سؤال بهتر: «یک endpoint ساده طراحی کن که داده employee رو بر اساس چند شرط برگردونه، بعد درباره paging، validation، error handling، test و edge case حرف بزنین.»

یا برای SDET:
سؤال بد: «یه Map در Java بساز.» پرسیدن Map به تنهایی کافی نیست، ولی برای کسی که ادعای ۶ سال تجربه Java automation داره، ندونستنش یک سیگنال منفیه.
سؤال بهتر: «یک سناریوی تست برای فرایند login با MFA طراحی کن، بعد بگو چه چیزی را unit، integration و e2e تست می‌کنی.»

با AI چه کنیم؟

متاسفانه رواج LLMها موجی از «توهم دانایی! و توانایی!» رو برای جامعه، و خصوصا جامعه نرم‌افزاری همراه آورده؛ و همین کار رو سخت کرده! شده مثل زمانی که طرف می‌گفت چون بیل‌گیتس و زاکربرگ دانشگاه هاروارد رو نیمه‌کاره رها کردن، پس من هم نیازی به تحصیل ندارم! الان هم هر چی می‌گی، می‌گن در زمانه‌ی AI دونستن فلان و بهمان نیازی نیست و توی مصاحبه آوردنش «ادایی» است! پرامپت خوب می‌نویسیم کار رو در میاریم!
یک کامنت داشتم که گفته بودن باید ببینی پرامپ چجوری می‌نویسه، نه اینکه لایوکدینگ بگیری!
حداقل نگفت ساختن صحیح ایجنت و تولز و MCP و Skill خوب رو بپرس. ارزیابی ساختارمند و دیباگ کردن اصولی AI رو بپرس، پرامپت‌نویسی آخه!

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

کوتاه: AI در مصاحبه نه ممنوع مطلقه، نه آزاد مطلق؛ بستگی داره دنبال چه سیگنالی باشی.

لذا استفاده از AI در حین مصاحبه هم برمی‌گرده به طراحی فرایند مصاحبه، درک از نیازهای پوزیشن شغلی و تیم و… مثلا من، بخش مشخصی رو در مصاحبه سوم/چهارم (بسته به پوزیشن) در مورد نحوه استفاده از AI، آگاهی به زیر و بمش اعم از اینکه
– در طراحی و توسعه اسکیل‌ها و ایجنت‌ها چه نکاتی باید رعایت شه
– چه زمانی ایجنت‌هامون رو بشکنیم و نحوه تعامل بین ایجنت رو چجوری طراحی کنیم
– موضوعات و دغدغه‌های امنیت، compliance، و.. در استفاده از LLM
– طراحی MCP در فرایند توسعه نرم‌افزار
– درک از harness, model, tools, prompt, context
و… (حتی این سوالات هم برای سطوح مختلف رو طرح می‌کنم. ولی جمع‌بندی من اینه که حداقل در حال حاضر برای پوزیشن‌ها و سطوحی که جذب داریم، در مرحله کدنویسی لزوم درک عمیق در یه سری موضوعات لازمه. لذا در چند مرحله فنی، خط قرمزه و هر تقلبی باعث رد شدن می‌شه. آیا این خوبه؟ آیا این بده؟ پاسخ اینه که سوال غلطه؛ نیاز هر تیمی متفاوته.

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

مثال و تجربه شخصی:

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

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

مثلا همین نکته ساده که اسم برخی شرکت‌ها برای کاندیداها می‌تونه استرس‌آور باشه؛ و ما چیکار می‌تونیم بکنیم که فرد بابت استرس مضاعف، شانس خودش رو از دست نده و بتونه به «بهترینِ خودش؛ نزدیک‌تر بشه» کلی فکر نیاز داشت، برای بچه‌های تیم که میرن مصاحبه آموزش گذاشتم. چون؛ قرار نیست جلسه مُچ‌گیری باشه، ما وقت اضافه نداریم که بریم آدم‌ها رو بچزونیم! ما باید تلاش کنیم در بازه زمانی معقول، هم‌تیمی خوب پیدا کنیم. مصاحبه‌ها داره از زمان افراد و شرکت صرف می‌شه و این یعنی پول یا هزینه‌فرصت پرداختن به کارهای جاری ما. پس بدون آمادگی و برنامه پیش‌رفتن، یعنی اتلاف منابع.
یک نکته مهم دیگه، عدالت در مصاحبه است. اگر دو کاندیدا برای یک نقش مصاحبه می‌شن، نباید یکی با سؤال سخت‌تر، مصاحبه‌گر خشن‌تر، زمان کمتر یا معیار مبهم‌تر ارزیابی بشه. البته مصاحبه همیشه صد درصد قابل استانداردسازی نیست، ولی داشتن rubric، سؤال‌های پایه مشترک، راهنمای مصاحبه‌گر و جمع‌بندی مکتوب کمک می‌کنه تصمیم نهایی کمتر وابسته به سلیقه، حال‌وهوای روز مصاحبه‌گر یا چند دقیقه آخر جلسه باشه. این چند جمله شاید به نظر ساده بیاد، ولی هماهنگ کردن تیم، آموزش دادن، و نگارش روش‌نامه‌ها فرایند زمانبر و دشواریه.

برای مصاحبه فنی، ابزارها مسئله اصلی نیستن. لایوکدینگ، سؤال الگوریتمی، take-home، system design و حتی AI، همه فقط ابزارن. ابزار خوب هم اگر بد طراحی بشه، خروجی بد می‌ده. اگر خوب طراحی بشه ولی در خدمت «حل مسائل شما نباشه» چیز خوب ولی زائده! حتی ابزار بد هم گاهی اگر آگاهانه و محدود استفاده بشه، می‌تونه سیگنال مفید بده!

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

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