במהלך החודשים האחרונים ביליתי במספר ראיונות עבודה. הפוסט הזה לא התעורר בעקבותם. הוא קינן בתוכי כבר שנים מאז שאני בעצמי ראיינתי הרבה מועמדים ותהיתי ביני לבין עצמי מה היא הדרך הנכונה לעשות זאת והאם הדרך בה בחרתי לא נולדה כתוצאה מחיקוי של המראיינים שראיינו אותי בעבר וכך הלאה והלאה.
הראיונות שעברתי במהלך החודשים האחרונים הציתו את הרצון לכתוב את הפוסט והוציאו לפועל את הכתיבה. הפוסט הוא פוסט שממוקד בפילוח ואבחון התאמה " טכנית " , כשירותו של המועמד במקצוע התכנות.
סוגי ראיונות נפוצים:
מודול מרכזי
חלק זה מתנהל לרוב כדיאלוג בין המראיין למרואיין בו המרואיין מסביר על מודול מרכזי שהיה שותף לפיתוחו.
חידות
חידות טהורות. כמו חידות הכובעים למינם.
שאלת אלגוריתם
כגון – כתוב פונקציה אשר מוצאת את האיבר השני בגודלו בעץ חיפוש בינארי.
שאלות ארכיטקטוניות
שאלות שדורשות הסתכלות רחבה יותר מהפאן הטכני של כתיבת הקוד במערכת נתונה. שאלות כגון
Spring vs Jee
Rest advantage and disadvantages
WebService vs Ejb Stateless
שאלות טכניות מונחים
Transaction isolation, Hibernate caching
שאלות טכניות קומפילציה
מה יקרה בתוכנית הבאה? האם תתקמפל? איזה שגיאות יהיו? מה יהיה הפלט
על מנת לבחון את כלי המיון הטוב ביותר עלינו תחילה להסביר מהו מיון טוב ( ובנוסח בדיחות הגיקים התשובה היא לא מיון מיזוג ואפילו במיונים אין דבר כזה הטוב ביותר. ההחלטה תלויה בכמה גורמים כמו מקום, מהירות, גודל )
מאפייניו של מבחן טוב:
מהימנות – שיטת הערכה היא מהימנה אם תוצאותיה עקביות וניתנות לשחזור. אם מבחן מפיק תוצאות שונות כשהוא ניתן בהזדמנויות שונות או נבדק על ידי בודקים שונים, אזי הוא אינו מהימן.
מדד נוסף של מהימנות הוא " עקביות פנימית " , המידה בה שאלות נפרדות במבחן מודדות את אותו הדבר. מדד זה נבדק על ידי מתאם הציונים שהושגו על ידי קבוצת אנשים בכל שאלה לציון הכללי שלהם.
לעיתים " תוכן השאלה " אכן רלוונטי לתהליך המיון, אך השאלה כפי שנשאלת על ידי המראיין תוביל לתוצאות לא עקביות אצל אנשים בקבוצה דומה ואפילו אצל אותו אדם לו נשאלה בזמנים שונים ביום.
באחד הראיונות נשאלתי את השאלה הבאה:
יש לך טבלה בעלת שתי שדות - שם, מצב נעילה (ערך בוליאני). מה לא טוב בטבלה?
כמובן מיד קופץ לראש (שלי לפחות) כל הנושא של אינדקס על קבוצה בעלת עוצמה נמוכה. פתרונות ומימושים בסוגי DB שונים, אך לא זה עניין את המראיין.
אני ממשיך להסתכל על הטבלה המאוד פשוטה הזאת וזורק עוד כל מיני הערות , אך גם אותן לא חיפש המראיין.
בסופו של דבר התשובה אותה חיפש היא שלא נכון יהיה להגדיר את עמודת השם בתור PK , בשל העובדה כי שמות הם לא יחודיים (אבי כהן בתור דוגמה).
לו השאלה הייתה נשאלת בתצורה ברורה וגלויה כמו - האם היית מגדיר שם של עובד בתור PK של טבלה, לא היה מפתח שלא היה ישר זועק את התשובה, שכן כל מי שכתב טבלה אחת בחיים שלו התמודד עם כך, אך לא כך כאשר השאלה תשאל בצורה עקיפה.
כל אחד מאיתנו ננעץ על פרטים שונים בדוגמה או בUser Story וזאת על פי עיסוקו , המיקוד שלו, ומה שהוא עסק בו בזמן האחרון. אי לכך אל תצפו כי הדברים הברורים לכם מאליו ברורים מאליו גם למרואיין. אל תשאירו הנחות סמויות או דברים שצריך להשלים בראש. נסחו את השאלה בצורה ברורה ואם אחרי הניסוח הברור השאלה נראית לכם ברורה מדי וטריויאלית מדי, אזי זאת רק ראיה כי השאלה אינה רלוונטית והייתה רלוונטית כל עוד הסתרתם ממנה טפח ואל לנו לצפות מהמרואיין שישלים בראש את אותו טפח שבראש שלנו.
נתקלתי במראיינים רבים שנזהרים מאוד באופן שבו הם שואלים את השאלה, שמא לו ינסחו או ידגישו משפט זה או אחר בשאלה אזי היא כבר תהיה טריווילאית. שאלה כזאת אינה עומדת בקריטריון המיהמנות.
במידה ונתתם למועמד לכתוב קוד והקריטריון שאותו אתם מחפשים זה Object Orientied אל תשאירו את ההנחה הסמויה הזאת אצלכם, מסרו לו בדיוק את הציפיות, כי אחרת הוא מבחינתו יכול להניח כי הקריטריון זה זמן או כמות שורות נמוכה או יכולת מיטבית לביצוע מקבילי או שפשוט יעבוד (כל אחד והעולם ממנו הוא בא) .
לעיתים " תוכן השאלה " אכן רלוונטי לתהליך המיון, אך השאלה כפי שנשאלת על ידי המראיין תוביל לתוצאות לא עקביות אצל אנשים בקבוצה דומה ואפילו אצל אותו אדם לו נשאלה בזמנים שונים ביום.
באחד הראיונות נשאלתי את השאלה הבאה:
יש לך טבלה בעלת שתי שדות - שם, מצב נעילה (ערך בוליאני). מה לא טוב בטבלה?
כמובן מיד קופץ לראש (שלי לפחות) כל הנושא של אינדקס על קבוצה בעלת עוצמה נמוכה. פתרונות ומימושים בסוגי DB שונים, אך לא זה עניין את המראיין.
אני ממשיך להסתכל על הטבלה המאוד פשוטה הזאת וזורק עוד כל מיני הערות , אך גם אותן לא חיפש המראיין.
בסופו של דבר התשובה אותה חיפש היא שלא נכון יהיה להגדיר את עמודת השם בתור PK , בשל העובדה כי שמות הם לא יחודיים (אבי כהן בתור דוגמה).
לו השאלה הייתה נשאלת בתצורה ברורה וגלויה כמו - האם היית מגדיר שם של עובד בתור PK של טבלה, לא היה מפתח שלא היה ישר זועק את התשובה, שכן כל מי שכתב טבלה אחת בחיים שלו התמודד עם כך, אך לא כך כאשר השאלה תשאל בצורה עקיפה.
כל אחד מאיתנו ננעץ על פרטים שונים בדוגמה או בUser Story וזאת על פי עיסוקו , המיקוד שלו, ומה שהוא עסק בו בזמן האחרון. אי לכך אל תצפו כי הדברים הברורים לכם מאליו ברורים מאליו גם למרואיין. אל תשאירו הנחות סמויות או דברים שצריך להשלים בראש. נסחו את השאלה בצורה ברורה ואם אחרי הניסוח הברור השאלה נראית לכם ברורה מדי וטריויאלית מדי, אזי זאת רק ראיה כי השאלה אינה רלוונטית והייתה רלוונטית כל עוד הסתרתם ממנה טפח ואל לנו לצפות מהמרואיין שישלים בראש את אותו טפח שבראש שלנו.
נתקלתי במראיינים רבים שנזהרים מאוד באופן שבו הם שואלים את השאלה, שמא לו ינסחו או ידגישו משפט זה או אחר בשאלה אזי היא כבר תהיה טריווילאית. שאלה כזאת אינה עומדת בקריטריון המיהמנות.
במידה ונתתם למועמד לכתוב קוד והקריטריון שאותו אתם מחפשים זה Object Orientied אל תשאירו את ההנחה הסמויה הזאת אצלכם, מסרו לו בדיוק את הציפיות, כי אחרת הוא מבחינתו יכול להניח כי הקריטריון זה זמן או כמות שורות נמוכה או יכולת מיטבית לביצוע מקבילי או שפשוט יעבוד (כל אחד והעולם ממנו הוא בא) .
תקפות – מהימנות בוחנת את המידה בה מבחן מודד משהו, אך מהימנות גבוהה לא מבטיחה שהמבחן תקף, כלומר בודק את מה שהוא אמור למדוד. למשל, אם ניתן במבחן גמר בפסיכולוגיה שאלות מכשילות או שאלות שכוללות אוצר מילים קשה, יהיה זה מבחן של היכולת המילולית שלך או של ביצוע המבחן, אך לא של החומר הנלמד. מבחן כזה הוא מהימן – התלמידים יקבלו ציונים דומים במבחנים חוזרים , אך לא תהיה זו בחינה תקפה של הישגי הקורס.
איזו תקפות אנחנו מחפשים?
התקפות שלנו היא כלפי המשרה הספציפית אותה אנחנו רוצים לאייש. עלינו לוודא כי המבחן הוא תקף עבור אותה משרה.רובנו נוטים להכליל את כל משרות התיכנות כאותו סוג ולכן להשתמש באותו מבחן על מנת לבדוק את ההתאמה. טעות זאת מובילה אותנו ליצור מבחן אחיד שלא יעניק לנו את התקפות המיטבית עבור סוג המשרה הספציפית.
אינם דומים הכישורים הנדרשים ממתכנת בצוות תשתיות עתיר טכנולוגיות לכישורים הנדרשים ממתכנת בצוות דליברי. אם נפרק את מונח R&D הראשון נדרש לכישורים ב- R ואילו השני נדרש לכישורים ב-D .
הראשון צריך היכרות עם טכנולוגיות, יכולת להבין מהר טכנולוגיות חדשות, לזהות את הכשלים בטכנולוגיה, לגדר סיכונים בטכנולוגיה... ואילו אצל השני נדרשת יותר ההבנה העסקית והיכולת לזהות את החוסרים במערכת קיימת. אפילו הכישורים הלא טכנולוגיים הנדרשים משניהם כדוגמת שחקן קבוצתי אינם זהים.
ניסיון ההכללה של כל המתכנתים בכל המשרות תחת אותה קטגורית מבחן הוא ניסיון שטחי ביותר. אוסף התכונות והכישורים אינו יכול להימדד על ציר אחד . אפילו מנהיגות בתור דוגמה נצרכת בצורה שונה במקומות ובאירועים שונים ובקהלים שונים (מנהיגות משימתית מול מנהיגות אנשים). אי לכך הרעיון לקחת אוסף של חידות ואפילו אם הן קשורות לעולם התוכנה (שכן עדיין עבור הרוב הגדול של המתכנתים פתרון החידות אינו נעוץ בכשורי היום יום התכנותיים שלהם, אלא בכשורי פתרונות של חידות או בזיכרון טוב לבעיות דומות מהאוניברסיטה) או מבחן אינטליגנציה כלשהו ועל בסיסו לפלג את כל אוכלוסיית המתכנתים הוא מדד שטחי ועלינו להתאמץ ולדרוש מעצמנו הנפקת תהליך מורכב מזה.
ישנם הבדלים גדולים בין מתכנת למתכנת. הבדלי תפוקה גדולים. הבדלי איכות... לכן עלינו לבודד היטב את המרכיבים אשר יוצרים מתכנת טוב יותר באותה פוזיציה ולנסות ליצור מבחן מיון אשר ממיין בצורה תקפה ומהימנה את התכונות הנדרשות לאותה פוזיציה.
האם בהכרח מתכנת שמבין קוד יותר מהר מצליח להבין יותר מהר דרישה עסקית?!
האם בהכרח מתכנת שכותב קוד יותר מהר כותב קוד שניתן לתחזוקה ול Refactor?!
האם מתכנת שכותב קוד מהר וקוד קריא בהכרח יישאר יותר זמן בארגון?!
האם תמיד עדיף לי מתכנת מעולה שאולי יישאר פחות זמן בארגון ממתכנת בינוני שיישאר ליותר זמן?!
האם עקשנות היא תכונה טובה למתכנת?!
האם שחקן קבוצתי תמיד עדיף על מתכנת יותר טוב?! ובאלו מינונים?!
האם עדיף מתכנת שכותב באגים אבל כותב מהר על פני מתכנת שכותב מושלם , אבל לאט?!
כפי שאתם רואים לאף שאלה אין תשובה מוחלטת. לחלק מהמשרות עדיף סוג אחד ולחלק מהמשרות סוג אחר.
פתגם סיני עתיק אומר שעדיף להיות עשיר ובריא מאשר עני וחולה, אבל החיים (למעט נוחי דנקנר) לא מסתדרים לנו תמיד במבנה של פתגם סיני ולכן עלינו לתעדף תכונות מסוימות ולעיתים גם למשרה מסוימת נעדיף תכונה מסוימת ובמשרה אחרת נרצה להימנע ממנה.
חלק מהתכונות המבדלות והמגדירות מתכנת טוב הן כלליות ונכונות לכל מתכנת בכל משרה, כמו – היכולת להיכנס לקוד בצורה מהירה, יכולת ניתוח וחלק הן דרישות ספציפיות עבור המשרה המיועדת ועל כן בבניית המבחן עלינו להסתכל על המשרה הספציפית אותה אנו מייעדים את המתכנת.
לאחר שאפיינו את הכישורים הנדרשים מאותה משרה עלינו לקחת את המתכנתים המצטיינים שלנו באותה פוזיציה ולבדוק את תקפות ומהימנות המבחן. נכון שעל מנת לבדוק תקפות ומהימנות ובכלל לצורך בדיקה סטטיסטית כלשהי צריך אוכלוסיה גדולה יותר, אך לצערנו אין לנו את המותרות הזאת.
עלינו לנסות להיות אמיצים לנסח את המבחן בעצמנו ולא להתחבא מאחורי הרגלים ומסורות, כדוגמת שאלות כאלה.
קל לנו להתחבא מאחורי שיטות מיון שרצות כבר שנים , כפי שהרבה חברות ממשיכות לעבוד עם שיטת הראיון המסורתית ועם מכוני המיון אף על פי שהמתאם שלהם הוא די גרוע במיוחד של הראיון האישי.
קל לנו להתחבא מאחורי שיטות מיון שרצות כבר שנים , כפי שהרבה חברות ממשיכות לעבוד עם שיטת הראיון המסורתית ועם מכוני המיון אף על פי שהמתאם שלהם הוא די גרוע במיוחד של הראיון האישי.
על מנת להשלים את הפוסט הזה בצורה הטובה ביותר אשמח לשמוע מכם על ראיונות טובים (מבחינת תקפות ומהימנות ) שאתם עשיתם או שעשו לכם וכמו כן על התכונות הנדרשות ממתכנת באופן כללי וממתכנתים בתפקידים מסוימים (דליברי, פיתוח תשתית ) באופן ספציפי.
כתבת יפה מאוד על סוגי ראיונות בהייטק! בהחלט טוב להתכונן לראיון עבודה בהייטק מול מה שכתבת.
השבמחק