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

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

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

What is a closure, and how/why would you use one?

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

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

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