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

1. טיפול בשגיאות

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

מה קורה כשאין רשת? מה אם הרשת איטית? מה אם אין מקום בכונן? אם מערכת ההפעלה מותקנת על כונן d במקום c? מה אם המשתמש לא אישר לכם להשתמש בנתוני המיקום? מה אם נתוני מיקום לא זמינים?

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

2. מוכנות לגדילה

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

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

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

3. עבודה לפי סטנדרטים

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

def addtwo(x, y):
    return x + y

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

אם יש סטנדרט יחיד לשפה (כמו בפייתון) ודאו שקראתם אותו לפני שהתחלתם לכתוב קוד. לפעמים אין משהו רשמי אבל כן יש סט כללים מקובל בקהילה, לדוגמא בפרל מדובר על העצות מהספר perl best practices שהפכו לסטנדרט מאוד נפוץ בקהילה. ב javascript יש מספר מדריכים מתחרים וזה גם בסדר, פשוט צריך לבחור סגנון מספיק פופולרי למשל זה שמתואר כאן: https://contribute.jquery.org/style-guide/js/

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

4. תיעוד, בקרת תצורה ו readme

שאלה לא פחות חשובה מאיך לכתוב את הקוד היא איך להגיש אותו. האם אתם שולחים קובץ zip? שיתוף בדרופבוקס? מערכת הגשה של החברה?

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

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

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

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