إزاي تعرض شغلك كـ 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.”
———
بالتوفيق 🌹
.
.
طبيعة شغل ومشاريع الباك إند مختلفة شوية عن مجالات تانية زي الفرونت إند أو الموبايل، بتقعد ساعات تكتب في 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.”
———
بالتوفيق 🌹
❤12
دورة مجانية: مقدمة في Laravel
تهدف الدورة إلى التعرف على بنية MVC (Model-View-Controller) ودورها الأساسي في تنظيم وتطوير تطبيقات الويب، وفهم كيفية تقسيم البرنامج إلى مكوناته الرئيسية لضمان كتابة كود منظم وقابل للتطوير، بالإضافة إلى التعرف على كيفية استخدام Laravel لتسهيل العمل مع كل من النماذج (Models)، الواجهات (Views)، ووحدات التحكم (Controllers).
https://satr.tuwaiq.edu.sa/course/lgdjP05YC9/view
تهدف الدورة إلى التعرف على بنية MVC (Model-View-Controller) ودورها الأساسي في تنظيم وتطوير تطبيقات الويب، وفهم كيفية تقسيم البرنامج إلى مكوناته الرئيسية لضمان كتابة كود منظم وقابل للتطوير، بالإضافة إلى التعرف على كيفية استخدام Laravel لتسهيل العمل مع كل من النماذج (Models)، الواجهات (Views)، ووحدات التحكم (Controllers).
https://satr.tuwaiq.edu.sa/course/lgdjP05YC9/view
❤4
System Design was HARD until I Learned these 30 Concepts 💯
https://blog.algomaster.io/p/30-system-design-concepts
https://blog.algomaster.io/p/30-system-design-concepts
❤4
إزاي نضمن إن المشروع شغّال زي ما العميل متوقع؟ 💯
.
.
الـ Testing مش مجرد خطوة بنعملها في الآخر "علشان نطمن"، ولا هو شوية Test Cases بنكتبهم والسلام.
الموضوع أعمق من كده بكتير...
واللي بيحدد شكله وتوقيته وطريقته هو نوع الـ Software Development Methodology اللي المشروع شغال بها.
———
📌 أولًا.. يعني إيه Software Testing؟
باختصار، الـ Testing هو الطريقة اللي بنكتشف بها الـ bugs قبل ما توصل للمستخدم.
وكمان بنقيس هل الـ software بيحقق الـ requirements ولا لا؟
هل قابل للاستخدام؟
هل بيشتغل كويس تحت الضغط؟
هل الـ UI سهل وواضح؟
كل دي أنواع مختلفة من الـ Testing...
———
📌 إزاي الـ Methodology بتأثر على الـ Testing؟
تعال نعرف الفرق...
1. الـ Waterfall Model:
في الـ Waterfall، الـ Testing بييجي في الآخر بعد ما كل حاجة تخلص.
يعني:
Requirements ➡️ Design ➡️ Development ➡️ Testing
📌 ده معناه إنك مش هتبدأ تختبر غير لما المشروع كله يكون جاهز.
وده بيخلي الـ Testing عبارة عن Quality Gate: لو الكود فيه مشاكل، بنرجع خطوة ورا، ونصلح.
⚠️ العيب هنا؟ لو فيه bug في البداية، هتكتشفه متأخر جدًا، وهتكلفك كتير.
———
2. الـ Agile Methodology:
موجود في معظم الشركات دلوقتي.
هنا بنشتغل في Sprints قصيرة، والـ Testing بيكون جزء من كل Sprint.
📌 الـ Testing بيحصل مع كل ميزة جديدة.
والـ QA بقى جزء من التيم من أول يوم.
🎯 النتيجة؟
- بتقدر تكتشف الـ Bugs بدري
- كمان تقدر تاخد Feedback من العميل بشكل مستمر علشان لو فيه تعديل
- وطبعًا التكلفة هتكون أقل
———
3. الـ DevOps / Continuous Integration:
هنا الـ testing بيكون جزء من الـ pipeline نفسها.
📌 هنا بنستخدم Tools زي Jest أو Cypress أو Selenium، وغيرها، نكتب بها Automated Tests
وأول ما الـ developer يعمل Push، الـ Tests بتشتغل أوتوماتيك.
🔥 ده بيخلي الـ Testing جزء من حياة الكود، مش خطوة منفصلة.
———
✅ لازم تبقى فاهم نوع الـ methodology اللي المشروع ماشي بها، علشان تعرف إمتى وإزاي تختبر.
✅ بلاش تعتمد بس على الـ QA، أنت كـ Developer مسؤول عن كتابة Unit Tests على الأقل.
✅ كل ما تكتب Tests أكتر، كل ما الكود بتاعك هيبقى أسهل في الـ Refactor، وأقل Bugs.
.
.
الـ Testing مش مجرد خطوة بنعملها في الآخر "علشان نطمن"، ولا هو شوية Test Cases بنكتبهم والسلام.
الموضوع أعمق من كده بكتير...
واللي بيحدد شكله وتوقيته وطريقته هو نوع الـ Software Development Methodology اللي المشروع شغال بها.
———
📌 أولًا.. يعني إيه Software Testing؟
باختصار، الـ Testing هو الطريقة اللي بنكتشف بها الـ bugs قبل ما توصل للمستخدم.
وكمان بنقيس هل الـ software بيحقق الـ requirements ولا لا؟
هل قابل للاستخدام؟
هل بيشتغل كويس تحت الضغط؟
هل الـ UI سهل وواضح؟
كل دي أنواع مختلفة من الـ Testing...
———
📌 إزاي الـ Methodology بتأثر على الـ Testing؟
تعال نعرف الفرق...
1. الـ Waterfall Model:
في الـ Waterfall، الـ Testing بييجي في الآخر بعد ما كل حاجة تخلص.
يعني:
Requirements ➡️ Design ➡️ Development ➡️ Testing
📌 ده معناه إنك مش هتبدأ تختبر غير لما المشروع كله يكون جاهز.
وده بيخلي الـ Testing عبارة عن Quality Gate: لو الكود فيه مشاكل، بنرجع خطوة ورا، ونصلح.
⚠️ العيب هنا؟ لو فيه bug في البداية، هتكتشفه متأخر جدًا، وهتكلفك كتير.
———
2. الـ Agile Methodology:
موجود في معظم الشركات دلوقتي.
هنا بنشتغل في Sprints قصيرة، والـ Testing بيكون جزء من كل Sprint.
📌 الـ Testing بيحصل مع كل ميزة جديدة.
والـ QA بقى جزء من التيم من أول يوم.
🎯 النتيجة؟
- بتقدر تكتشف الـ Bugs بدري
- كمان تقدر تاخد Feedback من العميل بشكل مستمر علشان لو فيه تعديل
- وطبعًا التكلفة هتكون أقل
———
3. الـ DevOps / Continuous Integration:
هنا الـ testing بيكون جزء من الـ pipeline نفسها.
📌 هنا بنستخدم Tools زي Jest أو Cypress أو Selenium، وغيرها، نكتب بها Automated Tests
وأول ما الـ developer يعمل Push، الـ Tests بتشتغل أوتوماتيك.
🔥 ده بيخلي الـ Testing جزء من حياة الكود، مش خطوة منفصلة.
———
✅ لازم تبقى فاهم نوع الـ methodology اللي المشروع ماشي بها، علشان تعرف إمتى وإزاي تختبر.
✅ بلاش تعتمد بس على الـ QA، أنت كـ Developer مسؤول عن كتابة Unit Tests على الأقل.
✅ كل ما تكتب Tests أكتر، كل ما الكود بتاعك هيبقى أسهل في الـ Refactor، وأقل Bugs.
❤8
أكيد تعرف npm install أو npm i
.
.
لكن هل تعرف npm ci؟
لما تكتب npm install، هو بيبص على الـ package.json ويشوف إيه الـ packages المطلوبة، وبعدين:
- لو فيه package-lock.json بيحاول يطابقه.
- ولو مش موجود، بيبدأ يركّب اللي محتاجه ويعمل واحد جديد.
- وكمان ممكن يحدث بعض الـ packages لو شاف إن فيه إصدار أحدث متوافق مع الشروط.
وطبعًا ده كويس لكن ممكن يحصل اختلافات من جهاز للتاني...
———
الـ ci معناها "continuous integration"، والأمر ده معمول مخصوص عشان الـ automation وبيشتغل بشكل أسرع وأسهل.
- بيمسح فولدر node_modules تمامًا.
- وبعدين يركّب الـ packages بالضبط زي ما هي مكتوبة في package-lock.json.
- لو فيه فرق بين package.json و package-lock.json بيقف ويعمل Error.
✅ ده معناه إن npm ci:
- أسرع من install.
- بيعمل نفس النتائج كل مرة.
- ممتاز في الـ CI/CD pipelines أو في الشركات الكبيرة.
———
لو شغال لوحدك ولسه بتضيف/تحدث packages: استخدم npm install.
لو بتشتغل في تيم أو بتعمل Deploy على سيرفر: استخدم npm ci عشان تضمن ثبات البيئة.
.
.
لكن هل تعرف npm ci؟
لما تكتب npm install، هو بيبص على الـ package.json ويشوف إيه الـ packages المطلوبة، وبعدين:
- لو فيه package-lock.json بيحاول يطابقه.
- ولو مش موجود، بيبدأ يركّب اللي محتاجه ويعمل واحد جديد.
- وكمان ممكن يحدث بعض الـ packages لو شاف إن فيه إصدار أحدث متوافق مع الشروط.
وطبعًا ده كويس لكن ممكن يحصل اختلافات من جهاز للتاني...
———
الـ ci معناها "continuous integration"، والأمر ده معمول مخصوص عشان الـ automation وبيشتغل بشكل أسرع وأسهل.
- بيمسح فولدر node_modules تمامًا.
- وبعدين يركّب الـ packages بالضبط زي ما هي مكتوبة في package-lock.json.
- لو فيه فرق بين package.json و package-lock.json بيقف ويعمل Error.
✅ ده معناه إن npm ci:
- أسرع من install.
- بيعمل نفس النتائج كل مرة.
- ممتاز في الـ CI/CD pipelines أو في الشركات الكبيرة.
———
لو شغال لوحدك ولسه بتضيف/تحدث packages: استخدم npm install.
لو بتشتغل في تيم أو بتعمل Deploy على سيرفر: استخدم npm ci عشان تضمن ثبات البيئة.
❤5
🔰 How to Use Rem Units in CSS
Rem units in CSS can be used for setting font sizes, margins, padding, widths, and heights relative to the root element's font-size. 💯
❤1
💡 Claude Tip
If you're frequently switching between Sonnet and Opus, try:
• This uses Opus for planning and more complex tasks while falling back to Sonnet for regular work.
• It's a useful setup when working on larger features, RFCs, architecture discussions, or multi-step tasks, while still keeping everyday interactions fast and efficient.
If you're frequently switching between Sonnet and Opus, try:
/model opusplan• This uses Opus for planning and more complex tasks while falling back to Sonnet for regular work.
• It's a useful setup when working on larger features, RFCs, architecture discussions, or multi-step tasks, while still keeping everyday interactions fast and efficient.
❤3👏2👍1