كيف توظف مطوّرًا برمجيًا وأنت لست شخصًا تقنيًا

اللحظة التي تدرك فيها أنك خارج نطاق خبرتك

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

هذا أمر طبيعي تمامًا. معظم من يديرون شركة يتراوح عدد موظفيها بين 10 و200 ليسوا مطوّرين، ومع ذلك يحتاج معظمهم لتوظيف واحد. الخبر الجيد: لست بحاجة لتعلّم البرمجة كي توظّف بشكل جيد. تحتاج فقط أن تتوقف عن محاولة الحكم على الكود، وتبدأ في الحكم على الأدلة المحيطة به.

لا تتظاهر بالإلمام التقني — فالأمر ينقلب عليك

يستطيع المرشحون معرفة متى تتظاهر. عندما تسأل "حدّثني عن تجربتك مع Kubernetes" ثم تكتفي بقول "رائع، رائع" مهما كانت الإجابة، فأنت بذلك تُعلّم المرشح الذكي أن هذه المقابلة لا معيار حقيقي فيها. من يستطيعون الحديث بطلاقة دون قدرة فعلية على الإنجاز سيمرّون بسهولة، بينما من هم أكفأ لكنهم أكثر هدوءًا، ويفترضون أنك تتحقق فعلاً، سيقلّلون من قدر أنفسهم.

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

استعر عيونًا تقنية لساعة واحدة، لا للعملية كاملة

لست بحاجة لشريك مؤسس تقني بدوام كامل كي توظّف بشكل جيد. تحتاج فقط ساعة من وقت مطوّر، مرتين: مرة لمساعدتك في كتابة وصف الوظيفة وأسئلة الفرز، ومرة أخرى للحضور في محادثة الجولة النهائية أو مراجعة عيّنة عمل.

من يمكن أن يكون هذا الشخص:

• مطوّر مستقل تدفع له مقابل ساعتين استشارة
• صديق أو مستشار سبق له بناء برمجيات
• متعاقد تستعين به بالفعل في أمر آخر

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

اطلب من المرشحين شرح عملهم الفعلي، لا افتراضات نظرية

المطوّر الذي بنى شيئًا فعلاً يستطيع شرحه بلغة بسيطة، وبأي مستوى من التفصيل تطلبه. أما من يبالغ في وصف سيرته الذاتية فعادةً لا يستطيع تجاوز السطح.

أسئلة جيدة، مرتبة حسب مقدار ما تكشفه:

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

السؤال الرابع هو الأكثر كشفًا. تقريبًا كل مطوّر حقيقي تسبب في عطل ما في مرحلة ما. من يقول "لم يحدث معي هذا أبدًا" بعد سنوات مزعومة من الخبرة إما يكذب أو لم يُطلق فعليًا أي عمل ذي أهمية.

استخدم عيّنة عمل صغيرة وحقيقية

لست بحاجة لأن يبني المرشح ميزة كاملة مجانًا. مهمة قصيرة ومحددة النطاق — تستغرق من 60 إلى 90 دقيقة، وتشبه إلى حد كبير العمل الفعلي الذي سيقوم به في الوظيفة — تخبرك أكثر مما تخبرك ساعة من الحوار.

حافظ على العدالة:

• ادفع مقابلها، أو اجعلها صغيرة بما يكفي فعلاً بحيث يكون عدم الدفع أمرًا معقولاً (معظم المرشحين سيخبرونك أيهما ينطبق)
• أعطِ نفس المهمة لجميع المرشحين في تلك المرحلة
• اطلب منهم شرح حلّهم بعد ذلك — هذه هي اللحظة التي تكشف فيها من حصل على مساعدة لم يذكرها

إن لم تملك الحكم التقني اللازم لمراجعة النتيجة بنفسك، فهذه هي اللحظة المناسبة تمامًا لاستخدام ساعتك المستعارة من الوقت التقني.

وإن كنت لا تفضّل بناء مهمة من الصفر، يمكن لاختبار فرز تقني معايَر أن يقوم بجولة أولى قبل وصولك إلى هذه المرحلة — تُجري منصة AssessFit اختبارات تكيّفية عبر مجموعة واسعة من المهارات التقنية، بحيث لا ترسل كل متقدّم مباشرة إلى مراجعك التقني الوحيد.

تحقق مما أنجزوه فعليًا، لا مما يدّعون معرفته

سيرة ذاتية مليئة بأسماء التقنيات تخبرك بما لمسه الشخص، لا بما يجيده. اطلب دليلاً بدلاً من ذلك:

• ملف GitHub، أو معرض أعمال، أو رابط لشيء حقيقي بناه
• اسم الشركة والمنتج، حتى تتمكن من الاطلاع عليه بنفسك
• ما نسبة المشروع التي كانت من عمله فعلاً مقابل عمل الفريق

لا تنبهر بقائمة طويلة من الأدوات. كن مهتمًا بشيء أو اثنين يستطيع الخوض فيهما بعمق. العمق هو المؤشر الحقيقي؛ أما اتساع المصطلحات الرنانة فغالبًا ما يكون عكسه تمامًا.

التحقق من المراجع: اسأل عن الإنجاز، لا عن المهارة

لا يمكنك أن تسأل مرجعًا "هل كان كوده جيدًا؟" وتتوقع إجابة مفيدة إلا إذا كان هذا المرجع تقنيًا أيضًا — وحتى عندها، هذا سؤال فضفاض وسخيّ نادرًا ما يعترض عليه الناس.

اسأل بدلاً من ذلك:

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

هذه الأسئلة أيضًا لا تتطلب من المرجع معرفة الكود. تتطلب فقط أن يكون قد عمل مع هذا الشخص، وهو معيار أسهل بكثير للحصول على إجابات صادقة.

الحد الصادق لكل هذا

لا شيء مما سبق يغني عن وجود شخص تقني تثق به في نهاية المطاف. إن كان هذا التوظيف هو أول مهندس لديك، ولا يوجد فعلاً أحد في شبكة علاقاتك يستطيع التحقق من كفاءته، فمن المفيد الاعتراف بذلك كمخاطرة صريحة — لنفسك، وربما لمستثمر مبكر أو مستشار قد يعرف شخصًا مناسبًا. فترة اختبار مدتها 90 يومًا مع معالم إنجاز واضحة وغير تقنية (هل تم إطلاق الشيء، هل عمل، هل اشتكى المستخدمون) هي خط دفاعك الأخير إن تبيّن أن التوظيف أضعف مما أوحت به المقابلة.

أنت لا تحاول أن تصبح مطوّرًا. أنت تحاول بناء عملية تلتقط الفرق بين من بنى أشياء فعلاً ومن حفظ المصطلحات الخاصة بها فقط.