שלום לך. עד עכשיו, התייחסנו לקורות החיים כאלו הפרוייקטים, ובמיוחד הטכנולוגיות שאת מציגה נגזרו משמיים, ועכשיו נשאר רק לכתוב את קורות החיים כך שהן יציגו את הפרוייקטים והטכנולוגיות באופן אופטימלי. כמובן שזה לא בדיוק המצב – הפרוייקטים והטכנולוגיות בהן רוב הסטודנטיות משתמשות נקבעים לרוב ע"י סגל ההוראה. מכיוון שכך, הם הרבה פעמים נקבעים באופן לאו-דווקא אופטימלי להשתלבות בתעשיה: עם כל הרצון הטוב, באקדמיה קשה לעדכן חומרי לימוד כל כמה סמסטרים, לפי הקצב של התעשיה. (גילוי נאות: אני מרצה בקורס תכנות שמבוסס על פרוייקטים. אני משקיע הרבה זמן בלעדכן את הסילבוס, ומשתדל באופן כללי, אבל ברור לי שגם הקורס שלי לא חף מהבעיות הללו).

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

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

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

אז יאללה, נצלול לרשימת הטכנולוגיות, בחלוקה לפי שפה:

טכנולוגיות שרלבנטיות תמיד, ללא תלות בשפת התכנות

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

אם לא למדת לינוקס באוניברסיטה (מוזר, אבל זה אכן קורה בחלק מהמקומות), בהחלט שווה להשקיע את הזמן בקורס הזה, הזה, או הזה (כבוד ועוצמה למאמר הזה דרכו הגעתי לשני הקורסים הראשונים – תודה!)

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

בפוסט זה נסקור שני כלים כאלה: subversion, או בשמו המקוצר SVN, ו-git.

Git הוא הכלי החזק מבין השניים, אבל יותר קשה ללמוד אותו. להגיע לשליטה טובה ב-git, במיוחד במצב שכמה מתכנתות עובדות על קוד משותף, עשוי לקחת גם כמה שבועות למתכנת ותיק (מנסיון כואב). לכן, אם את מחפשת כלי שמאפשר לעבוד בנוחות על פרוייקט עם שותפה, למשל במהלך הסמסטר, אני ממליץ קודם כל ללמוד ולעבוד עם SVN, למרות שבימינו זה כבר כלי די מיושן. לחלופין, אם את מתכוונת להשתמש בכלי לבדך, כן הייתי הולך על git.

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

על מנת ללמוד git, הייתי מנסה את הקורס הזה. יש גם ספרים (מהם דווקא לא הייתי ממליץ ללמוד, אבל מה אכפת לי לתת לינק) על SVN ו-git. עדכון, 22.3.18, תודה לקורא ברוך: האתר הזה נותן טוטוריאל אינטראקטיבי נפלא ללימוד git (רק שימו לב שיש שני "טאבים" בתוך האתר, main ו-remote; החלק תחת remote הוא האתגר האמיתי שמסבך אנשים ב-git). התוכנה git extensions עשויה בהחלט לעזור למתחילים, ובנוסף אליה, כדאי לשלוט לפחות חלקית ב-git מה-command line.

באופן כללי, מומלץ להעלות את הפרוייקטים הכי מרשימים שלך לאתר בסגנון github (למרות שמו, האתר תומך לא רק ב-git אלא גם ב-SVN). כל קוד שאת מעלה, צריך כמובן להיות מדוגם ומצוחצח כמה שיותר – נדבר על כך בפוסט עתידי. בינתיים, אני ממליץ לפחות להשתמש בכלים הנלווים לכל שפה, המפורטים מטה, על מנת לשפר את איכות הקוד כמה שניתן.

כלים פר-שפה

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

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

עדכון, 22.3.18: נשאלתי בתגובות לגבי המושג "קונבנציית קוד": בארגונים מודרניים, מקובל שכולם כותבים את הקוד בסגנון אחיד. למשל, האם כותבים שם פונקציה באותיות קטנות, function_name, או באותיות מתחלפות, functionName? האם הסוגריים המסולסלים אחרי if נפתחים באותה שורה, או בשורה שמתחתיו? מה לגבי הסוגריים המסולסלים שפותחים פונקציה? בארגונים מודרניים, יש תשובות ברורות לכל השאלות הללו, כך שכל הקוד שנכתב בארגון נראה אחיד, בניגוד למצב "קוד שמשה כתב נראה ככה, וקוד שחזי כתב נראה אחרת". גם בחלק משפות התכנות מקובל שכל הקוד שנכתב בשפה, לא משנה באיזה ארגון הוא נכתב, הוא אחיד לגבי השאלות הללו. היכרות עם קונבנציית קוד סבירה תעיד עליך לטובה, וחשוב מכך: כשמעלים קוד לאתר בסגנון github כדאי לוודא שהוא אחיד, ואם יש קונבנציה מקובלת לשפה בה הוא נכתב, שהוא תואם לקונבנציה הזו.

כלים רלבנטיים לשפות C ו-++C

• קונבנציית הקוד של גוגל ל-CPP.
• עבור שפת C, הייתי מנסה לחקות את הקונבנציה של s2n, ספריית ההצפנה של אמזון שכתובה ב-C. לצערי אין להם בדיוק מסמך קונבנציית קוד, אלא יותר משהו בסגנון קווים מנחים.
  
• מומלץ לפרמט את הקוד באופן אוטומטי בעזרת clang-format. הכלי תומך במספר סגנונות פירמוט ידועים; בהיעדר העדפה אחרת, הייתי הולך על הסגנון של גוגל. כדאי לבדוק גם את הכלי הדומה clang-tidy; גם עבורו, הסגנון של גוגל הוא בחירה סבירה.
• Valgrind הוא כלי שמאפשר לזהות גישות שגויות לזיכרון במהלך ריצה של תוכנית, גם אם הן לא גורמות לקריסה של התוכנית.
• Makefile הוא כלי לארגון והאצת קומפילציה בלינוקס (פה יש מדריך נוסף).

כלים רלבנטיים ל-Java

גילוי נאות: אני שונא ג'אווה. אבל בשביל לעזור לצעירים בתחילת דרכם, אפילו עם ג'אווה אני מוכן לטנף את הידיים 😉 ההמלצות כאן גובשו בעזרתו הנדיבה של רון ביגמן, ראש צוות בחברת EMC.

• הקונבנציה של גוגל לקוד ג'אווה. ניתן להשתמש ב-Checkstyle כדי לאכוף את הקונבנציה הנ"ל.
• בג'אווה יש תרבות טסטים נרחבת, וכדאי להכיר את ספריית הטסטים JUnit. מי שמחפשת הזדמנות להתעמקות נוספת בטסטים, יכולה להשתמש בתרגיל הזה.
• כדאי להכיר את הכלי Maven, שהוא מעין מקבילה ל-Makefile.

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

• Tomcat הוא שרת web פופולרי.
• Spring היא framework פופולרית שכדאי להכיר, למרות שלהערכתי הלימוד שלה לוקח זמן, והייתי מגיע לזה אחרון, אם בכלל. נראה לי שעדיף להתחיל בעזרת Spring Boot, שמתיימרת 'לבחור בשבילך' בחירות סבירות, על מנת שתוכלי להתחיל במינימום זמן. מי שרוצה להתעמק ב-Spring עצמו, יכולה להיעזר למשל בשלושת המדריכים האלה.
• Scala היא שפה שמנסה לשלב את היתרונות של תכנות פונקציונלי עם היתרונות (הלא קיימים) של ג'אווה. היכרות ראשונית איתה יכולה להיות סעיף תומך נחמד בקורות החיים שלך. אפשר להתחיל ללמוד אותה פה, או פה (למתכנתות עם נסיון בג'אווה).

כלים רלבנטיים לשפת Python

הרשימה גובשה בעזרתו הנדיבה של יוני צפיר, מפתח בחברת JoyTunes. אגב, את פייתון אני דווקא אוהב 🙂

• קונבנציית הקוד של פייתון ידועה בשם PEP 8, ונוסחה בעזרתו של יוצר השפה, חידו ואן רוסום. יש גם קונבנציה של גוגל, שלא ברור לי כמה היא תורמת מעבר ל-PEP 8, אבל נשים לינק שיהיה.
• כדאי להשתמש בכלי pylint על מנת לזהות בעיות בקוד באופן אוטומטי.
• pip הוא כלי פופולרי לניהול אוטומטי של חבילות מותקנות.
• פה יש רשימה מומלצת של חבילות, וכדאי לשחק עם כמה מהן פה ושם ברגעי שעמום (ממש לא לעבור אחת-אחת – זה לא שווה את הזמן שלך; לבחור שתיים-שלוש ולשחק איתן).
• המקבילה הפייתונית ל-JUnit נקראת PyUnit, וכדאי להשתמש בה.

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

