مهندس كبير في البحث عن عمل. حول المهام في المقابلات الفنية والأسئلة النظرية

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

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

مناقشة بنود الاختبار المكتملة

في الجزء الأخير ، وصفت كيف أنجزت مهمتي اختبار: الأولى في DevOps Engineer ، والثانية في Ruby Developer. سأخبرك بما حدث بعد ذلك.

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

مقابلة مع DevOps Engineer - نظر القائم بإجراء المقابلة في المهمة ، وأثنى عليه (قلت أنني أكملت ذلك من الناحية النوعية) وطرح بعض أسئلة التحكم على الحل: لماذا هذا الخط هنا؟ إذا قمت باستبدال الشرط بهذا ، في أي ملف ستحتاج إلى القيام بذلك؟ لماذا يتم استخدام هذا النهج هنا؟ و هكذا. كما أخبرني المجند ، بعض المرشحين لم يؤدوا مهامهم بمفردهم ، ولم يتمكنوا من الإجابة على مثل هذه الأسئلة. لذلك ، هنا تمكنت من دون مشاكل.

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

مقابلة المهام

نواصل موضوع مهام الاختبار من الجزء السابق وننظر في مهام الترميز في المقابلات.

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

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

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

محدث: أثناء ترجمة المقال ، أضاف repl.it وضع Multiplayer ، والذي يسمح لعدد غير محدود من المشاركين بالعمل في نفس الوقت مع الكود. خالية تماما! لم تعد هناك حاجة CoderPad ، هتافات!

أجريت مقابلة مع الشركة لشغل وظيفة Java Developer . تقوم الشركة بشيء مثل CRM وتكتب مجموعة من عمليات الدمج. اتصلت بأخصائي تقني Zoom وقال: "لنبدأ بمشكلة الخوارزمية". أجيب: "حسنًا ، سأقوم بالمهمة ، لكن لدي سؤال: هل تحتاج إلى هذه المعرفة في عملك ، هل تحتاج إلى حل أشياء مماثلة؟" التي حصلت على إجابة هائلة: "نكتب نقاط نهاية للراحة ونقود json-chiki ذهابًا وإيابًا ، لكن ليس من المثير للاهتمام التحدث عن ذلك ، لذلك دعونا نحل المشكلة." وهذا هو ، اعترف المقابلة نفسه لعدم الكفاءة. لا أعرف من كيف ، لكن منذ تلك اللحظة أدركت أنه لن يكون لدي شيء لألحق به هناك. ومع ذلك ، بدافع الاهتمام بالرياضة ، استمرت المحادثة.

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

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

لذلك ، كتبت على الفور الاختبارات وبدأت في التبييض باستخدام مؤشرات i و j و k :) حلقات في حلقات ، وما إلى ذلك. بعد 15-20 دقيقة كان لدي حل نصف العمل ، لكن الحالات الحدودية التي قدمها القائم بإجراء المقابلة لم تمر. استغرق 20 دقيقة أخرى منهم ، في النهاية ، ما زلت إكمال المهمة بشكل صحيح. بدا الشخص الذي أجرى المقابلة راضياً ، ثم بدأ يسألني عن هياكل البيانات. اتضح أنه لحل المشكلة التي أراد أن يقدمها في البداية ، سيكون من الممكن استخدام علامة التجزئة ، أو شيء من هذا القبيل ، وتوقع مثل هذا الحل فقط ، لكنني كسرته جميعًا.

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

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

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

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

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

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

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

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

كانت المهمة مرتبطة بـ I / O - كان من الضروري إنشاء واجهة برمجة تطبيقات لكتابة البيانات إلى ملف على القرص ، بحيث كان كل شيء آمنًا وسريعًا ، وكذلك كتابة اختبارات وحدة من شأنها التحقق من ذلك (بما في ذلك أمان سلاسل الرسائل). لم أعمل مع التزامن و I / O لفترة طويلة ، لذلك اضطررت للذهاب بسرعة عبر الاحواض وتذكر ما كان يحدث. كتبت حلاً في الجبهة ، وتأكدت من أنه آمن للخيط وما إلى ذلك. استغرق كل شيء عن كل شيء لي حوالي ساعة ونصف. أتعرض للضرب من مجري المقابلة ، قلت إنني مستعد ، لكن لم يكن هناك سوى شيء واحد صغير لتلميعه ، هل سننظر؟ أجاب على هذا: "لنجلس لمدة نصف ساعة أخرى وننهي كل ما لم تكمله". حسناً ، جلست ووضعت في ذهني كل الأشياء الصغيرة والخشونة ، أنهيت javadki ، ومرة ​​أخرى قرأت كل ما يمكنني فعله حول I / O وفكرت فيما يمكن أن يكون عيوب الحل.

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

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

