"אבל זה ידע בסיסי!"
- פותח הנושא GuestOfHonor
- פורסם בתאריך
לא רוצה לבאס אותך
בהחלט לא 90% נכשלים (איך הגעת למסקנה הזו?).
"לממש צבא" לא אמור להיות מלחיץ יותר משאלת פסיכומטרי של "פרות סגולות" או כל דבר אחר. כלל ראשון לכל מי שפותר משהו בלוגיקה או שפות פורמליות בכלל זה שהמושגים הם רק טרמינולוגיים וזה לא משנה אם זה "צבא" או "וועד בית". וכן, מתכנת אמור לתרגם בראש מבנה היררכי לקוד.
האמת שאני נותן את אותה שאלה (רק בלי הסיגריות...) מאז 2007 בערך. מי שמסתבך עם "צבא וחיילים" אני אומר לו שידמיין מנכ"ל שתחתיו יש מנהלים ומנהלים זוטרים ועובדים. מי שלא מסוגל לדמיין מבנה כזה נמצא בבעיה. אין בעיה לחשוב על זה 10 דקות אבל צריך להיות מסוגל לבטא מציאות לקוד.
יש מקומות שנותנים את המבחן בצורה של "ספריות וקבצים" ויש אינספור גרסאות לדיזיין הזה.
דבר אחרון: ממש לא בא לי לראות מימוש קוד של זה, שיכול לקחת שעתיים תלוי בדרישות. מספיק שיצייר על לוח משהו שמזכיר UML עם רשימת הקלאסים, היחסים ביניהם וכו'. מה שעושים בערך בכל ישיבת דיזיין ממוצעת בעבודה.
בהחלט לא 90% נכשלים (איך הגעת למסקנה הזו?).
"לממש צבא" לא אמור להיות מלחיץ יותר משאלת פסיכומטרי של "פרות סגולות" או כל דבר אחר. כלל ראשון לכל מי שפותר משהו בלוגיקה או שפות פורמליות בכלל זה שהמושגים הם רק טרמינולוגיים וזה לא משנה אם זה "צבא" או "וועד בית". וכן, מתכנת אמור לתרגם בראש מבנה היררכי לקוד.
האמת שאני נותן את אותה שאלה (רק בלי הסיגריות...) מאז 2007 בערך. מי שמסתבך עם "צבא וחיילים" אני אומר לו שידמיין מנכ"ל שתחתיו יש מנהלים ומנהלים זוטרים ועובדים. מי שלא מסוגל לדמיין מבנה כזה נמצא בבעיה. אין בעיה לחשוב על זה 10 דקות אבל צריך להיות מסוגל לבטא מציאות לקוד.
יש מקומות שנותנים את המבחן בצורה של "ספריות וקבצים" ויש אינספור גרסאות לדיזיין הזה.
דבר אחרון: ממש לא בא לי לראות מימוש קוד של זה, שיכול לקחת שעתיים תלוי בדרישות. מספיק שיצייר על לוח משהו שמזכיר UML עם רשימת הקלאסים, היחסים ביניהם וכו'. מה שעושים בערך בכל ישיבת דיזיין ממוצעת בעבודה.
GuestOfHonor
New member
GuestOfHonor
New member
כאמור, זאת לא השאלה המקורית
השאלה המקורית מנוסחת ביתר בהירות.
מה שראית פה זה משהו שהנפצתי בכמה דקות, וגם אותו בטוח אפשר לנסח פי אלף יותר טוב.
כסגל זוטר בעבר אני מסכים ככלל לגבי האמירה במשפט האחרון, *אבל* - זאת שאלת ראיון חוויתי אותה כמרואיין, ולכן אני די משוכנע שזה לא המצב. השאלה המקורית באמת רק דורשת הבנה בסיסית של חלוקה למחלקות ואת זה שמחלקות שונות יכולות לממש אותה פונקציה אחרת (ולא משנה אם השתמשנו בירושה או בממשקים וקומפוזיציה).
לגבי הבלאקאוט מהצבא, אני מקווה שברור לך שתוכן שאלת הדמה שכתבתי הוא הומוריסטי, ונשמע לי overreacting להיבהל משאלה רק כי היא על חיילים ולא דובוני אכפת לי. מבטיח שהדומיין של השאלה המקורית הוא נייטרלי
.
השאלה המקורית מנוסחת ביתר בהירות.
מה שראית פה זה משהו שהנפצתי בכמה דקות, וגם אותו בטוח אפשר לנסח פי אלף יותר טוב.
כסגל זוטר בעבר אני מסכים ככלל לגבי האמירה במשפט האחרון, *אבל* - זאת שאלת ראיון חוויתי אותה כמרואיין, ולכן אני די משוכנע שזה לא המצב. השאלה המקורית באמת רק דורשת הבנה בסיסית של חלוקה למחלקות ואת זה שמחלקות שונות יכולות לממש אותה פונקציה אחרת (ולא משנה אם השתמשנו בירושה או בממשקים וקומפוזיציה).
לגבי הבלאקאוט מהצבא, אני מקווה שברור לך שתוכן שאלת הדמה שכתבתי הוא הומוריסטי, ונשמע לי overreacting להיבהל משאלה רק כי היא על חיילים ולא דובוני אכפת לי. מבטיח שהדומיין של השאלה המקורית הוא נייטרלי
אוהב להתווכח
New member
אני חושב שמנהלים hands on הם טובים יותר
ולכן צריך לאפשר (ולהכריח) גם למפקדים לאסוף סיגריות.
ולכן צריך לאפשר (ולהכריח) גם למפקדים לאסוף סיגריות.
נתקלתי בזה המון פעמים
יש לזה כמה סיבות (ושילובים):
 