• אם אחד מהפרוייקטים שלך מאחסן נתונים באופן פרסיסטנטי, כדאי להשתמש ב-SQL.
• Docker הוא כלי פופולרי לאריזה של אפליקציות יחד עם התלויות שלהן – בגדול, הוא בא לפתור את הבעיה המוכרת "זה עובד לי על המחשב שלי, אז מוזר שזה לא עובד על המחשב שלך". פה יש מדריך כתוב, ופה יש קורס עם וידאו (יש גם חלק יותר מתקדם על טכנולוגיה בשם Kubernetes, שהוא 'אופציונלי' אפילו בהנתן שכל מה שכתוב בפוסט הזה הוא אופציונלי; אפשר ללמוד גם אותו, ולא הייתי מתקדם מעבר אליו).

יאללה, נראה לי שמספיק חפרתי. ביי בינתיים 🙂

הפוסט פורסם לראשונה באתר של הבלוג ב-The Marker

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

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

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

וכשאני כותב 'לסנן אנשים', אני לא מתכוון לתופעה זניחה, שאחוזים בודדים של סטודנטים נושרים מהתואר. אני מתכוון לאחוזי נשירה הנושקים ל-20%, אם לא יותר.

ניקח את הנתונים של אוניברסיטת ת"א ב-5 השנים האחרונות כדוגמה: [1]

שנת התחלה	טקס סיום	התחילו	סיימו	אחוזי נשירה
2013-2014	2017	229	169	26.2%
2012-2013	2016	244	156	36.1%
2011-2012	2015	204	161	21.1%
2010-2011	2014	202	163	19.3%
2009-2010	2013	242	198	18.2%
5 טקסי הסיום האחרונים, סה"כ		1121	847	24.4%

כמו ברוב התארים, רוב הסטודנטים שנושרים, נושרים בשנה א', שמורכבת רובה מקורסים מתמטיים. למשל בתואר חד חוגי במדעי המחשב, שנה א' מכילה 9 קורסים, מתוכם 6 הם קורסים מתמטיים. חלק גדול מהקושי הוא בשני קורסים מתמטיים בסמסטר הראשון של התואר, חדו"א 1 ומתמטיקה בדידה. אגב, התואר כולו מכיל 50 שעות של קורסים במתמטיקה [2], מתוך 122 שעות. כן, הבנתן נכון – סטודנטיות שרוצות ללמוד מדעי המחשב נאלצות ללמוד מתמטיקה במשך כשנה נטו מהתואר, או כ-40% מהתואר.
עדכון, 17.3.18: להלן התפלגויות הציונים בחדו"א ובבדידה, באדיבות האתר tau-factor. תודה!

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

 

אני כבר צופה מראש את ההתגוננות דה-לה-שמאטע מטעם בעלי השררה הנ"ל: "מתכנת לא שווה שום דבר בלי מתמטיקה". לפעמים המשפט הבא שמגיע הוא "מתמטיקה שימושית בהרבה תחומים במדעי המחשב, למשל הצפנה". באמת? יש לי כרגע רשימה בראש של שלושת המתכנתים הכי טובים שעבדתי איתם. לאף אחד מהם לא היה תואר, או ידע מתמטי נרחב.

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

זה כמובן נכון שיש תחומים במדעי המחשב שמצריכים ידע מתמטי. הצפנה היא בהחלט אחד מהם, ולהבנתי, כך גם data science. אבל אלו תחומים צרים יחסית, והרוב המוחלט של בוגרות תארים במדעי המחשב לא יעסקו בהם. רוב בוגרות התארים במדעי המחשב יפנו למשרות תכנות, שלא מצריכות ידע מתמטי נרחב. ואפילו בתחומים שמצריכים ידע מתמטי, מי שתרצה לעבוד במשרה בתחום, תצטרך להשלים ידע מעשי שלא נלמד באוניברסיטה [3]. מכיוון שממילא על מנת לעסוק בתחומים הללו צריך להשלים ידע, אני רואה מעט הגיון בלחייב את כולם ללמוד איזשהו בסיס ידע אקדמי, על מנת שמי שתרצה לעסוק בתחום עדיין תצטרך להשלים ידע, אבל פחות. אגב, מעניין שכשזה מגיע לפרקטיקות תכנות מודרניות, האוניברסיטה לא לחוצה להקנות לבוגרות ידע נרחב – את זה, מבחינת האוניברסיטה, שילמדו כבר בתעשיה. אבל מתמטיקה? מתמטיקה היא הבסיס עליו נשען העולם!

