זהו פוסט מספר i מתוך n במדריך "המקוצר" לקורות חיים למשרות הייטק. לא בטוחים מה קורה פה? כדאי לקרוא את המדריך מההתחלה.
ההתעסקות סביב הפרוייקטים לא נגמרה ברגע שרשמנו אותם בקורות החיים. כמו שאמרנו קודם, נקווה שבראיון עצמו המראיין יבקש ממך להסביר יותר על הפרוייקט, וכדאי מאוד להיות ערוכה לזה ולא לאלתר על המקום.
קודם כל, המראיין עשוי לבקש ממך לבחור את הפרוייקט שתציגי. לצערי, נתקלתי אפילו במתכנתים מנוסים שהבחירה הזאת הוציאה אותם משיווי משקל – למשל כי הפרוייקט מהעבודה הקודמת-קודמת שלהם יותר מרשים אבל הם כבר פחות זוכרים איך הוא עובד, ועכשיו הם מתלבטים מול המראיין איזה פרוייקט בכלל כדאי להציג. ראיון הוא סיטואציה מלחיצה לרוב האנשים, ורוב האנשים ילחצו עוד יותר כשהם צריכים פתאום לעשות בחירה, כך שמפה לשם, הראיון יכול להתדרדר די מהר כשהמרואיין מרגיש "מותקל". הכי פשוט לסדר לעצמך בראש את הפרוייקטים לפי הסדר בו את מעדיפה להציג אותם, ובנוסף לכך להיות ערוכה להציג את כל אחד מהפרוייקטים שרשומים בקו"ח גם אם הוא לא הפרוייקט המועדף עליך להצגה.
ראיון טיפוסי עשוי לקחת כשעה. לכן, כשאת מציגה פרוייקט, זה צריך לקחת כ-5 עד 10 דקות. את צריכה להיות מסוגלת לענות על כל שאלה סבירה שהמראיין ישאל על הפרוייקט, ולהסביר את המבנה של הקוד. אבל עוד לפני כן, ממש חשוב להתחיל מהסבר כללי, כך שגם אם המראיין לא מבין את הטכנולוגיה הרלבנטית, ההסבר יהיה ברור לו. יש לזה כמה סיבות:
- הרבה פעמים, אנשים שלא באמת מבינים במשהו כותבים סדרה של מלים מפוצצות בקורות חיים. כשהם מגיעים לראיין והמראיין מנסה לברר עוד פרטים, הם משתמשים בטקטיקה של לזרוק עוד ועוד מונחים טכניים ללא הרבה קוהרנטיות. התקווה שלהם היא לרוב שהמראיין יתבלבל ויחשוב "אוקיי, זה כנראה מסובך מדי בשביל שאבין בכל כך מעט זמן, אבל נראה שהוא מבין". מראיינים מנוסים אלרגיים לטקטיקה הזאת, וימהרו לקטלג אותך כאילו שזה מה שניסית לעשות, גם אם באמת ניסית להסביר להם אבל הם לא הבינו.
- הרבה פעמים הראיון הראשון דווקא יהיה סינון ראשוני ע"י אנשים לא טכניים מ-HR. הם עדיין מצפים להבין מה עשית ולנסות להעריך כמה זה מסובך, בלי קשר לשאלה אם הציפיה הזאת הגיונית או לא.
- חלק מהמראיינים הטכניים חושבים שזאת יכולת טכנית חשובה למתכנת להסביר בשפה פשוטה רעיונות מורכבים, למשל ג'ואל ספולסקי.
all things being equal, עדיף להציג פרוייקט שאת מתחברת אליו מאשר פרוייקט חובה שנפל עליך כי זה מה שנתנו לכולם לתכנת באותו סמסטר. למשל, אם בסדנה/מעבדה תכנתת סימולציה של ראוטרים באינטרנט כי את מתעניינת באספקטים של תקשורת ופרוטוקולים, יופי! תדברי על זה דקה או שתיים, ותסבירי למראיין למה התחום מעניין אותך, ואיך הפרוייקט מתקשר לעיסוק הכללי בתחום.
ועכשיו ל"מנה העיקרית" בהצגת הפרוייקט – ה-design. את תצטרכי להסביר למראיין בכמה דקות את הדיזיין של הקוד באופן שהוא יכול להבין מה הולך. רוב המראיינים יתנו לך דף ועט, ויעדיפו שתתחילי לצייר תרשימים של איזה קלאסים יש, מי קורא לפונקציות של מי, וכו'. אם הפרוייקט מורכב מכמה קומפוננטות, למשל DB ו-FrontEnd נפרדים, אז כדאי להציג גם את האינטראקציה בין הקומפוננטות השונות; גם פה, כדאי שזה יהיה תוך היעזרות בתרשים, מה שנקרא לפעמים "שרטוט ארכיטקטורה". וכמובן, הרציונל הרגיל של להציג כל מה שמרשים תקף גם פה: אם השתמשת ב-design patterns מסוימים, כדאי לציין את זה, ולהראות שאת מכירה את הקונספט. כנ"ל multithreading, או microservices, או reflection, וכו' וכו'.
רגע, אבל multithreading זה חומר חובה בקורס מערכות הפעלה, וגם OOP כולם יודעים, לא? לא! השונות בין סטודנטים, בין מוסדות לימוד, ובין מי שלמד קורסי בחירה מסוימים או אחרים היא גדולה מאוד, והמראיין ממש לא טרח לעקוב אחרי השינויים בסילבוס שהיו בפקולטה שלך לפני שנתיים. אם את יודעת, כדאי לך להדגים שאת יודעת.
בנוסף לקונספטי תכנות מרשימים, כדאי להציג פיצ'רים בפרוייקט, כמובן כמה שיותר מעניינים ומורכבים. יש מקום לספר גם על האתגרים העיקריים שהיו בפרוייקט מבחינתך.
הדרך הכי טובה לוודא שאת מציגה את הפרוייקט טוב היא כמובן להתאמן בזה. כדאי להתאמן לבד עד שאת מגיעה לרמת שאת מרוצה ממנה מבחינת שליטה ונינוחות בהצגה. אחרי שהגעת לרמה הזאת, כדאי לעשות לפחות "ראיון דמה" אחד עם חברה מהלימודים, או עדיף עם מישהו מהתעשיה (ואם הוא מראיין מדי פעם – אפילו יותר טוב). אנו נדון בהמשך באיך להתנהל במסגרת ראיון, אבל בינתיים ניקח הפסקה, ובפוסט הבא נחזור על החומר.