תהליך המיון הטוב ביותר שעברתי (או שלא)

לפני שנים רבות . עת הייתי צעיר וחוצפן התפרסמה מודעת דרושים – " חברת SAP מחפשת חיילים לסיירת JAVA עולמית ". אני הייתי בעל חצי שנה ניסיון בלבד והחלטתי לקפוץ מעל הפופיק ולהציע את מועמדותי . תהליך הסינון כלל מספר שלבים , בהם מבחן בכתב שהקיף נושאים רבים , כולל שאלות ארכיטקטורה וDESIGN , מספר ראיונות , חידות...
נתחיל מהסוף – לא התקבלתי.
עכשיו אחרי שהשבענו את הסקרנות אפשר לספר על החלק , שלדעתי מקנה לתהליך זה את התואר – התהליך התקף ביותר (שימו לב הוא תקף מאוד עבור המשרה הספציפית הזאת, ולא יהיה תקף עבור משרות אחרות).

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

האם זהו מבחן נכון לכל משרת תכנות? – ממש לא

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

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

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

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



Stack Or Heap?

I am reading now a great book - http://www.amazon.com/CLR-via-C-Jeffrey-Richter/dp/0735627045

One of the topic is "How Things Relate at Runtime" . Under this topic the author explain that value types are stored on the stack. I was curioues about it . so I google it and I found a lot of dicsussion about this topic and a lot of arguments either it store on the heap or stack.
Evantually i found this post - http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx

The interesting point in the post wast the answer to the question above.
The intresting point was - why the hall do you care about where is it stored????
"It is almost always irrelevant. We've worked hard to make a managed environment where the distinctions between different kinds of storage are hidden from the user. Unlike some languages, in which you must know whether a particular storage is on the stack or the heap for correctness reasons."

DAM , He is right!!!

Some might say that they need to know this due to performance reasons, but the performance impact (in most of the cases) is so negligible , so this is not a good reason.
The few times that I need to know extreme stuff about heap vs stack were in interviews.
This question is an example to knowledge which is poplular in interviews but has no impact or use in the " real development word ".

So, if this question is irellevant to the " real life " why interviewer keep asking it?
For my opinon there are couple of reasons for this:
1. assumpation that a good developer is measured by pitfall knowledge and small low levels details.
2. This is the kind of question that I was asked , so I am asking the same question
3. The interviewer did google for interview question and found these kind of questions.

תקפות ראיונות עבודה בהייטק

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

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

סוגי ראיונות נפוצים:

מודול מרכזי

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

חידות

חידות טהורות. כמו חידות הכובעים למינם.

שאלת אלגוריתם 

 כגון – כתוב פונקציה אשר מוצאת את האיבר השני בגודלו בעץ חיפוש בינארי.

שאלות ארכיטקטוניות

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

Spring vs Jee

Rest advantage and disadvantages

WebService vs Ejb Stateless

שאלות טכניות מונחים

Transaction isolation, Hibernate caching 

שאלות טכניות קומפילציה

מה יקרה בתוכנית הבאה? האם תתקמפל? איזה שגיאות יהיו? מה יהיה הפלט

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

מאפייניו של מבחן טוב:

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

מדד נוסף של מהימנות הוא " עקביות פנימית " , המידה בה שאלות נפרדות במבחן מודדות את אותו הדבר. מדד זה נבדק על ידי מתאם הציונים שהושגו על ידי קבוצת אנשים בכל שאלה לציון הכללי שלהם.
לעיתים " תוכן השאלה " אכן רלוונטי לתהליך המיון, אך השאלה כפי שנשאלת על ידי המראיין תוביל לתוצאות לא עקביות אצל אנשים בקבוצה דומה ואפילו אצל אותו אדם לו נשאלה בזמנים שונים ביום.
באחד הראיונות נשאלתי את השאלה הבאה:
יש לך טבלה בעלת שתי שדות - שם, מצב נעילה (ערך בוליאני). מה לא טוב בטבלה?
כמובן מיד קופץ לראש (שלי לפחות) כל הנושא של אינדקס על קבוצה בעלת עוצמה נמוכה. פתרונות ומימושים בסוגי DB שונים, אך לא זה עניין את המראיין.
אני ממשיך להסתכל על הטבלה המאוד פשוטה הזאת וזורק עוד כל מיני הערות , אך גם אותן לא חיפש המראיין.
בסופו של דבר התשובה אותה חיפש היא שלא נכון יהיה להגדיר את עמודת השם בתור PK , בשל העובדה כי שמות הם לא יחודיים (אבי כהן בתור דוגמה).
לו השאלה הייתה נשאלת בתצורה ברורה וגלויה כמו - האם היית מגדיר שם של עובד בתור PK של טבלה, לא היה מפתח שלא היה ישר זועק את התשובה, שכן כל מי שכתב טבלה אחת בחיים שלו התמודד עם כך, אך לא כך כאשר השאלה תשאל בצורה עקיפה.
כל אחד מאיתנו ננעץ על פרטים שונים בדוגמה או בUser Story  וזאת על פי עיסוקו , המיקוד שלו, ומה שהוא עסק בו בזמן האחרון. אי לכך אל תצפו כי הדברים הברורים לכם מאליו ברורים מאליו גם למרואיין. אל תשאירו הנחות סמויות או דברים שצריך להשלים בראש. נסחו את השאלה בצורה ברורה ואם אחרי הניסוח הברור השאלה נראית לכם ברורה מדי וטריויאלית מדי, אזי זאת רק ראיה כי השאלה אינה רלוונטית והייתה רלוונטית כל עוד הסתרתם ממנה טפח ואל לנו לצפות מהמרואיין שישלים בראש את אותו טפח שבראש שלנו.
נתקלתי במראיינים רבים שנזהרים מאוד באופן שבו הם שואלים את השאלה, שמא לו ינסחו או ידגישו משפט זה או אחר בשאלה אזי היא כבר תהיה טריווילאית. שאלה כזאת אינה עומדת בקריטריון המיהמנות.
במידה ונתתם למועמד לכתוב קוד והקריטריון שאותו אתם מחפשים זה Object Orientied אל תשאירו את ההנחה הסמויה הזאת אצלכם, מסרו לו בדיוק את הציפיות, כי אחרת הוא מבחינתו יכול להניח כי הקריטריון זה זמן או כמות שורות נמוכה או יכולת מיטבית לביצוע מקבילי  או שפשוט יעבוד (כל אחד והעולם ממנו הוא בא) .

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

איזו תקפות אנחנו מחפשים?

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

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

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

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

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

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

האם בהכרח מתכנת שכותב קוד יותר מהר כותב קוד שניתן לתחזוקה ול Refactor?!

האם מתכנת שכותב קוד מהר וקוד קריא בהכרח יישאר יותר זמן בארגון?!

האם תמיד עדיף לי מתכנת מעולה שאולי יישאר פחות זמן בארגון ממתכנת בינוני שיישאר ליותר זמן?!

האם עקשנות היא תכונה טובה למתכנת?!

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

האם עדיף מתכנת שכותב באגים אבל כותב מהר על פני מתכנת שכותב מושלם , אבל לאט?!

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

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

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

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

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

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