على مدار العقود الماضية ، تغيرت طريقة إجراء المقابلات مع المبرمجين عدة مرات ، وكل منهم يبدو مثير للسخرية في الماضي. إما أن نجد أخيرًا السر الحقيقي للمقابلات الفعالة ، أو تم إجراؤها بعيدًا عن اتجاه الموضة التالي ، والذي سيكون في غضون عشر إلى عشرين عامًا أمر مثير للسخرية.عندما أسأل أشخاصًا في شركات التكنولوجيا الكبيرة العصرية عن سبب ضرورة السؤال عن الخوارزميات في مقابلة ما ، فإن الإجابة الأكثر شيوعًا هي: "لدينا مثل هذا المقياس ، لا يمكننا السماح لأي شخص بكتابة
O(n^2) بطريق الخطأ
O(n^2) وطرق النظام بأكمله "
1 . ما هو مضحك بشكل خاص ، لقد قمت مؤخرًا بتطبيق هذه الخوارزميات في الممارسة العملية كثيرًا وحل المشكلات الحقيقية ، لكن لا يمكنني متابعة المقابلات التي يسألها الناس عنها! هل تعتقد أنني أفشل نصف المقابلات أو شيء من هذا؟ لا ، أكثر من النصف. شاركت في حوالي 40 مقابلة "حقيقية" ، وربما نجحت في مقابلة أو اثنتين. أو ليس واحد
2 .
عندما كتبت مسودة لهذا المقال ، وجد أصدقائي أنها مملة لأنني فشلت في إجراء الكثير من المقابلات. يقولون أنه يجب جدولة جميع حالات الفشل لأن لا أحد سيقرأ عشر صفحات من النص مع قائمة طويلة من حالات الفشل. نصيحة جيدة. تعمل بالفعل على طاولة.
دعونا نلقي نظرة على بعض الأمثلة.
في إحدى الشركات الكبيرة التي عملت فيها ، كتب الفريق مكتبة أساسية بتطبيقها الخاص لصفيف ديناميكي. إذا لم يكن هناك حجم كافٍ أثناء العملية ، فقد أضاف التطبيق عددًا ثابتًا من الصفوف إلى الصفيف ، ثم قام بنسخ الصفيف القديم إلى صفيف جديد بحجم أكبر قليلاً. هذا مثال كلاسيكي على التنفيذ غير الصحيح
لصفيف ديناميكي ، لأنه يؤدي إلى زيادة خطية في الوقت بدلاً من الوقت الثابت
المطفأ . هذا مثال كلاسيكي لدرجة أنه يستخدم غالبًا كقانون في شرح تحليل الإهلاك.
في شركات تكنولوجيا المعلومات الكبيرة ، تنقسم المقابلات الهاتفية التقليدية إلى ثلاث فئات:
- سؤال برمجة / خوارزمية "بسيط" ، ربما أولاً بسؤال "بسيط للغاية" للإحماء.
- سلسلة من أسئلة البرمجة / الخوارزمية "البسيطة جدًا".
- مجموعة من الحقائق المعروفة (نادراً ما تكون لشغل وظائف جيدة ، ولكن في كثير من الأحيان لشغل وظائف منخفضة المستوى أو غير إبداعية).
تعتبر مشكلة تنفيذ المصفوفة بهذه البساطة بحيث تندرج ضمن فئة "سهلة للغاية" وهي إما عملية تحضير لسؤال "حقيقي" أو تأتي مع مجموعة من الأسئلة البسيطة نفسها. ومع ذلك ، في شركتنا ، كانت هذه المجموعة الديناميكية مسؤولة عن حوالي 1٪ من إجمالي الحمل على أداة تجميع مجمعي البيانات المهملة في رمز JVM (كانت ثاني أكبر مصدر لتخصيصات الذاكرة في التعليمات البرمجية بالكامل) ، وكذلك عن حصة كبيرة من تحميل وحدة المعالجة المركزية.
لحسن الحظ ، لم يتم استخدام هذا التطبيق كصفيف ديناميكي عالمي ، ولكن تم إنشاؤه فقط بمساعدة قذيفة شبه متخصصة ، وبالتالي كان مسؤولاً عن "فقط" 1 ٪ من الضغط على GC. إذا سئل في المقابلة ، فإن معظم أعضاء هذا الفريق يجيبون عليه بشكل صحيح. جلبت رقعتي لصاحب العمل أموالاً في السنة أكثر مما جنيته في حياتي.
كان هذا ثاني أكبر مصدر لتخصيصات الذاكرة ، وكان المصدر الرئيسي هو تحويل زوج من القيم
long إلى صفائف بايت من نفس المكتبة الأساسية. على ما يبدو ، قام شخص ما بكتابة أو نسخ دالة تجزئة أخذت صفيفًا كمدخلات ، ثم غير الكود لأخذ صفيفتين والعمل معهم في تسلسل من دالة تجزئة قديمة مثل
byte[], byte[] . لاستدعاء هذه الوظيفة على جهازي شراء ، استخدموا وظيفة التحويل المريحة
long byte[] في مكتبة الأدوات المساعدة المستخدمة على نطاق واسع. بالإضافة إلى تمييز
byte[] ولصقه
long هناك ، تعمل هذه الوظيفة أيضًا على تغيير ترتيب البايت
long (على ما يبدو ، تم تصميم الوظيفة لتحويل القيم
long إلى ترتيب بايت الشبكة).
لسوء الحظ ، كان التحول إلى دالة تجزئة أكثر ملاءمة يعتبر تغييرًا خطيرًا جدًا ، لذلك كان التصحيح الخاص بي هو تغيير واجهة دالة التجزئة لأخذ زوج من صفقات الشراء بدلاً من زوج من صفيفات البايت وإزالة خطوة منفصلة لتغيير ترتيب البايت (حيث تم تغيير وظيفة التجزئة بالفعل له ، خطوة منفصلة لم يكن مطلوبا). جلب القضاء على هذه العمليات غير الضرورية صاحب العمل أكثر من المال في السنة مما كسبته في حياتي.
التحسين ليس من الناحية الفنية مسألة خوارزميات ، ولكن في الممارسة العملية يُطلب منه باستمرار. رداً على سؤال حول الخوارزميات ، يسألونني عادة: "هل يمكنك تسريعها؟" وغالبًا ما تتضمن إجابة هذا السؤال تحسينًا بسيطًا ، والذي يسرع الكود عدة مرات.
مثال محدد تم سؤالي مرتين خلال المقابلة: يمكنك تخزين المعرفات على أنها intts ، ولكن من السياق ، يتبع ذلك أن المعرفات مكتظة بشكل كثيف ، بحيث يمكن تخزينها كحقل بت. لكن الحل الموجود في العالم الحقيقي بعيد عن الإجابة المتوقعة حول مجال البت بحيث يصعب تحقيق التسارع عدة مرات. على الأرجح ، ستنتهي المقابلة هناك.
مثال آخر لسؤال بسيط على الخوارزميات هو التكوين الفعلي لبرنامج
BitFunnel ، وهو فهرس البحث المستخدم في Bing
3 .
سيستغرق وصف السياق الكامل لهذه الشركة بعينها الكثير من الوقت ، ولكن باختصار ، تحتاج إلى تكوين مجموعة من عوامل تصفية Bloom. تتمثل إحدى الطرق في كتابة وظيفة تحسين وفقًا لطراز الصندوق الأسود ، والذي يحاول ، باستخدام النسب المتدرج ، العثور على الحل الأمثل. لقد فعلوا ذلك ، لكن الوظيفة أظهرت بعض الخصائص الغريبة ، ولم يعمل تكوين الإخراج بشكل مثالي. تم تصحيح ذلك عن طريق تخفيف عوامل تصفية Bloom ، أي تخصيص المزيد من الموارد (وبالتالي ، الأموال) لهذه المشكلة.
عند تحليل فرص التحسين ، قد تلاحظ أن العملية الأساسية في BitFunnel تعادل احتمالات الضرب. لذلك ، لأي تكوين محدد ، يمكنك ببساطة مضاعفة بعض الاحتمالات - وتحديد كيفية عمل التكوين. نظرًا لأن مساحة التكوين ليست كبيرة جدًا ، يمكنك التنقل بين جميع الخيارات الممكنة ، ثم اختيار الأفضل. في الواقع ، هذا ليس صحيحًا تمامًا ، لأن تكاثر الاحتمالات ينطوي على بعض الاستقلال ، وهو ما لا يحدث في الواقع ، لكن الطريقة لا تزال تعمل بشكل جيد لنفس السبب الذي جعل
تصفية البريد العشوائي الساذجة بايزي تعمل بشكل جيد ، والتي تفترض بشكل غير صحيح وجود احتمال مستقل بحدوث هذه الرسالة. أي كلمتين التعسفي. للحصول على حل كامل ، يمكنك تحليل الترابط. على الرغم من أن هذا ربما يكون خارج نطاق المقابلة.
هذه فقط ثلاثة أمثلة تتبادر إلى الذهن ، وقد واجهت دائمًا أشياء متشابهة وأستطيع أن أتوصل إلى العشرات من الأمثلة ، ربما أكثر من مائة ، إذا جلست وأحاول سرد كل ما عملت عليه. وأكثر من مائة مثال عمل عليها شخص آخر (أو لا أحد). كل من هذه الأمثلة ، وكذلك تلك التي حذفت عنها ، لها الخصائص التالية:
- مثال يمكن أن تصاغ على شكل سؤال للمقابلة.
- إذا تمت صياغة السؤال ، فستتوقع أن يعرف معظم (أو جميع) الموظفين في الفريق المعني الإجابة الصحيحة.
- سيوفر توفير المال من هذا الإصلاح لصاحب العمل أموالًا في السنة أكثر مما كسبته في حياتي.
- استمرت المشكلة من المثال لفترة كافية ، وإلا فلن يكون لاحظت.
في بداية المقال ، لاحظنا أن شركات تكنولوجيا المعلومات الكبيرة تطرح أسئلة حول الخوارزميات ، لأن عدم الكفاءة على نطاق واسع سيكلفها غالياً. تُظهر تجربتي أنه في كل شركة تجري مقابلات معها ، يوجد مليون مثال على مثل هذه العيوب. اتضح أن الأسئلة حول الخوارزميات في المقابلة لا تساعد في حل مشاكل الخوارزمية الحقيقية في العمل.
أحد الأسباب هو أن الشركات الكبيرة تحاول العثور على أشخاص يمكنهم حل ألغاز الخوارزمية ، ولكن يحظرون مثل هذا المنطق في الإنتاج.
من بين الحلول الثلاثة للأمثلة المذكورة أعلاه ، ذهب اثنان إلى المنتج. بالنسبة لي ، هذه نسبة مئوية طبيعية إذا دعيت ببساطة إلى مشروع عشوائي ، وأنا لا أتابعه باستمرار. يمكن أن يقول المتهكمون أن النسبة مرتفعة. في فريق عشوائي ، قد تكون النتائج أسوأ ، لأنه ليس من المفيد لهم تنفيذ أي حل ، حتى أنه فعال. بعد كل شيء ، فإنه يتطلب منهم اختبار ودمج ونشر التغييرات. يتم إنشاء مخاطر جديدة. وهذا هو ، أطلب من الفريق القيام ببعض الأعمال وتحمل بعض المخاطر من أجل القيام بشيء مفيد للشركة ، ولكن لا طائل منه لأنفسهم. على الرغم من كل هذا ، عادةً ما يقبل الأشخاص الرمز ، على الرغم من أنهم لا يميلون إلى قضاء وقت في التحسين (سيتم قضاء وقت عملهم في أشياء تتفق مع أهداف الفريق)
4 .
لنفترض أن الشركة ترفض تقديم ألغاز المقابلة للمرشحين ، وتشجع المطورين على استخدام خوارزميات أبسط وفعالة نسبيًا. من غير المرجح أن يمر أي من الأمثلة المذكورة أعلاه دون أن يلاحظها أحد لسنوات عديدة. من المحتمل أن تكون المشكلة ثابتة. قد يرى بعض مطوري البرامج الافتراضية في شركة ذات ملفات تعريف الرموز العناصر "الأكثر سخونة" في ملف التعريف الخاص بالمكتبة الأكثر كثافة للموارد.
في حالتين ، ليس الحل العملي نوعًا من سحر الخوارزميات ، بل هو مجرد تحليل شامل. المثال الثالث أقل وضوحًا نظرًا لعدم وجود أداة قياسية لتحليل المشكلة. يمكنك محاولة تقديم النتيجة كنوع من التمكن الأسمى ، بعد كل هذا ، يستند هذا المثال إلى مقال علمي حصل على جائزة لأفضل مقال في أكثر المؤتمرات المرموقة في هذا المجال ، ولكن في الواقع هناك رياضيات بالمدارس الثانوية ، أي لحل المشكلة حقًا ، لدراسة حيث تكون هذه الأساليب الرياضية قابلة للتطبيق.
لقد عملت مرة واحدة في شركة لم تطرح أسئلة حول الخوارزميات في المقابلات ، لكنني ركزت على الأسئلة العملية. أثناء وجودي هناك ، وجدت فرصة واحدة فقط للتحسين تفي تقريبًا بالمعايير المذكورة أعلاه (نظرًا لصغر حجمها ، فإنها لا تتطابق قليلاً مع النقطة الثالثة ، أي بحلول ذلك الوقت كنت قد ربحت أكثر في حياتي من المدخرات السنوية من تحديد هذا الخطأ).
لماذا لم تواجه هذه الشركة تقريبًا أي مشاكل في مقابس الأداء؟ أعتقد أن السبب الرئيسي هو أن الكثير من الناس يعتقدون أن تحسين الشركة كان مهمتهم. لذلك ، تم تصميم الأنظمة في الأصل على النحو الأمثل تقريبًا. مع استثناءات نادرة ، كان هناك ما يكفي من المتخصصين الذين حاولوا الاستمرار في الاستفادة من الشركة ، وليس شخصياً لأنفسهم وفريقهم (والذي يختلف تمامًا عن المنفعة العالمية للشركة). وهكذا ، كان هناك دائمًا شخص ما قام بحل المشكلة قبل أن تصل إلي.
في شركات تكنولوجيا المعلومات الكبيرة ، عادة ما تكون المقابلات مع الخوارزميات ذات مهارات اختبار الترميز أبسط من الفحص الأولي عبر الهاتف. عادة ، لا يتم معالجة مشاكل تصميم النظام هنا.
منذ بعض الوقت ، حاولنا طرح سؤال حول الخوارزميات في مقابلة وجهاً لوجه. سؤال صعب للغاية ، ولكن في إطار ما قد تصادفه من خلال فحص الهاتف في الشركات الكبرى (ولكن لا يزال أسهل مما تتوقعه من المقابلات الشخصية). لقد تخلينا عن هذه الممارسة ، لأن جميع المرشحين فشلوا تمامًا في هذا الجزء (لم نطرح على المرشحين ذوي الخبرة سؤال حول الخوارزميات). إن شركتنا ليست معروفة جيدًا حتى تحصل على القادمين الجدد الذين يمكنهم الإجابة بسهولة على هذه الأسئلة ، وبالتالي ، فإن
مرشحات فحص المرشحين الأنيقة هذه لا تعمل لنا. في مقالات التوظيف الحديثة ، غالبًا ما يطلق على "خفض الشريط" ، لكنني لا أفهم لماذا يجب أن نهتم بالحد الأقصى لقفزة المرشح إذا كان عمله تقريبًا (أو أبدًا) يتضمن قفزات كبيرة. وفي تلك الحالات التي تحتاج فيها إلى القفز ، يتم تعيين الشريط على ارتفاع حوالي 5 سنتيمترات.
استنادا إلى الأداء الفعلي ، كانت الشركة الأكثر إنتاجية التي عملت فيها. أعتقد أن الأسباب موجودة في الثقافة ، وهي معقدة للغاية بحيث لا يمكن تفكيكها تمامًا في مقال واحد ، لكن ربما ساعدنا ذلك على عدم تصفية المرشحين الجيدين باستخدام اختبارات من الخوارزميات. اقترحنا أن يتمكن الأشخاص من دراسة هذه المواد في العمل إذا كانت لدينا الثقافة الصحيحة والموظفون يقومون بالأمر الصحيح بدلاً من التركيز على المهام المحلية لأنفسهم أو على قسمهم.
إذا كانت هناك شركات أخرى ترغب في حل مشكلات الخوارزميات في نفس المستوى التي يطلبونها في المقابلات أثناء العمل ، فأنت بحاجة إلى تشجيع الأشخاص بشكل أساسي على حل مشكلات الخوارزميات (عند الاقتضاء). يمكن القيام بذلك بالإضافة إلى أو حتى اختيار المرشحين للمشاكل النظرية.
الملحق: كيف وصلنا إلى هذا؟
في الأيام الخوالي ، تم طرح أسئلة "تافهة" في المقابلات. يمكن أن تبدو الإصدارات الحديثة كالتالي:
- ما هو MSI؟ ميسيتش؟ MOESI؟ MESIF؟ ما هي ميزة MESIF على MOESI؟
- ماذا يفعل المدمر؟ وإذا كان C ++ 11؟ وإذا قمت باستدعاء destructor subobject من destructor المستوى الأعلى ، ثم ما سيتم تنفيذ destructures subobject الأخرى؟ وخلال تعزيز المكدس؟ تحت أي ظروف يمكنك تجنب استدعاء
std::terminate ؟
سمعت عن هذه المقابلات البسيطة في المدرسة ورأيت في بعض الشركات "المدرسة القديمة". كان هذا أثناء قيادة Microsoft ، عندما تطلع أي شخص آخر إلى شركة ناجحة ونسخ Microsoft. قال مدوِّن البرمجة الأكثر قراءة (جويل سبولسكي) إن الجميع بحاجة إلى تبني بعض ممارسات التطوير لـ X لأن Microsoft تفعل ذلك. على سبيل المثال ، في واحدة من المقالات الأكثر نفوذاً في البرمجة في تلك الحقبة ، قدم Joel Spolsky اختبار Joel المزعوم ، والذي يحدد مدى مواكبة شركات مثل Microsoft:
12 نقطة ممتازة ، 11 نقطة مقبولة ، ولكن مع تصنيف 10 أو أقل لديك مشاكل خطيرة. الحقيقة هي أن معظم البرامج تعمل على مستوى 2-3 نقاط ، وأنها بحاجة إلى مساعدة جادة ، لأن شركات مثل Microsoft تعمل في المستوى 12 بدوام كامل.
وفقًا للأساطير الشائعة في ذلك الوقت ، سألت Microsoft عن هذه الأسئلة في المقابلات (وقد طرحت حقًا إحدى هذه المهام أثناء مقابلة في Microsoft في منطقة 2001 ، مع عدم وجود أسئلة حول الخوارزميات أو البرمجة):
- كيف تخرج من الخلاط إذا كان طولك 1 سم؟
- لماذا أغطية غرف التفتيش مستديرة؟
- تحتوي الغرفة بدون نوافذ على ثلاثة مصابيح ، يتم التحكم في كل منها بمفتاح من الخارج. أنت خارج الغرفة ويمكن أن تذهب إلى الداخل مرة واحدة فقط. كيفية تحديد التبديل الذي يتحكم في المصباح؟
منذ أن أجريت مقابلتي في عصر التغيير ، سُئلت الكثير من الأسئلة البسيطة ومجموعة من المهام (بما في ذلك كل ما سبق). في المقابلات التي جرت في ذلك الوقت ،
كانت أسئلة فيرمي ، التي ليست من الناحية الفنية الألغاز ، لا تزال شائعة. كان الاتجاه الآخر في ذلك الوقت هو المقابلات السلوكية دون وجود مشكلة فنية واحدة.
سواء كان الأمر كذلك ، حاول الناس نسخ المقابلات على غرار Microsoft. عندما سألت عن الألغاز أو أسئلة فيرمي التي كانت جيدة ، أجابوا لي أنه من الممكن بهذه الطريقة التحقق مما إذا كان المرشح قادرًا على التفكير ، بدلاً من أسئلة المعرفة ، التي تقول فقط إن الشخص تذكر بعض المعلومات. ونحن بحاجة إلى مرشحين يمكنهم التفكير حقًا!
إذا نظرنا إلى الوراء ، أصبح من الواضح الآن للجميع أن هذا غير فعال ، وأن نسخ كل خدعة من Microsoft لن يجعل شركتك ناجحة لأن Microsoft استخدمت العديد من الحيل الأخرى - فهي فعالة معًا فقط بسبب تأثير الشبكة. من خلال نسخ مقابلات Microsoft ، ستكون شركة تجري مقابلات ببساطة بنفس الأسلوب ، لكن لا يمكنك الاستفادة من تأثيرات الشبكة التي تستخدمها Microsoft.
بالنسبة للمرشحين ، كان إجراء المقابلة هو نفسه كما هو الحال الآن مع الخوارزميات. فقط للتحضير لمقابلة ، بدلاً من "التقطيع لمقابلة برمجة" ، كان عليك قراءة "How to Move Mount Fuji". أي أنك تحتاج إلى معرفة الكثير من المعرفة حول المهام التي لن تستخدمها أبدًا في العمل ، بدلاً من معرفة الخوارزميات التي لن تستخدمها أبدًا بنفس الطريقة.
في تلك الأيام ، وجد القائمون على المقابلة أسئلة المقابلة في كتب التحضير للمقابلات ، مثل كيفية تحريك جبل فوجي. تم طرح هذه الأسئلة على المرشحين الذين تعلموا الإجابات في نفس الكتب. يجد الشباب المعاصر هذا الأمر مثير للسخرية - من الواضح أن الأسئلة لا علاقة لها بالعمل ، وأن احتمال وجود إجابة جيدة يعتمد على التحضير للمقابلة أكثر من كفاءة المرشح. لكن مقاربة اليوم ليست مختلفة.
على مدى العقود الماضية ، تغيرت طريقة إجراء المقابلات مع المبرمجين عدة مرات ، وكل منهم يبدو مثير للسخرية في الماضي. إما أن نجد أخيرًا السر الحقيقي للمقابلات الفعالة ، أو تم إجراؤها بعيدًا عن اتجاه الموضة التالي ، والذي سيكون في غضون عشر إلى عشرين عامًا أمر مثير للسخرية.
دون الأخذ في الاعتبار الكفاءة ، لم تتغير أساليب المقابلة على مستوى meta (باستثناء التقنية الرفيعة المستوى للشركة الأكثر شهرة) ، لذلك كل شيء مشابه جدًا لهواية عصرية أخرى ، والتي لا تختلف عن الممارسات السخيفة السابقة. البحث التجريبي أو التحقق المستقل من فعالية الأساليب المختلفة يمكن أن يهز رأيي.مستوحاة من تعليق Wisley Pharmacist-Cassels ، قمت مؤخرًا بسؤال ممثلي أرباب العمل بالتحديد عن كيفية التحقق من فعالية المقابلات التي أجراها وكيفية تعاملهم مع التحيز. إليك ما أجابوه (بترتيب تنازلي متكرر):- ماذا؟ لا شيء ، لماذا هذا؟
- لا نعرف حقًا ما إذا كانت عمليتنا فعالة.
- نحن نعرف فقط أن كل شيء يعمل.
- ليس لدينا أي تحيز.
- كنا قد لاحظنا التحيز إذا كانت هناك عملية تقييم.
- قام شخص ما بدراسة و / أو إجراء بحث ، لكنه لا يستطيع أن يقول أي شيء ملموس حول كيفية دراسته وبأي منهجية أجريت الدراسة.
التطبيق: التدريب
كما هو الحال مع معظم المشاكل الحقيقية ، من المستحيل العثور على السبب الوحيد الذي يجعل الخلل بقيمة عشرات ومئات الملايين من الدولارات لا تزال مغلقة في الإنتاج. من ناحية ، واجهنا نوعًا من الدفاع المتعمق بحوافز غير متطابقة. من ناحية أخرى ، يتم التقليل من شأن التعلم للأسف .لقد ذكرت بالفعل أنه في جميع الشركات تقريبًا ، لا يشجع النظام الأشخاص على قضاء بعض الوقت في تحسين الكفاءة ، حتى لو أظهرت عملية حسابية بسيطة أن إصلاح الأخطاء يمكن أن يوفر بسهولة عشرات أو مئات الملايين من الدولارات. وفي غياب الحوافز ، ليس لدى المطورين أي مكان لاكتساب الخبرة في القيام بهذا العمل. العمل غير المألوف يبدو دائمًا أكثر تعقيدًا مما هو عليه بالفعل. وبالتالي ، حتى لو كان يوم العمل يمكن أن يجلب مليون دولار سنويًا في شكل مدخرات أو أرباح (هذا أمر شائع جدًا في الشركات الكبيرة ، في تجربتي) ، لا يدرك الناس أن هذا يوم عمل واحد فقط ويمكن القيام به دون إلهاء من بقية الحالات. طريقة واحدة لحل هذه المشكلة الأخيرة هي من خلال التدريب. ومع ذلك ، فإن الأمر أكثر صعوبة بالنسبة للمدير لتبريره من زيادة الكفاءة ، التي ليست جزءًا من المهام الرئيسية!على سبيل المثال ، بمجرد أن كتبت دليلًا صغيرًا (4500 كلمة ، أقل من هذه المقالة ، باستثناء الصورة) حول العثور على العديد من أوجه القصور في النظام: كيفية استخدام برنامج التعريف لتخصيص الذاكرة ووقت وحدة المعالجة المركزية ، وكيفية تكوين GC لدينا للقيام بمهام متخصصة ، وكيفية استخدام بعض أدواتي للعثور على الاختناقات تلقائيًا في تكوينات JVM ، والحاويات ، وما إلى ذلك. هذه هي حيل بسيطة وفعالة للغاية وسهلة الأداء. تمكن شخصان من تصحيح المشكلة وحلها بنفسهما ، وسمعتُ شخصًا آخر أن شخصًا آخر قد زاد من كفاءة خدمتهم. حسنًا ، إذا استفاد 10٪ من المهندسين من هذا الدليل ، آمل أن يكون قد ساعد عشرات المهندسين ، وربما أكثر.إذا أمضيت أسبوعًا في وظيفة "حقيقية" بدلاً من دليل ، فسوف أحصل على شيء محدد ، ذو قيمة كمية ، يبدو جميلًا في عرض ترويجي أو مراجعة أداء. بدلاً من ذلك ، لدي نوع من الإنجاز الغامض ، والذي يمكن اعتباره في أفضل الأحوال "ميزة إضافية". أنا لا أشكو - هذه هي بالضبط النتيجة التي توقعتها. لكن في المتوسط ، تحصل الشركات على ما تحفزه بنفسها على الموظفين. إذا كانوا يتوقعون أن التدريب يأتي من المطورين أنفسهم (دون تمويل إنتاج مواد التدريب) ، لكن لا يقدرونه بقدر تقدير عمل المطورين ، فسيصبح التدريب أمرًا نادرًا.أعتقد أنه من السهل ملاحظة النوعية الرديئة للمواد التعليمية العامة بسبب الصعوبة النسبية المتمثلة في نقد التعليم والتدريب. إذا كنت ترغب في استثمار البرامج التدريبية ، فهناك بعض الطرق الجيدة. من الواضح أن تسييل دورات الفيديو القيمة يعمل بشكل جيد (مئات أو آلاف الدولارات لدورة تدريبية قصيرة). تدريبات الشركات ، عندما تدعوك الشركات للتحدث مع 30 شخصًا ، وتأخذ 3 آلاف دولار من كل منها ، تعمل جيدًا أيضًا.إذا كنت تريد الوصول إلى (وربما مساعدة) عددًا كبيرًا من الأشخاص ، فعندئذٍ يكون النشر على الإنترنت فعالًا ، لكن لا تتوقع تحقيق الدخل. بالنسبة للموضوعات الفنية ، من غير المرجح أن يكون عدد الجمهور الذي لا يحتوي على أدوات حظر إعلانات كبيرًا بدرجة كافية لاستثمار المحتوى من خلال الإعلانات (على عكس الوصول المدفوع).على سبيل المثال ، جوليا إيفانزما يكفي من الدخل لبيع كاريكاتير الكمبيوتر ، والتي تجلب مؤخرا حوالي 100 ألف دولار سنويا. يمكن لأخصائي تدريب الشركات كسب هذا في يوم إلى يومين.ملحق: الدفاع بعمق مع عدم تطابق الحوافز ، الجزء 3
من الأمثلة الثلاثة المذكورة أعلاه ، في حالتين تلقيت بعض التشجيع لتوفير أموال الشركة. في تجربتي ، نادراً ما يحدث هذا في الشركات الكبيرة ، لكن رغم ذلك ، تبين أن توزيع الحوافز كان ضعيفًا إلى حد ما. في مرحلة ما ، بعد الترقية وزيادة الرواتب ، قمت بحساب نسبة الزيادة والمدخرات التي أتاحها للشركة. كانت النسبة حوالي 0.03 ٪ مباشرة في المال ، دون الأخذ في الاعتبار الأدوات التي طورتها ، والتي من الصعب حساب قيمة محددة. ربما هذه القيمة هي في الواقع أكثر من قيمة قابلة للقياس الكمي. لذلك ، يمكننا أن نستنتج أنني تلقيت أقل بكثير من 0.01 ٪ من المبلغ الذي جلبته الشركة. وهذا تقدير مبالغ فيه: في الواقع ، أشك بقوة في أن العمل المنجز لم يجلب لي أي شيء ،والزيادة لا علاقة لها بهذا المشروع الذي أنقذ الشركة عشرات الملايين من الدولارات. بعد أول 10 ملايين دولار في السنة ، أو ربما 20 مليون دولار في السنة ، لم يعد هناك أي حافز للقيام بعمل من حيث تقييم الفعالية ، والترقية ، والتحسين ، وما إلى ذلك. لأنه لا توجد إيجابيات ، ولكن هناك بعض العيوب (يمكنك الانخراط في المؤامرات السرية ، وإسقاط موقع بطريق الخطأ ، وما إلى ذلك) ، بحيث يصبح العائد على أداء العمل الاختياري سالبًا.ولكن هناك بعض العيوب (يمكنك الانخراط في المؤامرات السرية ، وإسقاط موقع بطريق الخطأ ، وما إلى ذلك) ، بحيث يصبح العائد على أداء العمل الاختياري سالبًا.ولكن هناك بعض العيوب (يمكنك الانخراط في المؤامرات السرية ، وإسقاط موقع بطريق الخطأ ، وما إلى ذلك) ، بحيث يصبح العائد على أداء العمل الاختياري سالبًا.تقدم بعض الشركات مكافآت كبيرة بشكل منتظم ، لكن لم يكن لديّ مثل هذه الشركة ، وفي الواقع ، لا يمكن لصاحب العمل تقييم الموظف للقيام بعمل إضافي ، باستثناء الحد الأقصى للتصنيف في مراجعة الأداء ، وهي ترمز إلى قدر كافٍ من العمل. فيما يتعلق بتصميم الآليات ، تطلب الشركة في الواقع من الموظفين التوقف عن العمل بمجرد قيامهم "بما فيه الكفاية".وبالتالي ، حتى في هذا الفريق المحترف نسبيًا ، فإن نظام المكافآت التابع للشركة يحد من الأشخاص دون تحفيزهم لتحقيق أقصى قدر من الكفاءة.وحدث أيضًا أن يتم إعطاء المديرين ميزانية فريق لزيادة الرواتب ، والتي تعتمد بشكل أساسي على عدد الموظفين ، ثم يتم توزيعها بين الموظفين. في الأساس ، لدى الفريق مطورون منتجون فقط ، لذلك لن يبرز أحد من بين آخرين. في نفس الوقت ، هناك معدل دوران منخفض للغاية للموظفين لأن المبرمجين يحبون العمل مع زملاء جيدين. لتشجيع الناس على الانتقال إلى فرق أقل فعالية ، تستخدم الشركة واحدة من أقوى العتلات - التعويض.نظرًا لأن هذا مخطط شائع ، في بعض الشركات ، يحاول المديرون إبقاء الموظفين غير مؤذيين ولكن غير فعالين من أجل التحايل على قيود المكافآت. إذا كان المرء يتساءل نظريًا إذا كانت الشركات بحاجة إلى توظيف أشخاص غير فعالين والاحتفاظ بهم ، فإن الجواب هو لا. ولكن في الممارسة العملية ، فإن مخطط المكافآت العالمية لفريق يحفز هذا بشكل غير مباشر.روابط ذات صلة
1. أولاً ، غالبًا ما تنسخ مقابلات Google الشركات الصغيرة التي تعتبر هذه الحجة غير مناسبة لها. لكن حتى أيا من الشركات الكبيرة تقوم بتطوير أو تنفيذ خوارزميات واسعة النطاق (ربما قامت Google بذلك في حوالي عام 2003 ، ولكن في شركات تكنولوجيا المعلومات الكبيرة الحديثة لا أحد يركز بشكل خاص على تطوير الخوارزميات). [عودة]2. "الحقيقي" هو في علامات اقتباس ، لأنني مررت بالعديد من المقابلات لأسباب لا تتعلق بعملية المقابلة نفسها. ربما كان لديّ توصيات جيدة للغاية ، أو ربما قرأ شخص ما مدونتي أو استفسر من زملائي السابقين ، أو نظرت في مشاريعي مفتوحة المصدر (على حد علمي ، حدث هذا مرة أو مرتين). عادة ، بعد فشل واضح في المقابلة ، أسأل لماذا عُرضت علي وظيفة ، لذلك جمعت بالفعل مجموعة من هذه الأسباب.أقترح أيضًا إمكانية حدوث نتيجة فارغة ، لأن مقابلة البرمجة "الحقيقية" الوحيدة كانت في Google ، لكن الرجال الخطأ جاءوا لمقابلتي. ذهبت للعمل مع الأجهزة ، وقد قابلني المبرمجون ، لذلك حصلت في الأساس على مقابلة مبرمج معيارية ، باستثناء أن أحد المقابلات طرح بعض الأسئلة حول جهاز الحالة وترابط ذاكرة التخزين المؤقت (أو شيء من هذا القبيل). ثم رتبوا مقابلة هاتفية مع مهندس أجهزة للتأكد من أنني لم أكذب بشأن العمل في بدء تشغيل الأجهزة من 2005 إلى 2013. من الممكن أن أخفقت في جزء البرمجة من المقابلة وتم تعييني فقط بسبب المحادثة الهاتفية اللاحقة.يرجى ملاحظة أن نتائجي الضعيفة تشير فقط إلى مقابلات البرمجة ، وليس الأجهزة. أنا جيد حقًا في إجراء مقابلات معكم عن الحديد ، رغم أنني لم أمارس هذا العمل منذ فترة طويلة. يقول أحد أصدقائي إن المقابلات مع الأجهزة جيدة جدًا بالنسبة لي بسبب المصطلحات المحددة: "أتحدث كمهندس أجهزة" وفي الحقيقة نتحدث نفس اللغة مع مهندسين إلكترونيين. من ناحية أخرى ، نقول بعض الأشياء بطريقة تجعلها غبية بشكل لا يصدق بالنسبة لمعظم المبرمجين ، لكن المشكلة تكمن في المفردات والمصطلحات وليس بالمعرفة أو المهارات الفعلية. [عودة]3. هذا السؤال أكثر تعقيدًا بقليل مما كنت تتوقعه عن طريق الهاتف ، ويمكن توقع مثل هذا السؤال في مقابلة شخصية. على الرغم من أن صديقي في مقابلة هاتفية مع Google سُئِل ذات مرة سؤالًا من نهائيات Google Code Jam World Finals ، لذا فإنه لأقصى درجة من التعقيد ، لا يوجد حد فعليًا ، بناءً على من يسألك.بالمناسبة ، إذا كنت مهتمًا ، فقد عرف صديقي الإجابة بالفعل ، لأنه حل هذه المشكلة في Google Code Jam. في المسابقة ، لم يجد الإجابة الصحيحة ، لكنه بدا لاحقًا للمتعة. ومع ذلك ، لم يعتبر من المعقول الإجابة فورًا عبر الهاتف ، لكنه طلب من القائم بإجراء المقابلة طرح سؤال آخر. لقد رفض ، لذلك فشل صديقي في مقابلة عبر الهاتف. على الرغم من أنني أشك في أن هناك أكثر من مئتي شخص في العالم يمكنهم الإجابة عن هذا السؤال بشكل صحيح عبر الهاتف ، وربما يفهم جميعهم تقريبًا عبثية الموقف. بعد فشله في المقابلة ، كان صديقي يبحث عن عمل لمدة نصف عام تقريبًا قبل بدء مقابلة لبدء التشغيل ، والتي طور في النهاية العديد من الأنظمة الرئيسية (من حيث التأثير على الأعمال والصعوبات الفنية). يواصل العمل هناك بعدكيف أجرت الشركة الاكتتاب العام بأكثر من مليار دولار. تتفهم الشركة مدى صعوبة استبدال هذا الشخص وتعامله جيدًا.[العودة]4. بالإضافة إلى المشاكل المعمارية الصارخة التي تؤدي ببساطة إلى انخفاض في الخدمة ، هناك نقطة أخرى. غالبًا ما تحل الفرق مشكلات الأداء ببساطة عن طريق طلب موارد حوسبة إضافية. تحاول بعض الشركات التعامل بطريقة أو بأخرى مع هذا. سمعت أنه في Facebook ، تقوم العديد من الفرق التي تعمل على تحسين الكفاءة بإرسال تقرير إلى قسم خاص يسمح لها بحظر طلبات زيادة السعة إذا لاحظوا عدم كفاءة قصوى في الفريق يرفضون إصلاحه. لكنني شخصياً لم أحضر مثل هذه الشركات. حاولت Google حل هذه المشكلة باستخدام نظام ربط ، من بين أشياء أخرى ، عدد الموظفين بموارد الحوسبة ، لكنني سمعت أنه تم التخلي عنها في النهاية لصالح نظام أكثر تقليدية لسبب ما. [عودة]