تحطيم أسطورة البرمجة التنافسية: لماذا قد لا تحتاج لتعلمها؟

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

ما هي البرمجة التنافسية؟

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

النظام المعيب في التوظيف التقني

النظام الحالي معيب حقًا. إليك مثال آخر من Hen-Wen يوضح هذه المشكلة:

هناك الكثير من الأمثلة التي يمكنني ذكرها. هل تعلم أن مبتكر Homebrew – مدير الحزم الذي يستخدمه تقريبًا كل من يعمل بنظام macOS – تم رفضه في إحدى الشركات الكبرى؟ وماذا عن مبتكر WhatsApp؟ لقد تم رفضه من قبل Facebook و Twitter. فما الذي يحدث هنا؟ هل هؤلاء الأشخاص غير مؤهلين بما يكفي للعمل في هذه الشركات متعددة الجنسيات (MNCs)؟

الجواب هو لا. هؤلاء المطورون قادرون على تطوير أدوات مفيدة وكتابة برمجيات رائعة بجودة code عالية المستوى، لكنهم على الأرجح يفشلون في (إعادة) اختراع خوارزمية لعكس شجرة ثنائية (binary tree) في غضون 30 دقيقة. بعض من أفضل الأكواد البرمجية التي كُتبت على الإطلاق لم تُكتب في 30 دقيقة. بعض من أفضل الخوارزميات المستخدمة في نواة Linux kernel حتى اليوم لم يكتبها Linus في 30 دقيقة. بعض من أفضل واجهات المستخدم (UIs) مثل Stripe لم تُصمم في 30 دقيقة. فكيف يمكن لموظف موارد بشرية (HR) عشوائي في شركة عشوائية أن يقرر قيمتك في 30 دقيقة؟

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

البرمجة التنافسية ليست هي البرمجة الواقعية

مقابلات العمل في الشركات أشبه بامتحان يجب عليك فيه حفظ وتعلم أشياء لن تستخدمها بعد الحصول على الوظيفة. قد تعتقد أنك بحاجة إلى تعلم خوارزمية Dijkstra's algorithm للعمل على Google Maps، ولكن بجدية، هل تعتقد أن Google ستسلم أحد منتجاتها الأساسية لشخص جديد في الشركة؟ هل تعتقد أنك لن تحصل على أي مساعدة من زملائك؟ على الأرجح ستعمل على واجهة المنتج، أو أنظمة موزعة (distributed systems) بدلًا من العمل على إحدى خوارزميات Google الأساسية. هذا يعني أن كل معرفتك بـ«البرمجة التنافسية» لا فائدة منها.

لن تجد أي استخدام تقريبًا للبرمجة التنافسية في العالم الحقيقي. لا توجد خوارزمية تعمل على خوادم Microsoft الإنتاجية مكتوبة بـ code غير قابل للقراءة، بأسماء متغيرات (variable names) قصيرة وعديمة المعنى، وغير موثقة (undocumented) ومُحسّنة فقط للسرعة وليس للقراءة أو الصيانة (readability or maintenance). يأتي تصغير الكود (Minifying) وتحسين الأداء (performance improvement) لاحقًا، وغالبًا ما يتم ذلك باستخدام أدوات آلية. على الأرجح، إذا كنت مبرمجًا تنافسيًا، فقد طورت عادة سيئة تتمثل في كتابة code قبيح. يمكن لأي شخص كتابة code للآلات. السؤال هو: هل يمكنك كتابة code للبشر؟

بارقة أمل: الطريق البديل للنجاح

الجلوس في مقابلات كهذه والأمل في أن تتمكن من حل سؤال نظري تدربت عليه لمدة 3-5 أشهر، متعلمًا فقط هياكل البيانات والخوارزميات (DSA) والبرمجة التنافسية، هو أحد الطرق. ولكن هناك طريقة أخرى – ستعمل مع عدد أقل من الشركات والأشخاص، لكنك ستستمتع بها وتتعلم الكثير من الأشياء الواقعية على طول الطريق. ستكون أيضًا أكثر فائدة من أولئك الأشخاص الذين يتعلمون «البرمجة التنافسية» لمجرد التعلم.

1. ابنِ شيئًا: أي شيء، ثم ابنِ المزيد فوقه.
2. امتلك محفظة أعمال قوية: (portfolio) تعرض مهاراتك.
3. امتلك مجموعة مهارات كاملة: تكون مفيدة للشركات.
4. أتقن حزمة تقنية معينة: (tech stack) كن خبيرًا فيها.
5. اعرض مشاريعك ومدوناتك وخبراتك: لتثبت أنك ما هو مكتوب في سيرتك الذاتية.
6. ابنِ علاقات وشبكات: مع الناس، واطلب توصياتهم.

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