1. כל מיני ראשי צוותים ופאונדרים hands on - לא באמת היו hands on כבר לא מעט זמן. לא בטוח שהיו טובים בתור מהנדסים גם לפני. אין בהכרח קורילציה בין מהנדס טוב למנהל טוב, ולפעמים דווקא אלה שטכנית לא הכי חזקים - טובים למדי בניהול צוותים/מחלקות ומעלה.
 
2. לחץ. כשאתה נלחץ דברים טריויאלים הופכים להיות לקשים. לא סתם שאלות ראיונות הן די טריויאליות בסך הכל. לא רק שלך - של רובנו. כי כשהמרואיין נלחץ - הדבר הכי טריויאלי מסתתר בפינת הblackout.
 
3. הנסיון לא ממש בכיוון - בתחום שלי למשל, הרבה אנשים מגיעים עם נסיון OOP שהוא תת רמה. כי מה לעשות, בעולם האמבדד, במיוחד על SOCים לא סטנדרטיים, יש עדיין הרבה קוד לגאסי שהוא C פרוצדורלי טהור. והרבה אנשים עובדים עליו, מתחזקים אותו ומוסיפים לו פיצ'רים. לא יודע מה כתוב לאנשים בקורות חיים, אבל כשבא אליי מישהו שיש לו 5 שנות נסיון של כתיבת FW על MIPS - כנראה שC++11 זה לא הצד החזק שלו.
 
4. שקרנים. גם בכאלה נתקלתי לא מעט. לא מן הנמנע שהקו"ח שלהם מונפצים, ולכל הפחות - משופצים. אומנם בbackground check היו עולים על זיופים - למה לחכות עד אז אם אפשר לשאול שאלה שהיא בול במרכז הנושא שהבן אדם "עבד עליו" 5 שנים ולצפות בו בוהה בך בעיני עגל?
יש לזה כמה סיבות (ושילובים):
 
1. כל מיני ראשי צוותים ופאונדרים hands on - לא באמת היו hands on כבר לא מעט זמן. לא בטוח שהיו טובים בתור מהנדסים גם לפני. אין בהכרח קורילציה בין מהנדס טוב למנהל טוב, ולפעמים דווקא אלה שטכנית לא הכי חזקים - טובים למדי בניהול צוותים/מחלקות ומעלה.
 
2. לחץ. כשאתה נלחץ דברים טריויאלים הופכים להיות לקשים. לא סתם שאלות ראיונות הן די טריויאליות בסך הכל. לא רק שלך - של רובנו. כי כשהמרואיין נלחץ - הדבר הכי טריויאלי מסתתר בפינת הblackout.
 
3. הנסיון לא ממש בכיוון - בתחום שלי למשל, הרבה אנשים מגיעים עם נסיון OOP שהוא תת רמה. כי מה לעשות, בעולם האמבדד, במיוחד על SOCים לא סטנדרטיים, יש עדיין הרבה קוד לגאסי שהוא C פרוצדורלי טהור. והרבה אנשים עובדים עליו, מתחזקים אותו ומוסיפים לו פיצ'רים. לא יודע מה כתוב לאנשים בקורות חיים, אבל כשבא אליי מישהו שיש לו 5 שנות נסיון של כתיבת FW על MIPS - כנראה שC++11 זה לא הצד החזק שלו.
 
