המיסתורין מאחורי system design / architecture interview

[hadooper]

המיסתורין מאחורי system design / architecture interview

קיבלתם תיאור מאד כללי (עם או בלי דרישות high-level) של מערכת מסויימת (שהיא נניח "large-scale"), האם אפשר בבקשה לקבל טיפים כיצד הייתם מנסים לפשט את הבעיה ולנסות לייצר ממנה תמונה יותר פרטנית של דרישות המערכת?

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

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

 

[hadooper]

בנוסף

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

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

בשורה התחתונה, אלו דברים שלוקח לי בחיים האמיתיים הרבה יותר זמן לעשות מאשר אותן 40 דקות מסכנות של ראיון עבודה עם לוח לבן... מה עושים?

 

[בן100]

בנוגע לשאלות ששאלת

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

 

[בן100]

התפקיד של ראיון ארכיטקטורה הוא לא בהכרח לבקש ממך לפתור אותה

המטרה היא לבדוק האם יש לך ראייה מערכתית.

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

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

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

5. במידה ובחרת לעבוד עם מודולים מוכנים או DB מסויים, לדעת להסביר למה בחרת דווקא במודול A על פני מודול B ומה הנימוקים לכך.
למשל, אם מדובר על DB, לדעת להסביר מה ההבדלים בין Oracle,MS-SQL, SQLite, MySql, Mongo וכו' וכו'.

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


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


* גילוי נאות: הכותב הינו ארכיטקט תוכנה וחוטא בראיונות עבודה של ארכיטקטים.

 

[Indigo121]

את כל זה הוא אמור לעשות מול לוח, באותו הרגע? כשהמראיין מחכה?

 

[בן100]

בראיון ארכיטקטורה?

כשמוקצבת שעה שלמה? 60 דקות?
&nbsp
כן.
&nbsp

 

[הייתיאביבקיץ]

אתה לא אמור לסיים את העיצוב, רק להתחיל

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

הם רוצים לראות איך אתה ניגש לנושא.

והשאלות שאתה שואל הן חלק מהעניין.

 

[user32]

לפי הכתיבה שלך בפורום לא אמורה להיות לך בעיה

פשוט דמיין את אחד השאלות שמישהו פה שאל כגון: "האם כדאי לי לממש פרוטוקול TCP משלי או להשתמש במשהו מוכן"?

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

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

 

[יבגניי34]

מה קשור ״מהנדס רע״? כל אחד יודע לעשות רק מה שהוא ניסה לעשות

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

מה שכן - בשלב הזה בראיון מנצח מי ש״לשונו נטועה יפה בפיו״.

 

[hadooper]

...

אם כך, האם היפותטית יכולתי להגדיל את סיכויי להתקבל למשרה אילו הייתי מפחית מקורות החיים את העובדה שאני מנוסה ב system design? או לפחות מציין שהמיומנויות שלי בכך הן "הוגנות" (fair skills) ולא "חזקות" (strong skills)?

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

 

[יבגניי34]

אין לי מושג, אני מתקשה להאמין שהמלל הזה משנה משהו למישהו.

המראיין יכול גם לשאול אותך על כיוון פסנתרים, ועדיין לא הייתי מוסיף בקו״ח ״piano tuning skills: basic״.

 

[choo]

האם שיקרת בקורות החיים שלך?

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

 

[hadooper]

תודעתית, system design היא משימה של ארכיטקטים ופחות של מפתח

בכיר ככל שיהיה, בסופו של יום.

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

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

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

 

[user32]

זה עניין סובייקטיבי

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

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

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

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

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

 

[user32]

הנה הצעה בשבילך

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

 

[choo]

תודעתית? תלוי בתודעה של מי מדובר

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

 

[ipv6]

אני לוקח פה הימור ומניח

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

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

 

[hadooper]

תודה על התגובה, האמת שיש לי תהיה לגבי העיצה הזאת...

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

 

[ipv6]

"לטחון" הכוונה לפתור שאלות כאלה

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

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

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

[1] תלוי בחברה כמובן.

 

[hadooper]

אז זהו, שעד כמה שידוע לי, אין כאן עניין של "תשובה נכונה"...

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

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