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

ברוב תהליכי הקבלה לחברות אתם תיתקלו בשלב של מטלת בית.

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

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

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

לפני תחילת העבודה

תקראו הוראות! (ואז תקראו אותן שוב… ושוב…)

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

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

תתכננו את העבודה

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

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

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

רצוי מול מצוי

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

כתיבת המטלה

תחשבו על הקורא

אחד הדברים החשובים בכתיבת קוד נכון וטוב הוא הקריאות של הקוד (readability).

ברוב המוחלט של המקרים המחשב לא יקרא את הקוד שכתבת בדיוק בצורה שכתבתם אותו. בדרך כלל הקוד יעבור תהליך כלשהו לפני שהוא ירוץ באמת במערכת (compilation, transpliation, minification, uglification וכו'…).
מכאן נובע שאת הקוד שאתם כותבים אך ורק בני אדם יקראו, ואתם רוצים לעשות לבני האדם האלה חיים קלים.

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

עקביות עקביות עקביות

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

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

הגודל לא קובע

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

מישהו כתב את זה קודם

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

נקודות בונוס

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

לפני ההגשה

תתחילו מאפס

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

תיעוד טוב שווה המון

כדאי מאד להוסיף למטלה תיעוד טוב, זה יכול להיות בקובץ PDF או גוגל דוקס או אפילו קובץ readme.md, הכל הולך ויוסיף לכם נקודות רבות. שוב פעם, קריאות של המטלה ומחשבה על הקורא יעזרו לכם מאד להתקדם בתהליך.

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

כמובן שניתן ורצוי להוסיף לכך מה שרלוונטי בעיניכם:

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

ניקיון אורוות

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

זהו, הגיע הרגע לשלוח את המטלה ולקוות לחדשות טובות.

שיהיה בהצלחה!

מפתח frontend ומנהל צוותי פיתוח במספר חברות סטארט-אפ. בעל ניסיון רב בגיוס לתפקידי פיתוח.

הישארו מעודכנים

הצטרפו לעמוד הטלגרם שלנו!

*זוהי קבוצה שקטה שבה רק האדמינים שולחים הודעות

עזרנו לכם? שתפו את הכתבה עם חברים!

יש לך מאמר שיעזור?