איך מתכוננים לראיונות, חלק ב'

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

לא בטוחים מה בכלל קורה פה? כדאי לקרוא את המדריך מההתחלה.

 

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

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

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

בדיקת ידע בשפה, לפעמים איזוטרי

חלק מהמראיינים פשוט ישאלו אותך שאלות שכוללות דקלום כלל של שפת התכנות הרלבנטית. למשל, "מה זה אומר שמתודה היא protected בג'אווה? מאיפה אפשר ומאיפה אי אפשר לקרוא לה?". אם את מרימה כרגע גבה, אני מבין למה… הרי אם הכלל הוא משהו שנתקלים בו במסגרת התכנות השוטף בשפה, כולם יענו בלי בעיה והשאלה לא מאפשרת לעמוד על טיבה של מועמדת. ואם הכלל הוא מקרה איזוטרי שלא מעניין אף אחד, סביר שיהיו מועמדים חזקים שלא ידעו דווקא את הטריוויה הזו בשלוף. למשל: "מני את כל השימושים האפשריים של ה-keyword static בשפת C, והסבירי מה כל אחד מהם עושה" (אגב, קריאה מומלצת לפני השינה).

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

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

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

קריאת קוד נתון, לרוב כולל מציאת באגים בקוד

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

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

תכנות מונחה עצמים

שאלות בנושא לרוב מציגות בעיה "מהעולם האמיתי", ומבקשות להציע מבנה קלאסים מתאים. למשל, "נניח שהיינו רוצים לתכנת משחק מונופול למחשב. אילו קלאסים את חושבת שצריכים להיות במערכת, אילו מתודות עיקריות יש לכל קלאס, ומי יורש ממי?". או "דמייני שאנחנו כותבים משחק סימולציה של חווה בסגנון FarmVille, שצריך לתמוך בסוגי החיות הבאים […]. אילו קלאסים יהיו במערכת, ומי יורש ממי?".

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

"A is a B”

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

“A pigeon is a bird”.

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

הפגנת ידע במערכות הפעלה ורשתות

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

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

  • מהו מודל השכבות? אילו שכבות מרכיבות אותו, ומה תפקידה של כל שכבה?
  • תארי איך עובד אחד מהפרוטוקולים הנפוצים באינטרנט, למשל TCP, HTTP, DNS. מה ההבדל בין TCP ל-UDP? (אגב, מנסיוני השאלה האחרונה היא ממש פופולרית, אני לא בטוח למה).
  • מה זה subnet? מה ההבדל בין MAC address לכתובת IP? מה ההבדל בין סוויץ' וראוטר?

מערכות הפעלה:

  • מה ההבדל בין thread ל-process? (אגב, גם זו שאלה נורא פופולרית).
  • איך ניתן להעביר מידע ולסנכרן בין threads? (המראיינת מצפה שתזכירי לפחות מנגנון סנכרון פופולרי אחד, למשל semaphore, mutex, Java synchronized methods.)
  • איך אפשר להעביר מידע בין processes? (תשובה אפשרית אחת: sockets)
  • מה זה deadlock, ואיך נמנעים ממנו?
  • מה זה זכרון וירטואלי? תארי בכלליות את הטיפול הטיפוסי ב-page fault.

 

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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