ما هو أنا في حمض أو وجهة نظر مختلفة

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

للبدء ، سأخبرك عن نفسي. آمل أن يكون هذا يساعدك على فهم أفضل ما هو موضح أدناه. في تطوير البرمجيات لمدة 9 سنوات ، عمل لبعض الوقت لنفسه (أنشأ روبوتات تبادل وتداول بأمواله الخاصة) ، وكان في معظم الأحيان مطورًا مستأجرًا (بما في ذلك مطور رئيسي). لقد كنت مؤخرا في موقف البقالة. جمعت 2 فرق على مستوى كبار. أجرى عدة عشرات (وإن كان أقل من 100) من المقابلات الفنية في مواقع middle2s كبار ، كبار ، الرصاص. لم أعمل في الاستعانة بمصادر خارجية لمدة يوم في حياتي أمضى 18 يومًا. لذلك ، أستطيع أن أقول إن كل الخبرة مرتبطة بالمنتج (صاحب العمل أو صاحب العمل) ، وقد أجريت جميع المقابلات بدافع "العثور على الشخص الذي سيحقق أقصى فائدة للمنتج". أعترف أن تجربة مؤلف المقال الأصلي أكبر من تجربتي ، لكن الهدف من ذلك هو عدم إخبارك بكيفية القيام بذلك بشكل صحيح ، أو تقديم المشورة بشأن كيفية التصرف ، ولكن لتوضيح كيف يمكنك أن تنظر إلى نفس الأشياء من أخرى ، بديلة ، وليس حقيقة أنها صحيحة ، وجهة نظر.

دعنا نذهب على النقاط (الأسماء مأخوذة من المشاركة الأصلية).

لا أحد يهتم بك رمز

بادئ ذي بدء ، فإن السؤال هو ، ما هو الرمز الجيد وما هي التوقعات من الكود الذي ينتجه مبرمج متمرس. بالنسبة لي ، فإن الكود الجيد هو وظيفة للمهمة ، والظروف التي يتم فيها تعيين هذه المهمة ، والمبادئ التوجيهية المعتمدة في الفريق (الشركة) ، وتوقعات المدير الفني (المهندس المعماري) ، ومدير المنتج ، و QA الرصاص. على سبيل المثال ، ضع في اعتبارك العديد من المهام:

1. لتطوير واجهة برمجة التطبيقات لإصدارها لاحقًا لجميع عملاء الشركة البالغ عددهم مائة شركة لدمج المنتج في حلولهم - من المتوقع أن يتم التوصل إلى حل مدروس جيدًا وموثق جيدًا من خلال الهيكل الأكثر قابلية للفهم والامتثال للمعايير المقبولة في السوق والتأكد من صحة البيانات بشكل كامل وتغطية الاختبار الكاملة والتوسع المدروس وتسجيل التفكير المدروس ، الامتثال لجميع متطلبات الأمان ، والقابلية للتطوير في الأداء ، ومقاومة نماذج DoS و DDoS البدائية على الأقل ؛
2. لتنفيذ امتثال المنتج لمتطلبات المنظم ، والذي يسري مفعوله في غضون شهر واحد ، ويمكن أن يؤدي إلى إيقاف العمل بالكامل - من المتوقع إيجاد حل موثوق به مع التركيز على الاختبار ؛
3. إصلاح الخلل في المنتج المتعلق بالتخزين المؤقت ، والذي أصبح معروفًا قبل ساعة من يوم الجمعة الأسود ، من المتوقع أن يتم كتابة الحل ونشره على المنتج في غضون 30 دقيقة ولن يكسر أي شيء. متطلبات أخرى تذهب على جانب الطريق .
4. اختبر الفرضية التي تحتاج إلى تحليل 250 صفحة من موقع المنافس لمرة واحدة ، ثم قم بتكوين مستند جدول بيانات google لمحلل الأعمال - من المتوقع ألا يقوم المبرمج بالكثير من العمل ويكتب رمز للكتابة فقط دون إنفاق الكثير عليه الوقت
5. للتحقق من أداء Aerospike في مهمة يتم استخدام PostgreSQL لها بشكل تقليدي في الشركة ، وهناك مشاكل في الأداء ، من المتوقع أن تؤخذ الفروق الحسابية الخاطئة وملف تعريف التحميل في الاعتبار ، ولكن سيتم التخلص من جميع الكود بغض النظر عن النتائج التجريبية .

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

انتصار المعرفة التي لا قيمة لها

فهم ممتاز للسخط المرتبطة

وحقيقة أن البحث عن فهارس B-tree في PostgreSQL له تعقيد لوغاريتمي؟ لقد اكتشفت أمس ، والآن أنت كذلك

ولكن ماذا من ناحية أخرى؟ الأخطاء المتعلقة بالتعقيد الخوارزمي هي بعض من أكثر الأشياء غير السارة في الأعمال التجارية. لا يتم تغطيتها بواسطة اختبارات الوحدة (O (N ^ 2) أثناء التشغيل التجريبي ، حيث يكون N = 10 ، وهذا سريع حقًا) ، ولا يتم تغطيتها عن طريق الاختبارات التلقائية والتكامل والانحدار واليدوي لنفس السبب. لا يطفو على السطح عند dbe، uat، sit (بعد كل شيء ، بالنسبة لـ N = 1000 فإنه لا يزال سريعًا) يمكنهم الانتظار لسنوات لوقتهم ، وليس تذكير أنفسهم ، حتى يضيف عميل واحد 250 منتجًا إلى سلته ، أو حتى يظهر عميل لشركة وساطة يقرر تجميع روبوت HFT على ركبته. ولكن ، عندما تظهر ، قد يصيب العمل بأكمله.


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

ضربك

وهنا هو عليه. ويبدو أن الرجال كافية. التين فهم. ثم ترى أن الشغور مفتوح لمدة نصف عام. حسنا حسنا.

لا يعني وجود وظيفة شاغرة على موقع الشركة (أو في مجمع الوظائف) أن الشركة تبحث عن شخص واحد في فريق واحد. واقع شركات المواد الغذائية خلال النمو هو إضراب دائم عن الطعام. أو يمكنك التوسع أو الاستيلاء على السوق أو الضغط على المنافسين أو الموت. ومدير المنتج لديه صداع دائم - "ما يجب التخلص منه". ليس "لماذا تفكر في برنامج رائع حتى يتسنى لـ 100 مبرمج تنزيله لمدة شهر ، حتى لا تشعر بالملل" ، ولكن يجب عليك التخلص من العملاء اللطفاء والضروريين والمخططين والمتوقعين (والموعدين) من الخطط حتى لا تؤخر الإصدار التالي لمدة عام. لذلك ، لا توجد أيدي إضافية ، وحقيقة أن الوظيفة الشاغرة كانت معلقة لمدة ستة أشهر لا تلغي حقيقة أن 10 أشخاص قد عثروا عليها بالفعل واستعانوا بها ، وسيأخذون نفس الشيء بكل سرور. مرة أخرى ، ليس في كل مكان وليس دائمًا ، ولكن الموقف الذي وصفته طبيعي ومقبول لتطوير المنتج.

لا يهمني المشاريع السابقة

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

المطورين ذوي الخبرة

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

بعض الأفكار الإضافية

ولكن هنا يمكنك الخروج ، وإجراء اختبار صغير لمدة ساعة أو ساعتين (ليس فقط في المكان: بالنسبة للكثيرين ، لا تزال المقابلة ضغوطًا).

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

والأفكار حول تعليق مثير للاهتمام من لوبي

وإذا كانت هناك مشكلة لا أعرف الحل في الحال - فيمكنك دائمًا دراسة المشكلة وإيجاد هذا الحل.

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

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

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