משרות טכנולוגיות

קורות חיים להייטק שקוראים אותם עד הסוף

במשרות פיתוח, דאטה, QA, DevOps ומוצר טכני, מי שקורא את המסמך מחפש שלושה דברים: מה בניתם, באילו כלים, ובאיזה הקשר. עיצוב עמוס לא עוזר — מה שעוזר הוא שורות ניסיון קונקרטיות, stack מסודר, פרויקטים שאפשר לפתוח, והתאמה אמיתית לתיאור המשרה.

  • מבנה שמעלה פרויקטים כשאין ניסיון תעסוקתי
  • מיפוי stack לקבוצות במקום רשימה אחת ארוכה
  • תבניות בעברית ובאנגלית באותו חשבון
  • תשלום חד-פעמי בהורדת ה-PDF, ללא חידוש

בונים וצופים בתוצאה לפני התשלום · תשלום חד-פעמי בהורדת ה-PDF · ללא חידוש אוטומטי

התאמה לתיאור המשרה
stack מסודר לפי קבוצות
פרויקטים וקישורי קוד
תשלום חד-פעמי בהורדה

מבנה

סדר החלקים המומלץ

הסדר משתנה לפי הניסיון שלכם. הכלל הפשוט: מה שהכי חזק אצלכם מופיע ראשון, אחרי פרטי הקשר והתקציר.

עם ניסיון תעסוקתי
  1. פרטי קשר וקישורים (LinkedIn, GitHub)
  2. תקציר קצר: תחום, שנות ניסיון וסוג המערכות
  3. ניסיון תעסוקתי, מהעדכני לישן
  4. Stack טכנולוגי מקובץ
  5. פרויקטים בולטים (אם אינם חלק מהניסיון)
  6. השכלה, קורסים והסמכות
  7. שפות ושירות צבאי אם רלוונטי
בתחילת דרך או אחרי בוטקאמפ
  1. פרטי קשר וקישורים
  2. תקציר: לאיזה תפקיד אתם מכוונים ומה הרקע
  3. פרויקטים — כולל מה נבנה, באילו כלים ומה האתגר
  4. Stack טכנולוגי מקובץ
  5. השכלה, בוטקאמפ, קורסים והסמכות
  6. ניסיון תעסוקתי קודם, גם אם מתחום אחר
  7. התנדבות, קהילה ותרומה לקוד פתוח

Stack

מיפוי טכנולוגיות במקום רשימה

ארבע קבוצות קצרות נקראות מהר ומאפשרות למגייס למצוא את מה שהוא מחפש. הדוגמה כאן היא מבנה בלבד — מלאו רק כלים שאתם באמת עובדים איתם.

שפות

  • JavaScript / TypeScript
  • Python
  • Java
  • Go

פריימוורקים

  • React
  • Node.js
  • Django
  • Spring

נתונים

  • PostgreSQL
  • MongoDB
  • Redis
  • Elasticsearch

תשתיות וכלים

  • Docker
  • Kubernetes
  • AWS
  • CI/CD
  • Git

ניסוח

שורת ניסיון: לפני ואחרי

בשתי הגרסאות מופיעות אותן עובדות. ההבדל הוא בבהירות — מה נבנה, באילו כלים ולאיזו מטרה.

לפני

אחראי על פיתוח בצד השרת ותחזוקה שוטפת של המערכת, עבודה מול צוותים.

אחרי

פיתוח שירותי צד שרת ב-Node.js ו-PostgreSQL, כולל תחזוקה שוטפת של המערכת ועבודה מול צוות המוצר וצוות ה-QA בהגדרת דרישות ובדיקות.

לא נוספו מספרים או הישגים שלא הופיעו בטקסט המקורי — רק פירוט של מה שנאמר.

קישורים

GitHub, LinkedIn ופורטפוליו

קישור טוב חוסך למגייס עבודה. קישור שבור או פרופיל ריק עושים את ההפך.

GitHub

הפנו למאגרים שאתם גאים בהם, עם README שמסביר מה הפרויקט עושה ואיך מריצים אותו. עדיף שלושה מאגרים מסודרים מעשרים מאגרים נטושים.

LinkedIn

ודאו שהתפקידים והתאריכים תואמים למסמך. סתירה בין השניים היא אחת הסיבות הנפוצות לשאלות לא נוחות בשיחת המיון.

פורטפוליו או אתר

רלוונטי בעיקר לפרונטאנד, מוצר ודאטה. אם אין לכם אתר, אין צורך להמציא אחד — מאגר קוד מסודר ממלא את אותו תפקיד.

שפה

עברית מול אנגלית — מתי כל אחת

אפשר להחזיק את שתי הגרסאות ולשלוח לפי המשרה. התרגום המובנה יוצר טיוטה אנגלית שאתם עוברים עליה.

שיקולמסמך בעבריתמסמך באנגלית
סוג החברהחברות ישראליות, גופים ציבוריים, חברות שירותרב-לאומיות, סטארטאפים ששפת העבודה בהם אנגלית
שמות תפקידיםלעיתים תרגום פנימי שאינו מוכר בחו״למונחים סטנדרטיים שמזוהים בכל שוק
כיוון וכתיבRTL, עם מונחים לועזיים בתוך הטקסטLTR אחיד, קל יותר לקריאת stack
מי קוראמגייס מקומי שמכיר מוסדות ותארים ישראלייםמנהל או מגייס שאינו מכיר את ההקשר המקומי

