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

لنفرض أنك مطور تخرجت قبل سنتين، وتعمل في وكالة صغيرة تبني مواقع ولوحات تحكم بـ Laravel وReact، ثم وصلتك رسالة من شركة تقنية مالية أكبر: «يسعدنا دعوتك لمقابلة وظيفة مطور Backend بمستوى متوسط، تبدأ بتقييم إلكتروني مدته 90 دقيقة، ثم ثلاث جلسات في يوم واحد بعد أسبوعين». وفي نفس الليلة تفتح الإنترنت فتجد قوائم «أشهر 500 سؤال في المقابلات»، وخطط استعداد مدتها ثلاثة أشهر، ونصائح متناقضة بين من يقول «حل 300 مسألة على LeetCode» ومن يقول «المسائل لا تفيد، ركز على مشاريعك»، والوقت المتاح لك ساعتان أو ثلاث بعد العمل كل يوم.

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

وسوف نناقش في هذا المقال ما يلي:

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

ماذا تختبر الشركات في مقابلة المطور؟

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

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

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

اقرأ الدعوة واسأل قبل أن تبدأ

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

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

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

قيم نفسك بصدق في ساعة

قبل أن تضع الخطة، اعرف أين أنت، والطريقة البسيطة أن تخصص ساعة في اليوم الأول لثلاثة أشياء: حل مسألة متوسطة واحدة بالوقت (35 دقيقة) دون أي مساعدة، ثم الإجابة بصوت مسموع عن ثلاثة أسئلة من مستوى «متوسط» في بنك أسئلة Backend أو Frontend أو الجوال بحسب وظيفتك، ثم كتابة قصة مشروعك الأخير في خمسة أسطر. والنتيجة تقول لك أين تضع الوقت: صاحبنا حل المسألة في 50 دقيقة بدلاً من 35، وتعثر في سؤال مستويات العزل في قاعدة البيانات، وكتب قصة مشروعه بصيغة «نحن» من أولها لآخرها، فعرف أن الأسبوع الأول للمسائل والأساسيات، وأن قصته تحتاج إعادة كتابة.

كيف يقيمك المقابل؟

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

• الحل ليس كل الدرجة: مرشح وصل إلى حل O(n²) صحيح وشرح لماذا يمكن تحسينه واختبره قد يحصل على درجات أعلى في أربع خانات من خمس، أما مرشح كتب الحل الأمثل في صمت ولم يختبره فقد يحصل على درجة عالية في خانة واحدة.
• التلميح يكتب ولا يعني الرسوب: إذا تعثرت وأعطاك المقابل تلميحاً فخذه واستخدمه، فالمقابل يكتب «وصل بعد تلميح» وهي درجة 2 أو 3، أما الإصرار على طريق خاطئ ورفض التلميح فيكتب عنه شيء أسوأ.
• الدليل يكتب بكلماتك: المقابل يكتب ما قلته وفعلته، مثل «سأل عن الحالة الفارغة قبل الكود» أو «لم يذكر تكلفة الحل»، لذلك قل الأشياء التي تفكر فيها بصوت مسموع، فما لا تقوله لا يكتب.

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

خطة الأسبوعين يوماً بيوم

الخطة التالية مبنية على ساعتين إلى ثلاث كل يوم، والأسبوع الأول للأساسيات والأنماط، والثاني لوضع المقابلة: الوقت والصوت المسموع والقصص والمقابلات التجريبية. والصورة التالية تبينها:

والجدول التالي يفصل كل يوم، مع ما تخرج به في آخره:

وفي الخطة أعلاه لاحظ التالي:

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

هياكل البيانات والخوارزميات: ما الذي تحتاجه فعلاً؟

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

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

طريقة حل المسألة أمام المقابل

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

