المقابلة التقنية من جانبي الطاولة

جلست على كلا الجانبين. رسمت تصاميم أنظمة على السبورة البيضاء بينما كان المحاور يومئ بصمت. وكنت أيضًا ذلك الذي يومئ، وأراقب مرشحًا يصمم نظام إشعارات على السبورة.

الفجوة بين ما يحضره المرشحون وما يقيمه المحاورون فعليًا هائلة.

ما يحضره المرشحون

• مسائل LeetCode الصعبة
• أسئلة خوارزميات غامضة
• "أخبرني عن وقت..."
• إجابات محفوظة لتصميم الأنظمة

ما يقيمه المحاورون فعليًا

• كيف تتعامل مع الغموض. أول شيء أفعله عند تلقي مشكلة تصميم نظام هو طرح أسئلة توضيحية. "كم عدد المستخدمين؟ ما متطلبات زمن الاستجابة؟ ما الميزانية؟" المرشحون الذين يبدأون برسم المربعات قبل طرح الأسئلة هم علامة حمراء. يبنون دون فهم المتطلبات — وسيفعلون نفس الشيء في العمل.

• الوعي بالمقايضات. لا توجد بنية مثالية. كل خيار له تكلفة. عندما يقول مرشح "يجب أن نستخدم Kafka لقائمة الرسائل"، أسأل "لماذا ليس SQS؟" إذا استطاع توضيح المقايضة (Kafka: إنتاجية أعلى، عبء تشغيلي أكبر، إعادة تشغيل أفضل؛ SQS: أبسط، مُدار، جيد بما يكفي لمعظم الحالات)، فهو يفهم الهندسة. إذا قال "Kafka هو المعيار الصناعي"، فهو يتبع دون فهم.

• التفكير في أنماط الفشل. "ماذا يحدث عندما تتعطل هذه الخدمة؟" إذا كانت الإجابة "لن تتعطل"، أعرف أنهم لم يديروا نظامًا في الإنتاج مطلقًا. كل شيء يتعطل. السؤال هو هل صممت لمواجهة ذلك.

• وضوح التواصل. هل تستطيع شرح تصميمك لشخص غير تقني في الغرفة؟ الأدوار العليا تتضمن التواصل مع مدراء المنتجات والمصممين والمديرين التنفيذيين. إذا كنت تستطيع شرح نظامك للمهندسين فقط، فقد وصلت إلى سقفك.

الأسئلة التي أطرحها (وما أختبره حقًا)

"حدثني عن مشروع حديث تفخر به."

أختبر: هل تستطيع سرد قصة متماسكة؟ هل تذكر القيود، وليس فقط التقنية؟ هل تنسب الفضل لفريقك أم تأخذ كل الفضل؟ هل تذكر ما كنت ستفعله بشكل مختلف؟

"تتلقى أخطاء 500 في الإنتاج. حدثني عن عملية التصحيح الخاصة بك."

أختبر: هل لديك نهج منهجي أم تخمن؟ هل تفحص السجلات والمقاييس أولاً أم تبدأ بتغيير الكود؟ هل تفكر في نطاق التأثير؟

"صمم نظامًا لـ [X]. لديك 45 دقيقة."

أختبر: هل تطرح أسئلة أولاً؟ هل تبدأ بالمتطلبات أم بالتقنية؟ هل تذكر المراقبة ومعالجة الأخطاء والتوسع — أم فقط المسار السعيد؟

ما تغير عندما بدأت إجراء المقابلات

كمرشح، ظننت أن المحاور يريد "الإجابة الصحيحة". كمحاور، تعلمت أنه لا توجد إجابة صحيحة. أنا أقيم عملية تفكيرك.

المرشح الذي يصمم نظامًا بسيطًا، يعترف بقيوده، ويشرح متى سيضيف التعقيد هو أقوى من المرشح الذي يصمم نظامًا معقدًا لا يستطيع شرحه.

نصيحتي (من كلا الجانبين)

للمرشحين:

1. اطرح 3-5 أسئلة توضيحية قبل تصميم أي شيء
2. ابدأ ببساطة وأضف التعقيد عندما يُطلب منك
3. اذكر أنماط الفشل دون أن يُطلب منك ("إذا تعطلت هذه الخدمة، إليك ما يحدث")
4. اشرح المقايضات لكل قرار رئيسي
5. كن صادقًا بشأن ما لا تعرفه — "لم أستخدم Kafka على نطاق واسع، لكني أفهم فوائد الإنتاجية. لهذه الحالة، سأبدأ بـ SQS وأهاجر إذا احتجنا إعادة التشغيل"

للمحاورين:

1. لا تختبر المعرفة التقنية المحددة — اختبر الحكم الهندسي
2. اسأل "ماذا كنت ستفعل بشكل مختلف؟" — أفضل المهندسين لديهم آراء قوية حول عملهم الخاص
3. امنح المرشحين مساحة للتعافي من الأخطاء — كيف يتعاملون مع الخطأ يخبرك أكثر من إجابتهم الصحيحة

أفضل المقابلات تشبه جلسات العمل. الأسوأ تشبه الاستجوابات. صمم للأولى.