תהליך

איך זה עובד ב-AiCV

ארבעה שלבים מהמסמך הריק ועד PDF שאפשר לשלוח.

  1. שלב 1

    בוחרים תבנית

    תבנית נקייה בעברית או באנגלית, עם או בלי תמונה אישית.

  2. שלב 2

    מדביקים תיאור משרה

    המערכת משווה את התוכן שלכם למונחים שמופיעים במשרה ומצביעה על פערים.

  3. שלב 3

    משפרים ניסוח

    ה-AI מציע ניסוח קצר וברור לכל שורה, ואתם מאשרים או דוחים כל הצעה.

  4. שלב 4

    מורידים PDF

    רואים תצוגה מקדימה מלאה, ורק אז משלמים תשלום חד-פעמי ומורידים.

לפני הגשה

טעויות נפוצות בקורות חיים להייטק

  • רשימת טכנולוגיות ארוכה שכוללת כל כלי שנראה אי פעם במצגת
  • גרפים ואחוזי שליטה במקום תיאור עבודה אמיתי
  • שורות ניסיון שמתארות תחומי אחריות בלבד, בלי מה שנבנה בפועל
  • קישור ל-GitHub ריק או למאגר שלא נגעו בו שנים
  • מסמך זהה לכל משרה, בלי התאמה לתיאור התפקיד
  • עומס עיצובי: שתי עמודות צפופות, אייקונים במקום מלל וטבלאות
  • כותרות תפקיד פנימיות שלא אומרות דבר למי שמחוץ לחברה

שאלות נפוצות — קורות חיים להייטק

עברית או אנגלית למשרת הייטק בישראל?

תלוי במעסיק. בחברות רב-לאומיות ובסטארטאפים שבהם שפת העבודה אנגלית, מסמך באנגלית נקרא טבעי יותר ועובר בקלות לצוותים בחו״ל. בחברות ישראליות, בגופים ציבוריים ובחברות שירות, עברית מקובלת לחלוטין. אם אתם לא בטוחים, אנגלית היא ברירת מחדל בטוחה למשרות פיתוח, ואפשר להחזיק את שתי הגרסאות ולשלוח לפי המשרה.

איך מציגים stack טכנולוגי בלי להפוך את המסמך לרשימת מילים?

מחלקים לקבוצות קצרות — שפות, פריימוורקים, בסיסי נתונים, תשתיות וכלים — ומשאירים רק מה שבאמת השתמשתם בו. אחר כך מוודאים שהכלים המרכזיים מופיעים גם בתוך שורות הניסיון, בהקשר של מה בניתם איתם. רשימה ארוכה בלי הקשר נראית כמו רשימת קניות ולא כמו ניסיון.

האם לציין רמת שליטה בכל טכנולוגיה?

עדיף לא בגרפים ולא באחוזים — הם לא ניתנים לאימות ולעיתים גם לא נקראים נכון בחילוץ טקסט. אם חשוב להבדיל, כתבו זאת במילים פשוטות, למשל להפריד בין כלים שאתם עובדים איתם יומיומית לבין כלים שהכרתם בפרויקט אחד.

מה עושים כשאין ניסיון תעסוקתי בפיתוח?

מעלים את הפרויקטים למעלה. פרויקט אישי, פרויקט גמר, בוטקאמפ או תרומה לקוד פתוח יכולים לתפוס את מקום הניסיון, בתנאי שכתוב מה בניתם, באילו כלים, מה היה האתגר ומה התוצאה. קישור למאגר קוד עובד שווה יותר מתיאור ארוך.

אילו קישורים כדאי לכלול?

GitHub או מאגר קוד אחר, LinkedIn מעודכן, ואם רלוונטי גם אתר או פורטפוליו. חשוב לוודא שהקישורים עובדים, שהפרופיל לא ריק ושמה שמופיע בו לא סותר את המסמך. קישור למאגר בלי README או בלי קוד עדכני עלול להזיק יותר מלעזור.

האם צריך להוסיף מספרים לכל שורה?

לא. מדדים משכנעים רק כשהם אמיתיים וכשאתם יכולים להסביר אותם בראיון. אם אין לכם מספר מדויק, תארו את ההיקף במילים — סוג המערכת, גודל הצוות, סוג המשתמשים או האתגר הטכני. אין לכתוב מספרים משוערים כאילו הם נמדדו.

כמה עמודים מתאימים למשרת הייטק?

עמוד אחד מספיק לרוב המועמדים עד כחמש שנות ניסיון. משם שני עמודים סבירים, בתנאי שהעמוד הראשון מכיל את החומר החזק ביותר. עדיף לקצר ניסיון ישן ולא רלוונטי לשורה אחת מאשר להאריך.

המשך קריאה

בנו גרסה שמתאימה למשרה הבאה

מלאו את החלקים, הדביקו תיאור משרה וראו את התוצאה בתצוגה מקדימה. התשלום חד-פעמי ורק בהורדת ה-PDF.

בונים וצופים בתוצאה לפני התשלום · תשלום חד-פעמי · ללא חידוש אוטומטי