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

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

1. האם יש לך נסיון עם MVC Framework כלשהו, למשל Backbone או Angular ?

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

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

2. האם את יודעת כיצד לממש מחלקה ב JavaScript? לבנות עץ ירושה? להסביר מהו Prototype ומתי להשתמש בו?

בשנת 2008 הוציא Douglas Crockford, אז מהנדס בחברת Yahoo, את הספר JavaScript: The Good Parts. ספר זה שינה את האופן בו מתכנתים רבים כותבים JavaScript. יחד עם השיפור בדפדפנים וחדירת מכשירים ניידים שקרו כולם באותם השנים, דור חדש של מתכנתי צד-לקוח החל לשנות את הכתיבה מקידוד מבוסס פונקציות לקידוד מבוסס Object Oriented.

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

3. בכלי הפיתוח בדפדפן, האם אתה יודע לקרוא את התרשים המופיע בטאב Timeline ?

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

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

4. האם את מכירה ספריות לניהול תלויות ב JavaScript למשל Require.JS ?

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

אם לא נתקלתם מעולם בספריות מסוג זה, מומלץ להתחיל לקרוא עליהן במאמר כאן:
http://addyosmani.com/writing-modular-js/

ולאחר מכן בקישור הזה:
http://www.2ality.com/2014/09/es6-modules-final.html

5. צעדים להמשך

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

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

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

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