שחזור ראיון מלא בזרטו

רשמתי את כל מה שזכרתי מייד לאחר הראיון ואני מביא אותו כאן:

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

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

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

שלב שני:
לעשות קוד ריויו ולזהות בעיות בקוד. לתת לכל בעיה עדיפות ולהציע שיפורים.

שלב שלישי:
להציע שיפורים להתנהגות השרת ולממש אותם יחד עם unit tests.

מפתח C# מתחיל

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

הראיון מתחלק לשלושה חלקים – צריך להבין את הקוד, למצוא בו באגים (ויש לא מעט) ואז לכתוב קצת קוד שמתקן חלק

מהבעיות.

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

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

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

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

Zerto – משרת QA

ראיון למשרת QA – הם מציירים לך מערכת שמצד אחד יש 3 מחשבים, שלושתם מחוברים דרך SWITCH לSTORAGE אחד גדול שואלים מה היתרונות ומה החסרונות.

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

מציירם את אחת המערכות מקודם (את הסינכרונית) -שואלים אותך מה הבעיות שיכולות להיות ואיך אתה יכול לאתר את הבעיות.

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