איך עונים לשאלה: "ספר על משהו שעשית בעבודה"

[S h a r k 1 8]

איך עונים לשאלה: "ספר על משהו שעשית בעבודה"

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

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

מה אתם עושים במצבים כאלה? איזה משימות אתם בוחרים להציג ואיך מציגים משימה שהיא בורג במערכת גדולה למישהו שלא מכיר בכלל את המערכת הגדולה?

 

[ipv6]

אתה שואל שאלה טובה

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

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

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

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

 

[S h a r k 1 8]

הבנתי. בקיצור, זאת בעיה.

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

 

[ipv6]

זה תלוי במשימה

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

כנ"ל באג.

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

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

 

[choo]

בוא נשאל אחרת - מה הדבר המשמעותי ביותר שעשית בעבודה שלך?

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

 

[S h a r k 1 8]

זה בדיוק מה שאני אומר

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

 

[בן100]

תראה

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

 

[choo]

אתה מסביר על המערכת ויורד לפרטים הרלונטיים.

&nbsp
כל זמן שאינך נותן לנו דוגמא קונקרטית - תקבל תשובות כלליות.
&nbsp
ברמת העקרון - אני זקוק לבערך 10 דקות כדי לתאר את המערכת שעבדתי עליה (למראיין אינטליגנטי שלא מגיע מהתחום שלי) לפני שאוכל להגיע לחלקים הנקודתיים שבהם עסקתי - וזו מערכת מורכבת למדי. גם ההסבר הזה מופרד למספר שכבות - כך שהמראיין יכול לעצור אותי בכל נקודת זמן שיבחר, ועדיין הוא יראה תמונה שלמה - ברמת הפירוט שיבחר לעצור בה. אין בעיה שהחלק של "ספר לי על פרוייקט שעשית בעבודה" בראיון עבודה ייקח 20-30 דקות, כולל פינג-פונג של שאלות, בראיון שנמשך שעה וחצי או יותר. התפקיד שלך זה להסביר בצורה ממצה ככל האפשר. התפקיד של המראיין הוא לכוון אותך למה שיותר מעניין אותו ולבקש יותר פרטים היכן שזה מספק לו מידע חשוב לו.
&nbsp
אם אינך יודע לתאר את המערכת שלך לאדם אחר - אתה יכול להתאמן על זה. ההבדל בין להסביר לגבי משהו שאתה מורגל להסביר והתאמנת עליו כבר 5-6 פעמים, לבין להסביר משהו בפעם הראשונה - יכול להיות ההבדל בין להסביר טוב וקצר, לבין להסביר גרוע ובמשך זמן ארוך מדי. ואם גם אחרי אימון לא תצליח להסביר את עצמך כמו שצריך - כנראה שיש לך בעיה שתפריע לך בראיונות עבודה.

 

[בן100]

כמה שנות נסיון יש לך?

בהתאם לשנות הנסיון ככה צריכה להיות התשובה.
&nbsp
מאדם עם 0-2 שנות נסיון אני מצפה לספר לי סיפור על פיצ'ר שמימש.
מאדם עם 10+ שנות נסיון אני מצפה כבר שיספר על מודול או מערכת שהיה אחראי עליה.
החל מהארכיטקטורה והשיקולים בנוגע להחלטות שקיבל ועד המימוש עצמו והבעיות שנתקל במימוש.
&nbsp
--
לשאלותיך?
* איך מציגים משימה שהיא בורג במערכת גדולה למישהו שלא מכיר בכלל את המערכת הגדולה?
&nbsp
מסבירים בקצרה על המערכת הגדולה ובלי להכנס לפרטים, לאחר מכן מסבירים על החלקים שהיית אחראי עליהם ומה היתה המשימה שעשית. משלב התכנון ועד שלב היישום.
&nbsp

 

[zaske]

לא מדוייק. לא נשאלתי את השאלה הזו בסיבוב האחרון

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