איך להתכונן לראיון טכני ולהפוך את זה לכיף (כמעט)

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

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

ראיון טכני הוא שיחה, לא גזר דין

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

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

להפוך כל ראיון לחומר אימון

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

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

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

”ספר/י לי על עצמך” הוא פיץ’, לא ביוגרפיה

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

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

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

STAR: מה הייתה הבעיה ומה קרה בזכותכם

כששואלים על פרויקט, רוב המועמדים צוללים ל-stack. השתמשתי ב-React. כתבתי API. שמתי lazy loading. שחר עוצר רגע קודם עם STAR: Situation, Task, Action, Result. קודם מסבירים איזו בעיה הייתה. אחר כך מה נדרש לעשות, מה אתם עשיתם בפועל, ומה הייתה התוצאה.

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

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

להתכונן לקוד בצורה ממוקדת

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

ומה עושים עם LeetCode? לא פותרים אלפיים שאלות אקראיות. לומדים חכם יותר. עובדים בקלאסטרים: תקופה של Arrays, אחר כך HashMaps, ואז Trees או Graphs. כך מזהים patterns במקום לזכור תשובה. שחר מזכיר גם את Blind 75 כרשימה מרוכזת של שאלות ואת החשיבות של חזרה על שאלה שלא הצלחתם לפתור: אחרי כעשרים דקות בודקים פתרון, מבינים אותו, וחוזרים אליה ביום הבא.

REACT לפני שמקודדים

המסגרת ששחר מציע לתרגיל קוד נקראת REACT: Repeat, Evaluate, Approach, Code, Test. קודם חוזרים על השאלה במילים שלכם. אחר כך בודקים איזה סוג בעיה זו ושואלים על input, output ומקרי קצה. רק אז מציגים approach. אין חובה שהרעיון הראשון יהיה מושלם: גם brute force הוא התחלה לגיטימית, כל עוד אתם מסבירים את המחיר שלו ואת הדרך לשפר.

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

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