מדריך הגרילה לראיונות עבודה
תורגם ע"י שי כפיר
את המאמר הזה שלח לי איתי גרוס לפני כמה חודשים. פתחתי את הלינק, דיפדפתי, דיפדפתי, דיפדפתי ודיפדפתי ומיד תייגתי אותו כ TL;DR קלאסי. יותר מ5000 מלים באנגלית נראה לי המון. לא מזמן מצאתי יום פנוי וקראתי אותו, וכל כך אהבתי את התוכן (טוב, את רובו) שהחלטתי לתרגם גם את המאמר הזה כדי לחסוך את תקרית הTL;DR לקוראי עברית אחרים. אגב TL;DR, העורכת הראשית שלי, שהיא גם אחותי, טוענת שהמאמר הזה לא ממש מדבר אל אנשים שלא מגיעים מההיי-טק. אם אכן כך הדבר, עמכם הסליחה.
השתדלתי לתרגם את המאמר כלשונו, ובעיקר כרוחו. אני לא מסכים עם כל מה שכתוב כאן, ולפעמים יש לספולסקי נימה צינית מתנשאת מעט עם נטיה קלה עד גבה-גלית לחפרנות, אבל רוב התוכן מדויק מאד. אני מניח שמתישהו בהמשך אכתוב מה אני חושב על כל זה, אבל יחד עם הביקורת הוא מומלץ מאד.
(ותודה לאחים שלי ולכפיר גולן על ההגהה)
אז הנה:
כנופיה מעורבת של אנרכיסטים, שוחרי אהבה חופשית, ולוחמים זועמים למען זכויות הבננה חטפה את ספינת האהבה מנמל פוארטו ואיירטה ומאיימת להטביע אותה על כל 616 נוסעיה (וזאת בנוסף ל327 אנשי הצוות) תוך שבוע, אלא אם כן כל דרישותיהם יענו.
הדרישות? מיליון דולר בשטרות קטנים ולא מסומנים ואימפלמנטציה מודרנית, תחת רישיון GPL של WATFIV, שזהו, כמובן, קומפיילר הפורטרן המוערך שפותח באוניברסיטת ווטרלו שבקנדה בסוף שנות השישים (גירסה 4). (מפתיע על כמה מעט דברים יכולים שוחרי אהבה חופשית ולחומי זכויות בננות להסכים ביניהם).
כמתכנת ראשי בצוות הספינה, אתה צריך להחליט אם אתה יכול לכתוב מאפס את הגירסה החדשנית של הקומפיילר המדובר תוך שבעה ימים. יש לך צוות של שני מתכנתים שישמח לעזור לך בביצוע המשימה.
אתה יכול לעשות את זה?
״זה תלוי...״ אתה עונה. אחד היתרונות בלכתוב את המאמר הזה הוא שאני יכול לשים לך מילים בפה ואין לך שום אפשרות לעשות שום דבר בעניין…
תלוי במה?
"אהה, הצוות יוכל להשתמש בכלי UML?"
האם זה באמת משנה? שלושה מתכנתים, שבעה ימים, פורטרן של ווטרלו (גירסה 4). האם כלי UML זה מה שיעשה את ההבדל?
"אני מניח שלא"
אוקיי, אז במה זה כן תלוי?
"האם יש לנו צגים של 19 אינטש? כמות בלתי מוגבלת של משקאות אנרגיה?"
שוב, זה באמת משנה? אספקת קפאין תקבע אם הפרויקט יצליח או יכשל?
"אני מניח שלא. רגע, אמרת שיש לי צוות של שני מתכנתים?"
כן.
"מי אנשי הצוות?"
זה באמת משנה?
"בטח! אם הצוות לא מסתדר זה עם זה בחיים לא נצליח לעבוד יחד. חוץ מזה אני מכיר כמה כוכבים שיכולים לכתוב קומפיילר פורטרן בעצמם תוך שבוע ומצד שני אני מכיר די הרבה מתכנתים שלא יצליחו לייצר את הודעת הפתיחה של הקומפיילר גם אם תיתן להם שישה חודשים"
עכשיו עלינו על משהו!
כולם משלמים מס שפתיים כשהם אומרים שאנשים הם החלק החשוב ביותר של פרויקט תוכנה, אבל אף אחד לא ממש בטוח מה אפשר לעשות בעניין. הדבר הראשון שאתה צריך לעשות, אם אתה רוצה מפתחים טובים הוא לגייס את המפתחים המתאימים, וזה אומר שאתה צריך להיות מסוגל להבין מיהם בדיוק המפתחים הנכונים עבורך, ועל פי רוב השלב הזה נעשה בראיון עבודה. לכן הפרק הזה עוסק כולו בראיונות עבודה.
(ראיון אישי הוא רק חלק אחד מתהליך הגיוס שכולל מיון קורות חיים וסינון טלפוני. המאמר הזה עוסק רק בראיון האישי.)
כדאי שלפחות שישה אנשים שונים יראיינו את המועמד, מתוכם לפחות חמישה חברי צוות לעתיד של המועמד (כלומר מפתחים, לא מנהלים). מכירים את החברות שבהן יש מנהל זקן ומריר שמראיין בעצמו וקובע לבד מי מתקבל ומי לא? אז לחברות כאלה אין מתכנתים טובים במיוחד שעובדים בשבילן. קל מידי לזייף ראיון עבודה אחד, במיוחד אם מי שמראיין אותך אינו מתכנת.
אם אפילו שניים מתוך ששת האנשים שפגשו את המועמד חושבים שהוא לא מתאים, אל תגייסו אותו.
זה אומר שטכנית, אפשר לפעמים לסיים "יום ראיונות" אחרי הראיון השני, בהנחה ששני המראיינים הראשונים לא רוצים את המועמד, שזה דווקא די יעיל, אבל כדי לא להתאכזר אליו כדאי לא להגיד לו מראש כמה אנשים הוא אמור לפגוש. שמעתי על חברות שמאפשרות לכל מראיין לדחות מועמד: זה נראה לי אגרסיבי מידי. כנראה שהייתי מאפשר לכל עובד בכיר לדחות מועמד, אבל לא הייתי דוחה מועמד רק בגלל שאחד מהצעירים לא חיבב אותו במיוחד.
אל תנסה לראיין כמה אנשים בו זמנית. זה לא הוגן. כל ראיון צריך להיות מורכב ממראיין אחד ומרואיין אחד בחדר עם לוח מחיק ודלת סגורה. מניסיוני - אם לא תראיין מישהו לפחות שעה אתה לא תוכל להגיע להחלטה לגביו.
אתה עומד לפגוש שלושה סוגים של אנשים בראיונות שלך. בקצה אחד של הסקאלה ישנם אלו שאין להם אפילו את הכישורים הבסיסיים למשרה. קל מאד לגלות מי אלו, לרוב שתיים-שלוש שאלות קצרות יספיקו.
מהצד השני של הסקאלה יש את המתכנתים הכוכבים, שבזמנם הפנוי כותבים בסוף השבוע קומפיילר ליספ בשפת מכונה, ומריצים אותו על פלייסטיישן 4.
בין שני אלו יש המון מועמדים של "אולי" שנראים שיש מצב שאולי הם יכולים לתרום משהו. הטריק הוא לדעת לברור את הכוכבים מה"אולי", כי אתה לא רוצה "אולי" מתכנתים בצוות שלך. לעולם.
בסוף הראיון אתה חייב להיות מוכן לקבל החלטה לגבי המועמד. יש בסך הכל שתי אפשרויות: לגייס או לא לגייס. אין אפשרויות נוספות. לעולם אל תאמר "לגייס, אבל לא לצוות שלי" - זה לא מנומס ומרמז שהמועמד אמנם לא מספיק מוכשר כדי לעבוד בצוות שלך, אבל יש מצב שהוא יתאים לצוות העלוב ההוא בקבוצה המקבילה אליך. אם קורה לך ואתה מתפתה ל "לגייס, אבל לא לצוות שלי", פשוט תתרגם את זה ל"לא לגייס" ויהיה בסדר. גם אם היה לך מועמד שהיה מבריק בביצוע משימה ספציפית של הצוות שלך, אבל נראה שלא יתאים כל כך לקבוצה אחרת, גם אז זה אומר "לא לגייס".
בעולם התוכנה דברים משתנים לעתים קרובות כל כך ובמהירות גדולה כל כך, כך שאתה צריך מתכנתים שיוכלו להתמודד עם כל משימה שתיתן להם. אם אתה מוצא ליצן שממש ממש טוב בSQL אבל לא מבין כלום בשום דבר אחר - אל תגייס. אם תגייס אותו אתה תחסוך קצת מהכאב בטווח הקצר בתמורה להרבה כאב לטווח הארוך.
אף פעם אל תאמר "אני לא בטוח". אם אתה לא בטוח זה אומר לא. זה באמת פשוט יותר מכפי שזה נראה. פשוט תגיד לא. אם אתה לא בטוח, תגיד לא. לעולם אל תאמר "תראה, נראה לי שנגייס אותו, אבל אני קצת מודאג בקשר ל…" אל תגייס. טכנית, תתרגם כל התלבטות ל"לא לגייס" ויהיה בסדר.
למה אני כל כך עקשן בעניין הזה? זה בגלל שעדיף בהרבה לדחות מועמד טוב מאשר לקבל מועמד גרוע. מועמד גרוע יעלה הרבה מאמץ וכסף ויגרום לבזבוז זמנם של המתכנתים האחרים, שיצטרכו לנקות אחריו את הבאגים. פיטורים של מישהו ששכרת בטעות יכולים לקחת חודשים ולהפוך סיוט אמיתי, במיוחד אם המועמד מחליט להיות לוחמני. במצבים מסוימים זה עלול להיות אפילו בלתי אפשרי לפטר אף אחד. עובדים גרועים פוגעים במוראל של הקבוצה. הם גם עשויים להיות מתכנתים גרועים אבל בני אדם ממש מקסימים, או כאלו שממש ממש צרכים את המשרה עד שלא תוכל לשאת את רגשות האשם, או שלא תוכל לפטר אותם בלי ששאר הקבוצה תשנא אותך, או משהו כזה. בכל מקרה זה סרט רע.
מצד שני, אם תדחה מועמד טוב, כנראה שיש בזה איזשהו "אי צדק קיומי", אבל הי - אם הם באמת חכמים, אין מה לדאוג, הם יקבלו הצעות עבודה טובות אחרות. אל תחשוש לדחות כל כך הרבה אנשים, בסוף תמצא מישהו. בכל מקרה, במהלך הראיון, זו לא הבעיה שאתה מתמודד איתה. חשוב לחפש את המועמדים הטובים אבל בזמן שאתה מראיין, דמיין כאילו בחוץ יש תור של עוד 900 אנשים שמחכים לראיון. לעולם אל תוריד את הסטנדרטים, לא משנה כמה קשה למצוא את המתכנתים המעולים שאתה מחפש.
אוקיי, אבל לא דיברתי על החלק הכי חשוב - איך לדעת אם לשכור מישהו או לא?
בעיקרון, זה פשוט. אתם מחפשים אנשים:
חכמים
עושים את העבודה
[הערת המתרגם: תרגמתי את "get things done" ל "עושים את העבודה", זה לא בדיוק זה, אבל לא מצאתי משהו יותר טוב]
זה הכל. זה כל מה שאתם מחפשים. תלמדו את זה בעל-פה. תדקלמו את זה כל לילה לפני השינה. ראיון קצר לא יספיק לכם בשביל להבין הרבה יותר מזה, אז אל תבזבזו את הזמן בניסיון להבין אם המועמד הוא מישהו שנעים להיתקע איתו בשדה תעופה או אם הם באמת מכירים COM וATL או שהם מבלפים בנושא.
אנשים חכמים שלא עושים את העבודה הם על פי רוב בעלי תואר שלישי ועובדים בחברות גדולות שבהן אף אד לא מקשיב להם כי הם לא מעשיים. הם יעדיפו דיון אקמי אודות הבעיה על פני עמידה בזמנים. קל לזהות אנשים כאלו בגלל שהם אוהבים להצביע על הדימיון התיאורטי בין שתי בעיות שונות מאד. למשל "גליונות אלקטרונים הם באמת רק מקרה קצה של שפות תכנות", ואחרי זה הם אוהבים לכתוב במשך שבוע סקירה טכנית מרתקת על התכונות הלשוניות-חישוביות התיאורטיות של גיליון אלקטרוני כשפת תכנות. חכם מאד, אבל לא שימושי במיוחד. דרך נוספת לזהות אנשים מסוג זה היא הנטייה שלהם להופיע במשרד שלך עם כוס קפה ולנסות לפתוח בשיחה ארוכה אודות היתרונות והחסרונות של בדיקת טיפוסים בג'אווה לעומת COM, בדיוק בבוקר שבו אתה אמור להוציא גיסת בטא שאתה עובד עליה חצי שנה.
אנשים שעושים את העבודה, אבל אינם חכמים יעשו דברים מטופשים בלי לחשוב עליהם יותר מדי ומישהו אחר יצטרך לנקות אחריהם. זה הופך אותם למעמסה על הארגון, כי לא רק שהם לא יתרמו, הם יצרכו זמן יקר של אנשים אחרים. זה סוג האנשים שמחליט לעשות ריפקטורינג של אלגוריתם הליבה שלך תוך שימוש ב visitor pattern (שבדיוק קראו עליו לראשונה אתמול בלילה והבינו אותו באופן שגוי לחלוטין) ובמקום לולאות פשוטות שמוסיפות פריטים למערך עכשיו יש לך AdderVisitor class וגם singelton שנקרא VisitationArrangingOfficer והקוד שלך כבר לא עובד.
איך אתה מזהה מישהו חכם בראיון? הסימן הראשון הוא שאתה לא צריך להסביר דברים שוב ושוב. השיחה פשוט זורמת. לעיתים קרובות המועמד אומר משהו שמראה תובנה אמיתית, או חוכמה, או חריפות מחשבה. כך שחלק חשוב מהראיון הוא ליצור שיחה שבה המועמד יוכל להראות לך שהוא חכם. המראיין הנורא ביותר שיש הוא הדברן. זה הטיפוס שמדבר בלי הפסקה ובקושי משאיר זמן למרואיין להגיד "כן, זה כל כך נכון. גם אני חושב ככה". דברנים מגייסים את כולם, כי הם מניחים שהם חכמים כי "הם חושבים ממש כמוני!"
הסוג השני הכי גרוע של מראיין הוא מראיין חידון הטריוויה. הטיפוס הזה משוכנע שאנשים חכמים הם אנשים שזוכרים המון עובדות. הם שואלים המון שאלות טריוויה של מתכנתים ונותנים ניקוד על תשובות נכונות. רק בשביל הקטע, הנה שאלת הראיון הכי גרועה בעולם: "מה ההבדל בין varchar2 ל varchar במערכת Oracle8i". זו שאלה איומה. אין שום סיכוי לאיזושהי קורלציה בין אנשים שיודעים את התשובה לשאלה הזו לבין האנשים אותם אתה רוצה לשכור. את מי זה מעניין מה ההבדל בין סוגי המשתנים? אתה יכול למצוא את המידע הזה באינטרנט תוך 15 שניות. תזכרו, חכם לא אומר "יודע תשובות לשאלות טריויה". בכל מקרה, קבוצות פיתוח רוצות לשכור אנשים עם כישרון, לא עם סט כישורים מסוים.ממילא כל סט כישורים שמישהו מביא איתו לארגון יהפוך להיות מיושן מבחינה טכנולוגית תוך שנים ספורות, כך שמוטב לשכור אנשים שיודעים איך ללמוד טכנולוגיה מאשר אנשים שיודעים איך לגרום ל JDBC לדבר עם MySQL ממש ברגע זה.
הדרך הטובה ביותר ללמוד על אדם היא לתת לו לדבר. תנו להם שאלות ובעיות פתוחות.
אז מה לשאול?
הרשימה האישית שלי לשאלות לראיונות עבודה מגיעה מהעבודה הראשונה שלי במיקרוסופט. למען האמת יש מאות שאלות ראיון מפורסמות של מיקרוסופט. לכל אחד יש סט שאלות שהוא מחבב במיוחד. גם אתה תפתח סט שאלות וסגנון אישי שיעזרו לך להגיע להחלטה של לגייס/לא לגייס. הנה כמה טכניקות שמצאתי כמוצלחות.
לפני הראיון, אני עובר על קורות החיים של המועמד ומשרבט תכנית ראיון על דף. תכנית הראיון היא רק רשימה של שאלות שאני רוצה לשאול. זו תכנית ראיון טיפוסית לראיון עם מתכנת:
הקדמה
שאלות לגבי פרויקט שהמועמד לקח בו חלק לאחרונה
שאלת תכנות פשוטה
שאלה שכוללת פויינטרים או ריקורסיה
האם אתה מרוצה?
האם יש לך שאלות?
אני מאד זהיר בנוגע לכל מידע שעלול ליצור אצלי דעות קדומות לגבי המועמד. אם אתה חושב שמועמד הוא חכם עוד לפני שנכנס לחדר, רק בגלל שיש לו תואר שלישי מ-MIT, אין כמעט דבר שהמועמד יגיד או יעשה שישנה את דעתך הראשונית. אם אתה חושב שהוא טיפש בגלל שהוא למד במכללה גרועה, גם אז שום דבר שהוא יאמר לא ישנה את דעתך. ראיון הוא כמו מאזניים עדינים, לא פשוט לשפוט מישהו על סמך שיחה של שעה, וההחלטה קשה מאד, אבל מידע מוקדם על המועמד הוא כמו משקולת גדולה שמונחת על כף המאזניים ואז הראיון הופך להיות חסר תועלת.
פעם, ממש לפני הראיון, נכנס המגייס למשרד שלי - "אתה הולך לאהוב את הבחור הזה", הוא אמר. חטפתי קריזה. "אם אתה חושב שאני הולך לאהוב אותו, למה אתה לא שוכר אותו במקום לבזבז את הזמן שלי?". אבל אז הייתי צעיר ונאיבי, אז המשכתי בראיון. כשהוא אמר דברים לא חכמים במיוחד חשבתי לעצמי "זה בטח נפילה רגעית שיכולה לקרות לכל בחור חכם" והסתכלתי על כל מה שהוא אומר דרך משקפיים וורודים. בסופו של דבר המלצתי לגייס אותו למרות שהוא היה מועמד מחורבן. ואתם יודעים מה? כל המראיינים אחרים שפגשו אותו נתנו תשובה שלילית.
לעולם אל תבקשו או תסכימו לקבל חוות דעת מהמגייס. אל תשאלו על מועמדים לפני שאתם מראיינים אותם ואל תדברו עם המראיינים האחרים שפגשו את המועמד לפני שגיבשתם החלטה בעצמכם. כך פועלת השיטה המדעית.
מטרת שלב ההקדמה בראיון הוא לגרום למועמד להרגיש בנח. אני מתעניין אם היה להם קל להגיע, אני מסביר בקצרה (כ30 שניות) על הראיון עצמו ומסביר למועמד שאני מתעניין בדרך שבה הוא ניגש לבעיה ולא בפיתרון עצמו.
החלק השני הוא שאלה על פרויקט שהמועמד היה שותף לו. אם אתם מראיינים בוגרי תואר, תשאלו על עבודת הגמר שלהם, אם יש כזו, או על קורס שלקחו שכלל פרויקט משמעותי. לדוגמה, לפעמים אני שואל "מה הקורס שהכי אהבת בסמסטר האחרון?" כשמראייינים מועמדים בעלי ניסיון עבודה קודם אפשר לשאול על המשימה האחרונה שלהם.
חשוב לזכור - תשאלו שאלות פתוחות, תישענו בכיסא ותקשיבו, כשרק מדי פעם אתם יכולים לכוון את השיחה ב"ספר לי עוד על X" אם נראה לכם שהשיחה תקועה.
מה לחפש כשאתם שואלים שאלות פתוחות?
נקודה ראשונה - חפשו להט והתלהבות. אנשים חכמים נלהבים מהפרויקטים שהם עובדים עליהם ונלהבים עוד יותר לספר עליהם. הם מדברים מהר תוך כדי נפנופי ידיים נמרצים. להט יכול להופיע גם בצד השלילי: "הבוס האחרון שלי רצה לעשות הכל במחשבי VAX כי זה היה כל מה שהוא הכיר. איזה דביל."
יש יותר מדי אנשים שיכולים לעבוד על פרויקט בלי שזה יזיז להם לכאן או לכאן. קשה מאד ליצור מוטיבציה לשום דבר אצל אנשים כאלו.
למועמדים גרועים פשוט לא אכפת והם לא יגלו טיפת התלהבות לאורך כל הראיון. סימן מצוין הוא שהמועמד כל כך נלהב לגבי משהו עד שהוא שוכח לרגע שהוא נמצא בראיון. לפעמים מועמד מגיע כשהוא לחוץ מאד - זה טבעי, ואני משתדל להתעלם מזה. אבל ברגע שאתה מתחיל לדבר איתו על אומנות מונוכרומטית ממוחשבת הם נדלקים וכל סימני העצבנות נעלמים. (אם אתם רוצים לראות דוגמה לאומנות מונוכרומטית ממוחשבת תנתקו את המוניטור מהחשמל). אתה יכול לנסות להתקיל אותם (נסו את זה - חכו שהם יגידו משהו שהוא בבירור נכון ותגידו "אין מצב שזה נכון") ואז הם יגנו על עצמם בלהט, גם אם חמש דקות קודם הם הזיעו בלחץ בכיסא, בגלל שהיו כל כך להוטים עד ששכחו שאתה עומד לקבל עוד מעט החלטה שעשויה להיות גורלית לגבי החיים שלהם.
נקודה שניה - מועמדים טובים מסבירים דברים היטב, לא משנה באיזו רמה. דחיתי מועמדים משום שלא הצליחו להסביר פרויקטים קודמים שלהם במונחים שמובנים להדיוטות. לעיתים קרובות בוגרי מדעי המחשב פשוט יניחו שכל אדם יודע מהו חוק בייס או מה המשמעות של ( O( log n. אם הם מתחילים לדבר ככה, תעצור אותם ואמר "האם תוכל בבקשה, רק לצורך הדיון, להסביר לי את המושג הזה בשפה שגם סבתא שלי תוכל להבין?". בשלב זה מועמדים רבים ימשיכו להשתמש בז'רגון ולא יצליחו להסביר את עצמם - טה דם! אתה לא רוצה להעסיק אותם, בעיקרון, בגלל שהם לא מספיק חכמים כדי להבין מה נדרש כדי להעביר את הרעיונות שלהם לאנשים אחרים.
נקודה שלישית - אם הפרויקט היה צוותי, חפש סימנים שהמועמד לקח תפקיד מוביל בצוות. מועמד עשוי לאמר "עבדנו על X אבל הבוס אמר Y והלקוח התעקש על Z" ואז אשאל "ומה אתה עשית?". תשובה טובה עשוי להיות "ישבתי יחד עם כמה חברי צוות וגיבשתי הצעה…". תשובה גרועה עשויה להיות "לא יכלתי לעשות כלום, המצב כולו היה בלתי אפשרי".
זכרו - חכם ועושה את העבודה. הדרך היחידה בה תוכלו לבדוק אם מישהו באמת עושה את העבודה היא לבדוק אם הוא עשה את העבודה בעבר. למעשה, אפשר לבקש מהמועמד דוגמה ישירה של מקרה שבו הוא לקח פיקוד והזיז דברים תוך כדי התגברות על מכשולים כמו, למשל, בירוקרטיה.
עם זאת, רוב זמן הראיון צריך לשמש את המועמד להוכיח שהוא מסוגל לתכנת.
תסביר שוב למועמד שאתה מבין שזה לא פשוט לכתוב קוד בלי אדיטור או IDE ושזה ממש בסדר אם הלוח הלבן יהיה מקושקש כולו בסוף הראיון. בנוסף תבהיר שאתה מבין שקשה מאד לכתוב קוד שאין בו באגים כשאין לך קומפיילר זמין כד לבדוק את עצמך וגם את זה תיקח בחשבון.
בראיון הראשון של יום הראיונות התחלתי לכלול שאלת תכנות מאד מאד פשוטה. התחלתי עם המנהג הזה בימי בועת הדוט קום העליזה שבהם הופיעו לראיונות הרבה אנשים שחשבו שכתיבת HTML זה סוג של תכנות, והייתי צריך דרך להימנע מבזבוז זמן יקר עליהם. השאלה היא כזו שמתכנת שעוסק בתכנות באופן יום יומי אמור לפתור בדקה אחת.
הנה כמה דוגמאות
כתוב פונקציה שבודקת אם מחרוזת מתחילה באות גדולה.
כתוב פונקציה שמחשבת שטח מעגל בהנתן הרדיוס.
סכם את כל הערכים במערך.
השאלות האלו נראות פשוטות מידי, וכשהתחלתי לשאול אותן ציפיתי שכל המרואיינים יענו עליהם בקלות. מה שגיליתי הוא שלמרות שכולם פתרו את הבעיה, היו הבדלים ניכרים בזמן שלקח למרואיינים לפתור אותה.
זה הזכיר לי למה אני לא יכול להתפרנס ממסחר במניות.
ג'ארד הוא סוחר במניות. הוא תמיד מספר לי על עסקאות מעניינות שהוא עשה. יש את הדבר הזה שנקרא אופציה, ויש אופציות מכר, ויש אופציות רכש ומשהו שנקרא steepeners וכל זה מאד מבלבל, הדבר המוזר הוא שאני מבין את המשמעות של כל המושגים, אני מבין בדיוק מה זו אופצית מכר (הזכות, אבל לא האחריות, למכור משהו במחיר מסוים) ותוך שלוש דקות בלבד אני יכול להבין מה צריך לעשות אם יש לך אופציות מכר והשוק מתחיל לעלות, אבל אני חייב את כל שלוש הדקות כדי להבין את זה, וכשהסיפור נהיה יותר מסובך ואופציות המכר הן רק החלק הראשון של הסיפור ויש עוד הרבה חלקים לסיפור אני מאבד את הסיפור מהר מאד כי אני שוקע בהרהורים ("בואו נראה, השוק עולה, שזה אומר שהריבית יורדת ועכשיו אופצית מכר היא הזכות למכור משהו…"). עד שהוא עוזב את הגראפים ומתחיל להסביר לי לאט לאט והעיניים שלי בוהות בנייר וכל זה מאד עצוב. ולמרות שאני מבין את כל החלקים הקטנים אני לא יכול להבין אותם מספיק מהר כדי לראות את התמונה הגדולה.
ואותו דבר קורה בתכנות. אם המושגים הבסיסיים לא קלים עד כדי כך שאתה לא צריך לחשוב עליהם בכלל, אין לך שום סיכוי להבין את הרעיונות המורכבים.
סרג' לאנג, פרופסור למתמטיקה באוניברסיטת ייל נהג לתת לתלמידי חדו"א שאלה אלגברית פשוטה בתחילת היום הראשון של הלימודים. שאלה פשוטה שכמעט כל אחד יכול לפתור, אלא שחלקם פתרו את השאלה כמעט באותה מהירות בה כתבו אותה ואילו לאחרים לקח זמן. פרופסור לאנג טען שאלו שפתרו את השאלה במהירות יקבלו ציון מעולה בקורס ואילו האחרים לא. המהירות שבה הם פתרו את השאלה האלגברית הפשוטה היתה כלי יעיל לניבוי הציון הסופי שלהם לא פחות מאשר סמסטר שלם של שיעורים, עבודות ומבחנים.
אתם מבינים, אם אתם לא עפים דרך הבעיות הפשוטות ב100 קמ"ש, אין שום סיכוי שתוכלו להתמודד עם הבעיות המסובכות.
אבל כמו שאמרתי, מתכנתים טובים נעמדים מול הלוח, כותבים את התשובה ולפעמים מוסיפים איזה התחכמות (יפה! תומך ביוניקוד!) וכל זה לוקח בערך שלושים שניות. עכשיו, כשהחלטתי שהם ממש טובים, אני עובר לכלים הכבדים - ריקורסיות ופויינטרים.
חמש עשרה שנים של ניסיון בראיונות עבודה עם מתכנתים שכנעו אותי שלמתכנתים הטובים ביותר יש את הכישרון להתמודד בקלות עם רמות שונות של הפשטה בו-זמנית. בתכנות, זה אומר שאין להם שום בעיה בהתמודדות עם ריקורסיה (מה שאומר שאתה אמור לזכר בראש כמה רמות של הcall stack בו זמנית) וגם שום בעיה בהתעסקות בפויינטרים (ששם כתובת הזיכרון של האוביקט היא מעין יצוג מופשט של האוביקט עצמו).
הגעתי למסקנה שהיכולת להמודד עם פויינטרים בC היא כישרון יותר מאשר יכולת נרכשת. תמיד בשנה הראשונה של לימודי הנדסת תוכנה ומדעי המחשב יש 200 ילדים וכולם וכולם כתבו משחקי הרפתקאות מורכבים בBASIC על הPC שלהם כשהם היו בני ארבע ושלושה חודשים. הם מעבירים את הזמן בכיף וממש נהנים בפקולטה כשהם לומדים C ופסקל עד שבוקר אחד המרצה מתחיל לדבר על פויינטרים, ואז, פתאום, הם לא תופסים את זה. הם פשוט לא מבינים שום דבר מכאן והלאה.
תשעים אחוז מהכיתה עוזבים ועוברים ללמוד מדעי המדינה ויחסים בינלאומיים ומספרים לחברים שלהם שלא היו מספיק סטונדטים חתיכים מהמין הנכון בפקולטה למדעי המחשב ובגלל זה הם עזבו.
מסיבה לא ברורה, חלק מבני האדם נולדו בלי החלק במוח שאחראי על הבנה של פויינטרים. פויינטרים דורשים צורה מורכבת של חשיבה עקיפה שלחלק מהאנשים פשוט אין. החשיבה הזו היא די קריטית לתכנות. הרבה "ילדי סקריפטים" שהתחילו את דרכם בהעתקת חלקי ג'אווה-סקריפט אל האתרים שלהם ואחר כך עברו לPERL מעולם לא למדו להתעסק עם פויינטרים, ואף פעם לא יוכלו לייצר קוד באיכות שאתה צריך.
זה המקור של שאלות הראיון המפורסמות כמו, "להפוך סדר של רשימה מקושרת" או "למצוא לולאות בעץ"
למרבה הצער, למרות שאני חושב שכל מהמתכנתים הטובים צרכים להיות מסוגלים להתמודד עם פויינטרים ועם ריקורסיות, וזו דרך מצוינת לזהות את המתכנתים הטובים, האמת היא שבימים אלו שפות תכנות מודרניות הפכו את שתי המיומנויות האלו למיותרות. אם לפני עשר שנים היה נדיר למצוא בוגר אוניברסיטה שלא למד ריקורסיות ותכנות פונקציונאלי בקורס אחד, ו C ופסקל עם מבני נתונים מורכבים בקורס אחר, היום לא נדיר למצוא בוגרי אוניברסיטאות ומכללות מכובדות בכל תחום אחר שלמדו רק ג'אווה.
הרבה מתכנתים שאתה פוגש היו נוטים לראות בריקורסיה, פויינטרים ואפילו במבני נתונים מורכבים כפרט שולי של האימפלמנטציה שנעלם לאבסטרקציה בתוך אחת משפות התכנות המודרניות החביבות. "מתי בפעם האחרונה מימשת אלגוריתם מיון?" הם יצחקקו.
ובכל זאת, לא ממש אכפת לי. אני רוצה שרופאה בחדר מיון תבין את האנטומיה של הגוף, גם אם כל מה שהיא צריכה לעשות זה להצמיד את האלקטרודות של הדפיברילטור הממוחשב לחזה שלי וללחוץ על הכפתור האדום הגדול, ואני רוצה שמתכנתים יבינו תכנות עד לרמת המעבד אפילו אם Ruby on Rails יודע לקרוא את המחשבות שלך ולייצר אפליקציית רשת חברתית בשלושה קליקים של העכבר.
למרות שעל פניו, הפורמט של הראיון נראה כמועמד שכותב קוד על לוח, המטרה האמיתי, היא ניהול שיחה אינטליגנטית על הקוד. "למה כתבת את זה בצורה הזו?", "מה מאפייני הביצועים של האלגוריתם?", "מה שכחת?", "איפה יש כאן באג?".
זה אומר שלא אכפת לי לתת למועמד שאלה קשה מידי, כל זמן שלמועמד יש סיכוי טוב להתחיל לכתוב, ואז אני מנדב בשמחה טיפים קטנים שיכוונו אותו הלאה. אני יכול לבקש ממועמד ליצור הקרנה של משולש על מישור, שזו בעיית גרפיקה טיפוסית, ואין לי בעיה לעזור לו עם הטריגונומטריה. כשאני מבקש ממנו להאיץ קצת את האלגוריתם אני עשוי לרמוז לו על שימוש בטבלאות חיפוש (look up tables). הנתונים שאני שמח לנדב הם בסך הכל פתרונות לשאלות טריוויה, כאלו שאפשר למצוא בשניות בחיפוש פשוט בגוגל.
תמיד יהיה באג בקוד של המועמד. כאן מגיעה השאלה שהזכרתי בתכנית הראיון: "האם אתה מרוצה מהקוד?". אפשר גם לשאול "בסדר, אבל איפה יש כאן באג?" שזו השאלה הפתוחה המובהקת מהגיהנום.כל המתכנתים טועים, אין עם זה שום בעיה, הם פשוט צרכים להיות מסוגלים למצוא את השגיאות של עצמם.
בפונקציות שמתעסקות בסטרינגים של C רוב בוגרי התארים שוכחים לסיים את הסטרינגים החדשים שנוצרים בnull. כמעט בכל פונקציה הם יפספסו בקטנה. לפעמים הם ישכחו נקוד פסיק, לפעמים לא יתייחסו היטב למקרי קיצון כמו סטרינג ריק או שהפונקציה תתפוצץ במקרה של כישלון של הmalloc. לעיתים רחוקות מאד תפגוש מועמד שיכתוב את הפונקציה המושלמת על הניסיון הראשון ואז זה אפילו יותר כיף. כשתציין שיש באג בקוד הם יבדקו אותו שוב לאט ובזהירות ואז אתה יכול לראות אם הם יכולים לעמוד על שלהם באופן מנומס, אבל תקיף.
השלב האחרון בראיון הוא לשאול את המועמד אם יש לו שאלות. חשוב לזכור שאף על פי שאתה זה שמראיין אותם, למועמדים טובים תהיינה הצעות עבודה נוספות והשלב הזה אמור לשמש את המועמד כדי להבין שהוא מעוניין לעבוד אצלך.
חלק מהמראיינים מנסים לקבוע האם המרואיין שואל שאלות "חכמות" בשלב האחרון. באופן אישי, לא ממש אכפת לי. בשלב הזה כבר קיבלתי את ההחלטה שלי לגבי המועמד. הבעיה היא שמועמדים פוגשים חמישה או שישה אנשים במשך היום, ולא פשוט למצוא שאלות טובות וחכמות כל פעם מחדש. זה בסדר גמור גם אם אין להם שאלות בכלל.
אני תמיד משאיר חמש דקות בסוף הראיון כדי למכור את התפקיד למועמד, וזה חשוב גם אם מדובר במועמד שאתה לא מתכוון להעסיק. אם היה לך מזל ופגשת מועמד טוב, אתה רוצה לעשות בשלב הזה כל מה שאתה יכול כדי שגם המועמד ירצה לעבוד איתך, אבל גם במקרה של מועמד לא טוב, חשוב שהם יצאו מהראיון עם רושם חיובי עליך ועל החברה.
אה, ובדיוק נזכרתי שאני צריך לתת גם כמה דוגמאות של שאלות ראיון ממש גרועות.
בראש ובראשונה, חשוב להימנע משאלות לא חוקיות. כל שאלה שקשורה לדת, גזע, מין, לאום, גיל, שירות צבאי, נטיה מינית או נכות פיזית הנה שאלה לא חוקית על פי חוקי ארצות הברית. אם קורות החיים שלהם אומרים שהם שירתו בחיל הנחתים, אתה לא יכול לשאול אותם, גם לא בשביל ליצור שיחה נעימה, אם הם היו בעירק. אם כתוב שהם בוגרי הטכניון בחיפה, אתה לא יכול לשאול אותם אם הם ישראלים, גם אם רק רצית לפתח שיחה ואשתך במקרה בוגרת טכניון ישראלית ואתה מת על פלאפל. אפליה על רקע מוצא היא בניגוד לחוק.
בנוסף, אל תשאל שאלות שעשויות להראות כאילו אכפת לך, או כאילו אתה מפלה על פי דברים שלא אכפת לך מהם ואתה לא מפלה על פיהם. הדוגמה הטובה ביותר שאני יכול לחשוב עליה היא לשאול מישהו אם הוא נשוי או אם יש לו ילדים. זה עלול ליצור את הרושם שאתה חושב שבעלי משפחות לא יכולים להקדיש מספיק זמן לעבודה שלהם, או שאתה חושש שהם יעלמו לך לחופשת לידה. בעיקרון, תיצמד רק לשאלות שרלוונטיות באופן ישיר לתפקיד שהמועמד אומר לבצע.
לסיום, המנע מכל מיני חידות הגיון, כמו זו שבה צריך ליצור ארבעה משולשים מושלמים זהים משישה מקלות באורך שווה, או כל שאלה אחרת שמכילה פיראטים, כדורים צבעוניים או קודים סודיים. רוב השאלות מהסוג הזה הן שאלות "א-הא!", שאלות שאליהן או שאתה יודע את התשובה או שלא. היכולת לדעת את התשובה לשאלות האלה תלויה בשאלה אם שמעת אותן קודם לכן. בתור מראיין השאלות האלו לא עוזרות לך לענות על שתי השאלות החשובות "האם הוא חכם" ו "האם הוא עושה את העבודה".
בעבר, שאלתי גם "שאלות בלתי אפשריות" (שמכונות גם "שאלות על גב המעטפה", בהשאלה מ"חישוב על גב מעטפה"). דוגמא קלאסיות לשאלה כזו היא "כמה מכווני פסנתרים יש בסיאטל?"
המועמד לא ידע את התשובה, אבל מועמדים חכמים לא יוותרו וינסו בשמחה לנסות ניחוש מושכל. "בוא נראה, יש בסיאטל בערך מיליון תושבים, ונניח שלאחוז אחד מהם יש פסנתר. פסנתר צריך לכוון כל כך וכך שנים וכיוון פסנתר אורך בערך 35 דקות." כל ההנחות שגויות כמובן, אבל לפחות הם תוקפים את הבעיה. הסיבה היחידה שיכולה להצדיק שאלה מסוג זה היא שהיא מאפשרת לך לנהל שיחה עם המועמד: "בסדר, נאמר 35 דקות, אבל מה לגבי זמן הנסיעה בין לקוח ללקוח?"
"נקודה טובה.אם מכוון הפסנתרים יכול לקבוע את הפגישות מראש, הוא יכול להגדיר סידור עבודה שיצמצם את זמני הנסיעה בין הלקוחות - אתה יודע, לתקן את כל הפסנתרים ברדמונד באותו יום ולא לנסוע על כביש 520 הלוך וחזור שלוש פעמים ביום".
שאלת גב-מעטפה טובה מאפשרת לך ליצור שיחה טובה שתעזור לך להחליט אם המועמד חכם או לא. שאלת "א-הא!" גרועה שעוסקת בפיראטים וגמדים נגמרת לרוב בזה שהמועמד בוהה בך ואז שיחה תקועה.
אם בסופו של הראיון שכנעת את עצמך שהמועמד חכם ועושה את העבודה ויש עוד ארבעה או חמישה מראיינים שמסכימים לאבחנה הזו, זה כנראה רעיון טוב להעסיק אותו. אבל אם בסוף יום הראיונות עדיין יש לך ספקות, עדיף לחכות למועמד טוב יותר.
הזמן האופטימלי לקבל החלטה לגבי מועמד הוא כשלוש דקות אחרי סיום הראיון. הרבה יותר מידי חברות מאפשרות למראיינים לתת חוות על המועמד ימים ארוכים אחרי שהראיון הסתיים, לרוע המזל, ככל שחולף הזמן ככה אתה זוכר פחות.
אני מבקש מהמראיינים לסכם את הראיון בקצרה לכל היותר 15 דקות אחרי סיום הראיון. הסיכום אמור להכיל את המלים "לגייס" או "לא לגייס" ושתי פסקאות קצרות של הסבר.
אם אתה לא מצליח להחליט, יש פתרון די פשוט - אל תגייס! פשוט אל תיקח מישהו שאתה לא בטוח לגביו. בכמה פעמים הראשונות זה עלול להיות קצת מורט עצבים - מה יהיה אם לא תמצא אף אחד? זה בסדר. אם מערכת סינון קורות החיים והמיון הטלפוני פועלות טוב, כנראה שיהיו לך כ20 אחוזי הצלחה בראיונות, וכשאתה פוגש מישהו שהוא חכם ועושה את העבודה, אתה תדע שזה זה. אם אתה לא נלהב מהמועמד, פשוט תמשיך הלאה.
ג'ואל ספולסקי, 2006
