DevGuide

إزاي تعرض شغلك كـ Backend Developer؟ 💡
طبيعة شغل ومشاريع الباك إند مختلفة شوية عن مجالات تانية زي الفرونت إند أو الموبايل، بتقعد ساعات تكتب في code، تبني APIs، تظبط الـ Auth، تتعامل مع Databases و Logging و Queues، وكمان ممكن تكون بتشتغل على Microservices و Event-driven architecture…إلخ.

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

الـ Backend أصعب شوية في النقطة دي عن الـ Frontend، لأن الناس مش بتشوف شغلك بعنيهم، فأنت اللي لازم "تخليهم يشوفوه".

تعال أقولك إزاي تعرض شغلك كـ Backend Developer بطريقة محترمة...

———

✨ أول حاجة: أنت بتشتغل على إيه؟

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

- إيه نوع الـ systems اللي اشتغلت عليها؟ (E-commerce, CMS, Booking system…)
- كان فيها كام user؟ أو traffic عامل إزاي؟
- هل كانت Monolith ولا Microservices؟
- هل اشتغلت على حاجات زي Authentication, Payments, Notifications؟
- هل فيه Challenges معينة حليتها؟ (scalability, performance, data integrity…)

✅ مثال:

اشتغلت على نظام E-commerce بيخدم 200K user شهريًا، بنيت فيه REST APIs بـ Node.js وExpress، وعملت Integration مع Stripe للـ payments.

ساهمت في refactor من Monolith لـ Microservices، واشتغلت على Service خاصة بالـ Orders باستخدام MongoDB وRabbitMQ.

———

✨ ثاني حاجة: تكلم عن قراراتك التقنية

بلاش تقول "اشتغلت بـ Node.js وخلاص"، ولكن احكي ليه استخدمتها؟
إزاي اختارت Database معينة؟ ليه استخدمت Redis أو Kafka؟

اللي بيفرق أي حد شاطر مش بس إنه بيعرف يستخدم tools…إنما بيعرف إمتى يستخدم إيه، وليه، وإيه البدائل اللي كانت متاحة؟

✅ مثال:

استخدمنا Redis علشان نعمل caching لبيانات المنتجات عشان نحل مشكلة الـ latency العالية في الـ product listing. ده قلل الـ response time بنسبة 60%.

———

✨ ثالث حاجة: تكلم بلغة الـ Impact

بلاش تقول "اشتغلت على كذا…"، الناس بتحب تسمع التأثير - "بسبب شغلي، حصل كذا وكذا…"

تتكلم عن النتائج:
- الـ API response time قل بنسبة كام؟
- كم bug اتصلحت؟
- الـ revenue زاد؟ retention اتحسن؟
- الـ system بقى يستحمل كام request في الثانية؟

✅ مثال:

عملت تحسين للـ queries في MySQL خلّى الـ checkout process أسرع بنسبة 40%، وقلل الـ cart abandonment بنسبة ملحوظة.

———

✨ رابع حاجة: الـ Showcase الحقيقي

- اعمل repos على GitHub فيها مشاريع حقيقية
- اعرض Postman Collection أو OpenAPI Spec
- لو اشتغلت على حاجات Open Source أو عندك Blog بيشرح اللي بتعمله ممكن تضيفه.

———

✨ خامس حاجة: خلي شغلك "مفهوم" للناس اللي مش في نفس التخصص

خلي دايمًا الطريقة اللي بتتكلم بها سهلة، وفيها أرقام.

بدل ما تقول:

“Built scalable APIs using Node.js.”

ممكن تقول:

“Built RESTful APIs using Node.js to handle 20K+ daily requests, with response time under 200ms.”

———

بالتوفيق 🌹

🎯 الفرق بين الـ Client-side Validation والـ Server-side Validation
أول حاجة تعال نتفق إن الـ "Validation" يعني التحقق من صحة البيانات اللي المستخدم بيدخلها، زي مثلًا لما تيجي تسجل في موقع وتدخل الإيميل والباسورد، لازم الموقع يتأكد إن البيانات دي صح ومظبوطة قبل ما يحفظها أو يتعامل معاها.

التحقق ده ممكن يحصل في مكانين:

———

🔹 الـ Client-side Validation (التحقق في المتصفح):

- يعني التحقق بيحصل قبل ما البيانات تروح للسيرفر.
- الكود اللي بيعمل التحقق ده بيكون شغال عند المستخدم نفسه، غالبًا باستخدام JavaScript أو HTML5 Validation.

مثلًا لو أنت بتدخل بياناتك في فورم تسجيل، والمتصفح طلع لك رسالة بتقولك "الإيميل مش مكتوب بطريقة صحيحة" أو "الباسورد قصير"، قبل حتى ما تضغط على Submit... ده كده Client-side Validation.

ولكن النوع ده مش آمن بنسبة ١٠٠٪، ومينفعش نعتمد عليه لوحده.

———

🔹 الـ Server-side Validation (التحقق عند السيرفر):

- هنا التحقق بيحصل بعد ما البيانات تتبعت للسيرفر.
- السيرفر هو اللي بيتأكد بنفسه من كل حاجة: الإيميل صح؟ الباسورد قوي؟ وهكذا.

بغض النظر المستخدم عمل إيه على جهازه، السيرفر بيستلم الداتا ويتأكد منها بنفسه.

النوع ده ممكن يحميك من هجمات زي SQL Injection وغيرها، ولكن ده بيزود الحمل على السيرفر.

———

✅ إيه الصح؟

الصح والمُتبع في أي مشروع محترم إنك تستخدم النوعين مع بعض:

- تعمل Client-side Validation عشان تحسن تجربة المستخدم وتظهر له Feedback سريع.
- وتعمل كمان Server-side Validation عشان تأمن نفسك وتحافظ على السيرفر والداتا بتاعتك.

———