لا تخلط بين هياكل البيانات والخوارزميات (DSA) والبرمجة التنافسية

لم أكن أرغب في كتابة هذا القسم في البداية، لكنني علمت أن الكثير من الناس سيخلطون بين الأمرين. DSA – هياكل البيانات والخوارزميات (Data Structures and Algorithms) – شيء مختلف. Heap، Maps، Arrays، Vectors، Linked Lists، وما إلى ذلك، كلها مفيدة جدًا في البرمجة الواقعية أيضًا. الجزء الممتع هو أنه يمكنك تطوير هذا الفهم من خلال الخبرة أيضًا. لم أتعلم صراحة عن «heap» باستخدام دورة DSA كبيرة مدتها 50 ساعة. وإذا كنت تتعلم البرمجة، فلن تحتاج إلى فهم عميق جدًا لذلك أيضًا. DSA بعمق مطلوب عندما ترغب في تعلم علوم الكمبيوتر (computer science)، وليس البرمجة (programming). افهم الفرق، علوم الكمبيوتر هي النظرية – البرمجة هي التطبيق العملي. كن على دراية بالأشياء الموجودة، والخوارزميات الموجودة، وهياكل البيانات الموجودة. لا تحتاج إلى تعلمها أو حفظها كلها. يبدو لي غبيًا بشكل لا يصدق أن أحفظ أو أتعلم شيئًا نادرًا ما يستخدم عندما يمكنني الحصول عليه بقليل من المساعدة من الزملاء والإنترنت.

قصتي الشخصية مع البرمجة التنافسية

أنا لست مبرمجًا تنافسيًا، وربما أنا طالب علوم الكمبيوتر (CS undergrad) الوحيد في جامعتي الذي لم يلمس البرمجة التنافسية في الكلية. لماذا؟ لأنني جربتها قبل 4-5 سنوات وكرهتها. لماذا؟ لأنني رأيت نفسي أقضي 3-5 ساعات من يومي، كل يوم، في حل مشاكل لم تجلب لي شيئًا. كنت أعرف شيئًا أو اثنين عن كيفية التعامل مع السؤال التالي، ولكن هل كان ذلك كافيًا لإحداث تأثير؟ هل كان ذلك كافيًا للتميز عن الحشد؟ ما الخير الذي كنت أفعله؟ شعرت وكأنني أضيع وقتي في أسئلة تم حلها بالفعل. قد يختلف الأمر بالنسبة للجميع، لكنني سعيد عندما أرى أشخاصًا آخرين يستخدمون الأشياء التي برمجتها (بدأت كمطور ويب web developer بحلول ذلك الوقت). لم أستطع تحمل إضاعة وقتي في تعلم شيء لن أستخدمه أبدًا في العالم الحقيقي.

اعتدت المشاركة في Google's Code Jam و Facebook's Hacker Cup في الماضي. لكن سرعان ما شعرت بالملل والإحباط، لعدم وجود كلمة أفضل، ولم أعد إليها أبدًا. لم يكن الحصول على وظيفة أو تدريب داخلي يقلقني، ولم يقلقني أبدًا. جلست لإجراء مقابلات Google مرة واحدة في الحرم الجامعي. كان لديهم جولة فرز السير الذاتية كجولة أولى، على عكس جميع الشركات الأخرى حيث كانت الجولة الأولى، انتظروا، جولة برمجة تنافسية. حسنًا، ذهبت سنوات خبرتي السبع في تطوير الويب والأنظمة أدراج الرياح. على أي حال، بالنسبة لـ Google، كنت الشخص الوحيد الذي تم اختياره بسجل أكاديمي (GPA) قدره 7.5 (أعلى GPA هو 10 في الهند). كان بقية الـ 10-15 شخصًا فوق 8.5 أو 9. لم أتجاوز الجولة التنافسية مرة أخرى، لكن ذلك علمني أنه من الممكن اختراق الجولة الأولى لشركة مثل Google بمجرد سيرتك الذاتية. لذلك، من المهم العمل على ذلك.

الخلاصة

باختصار (TL;DR) – لست بحاجة إلى تعلم البرمجة التنافسية للنجاح في الحياة. تحتاج إلى تعلم شيء تحبه كثيرًا لدرجة أنك تتقنه، وتصبح لا تُقهر في مجالك. هذا كل ما في الأمر. هل لديك آراء ووجهات نظر؟ تواصل معي على Twitter و Instagram ودعنا نتحدث!

الخلاصة التقنية

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