מה בוחנים מחפשים במשימות הבית של מועמדים למשרות תכנות?

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

מקור: Pixabay

מאת דניאל קורן

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

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

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

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

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

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

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

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

זה *חייב* לעבוד!

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

מרבית שגיאות ההרצה בהן נתקלתי נגרמו כתוצאה מהיעדר מודולים או ספריות צד שלישי נדרשות. המצב מצביע על כך שאותן החבילות לא הוגדרו ברשימת התלויות (dependencies) של פתרון התרגיל (package.json, requirements.txt וכו׳). סביר להניח שספריות אלו הותקנו באופן גלובלי בסביבת העבודה של המועמד.

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

ישנן מספר דרכים לעשות זאת, ביניהן: שימוש בסביבת ״sandbox״ (Python virtualenv, NodeJS NVM, Ruby RVM וכו׳), הרצת הקוד בתוך קונטיינר עם minimal image ועוד. תמיד תוכלו לבקש מחבר או קולגה להריץ את הפתרון בסביבה שלו, אך אין זה מבטיח ריצה ללא משגיאות.

השתמשו ב-Style Guide או Linter

Style guides (מדריכי כתיבת קוד) כמו Python’s PEP8, עוזרים להפוך את הקוד לקריא יותר ומוודאים עקביות. יש לכך חשיבות רבה במיוחד עבור מפתחים לא מנוסים, שהיכרותם עם הסטנדרטים בתעשייה מוגבלת. Linters (מנתחי קוד סטטי) כמו eslint של JavaScript, מוסיפים שכבה נוספת המסייעת במניעת טעויות וסיכונים פוטנציאלים.

זמנכם מוגבל, אל תבזבזו אותו בהתלבטות אם כדאי להשתמש ברווחים או ב- tabs, או בחיפוש אחר שגיאות כתיב. Style guides ו-Linters יעזרו לכם לוודא שלא פספסתם שאריות כמו TODOs, prints או הערות. במרבית ה-Linters ישנה אפשרות של תיקון שגיאות אוטומטי, וניתן לשלבם כתוסף בסביבת הפיתוח המועדפת עליכם.

אין זה משנה באיזה style guide או linter תבחרו, כל עוד תשתמשו בו בעקביות לאורך הקוד שלכם. התוויית סט כללים מקובלים יעזרו לבוחן להתמקד בעיקר – ההחלטות הארכיטקטוריות והלוגיקה שיישמתם (ללא צורך ב- “bikeshedding”).

פרו טיפ: זכרו לפרט באיזה style guide או linter השתמשתם בקובץ התיעוד (ה-README).

קוד פתוח – חברו הטוב ביותר של המתכנת

מקור: Pixabay

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

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

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

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

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

אחסון קוד המקור וניהול גרסאות

רוב החברות שאני מכיר משתמשות בשירותי ענן לאחסון קוד (source code hosting) בעבודה עם Git ככלי לניהול גרסאות (version control). בין אם GitHub, GitLab או BitBucket האפשרות לארח בענן, על כל המשתמע מכך, פרוייקטים פרטיים ופתוחים כאחד, הופכת אותם לפלטפורמה הטובה ביותר עבור תרגילי קוד לבית. לכן, הופתעתי כאשר מספר מועמדים בחרו לשלוח את הפתרונות שלהם באמצעות אימייל.
על אף שלא תמיד מדובר בדרישה, עצתי היא תמיד להגיש את משימת הקוד שלכם דרך שירות אחסון הקוד שנמצא בשימוש החברה אליה אתם מתמיינים, משתי סיבות עיקריות:

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

פרו טיפ #1: אם אתם חוששים מכך שהמעסיק הנוכחי יחשף למשימה שעשיתם, וודאו כי אתם משתמשים באופציה של פרויקט פרטי (private repository).

פרו טיפ #2: במידה ואתם עדיין לא רגילים לעבוד לפי הפרדיגמה הזו, חלקו את הקוד שלכם לקומיטים (commits) לוגיים. זה יעזור לבוחן להבין את קו המחשבה ואת תהליך הפיתוח שעברתם במסגרת המטלה. זה בסדר גמור לארגן מחדש את ה-commits לאחר השלמת המשימה, כל עוד אינכם מאחדים אותם לשינוי אחד (squash them all together). ברב המקרים אין הכרח לוודא שכל commit מתפקד באופן עצמאי ובלתי תלוי, כפי שמפתחים רבים נוהגים לעשות בעבודה היום-יומית, בייחוד במשימות שמורכבותן הלוגית איננה גדולה.

בדיקות

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

  1. מעבר לווידוא נכונות לוגית, טסטים מונעים רגרסיות אשר עלולות להיגרם מ- code refactors, שיפורי יעילות ותיקוני linter.
  2. הבוחן יכול להשתמש בהם כדי לזהות בקלות את התרחישים השונים ומקרי הקצה איתם התמודדתם, וכן להבין אזורים מורכבים מבחינה לוגית. בדיקות יכולות להיתפס כאמצעי יעיל לתיעוד הקוד.
  3. טסטים יעזרו לפתרון שלכם לבלוט, מהסיבה הפשוטה שמרבית המועמדים בוחרים לוותר עליהם.

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

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

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

תיעוד (Documentation)

מקור: Pixabay

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

בהנחה שבחרתם באחת מפלטפורמות אחסון הקוד בענן, הדרך הפשוטה והמהירה ביותר היא לכלול את כל המידע אותו אתם רוצים להעביר לבוחן במסמך ה-README.md. הפורמט הסניטקטי שלו, שמבוסס על שפת סימון (Markup language) ברורה וקלת משקל, הפך לסטנדרט המקובל בפרויקטי קוד.

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

