كيف يمكنني أن أفقد قلة خبرتي في تطوير الويب على نطاق واسع في المقابلات الوظيفية الكاملة لتطوير الويب؟


الاجابه 1:

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

غالبًا ما يتم تعيينك في فريق وستجد مساهمتك ، بناءً على ما ليس لدى الأشخاص الآخرين الوقت للقيام به ، أو أنهم يفضلون عدم القيام به.

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

الفرق بين تطبيق ويب واسع النطاق وإثبات سريع للمفهوم هو:

  • استخدام اختبارات الوحدة
  • المراقبة
  • devops
  • مشاكل محددة على أساس الحجم أو التعقيد

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

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

خلاصة القول ، يريد مدير التوظيف مطورًا مكتفيًا ذاتيًا عندما يطلب مطورًا متكاملًا.


الاجابه 2:

هاها! نوع سؤالي!

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

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

حقيقة

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

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

لا أوصي بقاعدة بيانات NoSQL مثل مونغو لأن معظم المنظمات تريد أن تعرف أنه يمكنك التعامل مع مفاهيم مثل تطبيع قاعدة البيانات.

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

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

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


الاجابه 3:

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

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

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

حظا سعيدا.