مقابلة تصميم النظام

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

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

جمع المتطلبات الوظيفية وغير الوظيفية

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

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

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

ولكن مهما فعلت ، لا تغوص مباشرة في التصميم. اكتشف ما تصممه أولا.

تقديم حل شامل

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

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

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

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

استخدام المصطلحات المتوافقة مع معايير الصناعة

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

على سبيل المثال ، لا تتردد في تسمية Drop Kafka أو Amazon SQS إذا كان هذا هو ما تشعر بالراحة معه ، ولكن اذكر أنك تريد قائمة انتظار رسائل تم تكوينها كنظام حانة / فرعي. هذا النهج له العديد من المزايا:

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

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

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

اشرح المشكلات التي تحلها باختياراتك

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

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

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

كن مستعدا للتعمق في مجالات خبرتك

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

هل قلت إنك عملت على بنية دفق لمعالجة البيانات؟ يجب أن تكون قادرا على التحدث عن قوائم انتظار الرسائل ، وذكر تقنيات مثل Apache Spark أو Samza (أو أي تقنيات استخدمتها من قبل)، والمقايضات بين معالجة البث ومعالجة البيانات عبر الإنترنت أو دون اتصال بالإنترنت ، وما إلى ذلك. إذا كنت قد عملت على نطاق واسع مع تخزين البيانات ، فيجب أن تكون قادرا على التحدث عن التجزئة ، وخيارات قاعدة البيانات ، والتخزين المؤقت المستمر المستند إلى القرص مقابل التخزين المؤقت في الذاكرة ، وما إلى ذلك.

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

تحدث عن إنتاج النظام

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

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

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

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

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

تم نشر هذه المقالة في الأصل على موقع Hiring For Tech. إذا كنت ترغب في قراءة المزيد من المحتوى مني ، فيرجى الاشتراك إما عن طريق البريد الإلكتروني أو على LinkedIn. إذا كان لديك أي أفكار حول المحتوى الخاص بي ، فقم بالتعليق أدناه. ولا تنس ذلك اتبعني لمزيد من المحتوى!