איך עוברים ראיון עבודה טכני?

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

אזהרה לקורא הנבון

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

הייחודיות של ראיון טכני

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

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

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

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

1. מבחן בית.
2. ראיון טלפוני קצר.
3. מבחן טכני מול מחשב שנועד לפתרון בעיות תיאורטיות.
4. מבחן טכני מול מחשב שנועד לפתור בעיות ממשיות.
5. מבחן טכני מול לוח (White board)

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

לפני הראיון

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

מומלץ גם להכנס לאתר GlassDoor כדי לבדוק על תהליך הראיונות ולבדוק בלינקדאין עובדים בעבר או בהווה שאתם מכירים כדי לשאול מה התהליך.

מבחן בית

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

חשוב כן במבחן בית לא רק לבצע את המטלה אלא גם לעשות אותה כך:

1. להקפיד על קומיטים אטומיים ככל האפשר (כלומר לא לדחוף את כל הקוד אלא להפריד את הקומיטים).
2. כן להכניס Readme ודוקומנטציה.
3. להקפיד על לינטרים.
4. לכתוב בדיקות אוטומטיות מסוג יוניט טסט ו-e2e – אם אפשר.

למה זה חשוב?

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

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

ראיון טלפוני קצר

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

"תארו לי אלגוריתם שעובר על מערך מ-1 עד 100, בכל איבר שמתחלק ב-3 הוא מדפיס Fizz, בכל איבר שמתחלק ב-5 הוא מדפיס Buzz ועל איברים שמתחלקים ב-3 וגם ב-5 הוא מדפיס FizzBuzz".

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

let a = 5;

a % 5 // 0;
a % 7 // 2

התשובה היא, אם מדובר בשיחת טלפון, כזו:

"לולאה פשוטה שעוברת על המערך לפי הסדר, בכל איטרציה אני עושה בדיקה עם מודולוס. אם האיבר מתחלק ללא שארית ב-3 וב-5 אני מדפיס -FizBuzz. אם הוא מתחלק רק ב-3 ללא שארית אני מדפיס Fizz, אם הוא מתחלק רק ב-5 ללא שארית אני מדפיס Buzz."

מומלץ לחפש שאלות FizBuzz בגוגל ולהתאמן עליהן גם בעל פה.

למה זה חשוב?

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

מבחן טכני מול מחשב בנוגע לבעיות תיאורטיות

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

"סדרת פיבונאצ'י היא סדרה שבה המספר הוא סכימה של שני המספרים הקודמים. למשל:

0,1,1,2,3,5,8,13,21

צור אלגוריתם שמחזיר את האיבר ה-n בסדרת פיבונאצ'י. למשל אם הקלט הוא 4, התוצאה היא 2 (האיבר הרביעי בסדרת פיבונאצ'י). אם הקלט הוא 8, הפלט הוא 13 (האיבר השמיני בסדרת פיבונאצ'י).

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

function fib(n) {
  let arr = [0, 1];
  for (let i = 2; i < n + 1; i++){
    arr.push(arr[i - 2] + arr[i -1]);
  }
 return arr[n];
}

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

function fib(n) {
  if (n < 2){
    return n;
  }
  return fib(n - 1) + fib (n - 2);
}

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

למה זה חשוב?

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

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

מבחן טכני מול מחשב בנוגע לבעיות ממשיות

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

1. להסתכל ישר על הקונסולה – הן של הטרמינל והן של הדפדפן.
2. לבדוק אם יש בדיקות אוטומטיות ולהריץ אותן.
3. לא להתבייש לשאול את הבוחן כמה שיותר שאלות לפני כתיבת הקוד.
4. במידה ונותנים לכם פרויקט שנמצא בגיטהאב – לא להתבייש להסתכל על התיעוד.

למה זה חשוב?

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

מבחן טכני מול לוח (White board)

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

1. מה הקלט שיש לי מחוץ למעלית – למשל: כפתור שנלחץ למעלה/למטה ומספר הקומה.
2. מה הקלט שיש לי בתוך המעלית ואם יש אפשרות לעשות override (התשובה היא מספר הקומה ואין לי override).
3. האם אנו עובדים בפורמט First In First Out? אם כן, המעלית יכולה לאסוף מישהו בדרך, אבל אם המעלית סיימה איטרציה בקומה 6. יש מישהו בקומה 7 שלוחץ למטה אבל לפניו בתור יש מישהו בקומה 0 שלוחץ למעלה, היא לא תעלה לאסוף את הנוסע בקומה 7 אלא תמהר לאסוף את האיש בקומה 0 למרות שזה פחות יעיל. אבל זה יותר הוגן.

אחרי השאלות האלו, אני יכול לתכנן את האלגוריתם, כאשר התכנון הנאיבי והבסיסי ביותר יכול להיות כזה:

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

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

כמה דברים חשובים:

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

למה זה חשוב?

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

לסיכום

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