ما كان جيدا في هذه المهمة؟

• القرب من العمل الحقيقي ، إلى ما يفعلونه في تلك الشركة.
• المهلة
• عدم المراقبة.
• القدرة على استخدام أي شيء وليس فحص الذاكرة.
• إنشاء أساس لمزيد من المحادثة.
• اختبار مهارات المرشح للترميز ، واستخدام IDE والتفكير بشكل عام.

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

أوجه القصور النموذجية في مهام المقابلة

1. المهمة لا علاقة لها بالعمل الحقيقي. يزعجني أكثر. يُسمح للخوارزميات بحلها ، على الرغم من أن الأكوام في الواقع تنصب. دعونا المهمة ذات الصلة ، سأفعل لك الخام! لماذا تحتاج إلى شخص يعرف كيفية البحث عن سلاسل في الأوتار؟
2. التنظيمية - في كثير من الأحيان لا توجد أداة طبيعية للحل. بمجرد أن أظهروا لي الكود في مستندات جوجل ، بمجرد تخبطت الشاشة في repl.it ، مرة واحدة كان CoderPad.
3. لا تخلق المهمة سياقًا لمزيد من المحادثات - وهذا نتيجة للفقرة الأولى. لماذا تعطي مهمة إذا لم نناقشها لاحقًا؟
4. لا يمكن لجميع الناس التعامل مع المهمة تحت الإشراف. تبعا لذلك ، يمكن القضاء على مرشح جيد في هذه المرحلة.

أسئلة نظرية

هذا هو الجزء المفضل لدي. الجميع يحب نظرية الطلب ، دعنا نذهب إلى هذا قليلا.

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

كانت المقابلة الأولى التي ذهبت إليها كمطور لـ Ruby هي المكان الذي يجب أن تتم فيه مهمة الاختبار ، ولكن ، كما اتضح فيما بعد ، لم يكن أحد مهتمًا بذلك. لم يحضر Timlid ، الذي كان من المفترض أن يتواصل معي ، (لقد كان عالقًا في ازدحام مروري أو شيء ما) ، لذا أعطوني واحدة أخرى. بعد الاجتماع ، يقول: "لدي قاعدة - أجري جميع المقابلات باللغة الإنجليزية ، لذلك نتحول إلى اللغة الإنجليزية." وبعد ذلك يتم لف أذني في أنبوب نانوي للجرافين ، لأن للمقابلة لهجة قوية جدًا. هذا ما أزعجني إلى حد ما (من الصعب جدًا عليّ التواصل مع رفاقي باللغة الإنجليزية).

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

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

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

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

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

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

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

لذا ، رفضوني لأنني لم أعرف أساسيات اللغة (روبي). حسنا ، دعنا ننتقل.

مقابلة أخرى في روبي Debeloper ، واثنين من المقابلات بالفعل. من الجيد أن يتحدث شخص واحد على الأقل بالروسية ، والثاني - باللغة الأوكرانية ، لذلك لم أضطر إلى كسر ذهني. لدهشتي ، تبدأ القصة نفسها: ما هي الوحدات ، ما هي الكتل. لم أقرأ الكتاب المدرسي بعد ، لذلك سبحت مرة أخرى في الإجابات. طلب مزيد من المعلومات حول أنواع الجمعيات في Rails. «- -», — , . ( ), , : « ». , — each_slice. , , . : « , - Rack middleware?». , . , , ( Java Servlets, middleware - Laravel/Express), . , .

, , . . , , rack middleware, , .

. — . , , , , …

Ruby Developer. , . , , . Proc, , :) : « , , , - ». 100% , - , . .

: « require». Rails Grape, , , . « , ». , . - -, « , ?». ActiveRecord — , .

concurrency ( ). , concurrency Ruby — . , , . , MRI — JVM , volatile synchronized , . , , ( !) concurrency . ? ?

, - SOLID. , « — », . , . , . - , . , « ». .

? . , , , . , ! ( ). , , Cracking Ruby Interview, . , - «» , , , :)

.

Fullstack Java Developer. — . , . , , Java.

, , , - . , , , , . , , .

. . , , , undefined null, var. JS WAT-. : «, WAT . , , , ». , -. «JavaScript: The Good Parts», .

, , . (?) , ( , ) , . . , :)

- , , . jQuery, . :)

DevOps Engineer , . : « ?». - :) , , — . , . , , , . . ( )?

( MVC). (-) 5-10 . ( GoF) . . Ruby-, , — , , ( MVC ActiveRecord ). Java- .

SOLID , , : Ruby-, — Java. DRY :)

?

1. , .
2. , .
3. , .
4. , .

, , :

• / . , . : « -AOP AspectJ Spring?» :) , , .
• LeetCode , .

, , . , , « » , .

( , ), , !