كيف أكتب سيرة ذاتية لوظيفة مهندس backend؟

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

كلتا المشكلتين قابلتان للإصلاح، والحلول محددة لهذه الوظيفة.

لا توجد مؤهلات أو تسجيلات أو تراخيص — قل الحقيقة بدلاً من ذلك

هندسة Backend في المملكة المتحدة ليس لها مسمى محمي، ولا هيئة تسجيل يعتمد عليها التوظيف، ولا ترخيص. عضوية BCS وCEng موجودة ونادراً ما تكون عاملاً في الحصول على مقابلة backend خارج بعض المقاولين في الدفاع والسكك الحديدية والطاقة النووية. درجة علوم الحاسب شائعة وليست مطلوبة؛ تدريب Level 6 Digital and Technology Solutions Professional ومسارات bootcamp إلى الصناعة كلاهما ممثل جيداً في الفرق التي توظف جيداً. إذا كان لديك خمس سنوات أو أكثر من الخبرة الإنتاجية، سطر الدرجة هو سطر واحد في الأسفل، بدون الوحدات.

الأشياء التي تعمل فعلياً كمؤهلات في هذا المجال مختلفة:

التصريح الأمني. تصريح SC أو DV هو بوابة حقيقية لعمل backend في Home Office وMoD وموردي GCHQ والكثير من استشاريي إطار Crown Commercial. إذا كان لديك، ضعه في الرأس مع المستوى وما إذا كان ساري المفعول أو منتهي الصلاحية. إذا كنت قد حصلت عليه وانتهت صلاحيته، قل ذلك أيضاً — التصريح منتهي الصلاحية أرخص بكثير لإعادة تفعيله من البدء من الصفر، ومديرو التوظيف في ذلك القطاع يعرفون ذلك.

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

التعرض للامتثال في المجال. نطاق PCI DSS، أنظمة إنتاج منظمة من FCA، NHS DSP Toolkit، HIPAA، ضوابط ISO 27001 التي نفذتها فعلياً. هذه ليست شهادات حصلت عليها، بل قيود عملت في ظلها، وفي توظيف fintech والصحة تحمل وزناً أكبر من أي شهادة. "بنيت وشغّلت خدمات داخل نطاق بيئة بيانات حامل البطاقة PCI DSS" هو سطر يُقرأ مرتين.

ما الذي يفحصه مدير توظيف backend أولاً

بالترتيب، تقريباً، وبسرعة:

1. اللغة الأساسية والبيئة، مع الإصدار. Java 8 وJava 21 وظيفتان مختلفتان. صيانة Python 2 وPython الحديثة async وظيفتان مختلفتان. Go أو Kotlin أو C#/.NET أو Node/TypeScript أو Ruby أو Rust أو Elixir أو Scala — أياً كانت، يجب أن تكون واضحة في الثلث الأول من الصفحة الأولى، وليس مدفونة في كتلة مهارات في النهاية.
2. قواعد البيانات. Postgres أو MySQL أو MongoDB أو DynamoDB أو Cassandra، وماذا فعلت بها. "PostgreSQL" وحدها لا تخبر المدير بشيء. "Postgres: تصميم المخطط، ضبط الفهارس، تقسيم جدول تجاوز أداء الاستعلام على عقدة واحدة، ترحيلات بدون توقف مع كتابة مزدوجة وملء خلفي" تخبرهم بكل شيء.
3. ما إذا كنت قد شغّلت أشياء في الإنتاج. دورة on-call، استجابة للحوادث، SLOs، موازنات الأخطاء، مراجعات ما بعد الحادث كتبتها. مهندس قدّم كوداً فقط لفريق عمليات هو توظيف مختلف عن واحد تم تنبيهه لخدمته الخاصة، وهذا يُفحص مبكراً.
4. حجم وشكل الزيارات. ليس لإثارة إعجاب أحد — لمعرفة ما إذا كانت غرائزك قابلة للنقل. معدلات الطلبات، أحجام البيانات، أهداف زمن الاستجابة، أحجام الدفعات، عدد المستأجرين. استخدم أرقامك الحقيقية. إذا لم يكن لديك، صف الشكل بدلاً من ذلك: "معاملات مالية منخفضة الحجم عالية القيمة حيث كانت الصحة أهم من الإنتاجية" جملة معلوماتية حقاً وليست رقماً كان عليك اختراعه.
5. المراسلة والتكامل. Kafka أو RabbitMQ أو SQS/SNS أو Pub/Sub أو gRPC أو REST أو GraphQL أو webhooks. ما إذا صممت العقود أو استهلكت عقود شخص آخر.

كل شيء آخر — Kubernetes وTerraform وخطوط CI ومزود السحابة — مهم، لكنه المرور الثاني. المهندسون الذين يبدؤون بجدار من أسماء خدمات AWS ويدفنون اللغة يصنفون أنفسهم في الكومة الخطأ.

الدليل في هذا المجال يعني أنظمة، وليس مسؤوليات

أكبر فرق بين سيرة ذاتية backend تحصل على مكالمة فحص وواحدة لا تحصل هو الفرق بين وصف دور ووصف نظام.

الدور يبدو هكذا: "مسؤول عن تطوير وصيانة microservices في بيئة Java/Spring Boot باستخدام منهجيات Agile."

النظام يبدو هكذا: "امتلكت خدمة تنفيذ الطلبات: Kotlin/Spring Boot، Postgres، مجموعة مستهلك Kafka تعالج أحداثاً من خدمة الدفع. أعدت تصميم المستهلك ليكون idempotent بعد أن كانت التسليمات المكررة تنتج طلبات مشحونة مرتين؛ قدّمت جدول outbox حتى تشترك الكتابة والنشر في معاملة."

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