1. افهم واسأل: أعد المسألة بكلماتك، واسأل عن حجم المدخل، وهل يمكن أن يكون فارغاً، وهل القيم مرتبة، وما شكل المخرج بالضبط. سؤالان أو ثلاثة يكفيان، والهدف ألا تحل مسألة غير المطلوبة.
2. أمثلة: اكتب مثالاً عادياً ومثالاً حدياً قبل أي كود، فالأمثلة تكشف ما لم تسأل عنه، وتصبح اختباراتك في الخطوة الأخيرة.
3. الحل البسيط: قله بصوت مسموع مع تكلفته، حتى لو كان O(n²)، والسبب أن الحل البسيط الصحيح نقطة أمان، وكثير من المقابلين يقولون «جيد، اكتبه» إذا كان الوقت ضيقاً.
4. حسن: اسأل نفسك أين العمل المتكرر، وهل يساعد هيكل من الجدول السابق، مثل قاموس يتذكر ما رأيته، أو ترتيب يجعل المقارنة مع الجار فقط.
5. اكتب: بأسماء واضحة ودوال صغيرة، واشرح ما تكتبه وأنت تكتبه دون أن يتحول الشرح إلى صمت طويل أو إلى كلام لا يتوقف.
6. اختبر: مر على الكود بالأمثلة التي كتبتها في الخطوة الثانية سطراً سطراً، فإذا وجدت خطأ بنفسك فهذا أفضل لدرجتك من ألا يوجد خطأ أصلاً، لأنه يبين أنك تتحقق من عملك.

مثال كامل: مدفوعات مشبوهة خلال ستين ثانية

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

في الخطوة الأولى سأل: هل المدفوعات مرتبة بالوقت؟ (لا)، وهل 60 ثانية بالضبط مشبوهة؟ (لا، أقل من 60 فقط)، وكم عدد المدفوعات؟ (حتى عشرات الآلاف). وفي الخطوة الثانية كتب أربعة أمثلة: قائمة فارغة، ومدفوعتان بنفس البطاقة بفرق 60 ثانية بالضبط، وبفرق 59، وبطاقتان مختلفتان في نفس الثانية. وفي الخطوة الثالثة قال: «الحل البسيط أن أقارن كل مدفوعة بكل ما بعدها، وهذا O(n²)، وهو صحيح ولكنه بطيء مع عشرات الآلاف». وفي الخطوة الرابعة لاحظ أن المقارنة تهم فقط بين مدفوعات نفس البطاقة، وأنه إذا رتبها بالوقت فلا يحتاج أن يقارن المدفوعة إلا بما قبلها خلال 60 ثانية، وهذا نمط النافذة المنزلقة. والكود التالي يكتب الحلين ويختبرهما ويقيس وقتهما:

# pairs.py: find payments made with the same card less than 60 seconds apart
import random, time

def suspicious_brute(payments, window=60):
    found = []
    for i in range(len(payments)):
        for j in range(i + 1, len(payments)):
            a, b = payments[i], payments[j]
            if a[1] == b[1] and abs(a[2] - b[2]) < window:
                found.append((a[0], b[0]))
    return found

def suspicious_sorted(payments, window=60):
    found = []
    by_card = {}
    for p in payments:                       # group by card: O(n)
        by_card.setdefault(p[1], []).append(p)
    for card_payments in by_card.values():
        card_payments.sort(key=lambda p: p[2])   # sort each card by time
        start = 0
        for end in range(len(card_payments)):    # sliding window over time
            while card_payments[end][2] - card_payments[start][2] >= window:
                start += 1
            for k in range(start, end):
                found.append((card_payments[k][0], card_payments[end][0]))
    return found

def make(n, cards, seed=7):
    rnd = random.Random(seed)
    return [(i, rnd.randrange(cards), rnd.randrange(86_400)) for i in range(n)]

# tests first: the edge cases an interviewer will ask about
assert suspicious_sorted([]) == []
assert suspicious_sorted([(1, "A", 100), (2, "A", 160)]) == []          # exactly 60 s apart: not suspicious
assert suspicious_sorted([(1, "A", 100), (2, "A", 159)]) == [(1, 2)]
assert suspicious_sorted([(1, "A", 100), (2, "B", 101)]) == []          # different cards
print("tests passed")