4. שקרנים. גם בכאלה נתקלתי לא מעט. לא מן הנמנע שהקו"ח שלהם מונפצים, ולכל הפחות - משופצים. אומנם בbackground check היו עולים על זיופים - למה לחכות עד אז אם אפשר לשאול שאלה שהיא בול במרכז הנושא שהבן אדם "עבד עליו" 5 שנים ולצפות בו בוהה בך בעיני עגל?
בוודאי שקורה
לדוגמא - מועמד עם נסיון שלא יודע להסביר מה ההבדל בין process ל-thread או מועמדת שהסתבכה בשאלת חימום כי לא ידעה מה זה מודולו...
בצד המקל, מעבר לדברים באמת חריגים - בסיטואציה של ראיון לפעמים אנשים רואים בשאלות פשוטות הרבה יותר ממה שיש בהן באמת ומתחילים להסתבך או להכנס לבלקאוט.
חוץ מזה, יש שלבים בחיי חברה שלקוד "נכון" אין הרבה חשיבות לעומת הכרת כלים או לייצר מהר משהו עובד ככה שהטייטל של מועמד לא צריך ליצור ציפיות (ה-CTO בחברה הקודמת שעבדתי בה היה אחד המתכנתים הכי גרועים שנקלתי בהם וכבר נתקלתי בכמה) - כן הייתי מתפלא אם מישהו שפיתח קוד תשתיתי במוצר מספיק גדול לא יודע לעשות דיזיין בסיסי.
לעניין תכנות מונחה עצמים - זה נושא שיש בו דיסוננס מובנה: מצד אחד הרבה מהשאלות בתחום הן סביב נושאים של ירושה (והתחכמויות מסביב) וגם בקורסים די חופרים על זה. מצד שני, בחיים האמיתיים מעבר לסיטואציות מאוד ספציפיות ירושה (ובמובנים מסויימים גם DP) די יצאה מהאופנה כשיש העדפה ברורה לקומפוזיציה ועבודה מול ממשקים לעומת מחלקות ככה שזה נושא שהרבה מתכנתים כבר לא נתקלים בו באופן מסיבי כמו פעם. אפשר לחשוב על שאלות טריוויאליות שמישהו בסוף קורס יענה עליהן יותר בקלות מאשר מישהו עם נסיון.
לדוגמא - מועמד עם נסיון שלא יודע להסביר מה ההבדל בין process ל-thread או מועמדת שהסתבכה בשאלת חימום כי לא ידעה מה זה מודולו...
בצד המקל, מעבר לדברים באמת חריגים - בסיטואציה של ראיון לפעמים אנשים רואים בשאלות פשוטות הרבה יותר ממה שיש בהן באמת ומתחילים להסתבך או להכנס לבלקאוט.
חוץ מזה, יש שלבים בחיי חברה שלקוד "נכון" אין הרבה חשיבות לעומת הכרת כלים או לייצר מהר משהו עובד ככה שהטייטל של מועמד לא צריך ליצור ציפיות (ה-CTO בחברה הקודמת שעבדתי בה היה אחד המתכנתים הכי גרועים שנקלתי בהם וכבר נתקלתי בכמה) - כן הייתי מתפלא אם מישהו שפיתח קוד תשתיתי במוצר מספיק גדול לא יודע לעשות דיזיין בסיסי.
לעניין תכנות מונחה עצמים - זה נושא שיש בו דיסוננס מובנה: מצד אחד הרבה מהשאלות בתחום הן סביב נושאים של ירושה (והתחכמויות מסביב) וגם בקורסים די חופרים על זה. מצד שני, בחיים האמיתיים מעבר לסיטואציות מאוד ספציפיות ירושה (ובמובנים מסויימים גם DP) די יצאה מהאופנה כשיש העדפה ברורה לקומפוזיציה ועבודה מול ממשקים לעומת מחלקות ככה שזה נושא שהרבה מתכנתים כבר לא נתקלים בו באופן מסיבי כמו פעם. אפשר לחשוב על שאלות טריוויאליות שמישהו בסוף קורס יענה עליהן יותר בקלות מאשר מישהו עם נסיון.
מסכים במיוחד עם החלק השני
אגב, זה לא רק מועמדים. לפעמים אני רואה מישהו שעובד איתי שאחרי תקופה ארוכה של עבודה בJS או בC על מיקרופרוססור לא זוכר דברים בסיסיים בירושה.
ואפילו מי שכן עובד בשפות תומכות ירושה כמו פיתון אבל תקופה ארוכה עובד במוד של סרביסים שטוחים או סקריפטים אות תכנות פונקציונלי אחרי שנה יש מצב שלא יזכור את כל הפינות.
לכן ריענון לפני ראיון הוא קריטי בעיניי (וגם אני עושה כך). למתכנת מנוסה לא צריך לקחת יותר משעה-שעתיים להזכר בניואנסים + כמה שאלות לדוגמא מגוגל לראות שהוא בעניינים.
מי שכן עובד בסביבה של OOP אבל מתעצל לחשוב עד הסוף על הקוד שהוא כותב ומגיע לראיון בלי לדעת דברים בסיסיים זה מעצבן ויכול להביא לפסילה על הקטנת ראש.
אגב, לבוגרים טריים יש יתרון בנושא הזה.
אגב, זה לא רק מועמדים. לפעמים אני רואה מישהו שעובד איתי שאחרי תקופה ארוכה של עבודה בJS או בC על מיקרופרוססור לא זוכר דברים בסיסיים בירושה.
ואפילו מי שכן עובד בשפות תומכות ירושה כמו פיתון אבל תקופה ארוכה עובד במוד של סרביסים שטוחים או סקריפטים אות תכנות פונקציונלי אחרי שנה יש מצב שלא יזכור את כל הפינות.
לכן ריענון לפני ראיון הוא קריטי בעיניי (וגם אני עושה כך). למתכנת מנוסה לא צריך לקחת יותר משעה-שעתיים להזכר בניואנסים + כמה שאלות לדוגמא מגוגל לראות שהוא בעניינים.
מי שכן עובד בסביבה של OOP אבל מתעצל לחשוב עד הסוף על הקוד שהוא כותב ומגיע לראיון בלי לדעת דברים בסיסיים זה מעצבן ויכול להביא לפסילה על הקטנת ראש.
אגב, לבוגרים טריים יש יתרון בנושא הזה.
טרול המתכנן
New member
ירושה היא אם כל חטאת. אתם מבססים את הגיוס שלכם על סילות הפוך
inverse filtering
מי שסולד מירושה בחוץ... אתם תשארו עם קוד מחורבן, מתכנתים מוכשרים ימצאו מקום טוב יותר להתבטא בו - נשמע לי win win.
inverse filtering
מי שסולד מירושה בחוץ... אתם תשארו עם קוד מחורבן, מתכנתים מוכשרים ימצאו מקום טוב יותר להתבטא בו - נשמע לי win win.
ויכוח דתי ידוע
כך או כך, במקום שכותבים בשפות מונחות עצמים באופן מלא (ג'אווה למשל...), וכל הקוד כתוב OO ואין כוונות להחליף, אין מנוס מלגייס מישהו שיודע לפחות את העקרונות שמלמדים אפילו בתיכון.
זאת גם דרך לבדיקת מהימנות של מישהו שטוען שיודע ועבד בזה.
מי שמודיע מראש שהוא עובד פונקציונלית ישאיר למראיין את ההחלטה אם זה מתאים לו או לא.
כך או כך, במקום שכותבים בשפות מונחות עצמים באופן מלא (ג'אווה למשל...), וכל הקוד כתוב OO ואין כוונות להחליף, אין מנוס מלגייס מישהו שיודע לפחות את העקרונות שמלמדים אפילו בתיכון.
זאת גם דרך לבדיקת מהימנות של מישהו שטוען שיודע ועבד בזה.
מי שמודיע מראש שהוא עובד פונקציונלית ישאיר למראיין את ההחלטה אם זה מתאים לו או לא.
GuestOfHonor
New member
האם היית מעסיק במשרת פיתוח מישהו שלא יכול להתמודד עם השאלה?
באופן אישי, שאלות בסגנון "ההבדל בין ממשק לאבסטרקט" מרגישות לי כמו שאלות חטיבת ביניים של "לשפוך ידע" ולא להוכיח שאתה מבין מה אתה אומר או מסוגל ליישם את ה"ידע" לכאורה הזה.
באופן אישי, שאלות בסגנון "ההבדל בין ממשק לאבסטרקט" מרגישות לי כמו שאלות חטיבת ביניים של "לשפוך ידע" ולא להוכיח שאתה מבין מה אתה אומר או מסוגל ליישם את ה"ידע" לכאורה הזה.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.