اكتب اثنتين أو ثلاثاً من هذه لكل دور حديث. ليس ثمانية. اختر تلك التي كان فيها شيء صعباً ويمكنك شرح المقايضة.

ما الذي يتركه مهندسو backend عادة

هذا هو الجزء الذي يكلف الناس مقابلات، وهو ثابت.

الترحيلات. تفكيك monolith، Python 2 إلى 3، Postgres ذاتي الإدارة إلى RDS أو Aurora، on-prem إلى السحابة، REST إلى gRPC، وسيط رسائل إلى آخر، قفزة إصدار رئيسية لإطار عمل عبر عشرات الخدمات. المهندسون يتركون هذه لأنها لم تكن ميزات وشعروا أنها صيانة. مديرو التوظيف يقيّمونها عالياً، لأن عمل الترحيل هو حيث تظهر الحكمة والتوافق العكسي وأعلام الميزات والكتابات المزدوجة والملء الخلفي وخطط التراجع دفعة واحدة. إذا قدت واحدة، تنتمي بالقرب من أعلى ذلك الدور.

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

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

الحوادث. ليس للاعتراف بالخطأ — لإظهار أنك كنت بالقرب من الإنتاج عندما تعطل. "شخّصت استنفاد تجمع الاتصال تحت طفرة زيارات؛ قدّمت PgBouncer وقاطع دائرة على المكالمة اللاحقة" سطر قوي.

الاختبار بعد كلمة 'اختبارات'. اختبار العقد بين الخدمات، Testcontainers، اختبارات قائمة على الخاصية، اختبار حمل مع k6 أو Gatling، كيف اختبرت ترحيلاً. "كتبت اختبارات وحدة" هو ضوضاء. "بنيت اختبارات عقد بين خدمتنا وثلاثة مستهلكين حتى نتمكن من النشر بشكل مستقل" إشارة توظيف.

شكل الفريق وقاعدة الكود. كم عدد المهندسين، كم عدد الخدمات التي امتلكتها، كم عمر قاعدة الكود، ما إذا كنت مهندس backend الوحيد. العمل بمفردك على Rails monolith قديم والعمل في فريق منصة من اثني عشر كلاهما محترم ولا يمكن استنتاج أي منهما من مسمى وظيفي.

وثائق التصميم وRFCs. إذا كنت تتقدم على مستوى senior أو staff أو principal، الشيء الذي يتم تقييمه هو نطاق اتخاذ القرار التقني. تأليف وثائق تصميم بنى فرق أخرى مقابلها هو أوضح دليل عليه. قل كم، عن ماذا، ومن كان الجمهور.

قسم المهارات، وكيف يفشل عادة

الفشل الشائع هو قائمة بستين تقنية في فقرة واحدة، بما في ذلك كل خدمة AWS فتحت لوحة التحكم لها. تُقرأ كحشو وتجعل قوة حقيقية غير مرئية.

صنّف حسب الوظيفة واحتفظ بكل مجموعة قصيرة: لغات، قواعد بيانات، مراسلة، بنية تحتية، قابلية المراقبة. أسقط أي شيء لا تريد أن يُسأل عنه لمدة عشر دقائق. لا تضع سنوات بجانب كل عنصر ولا تضع أشرطة كفاءة أو تصنيفات نجوم على أي شيء — مدير هندسي يقرأ "Kafka ★★★☆☆" لا يتعلم شيئاً ويشكل رأياً عن المؤلف.

إذا كنت مهندس full-stack تتقدم لأدوار backend، كتلة المهارات هي حيث تقرر موضوع السيرة الذاتية. React وTailwind وFigma في الأعلى ستجعلك تُقرأ كمهندس front-end يريد تغييراً. احتفظ بخبرة front-end — إنها سياق مفيد حقاً — لكن ضعها بعد مادة backend وصفها كما كانت.

أشياء متنازع عليها، بصدق

شهادات السحابة. AWS Solutions Architect Associate، GCP Professional Cloud Developer، CKA. في الاستشارات ومتكاملي الأنظمة ومحلات شركاء AWS وأجزاء من القطاع العام هذه موزونة بشكل واضح، أحياناً لأن وضع شريك صاحب العمل يعتمد على عدد الموظفين الحاصلين عليها. في معظم شركات المنتجات هي قريبة من محايدة، وحفنة من المهندسين الكبار يخصمونها بنشاط. لا توجد إجابة عالمية صادقة. انظر ما إذا كان الإعلان يسميها. إذا كان كذلك، ضعها في الرأس. إذا لم يكن، سطر واحد في الأسفل.

روابط GitHub. ملف من ثمانية repos تعليمية وdotfiles مستنسخة أسوأ من عدم وجود رابط. خدمة واحدة منشورة مع README يشرح المقايضات، أو رابط مباشر لـ PR مدمج في مشروع يحتفظ به شخص آخر، يستحق كثيراً. اربط بالشيء المحدد، وليس الملف.

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

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

ماذا تفعل بعد ذلك

خذ آخر إعلان backend رُفضت منه بدون رد. اكتب الأربعة أو الخمسة أشياء التي يطلبها فعلياً — اللغة، قاعدة البيانات، وسيط الرسائل، الحجم، ما إذا كان يريد شخصاً كان on-call. ثم افتح سيرتك الذاتية واحسب كم يستغرق من الوقت لإيجاد كل واحدة. إذا استغرقت أي منها أكثر من بضع ثوان للعثور عليها، حرّكها للأعلى.

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

فعل هذا بشكل صحيح لكل إعلان بطيء، وهذا سبب توقف معظم الناس عن فعله بعد أول اثني عشر طلباً؛ jobmarket.pro يقرأ كل إعلان بالكامل ويعد الطلب من ملف واحد لا يمكنه إضافة خبرة إليه.