for n in (2_000, 8_000):
    data = make(n, cards=n // 4)
    t = time.perf_counter(); a = suspicious_brute(data); tb = time.perf_counter() - t
    t = time.perf_counter(); b = suspicious_sorted(data); ts = time.perf_counter() - t
    same = sorted(tuple(sorted(x)) for x in a) == sorted(tuple(sorted(x)) for x in b)
    print(f"n={n:5}  pairs={len(b):3}  brute={tb*1000:8.1f} ms  sorted={ts*1000:6.1f} ms  same={same}")

وعند تشغيله بالأمر python pairs.py على Python 3.13 سوف يكون المخرج كما يلي:

tests passed
n= 2000  pairs= 11  brute=   134.1 ms  sorted=   0.9 ms  same=True
n= 8000  pairs= 24  brute=  2283.2 ms  sorted=   6.0 ms  same=True

في المخرج أعلاه لاحظ التالي:

• الاختبارات الأربعة نجحت قبل أي قياس، وهي نفس الأمثلة التي كتبها في الخطوة الثانية، والاختبار الثاني تحديداً هو ما يسأل عنه المقابل غالباً: «وماذا عن 60 ثانية بالضبط؟».
• عندما تضاعف عدد المدفوعات أربع مرات، من 2000 إلى 8000، زاد وقت الحل البسيط من 134 إلى 2283 ملي ثانية، أي حوالي 17 ضعفاً، وهذا قريب من 16 الذي يتوقعه O(n²) (أربعة في أربعة)، أما الحل الثاني فزاد من 0.9 إلى 6 ملي ثانية تقريباً، وهذا ما يتوقعه O(n log n) مع ترتيب مدفوعات كل بطاقة.
• العمود same=True يقارن نتيجة الحلين، وهذه عادة جيدة: الحل البسيط البطيء يصبح اختباراً للحل السريع.
• والأرقام نفسها ستختلف على جهازك، والذي يهم هو النسبة بين الحلين وكيف تتغير مع الحجم.

وفي المقابلة لا تحتاج إلى القياس طبعاً، ولكن عندما تتمرن في البيت فالقياس يثبت لك أن ما تقوله عن Big-O حقيقي، فتقوله في المقابلة بثقة.

ماذا يحدث إذا نسيت الترتيب؟

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

# nosort.py: the same window, but the candidate forgot to sort by time
def suspicious_nosort(payments, window=60):
    found, by_card = [], {}
    for p in payments:
        by_card.setdefault(p[1], []).append(p)
    for card_payments in by_card.values():
        start = 0
        for end in range(len(card_payments)):
            while card_payments[end][2] - card_payments[start][2] >= window:
                start += 1
            for k in range(start, end):
                found.append((card_payments[k][0], card_payments[end][0]))
    return found

print(suspicious_nosort([(1, "A", 100), (2, "A", 159)]))   # arrives in time order
print(suspicious_nosort([(1, "A", 100), (2, "A", 300), (3, "A", 120)]))   # third payment arrives late

والمخرج سوف يكون كما يلي:

[(1, 2)]
[(2, 3)]

والخطأ في المحاولة الثانية مزدوج: الدالة أعادت الزوج (2، 3) والفرق بينهما 180 ثانية فليس مشبوهاً، وفاتها الزوج (1، 3) والفرق بينهما 20 ثانية فقط. والسبب أن النافذة المنزلقة تفترض أن الوقت يزيد مع كل خطوة، فعندما وصلت المدفوعة الثالثة بوقت أقل من الثانية لم يتحرك مؤشر البداية للخلف، وأصبح الفرق سالباً فدخل في النافذة. وهذا درس للمقابلة أكبر من المسألة: الأمثلة التي تكتبها في الخطوة الثانية يجب أن تكسر افتراضاتك عمداً، فإذا كان حلك يفترض الترتيب فاكتب مثالاً غير مرتب، والمرشح الذي يقول «حلي يفترض أن المدخل مرتب، لذلك أرتب أولاً» يحصل على درجة أعلى من الذي يكتب الحل الصحيح دون أن يذكر الافتراض.

التقييم الإلكتروني Online Assessment: جلسة بلا مقابل

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

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

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

الأساسيات: الطبقات التي تبني عليها كل يوم

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

• HTTP: رموز الحالة، والطرق الآمنة للتكرار، والتخزين المؤقت في المتصفح، في HTTP وHTTPS ببساطة.
• قواعد البيانات: الفهارس وقراءة EXPLAIN، والمعاملات ومستويات العزل، في الفهارس Indexes وقراءة EXPLAIN وتعلم SQL (3): CTE ودوال النوافذ والمعاملات.
• التزامن: الخيوط وasync وحالات السباق Race Conditions، في Threads وasync/await.
• الذاكرة والأداء: ال Stack وال Heap، وما يجعل الكود بطيئاً، في الذاكرة للمبرمجين.
• التشخيص: من العرض إلى السبب، في استكشاف الأخطاء وتحليل الأداء للمبتدئين.
• الأمن الأساسي: حقن SQL والتفويض وتخزين كلمات المرور، في OWASP Top 10 للمبتدئين.
• Git والاختبارات: في Git في العمل اليومي وأنواع الاختبارات للمبتدئين.

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

وهذه إجابة نموذجية بالطريقة التي نقصدها، على سؤال تعثر فيه صاحبنا في اليوم الأول: «خمسون مستخدماً اشتروا آخر عشر تذاكر في نفس اللحظة، فبيعت خمسون تذكرة، لماذا؟». الإجابة الضعيفة: «مشكلة تزامن، والحل أن نضع الكود في Transaction». والإجابة الجيدة: «كل طلب قرأ العدد عشرة ثم حسب الجديد في الكود ثم كتبه، فضاعت التحديثات، وهذا التحديث المفقود Lost Update، والمعاملة بمستوى العزل الافتراضي Read Committed في PostgreSQL لا تمنعه لأن كل جملة فيها صحيحة وحدها. والحل الأبسط أن تكون القراءة والكتابة جملة واحدة ذرية: UPDATE ... SET stock = stock - 1 WHERE stock > 0، أو قفل الصف بـ SELECT ... FOR UPDATE إذا احتجت منطقاً في الكود». ولاحظ أن الإجابة الجيدة ليست أطول بكثير، ولكنها تشرح الآلية وتسمي الظاهرة وتذكر لماذا لا يكفي الحل الأول، وقد شغلنا هذه الحالة فعلاً في تمرين التذاكر في بنك Backend.

مثال على سلم المتابعة: سؤال الفهرس

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

1. ما هو؟ «بنية مرتبة تجعل قاعدة البيانات تصل إلى الصفوف المطلوبة دون أن تقرأ الجدول كله». وهنا يجيب الجميع تقريباً.
2. كيف يعمل؟ «في PostgreSQL وMySQL يكون غالباً شجرة B-Tree، فالبحث فيها O(log n) بدلاً من قراءة كل الصفوف». وهنا يتوقف كثيرون.
3. متى لا يفيد؟ «إذا كان الشرط يعيد نسبة كبيرة من الجدول، أو إذا لففت العمود بدالة مثل lower(email)، أو إذا كان الفهرس على عمودين والشرط على الثاني وحده، ولكل فهرس تكلفة على الكتابة والمساحة».
4. في الإنتاج: «قبل أن أضيف فهرساً أقرأ EXPLAIN ANALYZE للاستعلام البطيء نفسه، وعلى جدول كبير في الإنتاج أضيفه بـ CREATE INDEX CONCURRENTLY حتى لا أوقف الكتابة».
5. ماذا ستفعل بشكل مختلف؟ هنا يتحدث من عاش المشكلة عن تصميم الجدول نفسه، وهذه درجة لا يتوقعها أحد من مطور بخبرة سنتين.

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

تصميم الأنظمة بقدر مستواك

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

1. المتطلبات الوظيفية في جمل قصيرة، وما ليس في النطاق.
2. المتطلبات غير الوظيفية: كم مستخدماً، وما زمن الاستجابة المقبول، وما الذي لا يحتمل الخطأ.
3. تقدير سريع بالأرقام: الطلبات في الثانية في المتوسط والذروة، وحجم البيانات بعد سنة.
4. أبسط تصميم يعمل: غالباً تطبيق وقاعدة بيانات، مع الجداول والواجهات الأساسية.
5. نقاط الاختناق: ما أول شيء يتعطل عندما يتضاعف الضغط Load عشر مرات؟ ولكل نقطة أرخص حل وثمنه.

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

قصة مشروعك: الجلسة التي يهملها أغلب المرشحين

جلسة التعمق في مشروع سابق Project Deep Dive هي الجلسة التي يظن المرشح أنها لا تحتاج استعداداً لأنه «يعرف مشروعه»، ثم يكتشف في المقابلة أنه لا يتذكر لماذا اختار قاعدة البيانات، أو أنه يتحدث بصيغة «نحن» طوال الوقت فلا يعرف المقابل ما فعله هو. والمقابل في هذه الجلسة يصعد بالدرجات الخمس في الصورة التالية:

اختر مشروعاً واحداً تعرفه جيداً، ويفضل أن يكون من عملك وليس من الجامعة إذا كانت لديك خبرة، واكتب لكل درجة ثلاثة أسطر. وهذا ما كتبه صاحبنا عن لوحة حجوزات بناها لعميل في الوكالة، بعد أن أعاد كتابتها من صيغة «نحن»:

1. ماذا بنيت: «لوحة حجوزات لسلسلة عيادات أسنان فيها اثنا عشر فرعاً، يستخدمها موظفو الاستقبال، وكنت المطور الوحيد على جزء الحجز والتذكير بالرسائل».
2. لماذا هذا التصميم: «جعلت التذكير يعمل من طابور بدلاً من إرساله أثناء الحجز، لأن مزود الرسائل كان يتأخر أحياناً عشر ثوان فيتجمد الموظف أمام المريض، والبديل كان مهمة مجدولة كل ساعة، ورفضته لأن التذكير قبل الموعد بساعتين يحتاج دقة أعلى».
3. ماذا تعطل: «في الأسبوع الأول وصلت بعض الرسائل مرتين، ووجدت أن العامل Worker كان يعيد المهمة بعد انتهاء مهلتها وهي ما زالت تعمل، فأضفت مفتاحاً فريداً لكل تذكير يمنع إرساله مرتين».
4. الأرقام: «حوالي 900 حجز يومياً في كل الفروع، وزمن صفحة الحجز انخفض من ثوان أحياناً إلى أقل من نصف ثانية بعد إخراج الرسائل».
5. ماذا ستغير: «كنت سأكتب اختبارات للحالات الحدية في المواعيد من البداية، فقد اكتشفت خطأ التوقيت عند تغيير المنطقة الزمنية لفرع خارج المملكة بعد شهرين».

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

الأسئلة السلوكية بطريقة STAR

الأسئلة السلوكية Behavioural Questions تبدأ عادة بـ «حدثني عن مرة...»، وفكرتها أن الطريقة التي تصرفت بها في الماضي أفضل ما يتنبأ بتصرفك في المستقبل، وهذا ما تقوله Amazon صراحة في صفحة مقابلاتها، حيث تقول إنها لا تسأل ألغازاً وإنما تركز على «ماذا» و«كيف» في تجربتك و«لماذا» في قراراتك، وإن كل مقابل يسأل عادة سؤالين أو ثلاثة من هذا النوع، وتنصح بطريقة STAR لترتيب الإجابة، وبأن تكون «أنا» أفضل من «نحن». والصورة التالية تبين الطريقة مع الوقت التقريبي لكل جزء:

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

إجابة ضعيفة: «كان عندنا خلاف في الفريق على استخدام MongoDB أو MySQL، وكل واحد له رأي، وفي النهاية اتفقنا على MySQL والمشروع نجح والحمد لله».

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

ولاحظ في الإجابة الجيدة أن «ما فعلته» هو أطول جزء، وأن فيها دليلاً (القياس)، واحتراماً للزميل، واعترافاً بأن رأيه حسن الحل. ولا تجهز إجابة لكل سؤال ممكن، وإنما جهز ست قصص تغطي أغلب الأسئلة، كما في الصورة التالية:

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

الذكاء الاصطناعي في المقابلة

أغلب المطورين اليوم يستخدمون أدوات الذكاء الاصطناعي، ففي استطلاع مطوري Stack Overflow لعام 2025، المبني على أكثر من 49 ألف إجابة من 177 بلداً، قال 84% إنهم يستخدمون هذه الأدوات أو يخططون لاستخدامها، و51% من المطورين المحترفين يستخدمونها يومياً. ولكن نفس الاستطلاع يبين أن 46% لا يثقون في دقة ما تنتجه مقابل 33% يثقون، وأن المطورين الأكثر خبرة هم الأكثر حذراً. وهذا بالضبط ما تقيسه الشركات التي تسمح بالأدوات في المقابلة: هل تعرف متى تخطئ الأداة.

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

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

المقابلة التجريبية: أهم يوم في الخطة

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

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

ماذا يتغير بحسب الدور والمستوى؟

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

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

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

أخطاء شائعة في الاستعداد والمقابلة

يوم المقابلة وما بعده

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

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

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

بعد المقابلة: القبول والرفض والمقابلة التالية

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

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

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

قائمة تحقق قبل المقابلة

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

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

وبنوك الأسئلة التي تستعد منها، وبقية مقالات السلسلة:

دليلأسئلة مقابلة مطور Backend من المبتدئ إلى الخبيربنك أسئلة لمقابلة مطور Backend، لكل سؤال إجابة المبتدئ وإجابة الخبير وأسئلة متابعة، مع تمارين عملية شغلناها فعلاً.دليلأسئلة مقابلة مطور Frontend من المبتدئ إلى الخبيربنك أسئلة لمقابلة مطور Frontend، لكل سؤال إجابة المبتدئ وإجابة الخبير وأسئلة متابعة، مع تمارين عملية شغلناها فعلاً.دليلأسئلة مقابلة مطور تطبيقات الجوال من المبتدئ إلى الخبيربنك أسئلة لمقابلة مطور تطبيقات الجوال على Android وiOS، لكل سؤال إجابة المبتدئ وإجابة الخبير، مع تمارين عملية شغلناها.دليلكيف تدير مقابلة تقنية تكشف مستوى المرشح؟كيف تبني مقابلة تقنية منظمة تفرق بين المبتدئ والخبير بأسئلة المتابعة والتقييم بالدرجات بدلاً من الانطباع.

دليلهياكل البيانات Data Structures للمبتدئينلماذا تكون نفس العملية سريعة في هيكل بيانات وبطيئة في آخر، وأين تقابل كل هيكل في السيرفرات وقواعد البيانات.دليلBig-O للمبتدئين: لماذا يبطؤ كودك عندما تكبر البياناتلماذا يعمل الكود بسرعة على مئة صف ثم يتوقف على مئة ألف، وكيف تقرأ Big-O وتكتشف الخوارزمية البطيئة في كودك.دليلتمارين Kata في البرمجة بثلاثة مستويات مع الحلولتمارين برمجة تحلها بيدك دون ذكاء اصطناعي، من FizzBuzz إلى النصوص العربية وحالة السباق، ولكل تمرين حل مجرب في لغتين.دليلمدخل إلى تصميم الأنظمة: من سيرفر واحد إلى ملايين المستخدمينكيف يكبر متجر إلكتروني من سيرفر واحد إلى نظام يخدم ملايين المستخدمين، وما الثمن الذي تدفعه في كل خطوة.دليلكيف تستعد لمقابلة التدريب Internship وأنت طالب؟سيرة ذاتية بلا خبرة عمل، ومشاريع تبنيها لمسار التطوير والأمن، وإجابات لأسئلة مقابلة التدريب الشائعة، وأسئلة تسألها أنت.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتشغيل مثال المدفوعات المشبوهة على Python 3.13.3، والتحقق من صفحات Amazon وسياسات Anthropic وCanva واستطلاع Stack Overflow 2025 بتاريخ 26 أكتوبر 2026.