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

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

מתחילים בבעיה, לא ב־Stack

נניח שבניתם מנגנון לעיבוד הזמנות. הפתיחה החלשה היא: ״עבדנו עם Python, PostgreSQL, Redis ו־Kafka״. עדיין לא ברור מי השתמש במערכת, מה נשבר או מדוע נדרשה עבודה. פתיחה טובה יותר: ״לקוחות קיבלו סטטוס לא עקבי להזמנות, משום שעדכון המלאי והחיוב התבצעו בזמנים שונים. הייתי אחראי על תכנון זרימת הסטטוסים ועל השירות שמרכז אותם״.

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

משרטטים מסלול אחד מקצה לקצה

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

Client -> Orders API -> Orders DB
                     -> Outbox -> Broker
                                -> Inventory Worker
                                -> Payment Worker

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

בוחרים שתי החלטות שיש מאחוריהן מחיר

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

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

מפרידים בין ״אנחנו״ לבין ״אני״

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

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

מציגים תוצאה בלי להמציא מדידה

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

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

תרגול שמכין גם לשאלות המשך

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

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