מה כדאי לדעת לפני שתגיעו לראיון עבודה בהייטק?

David Meir-Levy | 2/11/2021, 6:39:25 PM

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

מה כדאי לדעת לפני שתגיעו לראיון עבודה בהייטק?

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

 

אל תגיעו למקום שלא מעניין אתכם

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

 

מה מצפים מכם בראיון?

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

 

מה לגבי תרגיל בית? איכות? מהירות? תוצאות?

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

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

אישית מה אני אוהב בקוד של תרגיל בית:

  1. קוד שממודל היטב. חלוקה טובה לקבצים ותיקיות לפי סדר לוגי.
  2. קונבנציה אחידה לכל הפרויקט.
  3. קוד אלגנטי.
  4. הזחות (indentation).
    אני בגיל 12 כתבתי אתר ב-ASP3 עם notepad. הייתי צריך לעשות את ההזחות לבד, ועשיתי. לך יש כלים אוטומטיים שעושים את זה במילא - אל תתעצלו על המראיין, אל תשכחו שאתם צריכים לפלרטט איתו, לא לגרום לו לרטט בכל הגוף.

 

עיצוב בתרגיל בית

מדובר על עניין נוסף, כי לא כל חברה שמה דגש בימינו על עיצוב, או על css בכלל (לדעתי האישית חבל, אבל גם אין זמן ויש המון זיבולי שכל אחרים שצריך לבחון, ששוכחים את הקטע הזה של פרונטאנד בפיתוח פרונטאנד), אבל בגדול - אם ביררתם והבנתם שהחברה רוצה לבחון את העניין הזה, אז תשקיעו מאמץ על הדגשים הכי קטנים.
בתכלס, רוב החברות היום בונות ממשקי ניהול שנראים פלוס מינוס אותו דבר. כנסו לאתר שלהם, תסתכלו על הפלטפורמה, תראו את הסטייל שלהם, ואם הם משתמשים באיזשהו UI framework (כנראה שכן).
הייתי ממליץ להשתמש בפריימוורק הזה כבר בתרגיל. אני מגדיל לעשות ועושה חיקוי אחד לאחד של חלקים מהעיצוב שלהם, מבחינת ה-layout, טבלאות, כותרות, צבעים.
זה לא קשה להעתיק עיצוב קיים, רק אל תורידו מהם את הקובץ css של האתר אלא תכתבו בעצמכם. זה לא צריך לקחת לכם יותר מ-20~ שורות של css ליצור איזושהי מסגרת של תרגיל שיהיה מאוד דומה לעיצוב של המוצר שלהם, וזה יזכה אתכם בכמה נקודות של קריצה למעסיק הבא שלכם, שאתם מבינים את השפה העיצובית.
אני גם הייתי מוסיף ״אפקטים״ לעיצוב שאין להם, אולי קצת תנועה, טעינה, מעבר של הצבעים, מסגרות דקות ועדינות בפינות הנכונות, ודקויות של הדברים הקטנים (חפשו בגוגל micro-interactions, זה אחלה נושא). אם כבר בוחנים אתכם על העיצוב - תפלרטטו איתם קצת.

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

Related tags: 
Powered by © Greenpress 2019.