كيف تجتاز الاختبار التقني في شركات الخليج
الاختبارات التقنية في شركات الخليج تختبر أكثر من الكود. كيف تتحضر للشكل الصح وتتجنب الأخطاء الشائعة وتقدم تسليمًا يلفت الانتباه.
افتراضيًا، الاختبار التقني يشبه امتحان الجامعة. تحفظ data structures لثلاثة أيام، تسلّم أول حل يشتغل، وبعدين تتساءل ليش الـ recruiter من Noon أو الفريق الرقمي في أرامكو ما رجع عليك. المشكلة مو في الكود، المشكلة في طريقة التفكير.
الاختبارات التقنية في شركات الخليج مو مجرد اختبار تعرف JavaScript أو لا. هي صورة مصغرة لأسلوب شغلك: تقرأ التعليمات بدقة؟ تكتب كود شخص ثاني يقدر يفهمه؟ تشرح القرارات اللي اتخذتها؟ تتعامل مع الحالات غير المتوقعة؟ الشركات تستخدم الاختبار عشان تفلتر على مستوى الحكمة الهندسية، مو بس الصنتاكس.
نفس نمط الفشل يتكرر في شركة بعد شركة. هذا اللي يتم تقييمك عليه فعلًا، والأخطاء اللي تُخرج المرشحين ذوي الخبرة قبل ما يوصلون لأول مقابلة.
ما هو الاختبار التقني في وظائف التقنية بالخليج؟
الاختبار التقني هو تمرين منظم يصممه المُقيِّم عشان يفلتر المرشحين على أساس المهارة التطبيقية قبل أي مقابلة مباشرة. في شركات الخليج، من Tabby وTamara في الـ fintech السعودي لـ STC وهيئة البيانات SDAIA في الاتصالات والقطاع الحكومي الرقمي، الشكل يختلف بشكل ملحوظ عن الشركات الغربية. قد تواجه اختبار كود محدد بوقت على HackerRank أو Codility، take-home project لمدة يومين أو ثلاثة، جلسة pair-programming مباشرة، أو تمرين system design عبر الفيديو. بعض الشركات تمر بنوعين أو ثلاثة من هذه الأشكال قبل ما تكلم hiring manager.
اللي لازم تفهمه: الاختبار مو مجرد "الكود يشتغل أو لا". يُقيَّم على مطابقة الـ spec، قابلية الصيانة، التعامل مع edge cases، وتوضيح الـ trade-offs. كثير من المرشحين يعدون الفلتر الأول ويفشلون في الثاني.
وفق تقرير HackerRank لعام 2024، 72% من فرق الهندسة حول العالم تستخدم اختبارًا تقنيًا كأول فلتر. الشركات الخليجية في نفس النهج، مع إضافة مهمة: الاختبارات هنا كثيرًا ما تشمل سيناريوهات اللوكلايزيشن، التعامل مع اللغة العربية، وسيناريوهات الدفع الإقليمية اللي التحضير الغربي التقليدي ما يغطيها.
هذا الملخص قبل التفصيل:
أكد الشكل قبل ما توصلك الاختبار، معظم الاختبارات التقنية في الخليج تقع في 4 أنواع: اختبار كود محدد بوقت، take-home لعدة أيام، جلسة pair-programming مباشرة، أو تمرين system design. راسل الـ recruiter بيوم قبل واسأل أي نوع تتوقعه وإذا في لغة أو stack مفضلة. أغلبهم يجاوبونك. اقرأ الـ brief كاملًا قبل ما تكتب سطر كود واحد. mismatches في الـ spec تُفلتر تلقائيًا قبل ما يشوفها أي مراجع. اكتب كود مقروء: أسماء متغيرات واضحة، functions لكل خطوة منطقية، edge cases توثقها. في أي take-home، اكتب README من 200 إلى 400 كلمة يشرح افتراضاتك وقراراتك. شركات الخليج تختبر سيناريوهات إقليمية، اللغة العربية، واجهة RTL، طرق دفع سعودية، اللي التحضير الغربي ما يشملها. سلّم قبل الـ deadline بساعتين على الأقل.
هذا هو الإطار العام. الباقي هو التفاصيل.
هل تتحضر للنوع الصح من الاختبار؟
الطريقة الغلط: تفترض إنه اختبار خوارزميات محدد بوقت، تقضي وقت التحضير تحل مسائل LeetCode. يجيك link لـ take-home لمدة 48 ساعة وتحس إنك ما عندك استعداد لبناء feature كاملة.
الطريقة الصح: قبل ما يوصلك الاختبار، راسل الـ recruiter. "هل هو محدد بوقت أو مفتوح؟ اختبار كود أو project؟ في لغة أو stack مفضلة؟" أغلب الـ recruiters يجاوبون. مسار Careem الهندسي المعتاد مثلًا يبدأ بجلسة HackerRank لمدة 60 دقيقة تركز على data structures، ثم ينتقل لـ take-home system design. معرفة هذا تغيّر كيف تُوزع وقتك في الأيام الأربعة اللي قبل وصول الاختبار.
تأكيد الشكل قبل استلام الاختبار هو أقل الاستراتيجيات استخدامًا في التوظيف التقني بالخليج. كثير من الشركات، خاصة المرتبطة بالحكومة كـ SDAIA والجانب الرقمي في سابك ومسار التوظيف الرقمي في أرامكو، تستخدم منصات داخلية أو خاصة. الدخول بدون معرفة الشكل يهدر أول 15 دقيقة.
التحضير يختلف بحسب النوع. للاختبار المحدد بوقت: تدرب تحت ضغط حقيقي بساعة تعد. للـ take-home: تدرب على هيكلة project وكتابة README وعمل commits نظيفة. لجلسة pair-programming: تدرب على شرح تفكيرك بصوت عالٍ بدل الحل بصمت. هذه مهارات مختلفة تحتاج تحضيرًا مختلفًا، والمرشحون اللي يخلطون بينها يُسيئون الأداء بانتظام على النوع اللي ما تحضروا له.
هل تقرأ الـ brief بشكل كامل؟
الطريقة الغلط: تتصفح المشكلة في 90 ثانية، تبدأ الكود فورًا، وتكتشف بعد 45 دقيقة إنك فهمت الـ output format غلط. تسلّم كود محكم تقنيًا لكنه ما يطابق الـ spec.
الطريقة الصح: خصص 10-15% من إجمالي وقتك للتحليل قبل الكود. للاختبار المحدد بوقت: اقرأ الـ brief كاملًا، علّم على edge cases، واكتب فهمك للـ inputs والـ outputs المتوقعة بلغة عادية أولًا. للـ take-home: قسّم المشكلة لمشاكل فرعية، ووثّق افتراضاتك في الـ README قبل ما تفتح code editor.
سيناريو حقيقي: مرشح قدم لـ backend role في SDAIA بحل Redis-based للـ caching كان متين هندسيًا. الـ spec كان يشترط database-persisted TTLs لمتطلبات التدقيق، شرط شائع في التقنية الحكومية السعودية حيث يهم مسار البيانات لأسباب تنظيمية. المرشح استخدم in-memory TTLs. التسليم تم فلترته تلقائيًا قبل ما يشوفه أي مراجع.
قراءة الـ brief كاملًا قبل لمس الكيبورد هو أعلى استثمار في أي اختبار تقني. لا يوجد تنفيذ ذكي يتعافى من حل المشكلة الغلط. الفلتر يمسك mismatches في الـ spec قبل تقييم جودة الكود، يعني كود ممتاز يفشل على أكثر خطأ يمكن تفاديه في العملية كلها.
هل الكود بتاعك مقروء مو بس شغّال؟
الطريقة الغلط: تكتب كود يعدي كل الـ tests. أسماء المتغيرات a، b، tmp2. الـ function الرئيسية 140 سطر. ما في comments. تسلّم لأنه يشتغل.
الطريقة الصح: صح ومقروء، بهذا الترتيب. في شركات الخليج، خاصة SDAIA وسابك الرقمي والجناح التقني في الراجحي، المقيِّم كثيرًا ما يكون senior engineer قد يصبح مديرك المباشر. يقرأ الكود وكأنه هو اللي راح يرثه. استخدم أسماء متغيرات تُوضح القصد. اكتب function واحدة لكل خطوة منطقية. أضف comments بس حيث المنطق سيُفاجئ قارئًا قادمًا.
استطلاع Stack Overflow للمطورين عام 2023 وجد إن 71% من المطورين يقضون وقتًا أكثر في قراءة الكود من كتابته. المقيِّم اللي يراجع تسليمك يعيش في هذا الواقع. كود غير مقروء لكنه صحيح يُقرأ على أنه "هذا الشخص ما يفكر في الفريق." كود مقروء وصحيح هو اللي يوصلك للجولة التالية.
هذا الفرق أكثر أهمية في شركات الخليج حيث الفرق الهندسية متعددة اللغات والكود يُصان عبر سياقات تنظيمية مختلفة. مقروئية الكود جزئيًا مهارة تواصل، مو بس مهارة تقنية. المُقيِّم في شركة مرتبطة بالحكومة السعودية يقرأ أسماء المتغيرات وهيكل الـ functions ويسأل: هل أرتاح لإدخال هذا الشخص في code review أمام الفريق؟
إيش اللي تختبره شركات الخليج ومو غيرها؟
هذي النقطة اللي تقبض على المرشحين اللي عملوا اختبارات تقنية غربية وافترضوا إن التجربة تتنقل مباشرة. شركات الخليج تُضمّن سياق منتج إقليمي في الاختبارات، والتفاصيل قابلة للاختبار.
| الجانب | شركات الخليج | شركات تقنية أمريكية/أوروبية |
|---|---|---|
| اللغة العربية وواجهة RTL | شائع للأدوار الأمامية والمنتج | نادر |
| تنسيق العملة (ريال/درهم) | شائع في fintech والتجارة الإلكترونية | لا |
| مسارات الدفع الإقليمية (mada، STC Pay) | Tabby، Tamara، Noon | لا |
| ردود API ثنائية اللغة | أحيانًا مطلوبة | نادر جدًا |
| التركيز على الأمن والامتثال | عالٍ للأدوار الحكومية والمالية | يتفاوت |
| تعقيد الخوارزميات المجردة | أقل شيوعًا من FAANG | شائع في FAANG |
| منصات داخلية خاصة | أرامكو، SDAIA | نادر |
اختبار product engineer في Noon قد يشترط التعامل مع تنسيق اللغة العربية وـ pagination بـ RTL وقواعد تقريب الدرهم في نفس الوقت. إذا كنت تتدرب فقط على تمارين باللغة الإنجليزية، راح تقلل من نطاق ما يُختبر.
أسرع طريقة لبناء السياق الإقليمي هي استخدام المنتجات نفسها. افتح Noon بالعربية. تجول في checkout الخاص بـ STC Pay. تصفح خدمة BNPL في Tabby من جوالك. راح تلاحظ edge cases المُقيّمون بنوها مسبقًا في الـ rubric.
بعض الأدوار في القطاعات المرتبطة بالحكومة تتوقع كذلك وعيًا بمتطلبات تخزين البيانات المحلية السعودية وأولويات رؤية 2030 الرقمية. هذا يظهر كقيود في تمارين system design، مو كأسئلة معلومات عامة. المرشح اللي يأخذ بعين الاعتبار متطلبات إقامة البيانات بدون ما يُطلب منه يُشير تحديدًا لنوع الحكمة السياقية اللي هذه الشركات تريدها.
كيف ترتب التسليم عشان تبرز؟
الطريقة الغلط: تضغط ملفاتك في zip، تكتب "هذا التسليم" في الإيميل، وترسل.
الطريقة الصح: لأي take-home، اكتب README من 200-400 كلمة يشمل أربعة أشياء: الافتراضات اللي اتخذتها، ما الذي كنت ستفعله مع وقت أكثر، ما الذي اختبرته وكيف، والـ trade-offs في نهجك. في جلسة pair-programming، قل هذه الأشياء بصوت عالٍ وأنت تشتغل بدل انتظار السؤال.
المُقيِّمون في Tabby وTamara، فنتك سعوديان بفرق هندسية صغيرة، ذكروا إنهم يقرأون الـ README قبل تشغيل الكود. المرشح اللي يكتب "اخترت Redis للـ session storage لأنه يتعامل مع TTL بشكل native؛ كنت أضيف Postgres persistence للجلسات طويلة الأمد في production حيث تهم سجلات التدقيق" يبدو كشخص نشر software حقيقي. الـ README الجيد يحوّل تنفيذًا بدرجة B إلى إشارة مرشح بدرجة A.
الـ README كذلك يعطيك نقاط حوار طبيعية في المقابلة التالية. المُقيِّم اللي قرأ منطق قراراتك قبل الاجتماع راح يسأل عنها. هذا فرصة مو فخ، يحوّل الـ take-home لـ portfolio piece تقدمه بثقة بدل محاولة إعادة بنائه تحت الضغط.
قائمة التحقق قبل التسليم
قبل ما تضغط submit، اشتغل على هذه القائمة بالترتيب:
- أعد قراءة الـ brief الأصلي وتأكد من تغطية كل متطلب
- شغّل الكود من الصفر في بيئة نظيفة
- كل أسماء المتغيرات والـ functions واضحة وتوضح القصد
- لا debug logs ولا تعليقات TODO ولا stubs متبقية
- الـ edge cases معالجة أو موثقة في الـ README
- الـ README يشرح الافتراضات والـ trade-offs
- للأدوار الأمامية: اختبرت على mobile viewport وـ RTL locale إذا كان ذا صلة
- أنت تسلّم النسخة الصحيحة والأحدث من ملفاتك
- تسلّم قبل الـ deadline بساعتين على الأقل
البند الأخير أهم مما يبدو. المنصات الآلية في بعض شركات الخليج ترفض التسليم المتأخر تلقائيًا دون مراجعة بشرية. في شركات أخرى، التسليم قبل دقائق من الـ deadline يعطي انطباعًا محددًا عن أسلوب عملك تحت الضغط. مرحلة التحقق قبل التسليم هي حيث يخسر المرشحون ذوو الخبرة نقاطًا ما كان ضروريًا خسارتها، مو في الخوارزمية، بل في الاحترافية اللي تشير لقدرتهم على العمل باستقلالية.
معظم المرشحين يتعاملون مع الاختبار التقني كحاجز للعبور. اللي يتقدمون يتعاملون معه كأول فرصة يُظهرون فيها نوع المهندس اللي هم عليه. وضّح الشكل مبكرًا، اكتب كودًا يقدر شخص ثاني يرثه غدًا، وسلّم README يثبت إنك فكرت ما وراء حالات الاختبار. هذا هو المعيار اللي صممنا جلسات IntervYou التجريبية التقنية عشان تحاكيه.
مقالات ذات صلة
مقالات ذات صلة
جاهز تتدرّب؟
بدل ما تقرأ عن المقابلات، ابدأ تتقنها. احصل على مقابلة وهمية بالذكاء الاصطناعي مصممة لدورك المستهدف — مجانًا بالكامل.
أو تصفّح الباقات والأسعارنصائح أسبوعية للمقابلات في الشرق الأوسط
استراتيجيات عملية للحصول على وظائف في أفضل الشركات في المنطقة.