كسرها: كيفية التعامل مع أي مشكلة مقابلة فنية

وصفة سهلة الاستخدام لمعرفة كيفية جعل أي مشكلة أكثر قابلية للإدارة.

1. عندما تحصل على السؤال (قبل كتابة سطر واحد من الكود)

أسهل طريقة للتأكد من فهمك للسؤال هو السير في حالات الاختبار.

الأشياء التي يجب توضيحها مع القائم بإجراء المقابلة:
ما هي المدخلات المتوقعة؟ ما هو الناتج المتوقع؟
أي افتراضات قد تكون لديكم حول بعض حالات الاختبار

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

فكر دائمًا في الطرق التي يمكنك بها حل المشكلة. هل هناك مشكلة أصغر وأسهل يمكنك حلها؟ وإذا كان الأمر كذلك ، كيف سيكون هذا الحل؟

2. كتابة الكود (وماذا تفعل إذا واجهتك مشكلة)

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

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

أثناء كتابة التعليمات البرمجية الخاصة بك ، تذكر:

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

حول التعامل مع هذا الصمت المحرج إذا واجهتك مشكلة أو تحتاج إلى بعض الوقت للتفكير ...

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

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

عادة ما يكون القائم بإجراء المقابلة في صفك ويرغب في رؤيتك تنجح - فقط تذكر ما إذا كان يعطيك تلميحًا ، ولا تتجاهله أبدًا!

3. مراجعة الحل الخاص بك وإضافة التحسينات

بمجرد الانتهاء من كتابة التعليمات البرمجية الخاصة بك ، تتبعها مع حالة اختبار للتأكد من أن برنامجك يتصرف بالطريقة التي تتوقعها.

في هذه المرحلة ، من الجيد مراعاة:

  1. حالات الحافة المحتملة التي قد تكون فاتتك
  2. أي إيقاف بسبب أخطاء واحدة (خاصة عند فهرسة أو استخدام حلقة)
  3. هل هناك أي تكرار في شفرتك يمكنك تنظيفه؟

أسئلة يجب طرحها عند محاولة التحسين:

  1. ما هو وقت التشغيل الحالي وتعقيد الفضاء؟
  2. هل هناك أي مجال للتحسين إذا كنت تستخدم بنية بيانات مختلفة أو تعديل النهج الخاص بك قليلاً؟

عند مراجعة الكود ، تذكر أنه من الممكن تمامًا أن تكون قد ارتكبت خطأً غير مقصود - حاول أن تتعقب برنامجك كما لو كان من عمل شخص آخر تشاهده للمرة الأولى!

التفاف كل شيء

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

للحصول على قائمة بالأسئلة ، وبنية البيانات ، والموارد اللازمة للمراجعة ، يمكنك الاطلاع على المزيد هنا: خطة لمدة 4 أسابيع للتغلب على المقابلة الفنية التالية

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

إذا كان هذا الدليل قادراً على مساعدتك بأي شكل من الأشكال ، فيرجى إرسال التصفيق أو اثنتين :) يعني ذلك كثيرًا بالنسبة لي - شكرًا لك ونتمنى لك التوفيق في رحلتك!