סעיפי חובה

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

נחמד להוסיף (Nice to have)

  1. ניתוח סיבוכיות – תלוי משימה כמובן, פירוט הסיבות לבחירה באלגוריתם או במבנה נתונים ספציפי משקף את צורת החשיבה שלכם והדרך בה ניגשתם לאתגר. אני ממליץ להשתמש ב-big O notation בחישוב סיבוכיות זמן הריצה.
  2. הנחות יסוד והבהרות – במידה והפיתרון שלכם מבוסס על הנחות מסוימות שלקחתם, לפרטו אותן. השתמשתם בשפת התכנות/בפריימוורק/במסד נתונים בפעם הראשונה? זה בסדר גמור, רק דאגו לציין זאת על מנת שלא תבחנו כמנוסים.
  3. ״הצעד הנוסף״ – קיימות דרכים נוספות לגרום לפתרון שלכם לבלוט. בין אם פתרתם את הבונוס, יישמתם ואלידציות על הדאטה, טיפלתם נכון בשגיאות או התמודדות עם מקרי הקצה המאתגרים ביותר, אל תסתמכו על כך שהבוחן יזהה זאת בעצמו.
  4. אם רק היה לי עוד זמן – לא הספקתם לטפל בתרחיש מסוים? יש לכם כיוון כללי איך לפתור את הבונוס? כתבתם טסט אחד אבל אתם יודעים מה המקרים האחרים שהייתם בודקים? ספרו זאת לבודק.

פרו טיפ: בסופו של דבר, מעבר על פתרונות של מועמדים אינה המשימה המרגשת ביותר ביומו של הבוחן (על אף חשיבותה). הוספת טאץ׳ אישי – MEME/gif/ASCII Art הקשורים לחברה או למשימה תמשוך את תשומת הלב של הבודק ותעלה חיוך על פניו.

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

הכותב הוא מתכנת Full Stack וראש צוות פיתוח בחברת BigPanda

כתב אורח

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

הגב

11 תגובות על "מה בוחנים מחפשים במשימות הבית של מועמדים למשרות תכנות?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אנאליטיק
Guest

TDD זה לכאלה שלא יודעים מראש לכתוב קוד כמו שצריך…

undefined
Guest

לא פלא שאתה אנאלי.

משתמש אובונטו
Guest

גדול :)

ראובן מ.
Guest

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

undefined
Guest

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

אליעד
Guest
חחחח קטלק מבחן בית יש לך הכל בגיטאב ומה שאתה רוצה אתה שואל בסטאקאובר עונים לך תוך שנייה אבל וואלק אומרים לך תראה את הקוד שלך מה עשית וזה.. עכשיו אין לי קוד קיצר אמרו לי ככה אי אפשר לענות דפקו לי מינוס ארבע על השאלה כושילירבאק תנו תאלגוריתם קיצר מצאתי את הפיתרון בגיקטוגיק שזה אתר של אשכנזים מלשנים שכותבים תשובות לשאלות מראיונות אבל וואלק למה לממש בסיפיפי שיש לך נוד ג’ייאס עושה נפמ אינסטול יש לך הכל סתם לסבך אבל וואלה סיפיפי שפה יפה מעמיקה זה גם פוינטרים יענו אנמנג’ד אבל גם מפנקים אותך באופיפי שתרגיש ג’אווה יענו זה… Read more »
דור
Guest

חבל שלימדנו את היהודים הערבים משהו חוץ מכבוד במשפחה ואלימות…

יהודי ערבי
Guest

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

איש עקרונות
Guest
קודם כל שאפו על הכתבה והטיפים, מכילה באמת הרבה טיפים טובים,. אומנם אני יודע שמטרת הכתבה היא לא לדון על היתרונות והחסרונות של שיטת משימות הבית, אבל בכל זאת כל הקונספט הזה של משימות בית הוא בעייתי במקרה הטוב כי אתה לא יכול לדעת מי באמת עשה את המשימה – יכול להיות שלמועמד יש חבר טוב מתכנת תותח והוא עשה את רוב המשימה והסביר בפירוט למועמד. מעבר לכך שלדעתי זה גם לא מוסרי למיין בשיטה הזאת כי אין חסם עליון לכמות הזמן שהמועמד ישקיע בבית ללא תמורה ויכול להיות שזה יהיה לחינם, במצב שנמשל המועמד חסר ניסיון בתחום ומאוד רוצה… Read more »
Rami Loiferman
Guest

אני הייתי מוסיף גם ci בTravis או Bitbucket Pipelines זה לא כזה מורכב ומראה על הבנה כם בdevops

משתמש אובונטו
Guest
אני משתמש במבחני בית במקרים מסויימים. חבל שהכותב לוקח את זה לכיוון של הערות, עבודה עם גיט, וטסטים. אלה דברים שאפשר ליישר קו תוך 3 ימים (כן, גם TDD, שבוע גג) ולא מעידים על איכות המועמד. גם הדברים האלה מאוד משתנים ממקום למקום, ובנוסף מישהו כמוני שכן עובד עם גיט, קומיטים, טסטים אבל לא יטרח לעשות את הדברים האלה בתרגיל ראיון. המטרה של התרגיל כמו כל תרגיל קוד נועד לבדוק אם המועמד מסוגל לקחת בעיה, להבין אותה, למדל אותה ולממש אותה בצורה טובה. ולא אם הוא יודע איך לשים שורה בnpn (יענו בpackage.json) או בmaven, או בכל מקום אחר. אם… Read more »
wpDiscuz

תגיות לכתבה: