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

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

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

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

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

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