אימרו ״די!״ לשאלות בית-ספר בראיונות טכניים

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

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

״אבל אבי, למה אתה כל כך מתנגד לשאלות כאלו?״

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

שאלו שאלות שידמו עבודה אמיתית עם המועמד

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

• צורת התנסחות – תקשורת בין חברי צוות ויכולת הסברה של בעיות הם קריטיים מבחינתי. מועמד שלא מסוגל להסביר את המערכת עליה הוא עבד בצורה טובה כנראה שאו לא מבין אותה מספיק טוב או שלא יודע לתקשר טוב.
• בורג קטן? או ראש גדול? מועמדים טובים ידעו לספר לכם המון על המערכת. גם על הגלגולים שהיא עברה, על הלבטים שהיו בדרך, על הטכנולוגיות שנבחרו, על הפשרות שנעשו ב-design אותו הם מציגים לכם וכו׳… הסבר מעמיק וברור על המערכת מראה שהמועמד היה מעורב מאוד בפרוייקט ולא רק בורג קטן. אין לי בעיה לשמוע הסבר של ״בחרנו ללכת על פיתרון X במקום פיתרון Y כי הארכיטקט החליט״ אבל אחפש מועמדים שמבינים למה הארכיטקט החליט כפי שהחליט, אפילו אם הם לא מסכימים עם ההחלטה.
• על מה המועמד עבד – כמובן שניסיון קודם הוא רלוונטי מאוד בהחלטה האם להתקדם עם מועמד כלשהו. ייתכן שהמועמד התעסק עם טכנולוגיות ובעיות שמאוד רלוונטיות לחברה אליה הוא מתראיין, דבר שעשוי לתת לו נקודות בונוס.

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

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

• איך הוא ניגש לבעיות – איך הוא מפרק בעיה גדולה ואיך הוא ממפה את הקשיים.
• אילו שאלות הוא שואל. פה ניתן ללמוד גם על העבודה העתידית עם הפרודקט – האם הוא מסוגל לשאול שאלות על פשרות ו-tradeoffs שמותר לעשות על מנת להקל על הפיתרון או לשפר ביצועים, האם הוא מנסה לאפטם (מלשון optimize) בעיות קטנות ולוקליות או שהוא מחפש פיתרון מוצלח שיפתור את כל הבעיה, האם הוא מחפש פתרונות פשוטים או שהוא נוטה להסתבך עם עצמו וכדומה…
• ידע קודם – האם המועמד מסוגל לקחת בעיות דומות שעבד עליהן בעבר ועם טוויסט קטן לשפר? לדוגמא, אם מועמד סיפר לי שהוא השתמש במערכת תורים בשביל לעשות scale במערכת, אחפש לראות שהוא יודע להשליך את הפיתרון גם על מערכת אחרת. כמובן שחשוב שהפיתרון גם יתאים לבעיה ולא שהמועמד ישתמש תמיד באותו ״מברג״ לכל בורג.

שאלות בית ספר לא ילמדו אתכם איך מועמד כותב קוד

היתרון המשמעותי שהרבה מראיינים רואים באותן שאלות אלגוריתמיות נמצא דווקא, או בנוסף, בבדיקת יכולת כתיבת הקוד של המועמד. לרוב אחרי שהמועמד יכתוב פסאודו-קוד שמוצא את המספר העוקב בעץ חיפוש בינארי (או האם המחרוזת היא פלינדרום) הוא יתבקש לכתוב פונקציה בשפת התכנות האהובה עליו (או על המראיין). גם הפעם, מרגיש לי קצת מדי. מבחינתי לכתוב קוד זה לא לכתוב פונקציה. לכתוב קוד זה לכתוב לכל הפחות מודול הכולל כמה מחלקות המתקשרות ביניהן. כך ניתן לראות הבנה של נושאים הרבה יותר עמוקים מאשר האם המועמד מעדיף סוגר מסולסל בסוף שורה או בשורה שמתחת. ניתן לראות את יכולת החלוקה ליחידות עבודה קטנות, הקפדה על ראשי תיבות אהובים כמו DRY ו-SOLID, אפשר לראות האם המועמד משאיר קצוות פתוחים או לחילופין עושה over-engineering עם המון הכנות למזגן (את ראשי התיבות YAGNI כבר הזכרתי?), אפשר לראות טיפול ב-exceptions, אולי גם יכולות כתיבת טסטים ועוד.

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

האם שאלות ״בית-ספר״ עשויות להיות רלוונטיות אי פעם?

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

לסיכום

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