איך מתכוננים לראיונות, חלק א'

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

 

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

 

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

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

 

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

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

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

 

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

 

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

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

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

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

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

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

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *