---

سلسلة Slack التي أثارت التغيير

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

السياق: لماذا هذا مهم

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

المشكلة بالتفصيل

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

ما جربناه أولاً

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

النهج الفني

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

# نموذج سكريبت النشر
import joblib
from flask import Flask, request

app = Flask(__name__)

model = joblib.load('model.pkl')

@app.route('/predict', methods=['POST'])
def predict():
    data = request.json
    prediction = model.predict(data['input'])
    return {'prediction': prediction.tolist()}

if __name__ == '__main__':
    app.run(debug=True)

ساعدنا هذا النهج في تحديد المرشحين الذين لم يفهموا فقط نظرية تعلم الآلة ولكن يمكنهم أيضًا التنقل في مشهد النشر، وهي مهارة حاسمة لفريقنا.

ما تغير في المنتج

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

ما تعلمناه

من خلال هذه العملية، اكتشفنا عدة رؤى رئيسية:

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

ما يعنيه هذا للمرشحين

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

ما يعنيه هذا للمجندين

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

الخطوات التالية

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