אגב, בתור דוגמאות להשלמת ידע מתמטי, אפשר להסתכל על מוקסי מרלינספייק, אחד ממומחי ההצפנה הבכירים בעולם, והאיש שאחראי להצפנה של WhatsApp, ועל אריק רסקורלה (כנ"ל), שאחראי להצפנה בדפדפן שלכם. למוקסי בכלל אין תואר, ולמעשה בצעירותו הוא חי כמה שנים בתור squatter. לאריק רסקורלה יש תואר ראשון בכימיה. מן הסתם, שניהם יודעים את הנושאים המתמטיים שרלבנטיים להצפנה, ברמה הרבה יותר גבוהה מבוגר תואר ראשון טיפוסי. רק שהם כנראה השלימו את הידע הזה ללא תואר רלבנטי – באותו אופן בו כל המתכנתים משלימים ידע שלא נלמד בתואר, וכאמור יש הרבה כזה.

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

 

…

*רעש רקע מוזר שנשמע קצת כמו מאבק*

…

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

אבל שניה לפני כן: בבקשה אל תבחרו תואר על סמך מאמר בבלוג. אנא מכן:

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

אז יאללה, ועכשיו באמת:

איך מקבלים תואר במדעי המחשב עם מינימום לימודי מתמטיקה, חלק א' – האוניברסיטה הפתוחה

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

הערה: המושג נקודת זכות, או בקיצור נ"ז, לרוב מתאר לימוד של שעה בשבוע לאורך סמסטר. למשל, בקורס של 4 נ"ז מתקיימות הרצאות פרונטליות במשך 4 שעות בשבוע לאורך סמסטר (ובנוסף לכך, רוב הקורסים מצריכים הכנת שיעורי בית בכל שבוע, והתכוננות לבחינה בסוף הסמסטר). נקודות זכות הן אומדן סביר, אך לא מושלם, להיקף הלימודים בתחום מסוים. רוב התארים מצריכים לימוד של כ-120 עד 130 נקודות זכות במצטבר, לאורך כשישה סמסטרים. כלומר 20 נקודות זכות הן כשישית מהתואר, שוב תחת ההסתייגות שנ"ז הן אומדן לא מושלם להשקעת זמן.

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

ממהרת ורוצה לקבל את השורה התחתונה בסקירת המסלולים? יש טבלה בסוף 🙂

1. אפשר להתחיל עם חטיבה במדעי המחשב – מערכות ויישומים:

החטיבה מכילה 24 נ"ז שמרכזות קורסים מתואר במדעי המחשב שבאמת רלבנטיים להשתלבות במשרות תכנות. מעיון זריז בסילבוסים, נראה שמבין קורסי הבחירה כדאי לקחת את: אלגוריתמיקה, מעבדה בתכנות מערכות, תכנות מתקדם בשפת Java, מערכות הפעלה, ואולי תכנות מונחה עצמים ומבוא לרשתות תקשורת מחשבים. התואר דורש רק כשני קורסים מתוך הרשימה הנ"ל, אבל להבנתי באוניברסיטה הפתוחה לא יעלבו אם תירשמי ליותר קורסים ממה שהתואר דורש. את כל הטוב הזה את יכולה ללמוד עם ארבעה קורסים מתמטיים, ברמת העמקה של מדעי החברה: נושאים במתמטיקה לתלמידי מדעי החברה, חשבון דיפרנציאלי לתלמידי כלכלה וניהול, ומבוא לסטטיסטיקה לתלמידי מדעי החברה א+ב. הקאץ' העיקרי הוא שאם רוצים בסוף לסיים תואר, אפשר לשלב את זה רק עם תואר בניהול.
כמו כל תואר, לפני שאת מתחילה, כדאי ליצור קשר עם יועץ לימודים של הפתוחה ולוודא שהתוכנית שלך נשמעת הגיונית.

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

2. אם שרדנו את זה, אפשר לשקול לשדרג לחוג במדעי המחשב – מערכות ויישומים לתואר דו-חוגי:

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

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

בנוסף ל-17 נ"ז במתמטיקה, יש עוד 45 נ"ז במדעי המחשב. כמו קודם, הן מכילות בעיקר את הקורסים שבאמת רלבנטיים להשתלבות במשרות תכנות (להבנתי, ותחת ההנחה שמתחשבים בהמלצות הנ"ל לגבי קורסי הבחירה).

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

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

 

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

 

3. מסלול רלבנטי נוסף הוא תואר בוגר במדעים בהדגשת מדעי המחשב. המסלול מכיל 23 נ"ז במתמטיקה, ברמה בינונית:

• בנוסף לקורס חדו"א א שליווה אותנו באופציה הקודמת, לומדים את קורס ההמשך, חדו"א ב. קורס ההמשך פחות סימפטי לטעמי, אבל גם פה, אם מתייחסים אליו בתור עוד קורס שצריך לעבור, הוא כנראה לא ביג דיל עדכון, 8.3.18: התפלגות הציונים של מועד א' האחרון של הקורס הגיעה לידי, ומה אני אגיד לכן, דווקא כן נראה כמו ביג דיל.
• בניגוד לשתי האופציות הקודמות, במסלול זה הידע באלגברה לינארית מוקנה ע"י הקורס "אלגברה לינארית לתלמידי מדעי הטבע". כך שאם את מתכננת לשדרג מהאופציות הקודמות, זה כנראה מצריך לזרוק את הקורס "נושאים במתמטיקה לתלמידי מדעי החברה". יכול להיות שאם כבר למדת את "נושאים במתמטיקה לתלמידי מדעי החברה", אפשר להגיש בקשה לועדת הוראה להסתפק בקורס הזה ולא לעשות עוד קורס באלגברה לינארית (אבל לא ידוע לי מה המדיניות בנוגע לבקשות כאלו, ויכול להיות שבקשה כזו תידחה מיד).
• בנוסף, המסלול כולל את הקורס במתמטיקה בדידה, שלא היה חלק משתי האופציות הקודמות. אני מכיר את הקורס, והייתי אומר שהוא ברמת קושי בינונית, וגם הוא לא ביג דיל אם בעיקר מנסים לעבור.
• ולסיום, המסלול כולל את הקורס "מבוא לסטטיסטיקה ולהסתברות למדעים", שהופיע גם באופציה הקודמת.
• אגב, המסלול כולל קורס עיוני בודד בפיזיקה.

למה שמישהי תרצה ללמוד במסלול הזה, ולא במסלול הקודם? יש למסלול הזה כמה יתרונות, שייתכן שמצדיקים את העליה המדודה ברמת המתמטיקה: המסלול מעניק תואר B.Sc., ואולי זה נראה קצת יותר טוב בתעודת סיום התואר. בנוסף לכך, זה המסלול 'המינימלי' המאפשר להמשיך לתואר שני, אחרי השלמות. האם זה שווה את זה? תלוי בך 🙂 אישית, הייתי מעריך שלמי שלימודי המתמטיקה לא מהווים עבורה נטל בלתי נסבל, ייתכן ששווה 'לשלם' בעוד 6 נ"ז, עליה מדודה ברמת המתמטיקה, וקורס בפיזיקה, עבור היתרונות הללו. עבור סטודנטים ש'מגרדים' בקושי 60 בקורסים מתמטיים, ורוצים להתמקד בלימודי התכנות כמה שיותר מהר, זה כנראה לא שווה את זה. אופציה אחת היא להתחיל מהקורסים חדוא א ומבוא לסטטיסטיקה, שמשותפים למסלול הזה ולמסלול הקודם, על מנת לאמוד את יחסך לקורסים מתמטיים, ולהמשיך משם. כמובן שגם פה, מומלץ להתייעץ עם יועץ לימודים.

 

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

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

אבל ממתמטיקה לא מתחמקים פה: התואר הזה כולל קורסי מתמטיקה שנה א' סטנדרטיים, כגון אינפי (אותו קורס שמתמטיקאיות לומדות), אלגברה לינארית (כנ"ל), וכו'.

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

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

 

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

 

לסיכום, להלן טבלה שמנסה לעשות סדר במסלולים, מסודרים בסדר עולה לפי היקף לימודי המתמטיקה:

תזכורת: הטבלה מבוססת על סקירה בסיסית שביצעתי, ועשויה לכלול טעויות!

מסלול	קורסים מתמטיים	נ"זים במדעי המחשב	קורסים שאפשר להעביר מהאופציה הקודמת	הערות וקאצ'ים
ניהול עם חטיבה במדעי המחשב – מערכות ויישומים	4, ברמת מדעי החברה	לפחות 20, בפועל כדאי כ-30		לא מאפשר להמשיך לתואר שני במדעי המחשב.
חוג במדעי המחשב – מערכות ויישומים לתואר דו-חוגי	4, ברמה בינונית	45	ניתן להעביר קורס אחד מתוך ה-4.	לא מאפשר להמשיך לתואר שני במדעי המחשב.
בוגר במדעים בהדגשת מדעי המחשב	5, ברמה בינונית	53 – 81	ניתן להעביר 2 קורסים מתוך ה-4.	צריך קורס בודד בפיזיקה. מקנה תואר B.Sc. מאפשר להמשיך לתואר שני, אחרי השלמות.
תואר דו חוגי במדעי המחשב ו-X	6, ברמה של מתמטיקאיות	42	לא ניתן להעביר.	הקורסים המתמטיים הם אותם קורסים שסטודנטיות למתמטיקה לומדות.

 

'מוניטין'

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

בכל מקרה, להבנתי במצב הנוכחי, ה'מוניטין' של האוניברסיטה הפתוחה מעט נמוך יותר מאשר מוסדות אחרים. אני לא רוצה לפרט יותר מדי כי זה לא הנושא של הפוסט, אבל להבנתי האוניברסיטה הפתוחה נתפסת בתור מוסד 'מהשורה השניה' – כלומר, אם נבקש מהמעסיק הטיפוסי לדרג את מוסדות הלימוד בארץ לפי המוניטין הנ"ל, היא תימצא אי שם במקומות 5-10. כל העניין הזה נראה לי כמו קשקוש, אבל זה כנראה מה ש(רוב) המעסיקים חושבים, וכדאי לקחת את זה בחשבון.

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

 

הפוסט נהיה כבר ארוך, אז ניפגש בפוסט ההמשך, בו נסקור אופציות במוסדות נוספים. ביי בינתיים 🙂

 

[1] המקור לנתונים לגבי סטודנטים שהתחילו את התואר בכל שנה הוא פה:
לוח 2.10.1.- סטודנטים חדשים לתואר ראשון באוניברסיטאות במקצועות לימוד נבחרים, לפי מין ומוסד.
המקור לנתונים לגבי סטודנטים שסיימו הוא פה.
שימו לב שסטודנטית שהתחילה את התואר באוקטובר 2013 וסיימה אותו בקיץ 2016, קיבלה את תעודת הסיום בטקס שהתקיים ב-2017.
סטודנטית שלמדה שני מקצועות, נמנית בכל אחד מהמקצועות בשני המקורות הנ"ל, כך שהנתונים אמורים להיות מדויקים, גם בהתחשב בסטודנטיות לתואר דו חוגי (להבנתי, מלבד סטודנטיות להנדסת מחשבים, ביואינפורמטיקה, ומדעי המח). אבל מן הסתם, לא עשיתי על זה עבודת דוקטורט, וייתכן שישנם אי דיוקים.

בכל מקרה, ההערכה שאחוז הנשירה מהתואר הוא באיזור ה-20%, אם לא יותר, היא ממש לא המצאה שלי – ראש החוג אף טען בשיחה פתוחה עם סטודנטים שאחוז הנשירה הוא 38%.

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

[2] אני מוסיף ל-36 + 8 = 44 השעות הרשומות בלינק את 6 השעות של מתמטיקה בדידה.

[3] לפחות בנושא הצפנה, נדמה לי שאני יודע על מה אני מדבר.

הפוסט פורסם לראשונה באתר של הבלוג ב-The Marker.

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

הכנה טכנית לראיונות

שאלות בראיון טכני עשויות לכלול אחד או יותר מהאלמנטים הבאים:

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

תכנות עם דף ועט

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

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

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

שאלות עם בעיה מוכרת

להלן כמה מקורות לשאלות עם בעיה מוכרת מהתואר:

• מבני נתונים: בחרי פעולה אחת מבין "הכנסה/חיפוש/מחיקה" ומבנה נתונים אחד מבין "עץ בינארי/טבלת האש/ערימה", וממשי את הפעולה הזו על המבנה הזה 🙂
• מיונים: בעיקר QuickSort ו-MergeSort. היי מוכנה גם להסביר למה הם רצים ב-O(n logn)
  
• אלגוריתמים על גרפים: בעיקר BFS, DFS, Dijkstra.
• תכנות דינמי: אפשר לתרגל בעזרת חומר מהתואר, או לחלופין פה.
• חיפוש בינארי: בעיקר לוודא שאת יודעת לתכנת חיפוש בינארי 🙂

שאלות של מציאת אלגוריתם

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

להלן כמה מקורות לשאלות מהסוג הזה:

• https://www.codeeval.com/
• https://leetcode.com/
• https://www.interviewbit.com/
• https://www.interviewcake.com/
• https://adventofcode.com/
• https://www.hiredintech.com/
• https://careercup.com/page
• https://arena.topcoder.com (easy and medium questions)
• http://www.geeksforgeeks.org/
• https://www.youtube.com/user/mycodeschool

תקשורת עם המראיינת

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

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

מומלץ להתכונן גם בעזרת ראיונות דמה, עם מתכנתות מנוסות, או עם חברות מהתואר.

בדיקת ידע בשפה

חלק מהמראיינים ישאלו אותך שאלות שכוללות דקלום כלל של שפת התכנות הרלבנטית. למשל, "מה זה אומר שמתודה היא protected בג'אווה?". אני לא ממליץ להתכונן יותר מדי לשאלות כאלו. כן כדאי לבדוק שאת מכירה היטב את הכללים שהגיוני שכולם ידעו. כדאי לעבור על כמה פיסות קוד שכתבת במהלך ההכנה לראיונות, ולוודא שאת יודעת להסביר או לתת הגדרה סבירה של כל הקונספטים שמופיעים בקוד.

קריאת קוד נתון, ומציאת באגים

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

תכנות מונחה עצמים

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

"A is a B”

צריך להיות נכון "בעולם האמיתי" (למעשה, אם ורק אם). למשל אם יש לנו קלאס של ציפור וקלאס של יונה, הקלאס של יונה ירש מהקלאס של ציפור, שכן

“A pigeon is a bird”.

(כמובן, תכנות מונחה עצמים זה עניין הרבה יותר מורכב. אבל לכל הפחות, חשוב לוודא שאתם לא נופלים על זה.)

הפגנת ידע במערכות הפעלה ורשתות

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

תקשורת:

• מהו מודל השכבות? איזה שכבות מרכיבות אותו, ומה תפקידה של כל שכבה?
• תארי איך עובד אחד הפרוטוקולים מבין TCP, HTTP, DNS. מה ההבדל בין TCP ל-UDP? (שאלה ממש פופולרית).
• מה זה subnet? מה ההבדל בין MAC address לכתובת IP? מה ההבדל בין סוויץ' וראוטר?

מערכות הפעלה:

• מה ההבדל בין thread ל-process? (גם שאלה פופולרית). איך ניתן להעביר מידע ולסנכרן בין threads? ובין processes? מה זה deadlock, ואיך נמנעים ממנו?
• מה זה זכרון וירטואלי? תארי בכלליות את הטיפול הטיפוסי ב-page fault.

 

זהו בינתיים. נתראה בפוסט הבא 🙂

הפוסט פורסם לראשונה באתר של הבלוג ב-The Marker.

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

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

בואי ניקח כדוגמה את המקרה שלי כסטודנט בשנה ג'. תחום העניין העיקרי שלי בתוך מדעי המחשב היה רשתות, ואכן רוב קורסי הבחירה שלי היו בנושא הזה. קורות החיים שלי שיקפו את זה, בעיקר כי הפרוייקט המרכזי שלי בתואר עסק בסימולציה של התנהגות של ראוטרים באינטרנט (הפרוייקטים הללו באוניברסיטת ת"א נקראים "סדנה"). מכיוון שכך, מראיינים שאלו אותי פה ושם שאלות בסגנון "וואלה, רשתות זה נושא מעניין, איך הגעת להתעניין בזה?". לפני שאדגים תשובה מוצלחת, אדגים את התשובה 'הנכונה' והמאוד לא-מוצלחת:

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

לחלופין, בואי נחשוב ביחד איך אפשר לענות תשובה קצת יותר מוצלחת, שמכילה רק דברים נכונים ולא יוצרת רושם מוטעה במיוחד. למשל, אפשר לענות: "תמיד התחברתי יותר לצד המעשי בתואר, של תכנות, מבני נתונים וכו', ופחות הוכחות ו-P!=NP. בת"א כל סטודנט צריך לבחור סדנה בתואר, ונוצרה הזדמנות שמרצה שממש נהניתי ללמוד אצלה בסמסטר קודם העבירה סדנה ברשתות, ועוד השותף הקבוע שלי לפרוייקטים גם רצה. כבר קודם היה ברור לי שאני רוצה להיות מתכנת, ולא תיאורטיקן כשאהיה גדול 🙂 אבל זה ספציפית מה שהכניס אותי לנושא של תקשורת, ובגלל שממש נהניתי מהסדנה, שאר קורסי הבחירה שלי בהמשך גם היו בנושא." אני מקווה שתסכימי איתי שהתשובה השניה צפויה ליצור רושם הרבה יותר טוב אצל כל מראיין, במיוחד אם הוא מזדהה עם המאמר שקישרתי אליו למעלה.

עד כה לגבי passion, ועכשיו לבטחון עצמי. גם פה – את לא שחקנית בטלנובלה, ואני לא ממליץ 'לשחק אותה'. הדגשים על שפת גוף מהפוסט בנושא יעשו את רוב העבודה, ואמורים למנוע ממך לשדר חוסר בטחון עצמי מופגן. מה שכן, למי שיש בעיות לחץ (תופעה נפוצה שאין מה להתבייש בה), כדאי לעבוד עליהן לפני תקופת חיפוש העבודה. אני בוודאי לא מומחה לנושא, אבל יכול לפחות להציע לנסות טכניקות הרגעות שונות (אני אישית ממליץ על מדיטציה, אבל מה שעובד בשבילכם – אולי זה?), ובמידת הצורך לעשות הרבה ראיונות דמה עם חברים, עד שרואים ש'העסק זורם'.

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

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

בתקופת הראיונות שלי לקראת סיום התואר, הגעתי לראיון במקום שלא שמעתי עליו יותר מדי, ולכן לא ידעתי אם אני מעוניין להגיע דווקא לשם. כצפוי, בשלב מסוים המראיין שאל אותי איזה נושאים מהתואר מעניינים אותי במיוחד, ועניתי שאני מתעניין ברשתות, בין השאר ב-TCP congestion control. מסיבות שלא היו ברורות לי, המראיין הגיב מיד שהעולם בדרך לרדת מהשימוש ב"פרוטוקולים כמו TCP, ובמקום זה עוברים לפרוטוקולים שמסוגלים להבטיח קצב תעבורה מסוים". לאלו מכם שטרם למדו קורסים בנושא: העמוד שאתם קוראים בדפדפן שלכם ברגע זה, הגיע למחשב שלכם באמצעות TCP, כמו (כמעט*) כל אתר אינטרנט אחר שאי פעם פתחתם. בשעתו, איך שהמראיין אמר את זה, חשבתי לעצמי: "אוקיי, נפתרה הדילמה. אם המנהלים שם עד כדי כך לא מבינים מהחיים שלהם, אני לא רוצה להגיע לשם". הגבתי למראיין ב"הממ, מעניין מאוד", והמשכתי להריץ את הראיון על טייס אוטומטי כשאני רק מחכה שהוא יסתיים. אח"כ, כשהגעתי למאמר אליו קישרתי למעלה, שמציע לסתור דברים נכונים שהמרואיין אומר, התחלתי לחשוב שאולי המראיין השתמש 'בחוכמה' בטקטיקה הזאת. (לאלו מכם שתוהים האם יכול להיות שאני פשוט לא מספיק passionate לגבי TCP congestion control: לצערי, אני חולם על זה בלילה.)

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

שאלות על החברה בסוף הראיון

בנוסף לשפת גוף, יש לך הזדמנות נוספת להדגים כמה את נלהבת (תרגום באדיבות גוגל טרנסלייט של המלה animated, אותה מחפש ג'ואל ספולסקי במרואייניו) בסוף הראיון, כשהמראיינת תשאל אותך אם יש לך שאלות. כפי שכתבתי בעבר – כן, יש לך שאלות, ועוד איזה! 🙂

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

זה לא קריטי מה בדיוק תשאלי, כל עוד את שואלת משהו על החברה (לא "מה תהיה המשכורת שלי" וכו'), וממשיכה לשמור על אווירה חיובית ולהפגין התעניינות. בנוסף לכך, זאת הזדמנות להראות למראיינת שעשית שיעורי בית, וקראת על החברה לפני הראיון: נסי למצוא דרך להפגין את זה, אפילו עם שאלה בסגנון "הבנתי שהמוצר שלכם עושה ככה וככה, ולכן הלקוחות הם חברות כאלה וכאלה – הבנתי נכון?". רוב המראיינים ישמחו להרחיב על מה המוצר שלהם עושה בתגובה לשאלה כזו.

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

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

השאלה על הג'וניורים שהגיעו בעבר היא הזדמנות טובה להבין מה הסיכוי שתגיעי ו'זה לא יסתדר', וכדאי לשאול אותה גם בראיון עם ראשת צוות, וגם בראיון HR. התשובה האידיאלית מבחינתך היא "בטח, כל שנה מגיעים כמה ג'וניורים, רובם ממשיכים בחברה כמה שנים". זה אידיאלי מכיוון שזאת אינדיקציה שהחברה יודעת לגייס ג'וניורים שמתאימים לחברה הזאת ספציפית, יודעת להכשיר אותם, ויודעת למה לצפות מהם. בפועל, אם אנשים נשארים כמה שנים, זאת אינדיקציה שההתקשרות כנראה היתה מועילה לשני הצדדים – החברה היתה מרוצה מהעובד, והעובד הג'וניור כנראה היה מספיק מרוצה, וכנראה הרגיש שהוא צובר מספיק נסיון כדי לא להחליף עבודה. שימי לב אם את מקבלת תשובות בסגנון "לא, את תהיי הראשונה" – אם יש לך אלטרנטיבות, לא ברור שכדאי להמר על חברה שבחיים לא שכרה ג'וניור, לא בהכרח יודעת למה לצפות, לא בהכרח יודעת איך להכשיר ג'וניור, וכו'. בדומה, כדאי לך 'להוריד נקודות' לחברה אם בעבר הגיעו ג'וניורים, אבל לא בשנים האחרונות, או שהגיעו ג'וניורים, אבל הם לא המשיכו בחברה תקופה משמעותית. המראיינת לא תנדב את המידע הזה, אז אם 'נדלקה אצלך נורה' שאולי יש פה בעיה, נסי לקחת את הדיון לכיוון של מספרים: נסי לשאול בזהירות "אפשר לשאול כמה בערך הגיעו? שניים-שלושה? עשרה?", "ואפשר לשאול כמה מהם עדיין עובדים אצלכם?".

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

זהו בינתיים. נתראה בפוסט הבא 🙂

* בשנים האחרונות יש את QUIC, פרוטוקול אחר שגוגל משתמשים בו לחלק מהאתרים שלהם. הראיון היה בערך עשר שנים לפני שגוגל התחילו להשתמש ב-QUIC.

הפוסט פורסם לראשונה באתר של הבלוג ב-The Marker.

אהלן חברים, היום נדבר על עובדה מרתקת שכולנו כמובן נתקלים בה בחיי היומיום, ונוגעת לחיים של כולנו, והיא
e^-2 ≈ 0.1
או בעברית: 10% מהאנשים יצטרכו לעבוד פי שתיים יותר קשה, סתם בגלל שהיה להם מזל רע.

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

בואו נדמיין אדם שמטיל מטבע, עד שהוא מקבל עץ בפעם הראשונה. הסיכוי לקבל עץ בהטלה ספציפית הוא חצי, ולכן נצפה שנצטרך להטיל את המטבע בערך פעמיים עד שנקבל עץ בפעם הראשונה [1].
אותו הגיון נכון, למשל, גם אם נטיל קוביה שוב ושוב, עד שהקוביה נוחתת על שש. הסיכוי שהקוביה תנחת על שש בגלגול אחד שלה הוא שישית, או אחד-לשש. עכשיו, אם נשאל "כמה פעמים נצפה שנצטרך לזרוק את הקוביה עד שנקבל שש בפעם הראשונה?", התשובה היא "בערך שש פעמים".

ובאופן כללי יותר, אם אנחנו מנסים משהו שוב ושוב עד שאנחנו מצליחים, והסיכוי להצליח בפעם נתונה הוא "אחד ל-X" (למשל: אחד לחמישים ושש), אז נצטרך לעשות בערך X נסיונות בממוצע עד שנצליח בפעם הראשונה (באותה דוגמה: נצטרך בערך חמישים ושש נסיונות עד שנצליח). סבבה? סבבה.
מיטיבות הלכת ביניכן מזהות כמובן את הטענה מקורס מבוא להסתברות: התוחלת של משתנה גיאומטרי עם סיכוי הצלחה 1/n היא n. אבל אם הבנתם עד "סבבה", הכל סבבה.

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

ועכשיו, נסבך את העלילה, ונשאל כמה ג'וניורים יצטרכו להתראיין בהרבה יותר מקומות, סתם בגלל שיש להם מזל רע? נניח, כמה ג'וניורים יכשלו בלפחות עשרה ראיונות? שימו לב: אני לא שואל "איזה אחוז מהג'וניורים הם משמעותית פחות טובים מהשאר" – לא. להיפך: אני מניח שכל הג'וניורים באשר הם טובים באותה מידה, ועוברים ראיון באותו סיכוי, אחד-לחמש. ועוד נשים לב שאני שואל "מבין הג'וניורים, שסיכמנו שכולם אותו דבר, כמה נדפקו ממש עם מזל רע וצריכים להתראיין ביותר מפי שתיים חברות מהצפוי?". כלומר, זה לא קצת מזל רע, טיפה לפה טיפה לשם. זה יותר מפי שתיים ראיונות מבאסים ממה שהיינו מצפים.

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

0.8 * 0.8 * … * 0.8 = 0.8¹⁰ = 0.1073 = 10%

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

0.9²⁰ = 0.1215 = 12%

והשוס הוא שהסיכוי עצמו כמעט לא משנה כאן – בהנחה שהסיכוי להצלחה קטן מרבע, זה לא משנה מה הסיכוי בדיוק, לפחות 10% מהאוכלוסיה יצטרכו לנסות יותר מפי שתיים פעמים מהצפוי, סתם בגלל שיש להם מזל רע!

למשל, אני מצרף פה טבלה עם סיכויי הצלחה עד אחד-לעשרים:

סיכוי במילים, אחד ל-	מזל ממש רע: פי שניים נסיונות	סיכוי הצלחה עשרוני	סיכוי כשלון עשרוני	סיכוי ליותר מפי שתיים נסיונות מהצפוי
2	4	0.50	0.50	6.25%
3	6	0.33	0.67	8.78%
4	8	0.25	0.75	10.01%
5	10	0.20	0.80	10.74%
6	12	0.17	0.83	11.22%
7	14	0.14	0.86	11.55%
8	16	0.13	0.88	11.81%
9	18	0.11	0.89	12.00%
10	20	0.10	0.90	12.16%
11	22	0.09	0.91	12.28%
12	24	0.08	0.92	12.39%
13	26	0.08	0.92	12.48%
14	28	0.07	0.93	12.56%
15	30	0.07	0.93	12.62%
16	32	0.06	0.94	12.68%
17	34	0.06	0.94	12.73%
18	36	0.06	0.94	12.77%
19	38	0.05	0.95	12.81%
20	40	0.05	0.95	12.85%

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

(1 – 1/n)²ⁿ ≈ e^-2 = 0.1353

וזה נכון ללא תלות בערך הספציפי של סיכוי ההצלחה, כל עוד n>=4. וכן, אני מעגל 13% ל-10%, תתמודדו 🙂

עכשיו, במבט ראשון זאת נראית כמו טענה די יומיומית – כן, יש אנשים עם מזל רע, ידוע. אני רק לא בטוח שכולם מבינים של-10% מהאנשים יש מזל ממש ממש רע, ברמה שהם צריכים לעבוד פי שתיים יותר קשה מהצפוי. וזה נכון בכל תחום [2]: 10% מהג'וניורים יתבאסו ויחשבו שיש להם בעיה לעבור ראיון, או להשיג ראיון, כשבעצם מה שקרה זה סתם מזל רע. 10% מהדוקטורנטים יחשבו שיש להם בעיה רצינית לכתוב את המאמר הראשון שיתקבל לפרסום, כששוב, זה הכל מזל רע. תחשבו על זה: אם היו בעולם מטילי קוביות מקצועיים, 10% ממטילי הקוביות הג'וניורים היו חושבים שהם לא טובים בעבודה שלהם!

ואת התוצאה הזאת עוד הוכחנו עם הנחות מחמירות: ההגדרה שלנו ל'מזל רע' היא 'יותר מפי שתיים מאמץ ובאסה מהצפוי'. וכמו שאמרנו, כמות האנשים הזאת היא בעצם לפחות 12% ברוב המקרים, שזה יותר מ-10% [3]. מה קורה כששואלים למשל, מה הסיכוי להתאמץ 'רק' 50% יותר מהצפוי ומעלה? התשובה היא שבערך e^-1.5 = 22% מהאנשים יצטרכו לעשות את זה – כמעט רבע מהאנשים!

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

אגב, אם שואלים כמה אנשים יצטרכו להתאמץ יותר מכמה שצפוי עבורם אישית – לא פי שתיים יותר, אפילו רק טיפה יותר – התשובה היא יותר משליש מהאנשים! [4]

X ~ Geom(p) => P(X > 1/p) = (1-p)^1/p ≈ e^-1 = 37%

המסקנה המתבקשת מהתרגיל המחשבתי הזה היא 'לא להתייאש', ובגלל שזה ברור ואת זה כולם אומרים, לא נראה לי שיש טעם להתעכב עליה.
המסקנה הפחות ברורה, אבל לטעמי יותר חשובה פה, היא שלא כל דבר מבאס שקורה לכם בחיים, קורה בגללכם, בטח כשמדובר בראיונות. Don't get me wrong: כדאי לעצור אחרי כל ראיון, לשאול מה הלך טוב ומה פחות טוב, ולנסות לשפר להבא. אבל ממש לא כדאי לקפוץ למסקנות לגבי הסיכוי שלכם להשתלב בתעשיה אחרי כל ראיון שלא הלך, ובטח ובטח שלא כדאי להגיע לקטעים של האשמה עצמית וכו'.

אמרנו בעבר, ונגיד שוב: ראיונות זה numbers game, וחלק מהזמן הסיכויים יפעלו שלא לטובתכם. נתראה בפוסט הבא, ועד אז may the odds be ever in your favour 🙂

 

[1] התגוננות מראש לדקדקנים מתמטיים סביב הניסוח הלא פורמלי: תוחלת = מה שמייחלים לו = מה שמצפים לו. גם באנגלית: Expected value.

[2] בכל תחום בו אפשר לטעון שהצלחה נראית בערך כמו הצלחה ראשונה בסדרת ניסויי ברנולי בלתי תלויים שווי-התפלגות עם סיכוי הצלחה 1/n, n>=4. בחיי, 15 שנה אחרי שנה א', ואני עדיין לחוץ שיורידו לי נקודות על חוסר פורמליות 🙂

[3] לצרכי הטענה הזו, ברוב המקרים <=> כשסיכוי ההצלחה הוא 1/n , ו-n>=9

[4] מהאנשים עבורם 0.14>p, ואם p לא מהצורה 1/n אז צריך לקחת את הערך השלם של 1/p במעריך. בודק יקר, אני פונה ללב שלך, נגמר לי הזמן במבחן להצדקות פורמליות, אנא גלה רחמים.

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

 

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

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

 

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

לאחר שתתיישבו, המראיינת לרוב תספר טיפה יותר על עצמה ועל המשרה. למשל: "אז היי, אני שושנה, אני ראשת צוות DOS, הצוות הוא אחד מכמה צוותים פה בקבוצת הפיתוח. בחברה שלנו מפתחים בעיקר ב-C בעזרת Turbo Debugger. המוצר העיקרי שלנו הוא קומפיילר שעושה כך וכך, אבל לפני שאני מספרת עליו, אשמח לשמוע קצת עליך". יש מראיינות שיתנו הקדמה של כמה משפטים ספורים כמו בדוגמה הזו, ואז יעבירו את הכדור אליכם ויבקשו שתספרו קצת על עצמכם. מראיינות אחרות כן ירחיבו בכמה דקות ישר בתחילת הראיון על מה החברה עושה, ובאיזה טכנולוגיות היא משתמשת. אם המראיינת חופרת מדברת כמה דקות, כדאי לתת לה פידבק חיובי לא-מילולי שאתם מקשיבים ושהיא לא איבדה אתכם, כפי שלמדנו בפוסט הקודם. בכל מקרה, די מוקדם בתחילת הראיון, המראיינת תבקש שתספרו על עצמכם, ועכשיו האקשן מתחיל 🙂

 

לטעמי, הדרך הכי חיובית להציג את עצמכם היא להסביר בכמה משפטים מה הרקע הרלבנטי שלכם, תוך כדי שאתם מוסיפים כמה פרטים שנותנים לאינטראקציה נופך מעט אישי. למשל, דמיינו מועמד שעונה בקול הכי רובוטי שאפשר לדמיין: "אני משה; סטודנט שנה ב' בבן גוריון; end;" – זה לא מה שאתם רוצים לעשות 🙂

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

אם יש מידע מקצועי רלבנטי שמייחד אתכם ויעניין את החברה, כדאי להזכיר אותו במשפט או שניים כחלק מה-pitch הראשוני. למשל להמשיך ב-"האמת שאני ממש מתעניינת בקומפיילרים, לקחתי את הקורס בקומפילציה כקורס בחירה, ואפילו כתבתי קומפיילר צעצוע ל-Lisp באיזה סופ"ש בשביל הכיף; בגלל זה המוצר שלכם נראה לי ממש מעניין וזו אחת הסיבות שהגשתי מועמדות אליכם". לרוב לא יהיה לכם משהו כזה להוסיף, ואז אפשר להוסיף משפט גנרי בסגנון "אני מחפשת את העבודה הראשונה שלי בתעשיה, הדבר שהכי חשוב לי הוא ללמוד כמה שיותר ולהתפתח מקצועית כמתכנתת". אם אתם יכולים להוסיף בכנות סיבה שבחרתם להתראיין דווקא בחברה הזו, זה כמובן מבורך, למשל: "שמעתי שהרמה המקצועית אצלכם גבוהה, ולכן החברה שלכם נראית לי כמו מקום מצוין להתפתח מקצועית".

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

 

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

 

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

 

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

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

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

גם לגבי הופעה, הרציונל הוא בסה"כ שצריך להימנע ממשהו שעשוי להיתפס כמזלזל. אם אתם כמוני, ונוטים להסתובב עם שיער (או זקן) מדובלל חלק מהזמן, עדיף להימנע מכך בראיון (וכמו כן, אתם מוזמנים להצטרף אליי בחזרה ולהתפרע עם סיום תקופת הראיונות 🙂 ). זה לא מסדר צבאי, ואין צורך להגיע עם תספורת או גילוח תקניים, אבל כן כדאי להשקיע כמה דקות ולהגיע בהופעה 'מסודרת'. להבנתי, אין צורך להשקיע בהופעה מעבר ל-baseline הזה.

זהו בינתיים. שנה טובה, ונתראה בפוסט הבא 🙂

הפוסט פורסם לראשונה באתר של הבלוג ב-The Marker

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

 

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

 

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

אולי אתם אומרים לעצמכם "אוקיי, זה כנראה היה ככה בשנות השבעים, אבל סביר שהתקדמנו קצת מאז"? אז אולי התקדמנו, אבל כנראה שלא הרבה. לא מזמן ליוויתי קרובת משפחה לפגישת יעוץ סביב איזה תואר ראשון ללמוד, עם יועץ של אחד מהמוסדות האקדמיים. הגענו מראש כשנראה לשנינו שהכיוון הוא תואר דו חוגי במדעי המחשב וביולוגיה (כמו שאתם רואים, מצב נפוץ במשפחה שלי 😉 מה אני אגיד לכם, לא לקח לו הרבה זמן להגיד לה שהתואר הזה יהיה קשה לה מדי, להציע לה "לדלל" את מדעי המחשב עם חוג נוסף אבל בפסיכולוגיה, להזהיר אותה מהקושי של הקורסים המתמטיים בתואר, ובגדול להוציא לה את הרוח מהמפרשים. ומדובר במישהי שאין סיבה מיוחדת לפקפק ביכולת שלה לסיים תואר במדעי המחשב: היא יכולה להתקבל אוטומטית לתואר הזה בכל מוסד אקדמי בארץ, קיבלה ציון גבוה בחלק הכמותי של הפסיכומטרי, ואם כל זה לא מספיק, שני ההורים שלה וגם אחותה מתכנתים (כן כן, משפחה שכזו… :-). אני מת לשמוע האם יש מישהו שחושב שגם בחורים עם נתונים דומים מקבלים תגובות דומות כשהם אומרים שהם מתכננים ללמוד מדעי המחשב. אני יכול לומר לכם שאישית, לא קיבלתי שום תגובה שקרובה לזה.

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

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

מה שכן, בהיעדר יכולת להתייעץ בצורה נורמלית בנושא ה"זניח" שלפנינו, "לאיזה כיוון לקחת את החיים שלכן", אולי כדאי שאציע פתרון חלקי. רק להבהיר, אנחנו דנים במצב הדי ספציפי הבא: "אני בחורה די ריאלית, ללא העדפה מסוימת לתחום מסוים מבין התחומים הריאליים. חשבתי ללמוד מדעי המחשב, אבל מדי פעם רומזים לי שעדיף לזרום לכיוון ביולוגיה או כימיה. מה ללמוד?". כמובן, אפשר וכדאי להציע עזרה בבחירת כיוון גם לנשים וגברים ללא נטיות ריאליות, אבל קטונתי מלהציע אותה. ועוד להבהיר: לי בוודאי אין מונופול על חוכמת החיים בעולם, ותמיד כדאי לשמוע דעה נוספת, גם תחת הסיכון שתיפלו על מישהו מטומטם (שלא לומר שהסיכוי הזה קיים גם פה). אחרי כל ההסתייגויות, יאללה לעניין.

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

 

"אבל אני באמת לא יודעת אם מדעי המחשב זה בשבילי, אני אפילו לא יודעת לתכנת!"
קודם כל, מוזר לי שהטיעון המקביל לא עולה כשדנים בכימיה וביולוגיה. שם את כן יודעת לעשות עבודה של ביולוגית או כימאית? לא? אז מה ההבדל? 🙂 אבל כן, כשבוחרים תואר, קשה מאוד לדעת האם זה מתאים. יתרון אחד של תואר במדעי המחשב הוא שזול להעריך: אפשר ללמוד תכנות בעזרת קורסי אונליין, או ב-She-codes. She-codes הוא ארגון בו (בין השאר) נשים מלמדות נשים לתכנת, באווירה תומכת וללא תשלום. הן בדיוק פותחות את מסלולי הלימוד באוניברסיטת ת"א, אז אם את מאזור המרכז, עכשיו בכלל יש לך הזדמנות מצוינת להצטרף.
בכל מקרה, לדעתי יש פה יתרון קל דווקא למדעי המחשב: אם למדת לתכנת ונראה לך שזה בשבילך, למה לא ללכת על זה? אם לא למדת לתכנת, וגם לא למדת תחומים אחרים ברמה גבוהה, לכאורה אין סיבה להעדיף אחד על השני. אם הרחבת את הבגרות בביולוגיה או כימיה, קטונתי מלומר כמה הבגרות משקפת את העבודה בקריירה בתחומים הללו. לכל הפחות, אני מקווה שתסכימי שכדאי לשקול היטב במה לעשות תואר, ולאו דווקא לזרום עם נושא שהרחבת בבגרות. אותו רציונל תקף כמובן גם למדעי המחשב: אם את לא יודעת לתכנת, יש הגיון בלהשקיע כמה חודשים וללמוד תכנות "באיזי" בערבים, לפני שנכנסים למחויבות כמו תואר.

כמו כן, אם את מתלבטת בין מדעי המחשב ותחום נוסף, אולי אוכל לעניין אותך באפשרות של תואר דו חוגי במדעי המחשב ובתחום הנוסף? זה שומר על שתי האופציות פתוחות בהמשך, הן לגבי העסקה והן לגבי תואר שני. ואפילו יותר מזה: אם תרצי להמשיך למחקר בתחום השני, ידע בתכנות הוא נכס שימושי לכל תחום מחקרי (להבנתי, כולל תחומים במדעי החברה כגון פסיכולוגיה). וגם אם תפני לתעשיה בתחום אחר, תכנות הוא עוד כלי שימושי שכדאי שיהיה לך בארגז. לרוב הוא תורם לא פחות מהאלטרנטיבה שיש ברוב התארים החד חוגיים: קורס בחירה בשנה ג' בתת-נושא הכי נישתי בעולם. ולמקרה שתהית, אין הבדל ניכר בכישורי התכנות שתרכשי בתואר דו חוגי או חד חוגי במדעי המחשב.

אם מה שעוצר אותך הוא הליך הקבלה לתואר במדעי המחשב, חשוב לי שתדעי שדי קל לשפר את ממוצע הבגרות שלך. רוב המכונים ימליצו לך להוסיף שלוש יחידות בתנ"ך, היסטוריה וספרות, וכך יהיו לך חמש יחידות במקצועות הללו. במצב הזה, את מקבלת בונוס של 25 נקודות לכל מקצוע שהרחבת, והממוצע עולה די מהר. למועמדות רבות, הרחבה של שניים מהמקצועות הללו תספיק בשביל להתקבל. כמובן שמומלץ לוודא את המצב בעזרת אתרי הקבלה של המוסדות השונים, וכמובן שזה תלוי בציונים הקיימים ובפסיכומטרי. את ההרחבות הללו ניתן לעשות רק במועד קיץ, ולא במועד חורף. השקעת הזמן פה לא ענקית: הקורסים לרוב מתחילים במרץ, הבחינות ביוני, וכל הרחבה דורשת לימוד של כיומיים מלאים בשבוע. אם זה מה שעומד בינך ובין תואר במדעי המחשב – תאמיני לי שההשקעה הזו, של כולה שלושה חודשים, שווה את זה. (אני מקווה להתייחס בעתיד בצורה יותר מעמיקה לנושא הקבלה לתואר).

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

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

 

הפוסט פורסם לראשונה באתר של הבלוג ב-The Marker

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

 

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

בעצם בואו ננסה לחסוך למראיינת עוד התעסקות: לא רק שאפשר לחסוך לה את העיסוק באישיות המועמד, אולי אפשר לחסוך את כל הראיון? הרי אפשר להעביר למועמד מבחן בכתב. בשביל זה מספיק זמן של המתכנת הכי זוטר בצוות, למענה על שאלות (ואולי אפילו לא זה), ואפשר לבחון הרבה יותר מועמדים בעלות נמוכה יותר. והרי זה לא שיש סיבות מיוחדות להאמין שעדיף לשאול מועמד פנים אל פנים מה ההבדל בין TCP ו-UDP, מאשר לשאול אותו בכתב, נכון?

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

כלומר המסקנה היא שלטוב ולרע, ה-cognitive biases שמושפעים משפת גוף וסגנון התנסחות ישחקו תפקיד בראיונות. וזאת ממש לא הסיטואציה היחידה בחיים בה דברים כאלה משחקים תפקיד – אלפי אנשי מכירות לא טועים 😉

בדיוק השבוע דיברתי על זה עם מכר שלי, שהיה מנהל בכיר בארגון טכנולוגי גדול, וכמובן גייס לא מעט אנשים לאורך השנים. אם עוד לא השתכנעתם, נדמה לי שהתגובה שלו תבהיר את העניין סופית: """מה אכפת לי אם יש לו ממוצע 85 או 82? אני מסתכל במיוחד על דברים אישיותיים בולטים, כמו האם המועמד פיקד על אנשים בצבא, או אפילו אם הוא היה רשג"ד בצופים. תוך כדי הראיון אני מנסה להעריך אותו כאדם, ומשתמש באינטואיציה שלי כדי להעריך איך הוא ישתלב בחברה.""" (כן, גם אותי הקטע עם רשג"ד בצופים הפיל מהכיסא 🙂

 

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

 

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

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

 

• שפת גוף פתוחה וחיובית – ראיון הוא כמובן סיטואציה מלחיצה, וכשאנשים נלחצים הם נוטים לכווץ את שפת הגוף שלהם: לשלב ידיים, לקרב את הכתפיים, ולכופף את הגב. נסו להימנע מהדברים האלה. הם יוצרים אווירה לא טובה, וגם ממשיכים אצלכם את תחושת הלחץ, במקום להשתחרר ככל שהדקות עוברות בראיון ואתם רואים שהמראיין לא מפלצת. גם אל תעשו את ההיפך: לא כדאי להתפרש בכיסא בפישוק רגליים ו"לארג'יות". כדאי פשוט לנטרל את ההתנהגות הסגורה: נסו להביא את הגב והכתפיים למצב נטרלי ונוח. אל "תישפכו" לתוך הכיסא, אלא שבו בגב זקוף. אם אתם לא בטוחים מה לעשות עם הידיים כי כרגע אתם לא כותבים או מדגימים משהו, אפשר לשים אותן בצורה לא משולבת על הברכיים, או על משענות הכיסא. (ובמיוחד, אל תעשו תנועות עצבניות עם הידיים מתוך חוסר-מעש, מה שנקרא בלעז don't fidget).

 

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

שימו לב במיוחד לנקודות האלה בזמן שהמראיין מדבר ואתם מקשיבים – כפי שכתבתי, במצבים האלה קל לאבד ריכוז 🙂

 

מדי פעם, לפני שאני מציע למכר לעשות ראיון דמה ולהתמקד בתקשורת, אני שומע את התגובה הנפוצה "למה שאצטרך את זה? אני יודע לדבר עם אנשים, אני גם ככה עושה את זה בחיים :-)". מנסיוני, גם אנשים חברותיים מאוד עשויים ליפול בדברים האלה. קל מאוד להקרין לחץ ותחושת אי נוחות בראיון, פשוט כי זה מה שאתם מרגישים. ובאופן עוד יותר בולט מנסיוני, אנשים לא מקפידים במצב הזה על קשר עין, גם כנראה מתוך לחץ. אם הקשבתם לעצתי מהפוסטים הקודמים בנושא, אתם ממילא עושים ראיון דמה מתישהו, עם מתכנתת ותיקה שיצא לה לראיין, או עם חברים מהלימודים. אני ממש ממליץ לבקש מהמראיין-דמה שישים דגש על הנושא הזה, ובאותה הזדמנות יראיין אתכם גם על ההצגה הראשונית שלכם (נדון בהצגה הראשונית בפוסט עתידי). זה לא יאריך את ראיון הדמה כמעט בכלום, ובהחלט עשוי לעזור (ואם לא – לא הרווחתם, וגם לא הפסדתם). גם אם אתם עושים ראיון דמה עם חבר מהלימודים שלא מנוסה בראיונות, בקשו ממנו לשים לב כל כמה דקות לאווירה בראיון כפי שהוא תופס אותה (ואם יש לו כח לקרוא קודם את הפוסט הזה, כדי לקבל רעיונות לאיזה דברים לשים לב – עוד יותר טוב 🙂

 

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

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

לא בטוחים מה בכלל קורה פה? כדאי לקרוא את המדריך מההתחלה.

 

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

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

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

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

חלק מהמראיינים פשוט ישאלו אותך שאלות שכוללות דקלום כלל של שפת התכנות הרלבנטית. למשל, "מה זה אומר שמתודה היא protected בג'אווה? מאיפה אפשר ומאיפה אי אפשר לקרוא לה?". אם את מרימה כרגע גבה, אני מבין למה… הרי אם הכלל הוא משהו שנתקלים בו במסגרת התכנות השוטף בשפה, כולם יענו בלי בעיה והשאלה לא מאפשרת לעמוד על טיבה של מועמדת. ואם הכלל הוא מקרה איזוטרי שלא מעניין אף אחד, סביר שיהיו מועמדים חזקים שלא ידעו דווקא את הטריוויה הזו בשלוף. למשל: "מני את כל השימושים האפשריים של ה-keyword static בשפת C, והסבירי מה כל אחד מהם עושה" (אגב, קריאה מומלצת לפני השינה).

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

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

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

קריאת קוד נתון, לרוב כולל מציאת באגים בקוד

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

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

תכנות מונחה עצמים

שאלות בנושא לרוב מציגות בעיה "מהעולם האמיתי", ומבקשות להציע מבנה קלאסים מתאים. למשל, "נניח שהיינו רוצים לתכנת משחק מונופול למחשב. אילו קלאסים את חושבת שצריכים להיות במערכת, אילו מתודות עיקריות יש לכל קלאס, ומי יורש ממי?". או "דמייני שאנחנו כותבים משחק סימולציה של חווה בסגנון FarmVille, שצריך לתמוך בסוגי החיות הבאים […]. אילו קלאסים יהיו במערכת, ומי יורש ממי?".

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

"A is a B”

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

“A pigeon is a bird”.

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

הפגנת ידע במערכות הפעלה ורשתות

במשרות עבורן הידע הזה דרוש, המראיינת עשויה לבקש ממך להסביר קונספטים במערכות הפעלה ו/או רשתות. לרוב המראיינת תרצה שתתארי איך משהו עובד, או תסבירי מה ההבדל בין שני קונספטים דומים. החלק הזה לרוב לא יכלול כתיבת קוד, אלא הסבר מילולי בלבד. בניגוד לשאלות ממבחנים באוניברסיטה, המראיינת לרוב לא תצפה להתפלפלות סביב תת-מקרה חריג, אלא שתשלטי בעיקר הדברים ובמקרים טיפוסיים. למשל, היא תשאל מה ההבדל בין TCP ו-UDP, לא מה זה Silly Window Syndrome.

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

• מהו מודל השכבות? אילו שכבות מרכיבות אותו, ומה תפקידה של כל שכבה?
• תארי איך עובד אחד מהפרוטוקולים הנפוצים באינטרנט, למשל TCP, HTTP, DNS. מה ההבדל בין TCP ל-UDP? (אגב, מנסיוני השאלה האחרונה היא ממש פופולרית, אני לא בטוח למה).
• מה זה subnet? מה ההבדל בין MAC address לכתובת IP? מה ההבדל בין סוויץ' וראוטר?

מערכות הפעלה:

• מה ההבדל בין thread ל-process? (אגב, גם זו שאלה נורא פופולרית).
• איך ניתן להעביר מידע ולסנכרן בין threads? (המראיינת מצפה שתזכירי לפחות מנגנון סנכרון פופולרי אחד, למשל semaphore, mutex, Java synchronized methods.)
• איך אפשר להעביר מידע בין processes? (תשובה אפשרית אחת: sockets)
• מה זה deadlock, ואיך נמנעים ממנו?
• מה זה זכרון וירטואלי? תארי בכלליות את הטיפול הטיפוסי ב-page fault.

 

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

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

 

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

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

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

בסוף הראיון, לרוב ישארו כמה דקות לשאלות שאת אולי רוצה לשאול את המראיינת. לרוב יסתבר שאת אכן רוצה לשאול משהו 🙂 גם בזה נדון בהזדמנות אחרת.

 

שאלות בראיון טכני עשויות לכלול אחד או יותר מהאלמנטים הבאים:

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

(כמובן, אלו לא כל הנושאים האפשריים לשאלות, אבל להערכתי, הרשימה הזו נותנת כיסוי סביר).

 

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

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

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

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

 

אז יאללה, נפסיק להתבכיין ביחד ונתחיל לתרגל 🙂 בכל תרגיל תכנות, לאחר שכתבת פתרון על נייר, מומלץ להקליד אותו למחשב ולמצוא את הבאגים – ויהיו באגים, בטח בפעמים הראשונות. כל באג שאת מוצאת הוא לא סימן שלעולם לא תתקבלי למשרת תכנות ותחיי כהומלסית, אלא מהמורה קטנה בדרך שממנה אפשר ללמוד. כדאי להבין למה הבאג קרה, והאם הוא נופל לקטגוריה של באגים פופולריים: למשל "חוסר טיפול במקרה הריק", או "חסר פה פלוס/מינוס 1". מנסיוני, רוב הבאגים נופלים לכמה קטגוריות כאלו, ואחרי כמה תרגילים שפתרת, תראי שאת מתחילה לשים לב לנקודות הללו אוטומטית.

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

 

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

• מבני נתונים: המראיינת עשויה לבקש שתתכנתי פעולה על מבנה נתונים קלאסי, למשל "הכנסה לעץ חיפוש בינארי". מבני הנתונים הללו הם בעיקר: עץ חיפוש, טבלת האש, וערימה, והפעולות הרלבנטיות הן בעיקר הכנסה, מחיקה, וחיפוש. בהקשר של עצים יש גם סריקות pre/in/post-order, מציאת איבר עוקב, וכו'. אני מציע לבחור אקראית כמה מצבים כאלה, ולתרגל בעזרתם. זאת הזדמנות טובה לוודא שאת זוכרת איך מבני הנתונים הקלאסיים עובדים, כולל הסיבוכיות שלהם, כי את עשויה להישאל על זה גם בע"פ 🙂
• מיונים: כדאי לשלוט בעיקר ב-QuickSort ו-MergeSort, כך שתוכלי להסביר איך הם עובדים ולתכנת אותם. כדאי גם להיות מסוגלת להסביר למה הם רצים ב-(O(n logn, בפורמט של הסבר אינטואיטיבי, לא הוכחה פורמלית.
• אלגוריתמים על גרפים: BFS, DFS, Dijkstra הם בגדר "חובה", ואת בהחלט עשויה להישאל עליהם. ייתכן שכדאי לחזור גם על Bellman-Ford ו-Floyd-Warshall. להבנתי, לא נהוג לשאול על אלגוריתמי גרפים נוספים.
• תכנות דינמי: אם יש לך חומר בנושא מהתואר ואת יודעת להתמצא בו, הייתי לומד ממנו ומתכנת את תרגילי הבית בנושא. אם לא, פה יש הרצאות עם דוגמאות.
• חיפוש בינארי – אין פה הרבה מה להרחיב, בעיקר לוודא שאת יודעת לתכנת חיפוש בינארי 🙂

 

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

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

• https://www.codeeval.com/
• https://leetcode.com/
• https://www.interviewbit.com/
• https://www.interviewcake.com/
• https://adventofcode.com/
• https://www.hiredintech.com/
• https://careercup.com/page
• https://arena.topcoder.com (easy and medium questions)
• http://www.geeksforgeeks.org/
• https://www.youtube.com/user/mycodeschool

יש גם ספר שמכיל שאלות כאלו: Cracking The Coding Interview. נתקלתי בכמה המלצות שמתייחסות אליו בתור הספר ה"קאנוני" לצורך הזה, אך כמובן שהוא לא היחיד.

 

הקוד שאת כותבת צריך כמובן להיות כמה שיותר איכותי. המראיינת תניח שבראיון את מקפידה יותר מהרגיל על הנושא הזה, ותתפוס "עיגולי פינות" במהלך הראיון כראיה שאת מעגלת את אותן פינות בעבודה, בצדק או שלא בצדק. חשוב לתת שמות משמעותיים למשתנים ולפונקציות, ולהשתמש באינדנטציה. במידת האפשר, עדיף להמנע מ-arrowheads (מצב של if בתוך while בתוך if…) בעומק 4 ומעלה. רוב המראיינות לא יצפו ממך להוסיף תיעוד, אך כדאי לשאול את המראיינת אם היא מצפה לתיעוד.

 

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

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

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

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

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

וגם אחרי כל ההכנה הזאת, סביר שיהיו ראיונות שלא ילכו לך. זה קורה למתכנתים מנוסים, ובוודאי גם למתכנתים צעירים בתחילת דרכם. לפעמים המרואיין לא "נכנס לגרוב", או שהמראיין מגיע לראיון עצבני – שניהם קרו לי, ולא רק לי. רוב הדיונים שקראתי בנושא מכירים בכך ששיטת הראיון הזאת היא הסתברותית, ושיש לה לא מעט false negatives. למשל, גוגל נתפסת כ"מייצגת" של שיטת הראיונות הזאת, ואפילו הם פשוט מעודדים מועמדים שלא הצליחו לחזור ולהתראיין שוב אחרי זמן מה. אנשים באופן טבעי נוטים לדון בשאלה "האם זאת שיטת ראיונות הגיונית, והאם יש שיטות יותר טובות", ועבור מגייסים, הדיון הזה כמובן מבורך. אבל לצרכי הפוסט הזה, הדיון הזה לא תורם כרגע, לפחות לדעתי. כרגע אני ממליץ לך להתרכז בלהתקבל לעבודה במסגרת השיטה, על כל מגרעותיה. ואני כמובן מקווה לשמוע ממך עוד כמה שנים, כשתהיי ראשת צוות, ותשקלי שיטות ראיונות קצת יותר הגיוניות 🙂

עדכון, 7.8.2017: פוסט ההמשך על הכנה לראיונות עלה. תבלו 🙂