איך מראיינים סניורים?

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

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

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

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

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

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

המערכת

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

1. בדיקות (יוניט, אינטגרציה ו-e2e)
2. דיפלוימנט לסביבה כלשהי.
3. README כלשהו עם הוראות התקנה והפעלה לוקלית.
4. תהליך CI, לינטרים וכל הג׳אז הזה.

במערכת יש באג אחד מאד בולט. מה שחשוב הוא שזה משהו שממש ממש קל למצוא ואפילו עם הערת TODO של fix it. זה אחד השלבים הקריטיים ביותר.

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

1. בעיות אבטחה: היו בה בעיות של XSS Injection – לפחות שלוש מהן. שלושה מודולים מיושנים, טוקנים גלויים בקוד.
2. בעיות ביצועים: ריקורסיות שאין בהן צורך. פונקציות סינכרוניות שאפשר בקלות להמיר לאסינכרוניות.
3. בעיות של נוסח קוד: הגדרות הלינטר היו שבורות, שמות לא קוהרנטיים, רווחים מוזרים, דברים שניתן לפתור עם auto fix וכאלו שלא.
4. באגים פונקציונליים אחרים אבל כאלו שלא מהותיים ממש.
5. בדיקות שנופלות ולא עובדות וקל לתקנן. למשל יוניט שנופל כי הוא לא עושה import נכון, e2e שמשתמש בסלקטורים לא טובים וכך הלאה.
6. דיפלוימנט שבור שאינו עובד – במקרה הזה פשוט הצבתי משתנה סביבה עם שגיאת כתיב ו שגיאות בgithub actions.
7. שגיאות כתיב, נוסח ובכלל טירוף בדוקומנטציה.

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

נוסח המבחן

כשהמתמודד או המתמודדת מגיעים, יושבים איתם עד שיפתור את הבאג הפשוט. מטרת הבאג הפשוט היא לא לראות אם המועמדים מבינים בקוד אלא לראות שהם on track. כלומר הצליחו לעשות git clone, הצליחו לפתוח את ה-IDE ויודעים להסתדר איתו. חשוב להבהיר שזה שלב חימום ולוודא שבאמת השלב הזה נעשה ויש למועמדים קוד, הם מריצים את הקוד לוקלית ומצליחים לפתור את הבאג הפשוט.

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

1. אין ציפיה לפתור את כל הבעיות ואין דרך לעשות כן.
2. יש חשיבות לסדר פתירת הבעיות, לתהליך האנליזה וכו׳.
3. יש לבצע git commit מסודר עם commit message אחרי כל פתרון בעיה (קריטי במטלת בית)

המדידה

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

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

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

למשל:

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

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

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

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

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

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

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