Stop Failing Live Coding Interviews: שיעורים מ 100+ פגישות אמיתיות

פעם שכרתי מפתחים שלא פתרו את הבעיה.הם עברו חצי הדרך, יצאו מהזמן, והקוד שלהם לא רכש.אני ממליץ להם על הצעה בכל מקרה.הם בילו את כל השעה לחשוב בקול רם, לשאול שאלות ברורות, והתייחסו אליי כמו עמית לתיקון משהו ביחד. אז הבנתי שהראיונות בקוד חי נקראים רע, הם לא באמת על הקוד. הייתי בתעשייה זו במשך 12 שנים. ראיתי מאות תפקידים, עברתי מעל 50 סיבובים טכניים, וביצעתי יותר מ -100 ראיונות קודינג חי במקומות כמו מונזו וסופרבט. התבנית היא עקבית: הקודרים הטובים ביותר לא תמיד מועסקים. אלה הקוליים ביותר עושים. אתה יכול לכתוב קוד ללא פגמים בשתיקה ובכישלון. אתה יכול להילחם דרך פתרון בינוני תוך תקשורת יפה ומצליח. הראיון הוא לבדוק אם הצוות רוצה לבלות 40+ שעות בשבוע בעבודה איתך. למה אנחנו צריכים לעשות ראיונות קודי חי? אני זוכרת שביום אחד ביקרתי באמא שלי ושאלתי אותה: אני מצטער אמא, אין לי תשובה בשבילך.זה היה רק סיבוב 3 מתוך 7.אני עדיין יש עיצוב מערכת, קוד חי, התנהגות וצוות מתאים סיבוב ללכת. - היא שאלה, מוטרדת - שינויים בעבודה שלה כוללים לבלות 15 דקות עם מנהל רפואי, בעיקר לדון בשכר ושעת התחלה וזהו. "איך עשית את הראיון בחברת X? “מה?” "האם זה לא אותו תפקיד שהיה לך בעבר?" הנדסת תוכנה היא מקצוע בעל אמון נמוך – ועם סיבה טובה גם כן.הבדל ביכולות בין מפתחים יכול להיות מדהים. הנוף גם משתנה במהירות.התאמה הופכת ליותר מוערכת, בעוד יסודות חזקים ועקרונות מוצקים נעלמים. סטודנט חוסך 300 אלף דולר ב-TikTok על-ידי בניית מחדש של שירות מיקרו ב-Rust היית מועמד לתפקיד החלום שלך וקיבלת שיחת טלפון מ-HR. והם אתה בודק את לוח הזמנים שלך. Panic sets in - אתה מתחיל לגלוש אז בואו נגיע לכאן, בואו נעשה את העבודה הזאת. "הופתעתי מהחוויה שלך" "אני מצפה לקדם אותך לשלבים הבאים" Live coding interview — tomorrow 3PM "איך לעבור ראיון קודי חי" סוגים של ראיונות Live Coding לא כל ראיונות הקוד חי נוצרים שווים.לפני שאתה נכנס לפאניקה, זה עוזר לדעת באיזה פורמט אתה הולך. : בדומה לתחרות לתכנות, תקבל משימה הדורשת הבנה מוקדמת של אלגוריתם ידוע.זה אומר לך מעט מאוד על היכולת האמיתית של מהנדס תוכנה. LeetCode-style interview לחתוך אתר אינטרנט כמו LeetCode במשך כמה שבועות, עד שתוכל לפתור בנוחות בעיות קלות ובינוניות. זה צריך להכין אותך לשאלות קשות גם. מסרב להשתתף.אם החברה מחפשת ספציפית מתכנתים תחרותיים, סגנון ראיון זה הגיוני. : אתה תתחיל עם תרגיל לקחת הביתה. ברגע שתשלח את זה, צוות ההשכרה יעשה עזיבה קולית כדי לבחון את הפתרון שלך. אם הם מרוצים עם זה, אתה עובר לסיבוב 2 - פגישה חיה שבו יהיה לך 10-30 דקות כדי לעשות שינוי קטן או ליישם תכונה חדשה קטנה. Take-home exercise with live counterpart : בדרך כלל יש רק משימה אחת, שנועדה לקחת בערך שעה אחת. זה בודק את כישורי פתרון הבעיות שלך סוף סוף. תוכל לקבל הצהרת בעיה מוגדרת היטב וסביבה לכתוב קוד. תוכל לשתף פעולה עם המראיין(ים) כדי להתקרב לפתרון. לעתים קרובות יש גודל גם לזה - אם אתה לא יכול להשלים את המשימה כולה בזמן, זה לעתים קרובות עדיין מקובל. Pair-coding exercise : אתה תקבל הרבה שאלות הקשורות לתכנות, בדרך כלל גדל בקושי. השאלות הראשונות פשוט לבדוק אם יש לך רמה מסוימת של מיומנות בשפה. השנים הבאות ייקח קצת זמן לחשוב. אתה יכול להתחיל לקחת הערות כאן - באמצעות הערות קוד לפני שתבצע את העבודה היטב. 1-3 השאלות האחרונות נועדו להטעות אותך, להתבלבל איתך, ולגרום לך לרצות לוותר על עבודה בתוכנה. בהתאם לשפה, זה יכלול אקדחים טיפוסיים, חשודים נפוצים בעת חיתוך, ולפעמים מקרים אקזוטיים קצה המראיינים נפגשו. אתה לא יכול לפתור את אלה, וזה בסדר. ללכת את המראיינים דרך איך היית מתקרב אליהם. Live programming trivia : הבוס האחרון של ראיונות טכנולוגיה. אני בר מזל שיש לי רק השתתף בשני ראיונות הלבן בקריירה שלי. הם אינם פופולריים כעת כפי שהם היו פעם. אתה תמצא אותם לעתים קרובות בשימוש על ידי חברות טכנולוגיות עתיקות שלא חזרו על תהליך ההשכרה שלהם בשנה זו. אם אתה בר מזל, אתה יכול להשתמש pseudo-code כדי להדגים את הרעיונות שלך. אתה לעתים רחוקות צריך לכתוב את התוכנית כולה. Whiteboard לא כולם עושים ראיונות באותו אופן, אז אם אתה רוצה להיות בטוח, להתכונן פורמטים מרובים. 1. RTFM קרא את מדריך ידידותי, או במקרה זה, קרא את הדואר האלקטרוני שהצוות שלח לך. יש חברות שישלחו לך הוראות מפורטות לפני הראיון.הן יאמרו לך איזה סוג של בעיה לצפות, אילו טכנולוגיות תשתמש, כמה זמן יהיה הראיון, ואיזה כלים תצטרך.קרא את האימייל הזה ולאחר מכן קרא אותו שוב.ראיתי מועמדים מופיעים לא מוכנים לדברים שהוזמנו במפורש בהזמנה. הנה מה שאתם צריכים להסביר לפני תחילת הראיון: רוב המראיינים רוצים לראות אותך.זה מזיע לדבר בשתי אותיות במעגל למשך שעה.אם מצלמת המחשב הנייד שלך שבור, להשתמש בטלפון שלך.אם אין לך מצלמת אינטרנט בכלל, להודיע להם מראש - אבל להבין שזה יכול להיות פריצת דרך עבור כמה חברות. Get your webcam working. ייתכן שתצטרך לשתף את המסך או להשתמש בכלי שיתוף פעולה כמו , ודא שאתה יכול למעשה לעשות את זה לפני הראיון.ראיתי 5 דקות מבוזבזות כאשר מועמד ניסה להבין איך לחלוק את המסך שלהם. Test your screen sharing. CoderPad תגיות אם האינטרנט שלך הוא קצר, הראיון יהיה כואב לכולם. חיתוך אודיו, שיתוף מסך קפוא, קוד לא סינכרון - כל זה הורג את תחושת שיתוף הפעולה של הראיון. אם אתה יודע שהקשר שלך אינו אמין, פנה לצוות ההשכרה מראש. Check your internet connection. לפעמים יהיה לך מגע אישי חיצוני - קצין טכנולוגי ממוסד, למשל.בעבודה הנוכחית שלי ב-Speakeasy, עבדתי עם קצין שכבר הסביר כל צעד בפירוט ועשה כמיטב יכולתו כדי להכין אותי. Work with your recruiter. הדבר הגרוע ביותר שאתה יכול לעשות הוא להופיע לראיון ולבלות את 15 הדקות הראשונות לפתרון בעיות טכניות שניתן היה לפתור את היום הקודם. 2 הוכח שאתה חבר טוב זה די משעמם, נכון? אבל הנה העניין – אתה לא נתקל רק ביכולת הקוד שלך.אתה מוערך אם הצוות רוצה לבלות 40+ שעות בשבוע בעבודה איתך.ראיתי מהנדסים מדהימים מקבלים דחייה כי הם התנצלו במהלך הראיון.ראיתי גם מתכנתים ממוצעים שכרו כי הם היו נעימים לעבוד איתך וראו שהם יכולים ללמוד. מתוך הניסיון שלי לנהל יותר מ -100 ראיונות קידום חי, המועמדים המוצלחים ביותר כולם יש תכונה אחת במשותף.הם קוליים.הם לתקשר את תהליך המחשבה שלהם, הם שואלים שאלות ברורות, והם מתייחסים לראיון כמו פגישה שיתופית לפתרון בעיות במקום בחינה שהם נבדקים על. המראיין מנסה לענות על שאלה אחת: הכישורים הטכניים שלך חשובים, אבל גם איך אתה מתמודד עם התסכול, איך אתה מגיב להמלצות, ואם אתה נחמד כאשר אתה תקוע. "האם אני רוצה את האיש הזה בקבוצה שלי?" כללים טובים: אם המראיין נראה מעורב, שואל שאלות מעקב, והשיחה זורמת באופן טבעי, סביר להניח שאתה עושה טוב במבחן "עמיתים". דברו, אבל אל תתנתקו זה מרגיש לא טבעי בהתחלה - כמו שאתה מספר תיעוד טבע על המוח שלך - אבל זה הדבר היקר ביותר שאתה יכול לעשות בראיון קידום חי. "אני חושב שאנחנו צריכים לחזור דרך המסדרון הזה, ואנחנו יכולים להשתמש ב- a for loop, אבל מאחר שאנחנו משנים כל אלמנט, map תן לי להתחיל עם זה ואנחנו יכולים לאופטימיזציה אם יהיה צורך". הדבר משרת שני מטרות: ראשית, הוא מראה לראיין איך אתה חושב; הם לא רק מעריכים את הפתרון הסופי שלך; הם מעריכים את הגישה שלך לפתרון בעיות; שנית, זה נותן להם הזדמנויות לתקן אותך לפני שאתה מבלה 15 דקות הולך בדרך הלא נכונה. ראיתי מועמדים אשר, כאשר נשאלו שאלה ישירה, יפתחו דיון פילוסופי של 5 דקות על עקרונות הנדסת תוכנה כדי להימנע מלהודות שהם לא יודעים את התשובה. אם המראיין שואל ואתה לא יודע, אל תגיב עם רק תגידו : “מה המורכבות של הזמן הזה?” אתה רואה, המורכבות תלויה בגורמים רבים, ובעולם האמיתי, אנחנו צריכים לשקול את מיקומה של הקאש ו..." "אני לא בטוח לגבי המורכבות המדויקת, אני חושב שזה יכול להיות O(n log n) בגלל צעד הסדר, אבל אני רוצה לאמת את זה". כנות מעוטרת במחשבה מכה את ההפרעה בכל פעם. השאלות שלך חשובות כמו התשובות שלך האם אי פעם רציתם לומר בראיון: ? ובכן, אנו מעודדים באופן פעיל מועמדים להשתמש ב- Google, Stack Overflow, ותעודות במהלך ראיונות קוד חיות. חברות רבות עוקבות אחר גישה זו, אבל לא את כולם. הדבר הגרוע ביותר שהם יכולים לומר הוא לא, ואתה תדע איפה אתה עומד. "אני רק הולך לגלוג את זה" האם מותר לי להסתכל על הדברים?" אבל גם עם Google זמין, לשאול שאלות הוא עדיין קריטי. בעבודה אמיתית, אתה כל הזמן לשאול שאלות. אתה שואל את מנהל המוצר שלך להבהרה. אתה שואל את עמיתיך על האדריכלות הקיימת. אתה מסתכל על התיעוד. הראיון צריך לשקף את המציאות הזאת. כשאתה נתקל בבעיה, אל תתחיל מיד בקוד. "מה הגודל הצפוי של ההכנסה? אנחנו מדברים על 10 פריטים או 10 מיליון?" "האם אני צריך לאופטימיזציה עבור מורכבות זמן או מורכבות חלל?" "האם יש מקרים מסוימים שאני צריך להיות מודע במיוחד?" "מה יקרה אם הכניסה היא אפס או ריקה?" אני זוכר שראיתי מהנדס בכיר שהוציא את 8 הדקות הראשונות של ראיון בן 45 דקות רק כדי לשאול שאלות על הדרישות.התחלתי לדאוג שהם לא יהיו מספיק זמן לפתח פתרון.אבל אז, חמושים במגוון רחב של דרישות ותנאים שהם הקימו, הם התעלמו מהיישום.הם קיבלו את ההצעה. היזהר, לעומת זאת: השאלות צריכות להיות הסברים אמיתיים, לא בקשות עקיפות לרמזים. (השאלה הנפוצה ביותר) ו (הדג עבור הפתרון) "מהו גודל ההכנסה הצפויה?" "האם מפת hash יהיה שימושי כאן?" חוק אצבע טוב הוא, אם אתה עומד לענות על שאלה מתחילה עם במקום זאת, הסבירו שאתם זקוקים להבהרה נוספת ולרשום מה גורמים הפתרון שלכם יהיה תלוי.זה מראה שאתם מבינים את ההסכמים מבלי לגרום לראיין למשוך אותו ממך. “זה תלוי” אם אינך יודע - תשאל זה נשמע זהה לסעיף 4, אבל זה שונה מאוד. סעיף 4 הוא על לשאול שאלות כדי להבהיר את הדרישות. ראיתי מועמדים מבזבזים 20 דקות מנסה לזכור את הסינטקס המדויקת עבור משהו טריוויאלי, ביישן מדי לשאול. "רק תשאל אותי, אני אגיד לך, ואנחנו יכולים לעבור לחלק המעניין." אם אינך זוכר אם JavaScript אם אתה שומע את השם של האלגוריתם שלמדת באוניברסיטה, לתאר את מה שאתה זוכר ושואל אם המראיין יודע מה זה נקרא. sort() המפתח הוא להיות ספציפי לגבי מה שאתה לא יודע. אבל "אני לא יודע איך לעשות את זה" "אני דואג איך למצוא כפולים בצורה יעילה במסדרון הזה.אני חושב על שימוש בסדרה, אבל אני לא בטוח אם זו הגישה הנכונה כאן." זה עושה שני דברים: ראשית, זה מראה שאתה לא פשוט מוותר - אתה חשב על הבעיה ויש לך ההשערה. שנית, זה נותן לראיין מידע שימושי על איפה לעזור לך. או או "הגישה המוקדמת היא טובה" "חשוב על מה שאתה צריך להשיג עם קבוצה" "יש למעשה גישה פשוטה יותר אם אתה מסדר ראשון." אף אחד לא מצפה ממך לדעת הכל, אבל הם מצפים ממך להיות משאבים כשאתה לא. זה לא הזמן לנסות דברים חדשים במהלך ראיון קוד שביצעתי, המועמד ציין שהם יודעים C# טוב יותר - אחד השפות שאנו מציעים לראיון.אבל הם היו כותבים Scala במשך כמה השנים האחרונות, ומכיוון Scala פועלת על JVM בדיוק כמו Java, הם החליטו לעשות את הראיון ב- Java במקום.אולי הם צפו כי הידע של סביבת ההפעלה עשוי להיות שימושי יותר. המשימה שלנו בקוד חי היא פשוטה מאוד - זה רק על הבנה ותפיסות תכנות בסיסיות.ההתערבות לא שילמה.הם השקיעו זמן יקר במאבק עם סינטקס ג'אווה שהם לא היו שוטים בה, כאשר הם יכלו לחצות את הבעיה ב- C#. הראיון הוא לא הזמן להתנסות עם המסגרת החדשה ששמעת על Hacker News.זה לא הזמן לנסות תכנות פונקציונליות בפעם הראשונה.זה לא הזמן לאופטימיזציה עבור מה שאתה חושב שהראיין רוצה לראות. אם אתה יודע Python טוב יותר מאשר Java, להשתמש Python (אם יש לך את הבחירה). המראיין רוצה לראות אותך פותר את הבעיה, לא לצפות שאתה נאבק עם סינטקס שאתה לא יודע. reduce יש יוצא מן הכלל אחד: אם המראיין מבקש ממך במיוחד להשתמש במשהו שאתה לא מכיר, זה שונה, אבל אפילו אז, אתה יכול לומר: "לא השתמשתי ב-X הרבה לפני כן, אז אולי אני צריך לחפש את הסינטקס, אבל הנה הגישה שלי..." הראיונות שלך הם גם בני אדם הם כנראה גם עצבניים.אולי זו הפעם הראשונה שלהם לנהל ראיון.אולי היה להם בוקר קשה.אולי הם מודאגים אם הם שואלים את השאלות הנכונות. בתור מועמד, התייחסתי לראשי ראיונות כמו לשופטים - סמכויות רחוקות ובלתי טעימות המעריכות את הערך שלי.כראיין ראיון, הבנתי שאנחנו רק מפתחים רגילים שמנסים להבין אם נוכל לעבוד יחד טוב. זה אומר כמה דברים בפועל: אם משהו אינו ברור בהצהרת הבעיה, זה כנראה כי המראיין לא הסביר את זה היטב, לא כי אתה אמור לגלות את זה באופן קסום. אם המראיין נראה מוטרד או בודק את הטלפון שלו, אל תיקח את זה אישית. אם אתה מבחין תסריט בבעיה או חושב שיש בעיה עם מקרי הבדיקה, לציין את זה באדיבות: "אני חושב שיכול להיות כאן מקרה קיצוני שאנחנו לא מכסים - מה צריך לקרות כש...?" והנה אחד גדול: אתה יכול לבנות דו"ח. מעט שיחה קטנה בהתחלה עוזר. או במהלך הראיון, כאשר הם נותנים לך רמז, אתה יכול לומר להראות שאתה מעריך את התרומה שלהם. “איך הולך היום שלך?” "תודה על שהזמנת את הזמן לראיון איתי" "זו נקודה טובה, לא חשבתי על זה." הראיון הוא רחוב משני כיוונים, אתה מעריך אותם כמו שהם מעריכים אותך. תהליך חשיבה ברור שווה אלף שורות של קוד אני מעדיף לראות מועמד כותב 20 שורות של קוד ברור ומדויק מאשר 200 שורות של שטויות חכמות ומבלבלות. כאשר אתה מקודד בראיון, בהירות מנצחת חכמה. לא ו אבל ו כן, אפילו בראיון זה לוקח 3 שניות נוספות והופך את הקוד שלך אינסופי יותר קריא. Name your variables properly. x y userCount maxRetries אם אתה כותב דיון אחד-לינר שעושה חמישה דברים, לחלק אותו לשלבים מרובים עם משתנים ביניים. Break down complex logic. מהיר לפני מבצע מסנן מורכב יכול להציל את המראיין מהצורך להפוך את הכוונה שלך. Add comments if it helps. // Find all users who haven't logged in for 30+ days אומר בדרך זו, אם אתה על המסלול הלא נכון, המראיין יכול לתקן אותך מוקדם. Think out loud before you code. "אני הולך לחזור דרך המסדרון ולבנות מפה hash של ערכים לאנדקסים" ראיתי פעם מועמד אשר פתר את הבעיה עם פתרון חוזר אלגנטי להפליא שלא יכולתי לעקוב אחר.כאשר ביקשתי מהם להסביר את זה, הם לא יכלו להסביר מדוע זה עבד.השווה את זה למועמד אחר שכתב פתרון חוזר פשוט עם שמות משתנים ברורים והלך לי דרך כל שלב.הועמד השני קיבל את ההצעה. המטרה שלך היא לא להרשים את המראיין עם המבריק שלך.המטרה שלך היא להוכיח שאתה יכול לכתוב קוד ששותפי הקבוצה שלך יבינו בתוך שישה חודשים. 9 - הכירו את הגבולות שלכם ניהול זמן בראיונות הוא אכזרי.אתה מוערך תוך כדי ניסיון לפתור בעיות במקביל תחת שעון טיקינג. הנה מה שאני ממליץ: זה מגדיר את לוח הזמנים הפנימי שלך ועוזר לך לקצב את עצמך. At the start, clarify the time limit. יש לנו 45 דקות, נכון? תגידו : אל תשרוף את חצי הזמן שלך לראיון להיות עקשני. If you're stuck for more than 3-5 minutes, speak up. "אני חושב על זה במשך כמה דקות ואני לא עושה התקדמות. אם לראיון יש בעיות מרובות ואתה תקוע באחד הראשון, לשאול: "האם אני צריך להמשיך לעבוד על זה, או שאתה רוצה שאני לעבור לבעיה הבאה?"לפעמים מראיין רוצה לראות רוחב, לא רק עומק על בעיה אחת. Know when to move on. אל תבזבזו 40 דקות בקוד ולאחר מכן אין לך זמן לבדוק את הפתרון שלך. אם תסיימו עם 5-10 דקות נשארות, ללכת דרך הקוד שלך עם כמה כניסות דוגמה. ! Save time for testing. ודא שאתה מנהל אותם אם יש לך עבודה פתרון עם 5 דקות נשארות, לא לנסות לשחזר אותו הזכרו מה הייתם אופטימיזרים אם הייתם לוקחים יותר זמן, אך קודם כל תספקו פתרון עובד. Be realistic about optimisation. O(n²) O(n log n) I failed an interview once because I spent 35 minutes perfecting the first of three problems, then had to rush through the other two. I was so focused on making the first solution perfect that I lost sight of the bigger picture. Don't be me. להראות עומק, אבל לא להכריח אותו אם עבדתם עם מערכות מפוזרות, אסטרטגיות קישוריות או דפוסים ארכיטקטוניים מורכבים, והבעיה מובילה באופן טבעי לשם, הזכרו את זה. ראיתי מועמדים אשר, כאשר ביקשו ליישם פונקציה הפוכה פשוטה של חרוזים, השיגו תזה של 10 דקות על נורמליזציה של Unicode, קבוצות גרף ועיבוד טקסט ימין לשמאל.כן, אלה הן דאגות אמיתיות במערכות ייצור. המפתח הוא לקרוא את החדר.אם המראיין נראה מעוניין ושואל שאלות מעקב על החוויה שלך עם מערכות מפוזרות, להרחיב על זה. הנה דפוס טוב: לפתור את הבעיה תחילה, ולאחר מכן להציע עומק. "הפתרון הזה עובד עבור הדרישות שדיברנו עליהן.בפיתוח, הייתי גם שוקל [דאגה מתקדמת ספציפית], אבל אני מניח שזה מחוץ לתחום של תרגיל זה. גישה זו מראה שאתה מבין את ההקשר הרחב מבלי לגרד את הראיון. פעם עשיתי את הטעות של להשקיע 15 דקות להסביר איך הייתי מיישם הגבלת שיעור עבור נקודת קצה API כאשר השאלה הייתה רק לומד מהכישלון שלי: לענות על השאלה שנשאלת, לא על השאלה שהיית רוצה שהם שאלו. "כתוב פונקציה המאשרת כתובות דואר אלקטרוני." +1 תמיד לבקש משוב רוב החברות לא ייתן לך משוב מפורט (סיבות אחריות, בעיקר), אבל זה שווה לשאול בכל מקרה. אם תקבלו את ההצעה: "תודה רבה!האם אני יכול לשאול מה הלך טוב בראיון?אני תמיד מחפש להשתפר." אם אתה נדחה: "אני מבין שיש לך מדיניות סביב משוב, אבל אם אתה יכול לשתף משהו על איך אני יכול לשפר לראיונות עתידיים, אני באמת מעריך את זה." חלק מהמראיינים יתעלמו מכך.חלקם יביאו לך תפיסות כלליות.אבל מדי פעם, תקבלו משוב אמיתי וניתן לפעול שיעזור לכם בראיון הבא. "אתה מסביר דברים יותר מדי, לא לקחת בחשבון את הקהל שלך" "הפתרון שלך היה נכון, אבל אני נאבקתי לעקוב אחר תהליך המחשבה שלך" "זה ברור שיש לך הרבה רוחב, אבל אנחנו מעריכים קצת יותר עומק על כמה נושאים" ראיונות הם מכרה זהב למסע השיפור העצמי שלך. הנה משהו שרוב המועמדים לא יודעים: חלק מהמראיינים נוחים לשוחח על הראיון לאחר מכן ישירות – באמצעות דואר אלקטרוני או LinkedIn. רוב האנשים יגידו כן, וזה פותח ערוץ לתגובות כנות יותר ממה ש-HR יכול לספק. "האם זה יהיה בסדר אם אני פונה אליך ישירות על לינקדאין אם יש לי שאלות מעקב?" לפחות, ביקשת משוב מראה שאתה מישהו שרוצה לגדול. גם אם אתה לא מקבל מידע שימושי, אתה משאיר רושם חיובי. במהלך הזמן שלי ב- Docler, היו לנו מועמד קבוע, אשר היה חוזר בזהירות, כל שישה חודשים. הוא תמיד עזב עם משוב ולא עשה את אותה טעות פעמיים. בפעם האחרונה, הוא עשה ראיון מושלם. הוא עדיין עובד שם עד היום. התוצאה הגרועה ביותר היא שאתה לא שומע כלום התוצאה הטובה ביותר היא שאתה לומד משהו שמביא לך את העבודה הבאה. Good luck! אני מאחל לך מזל טוב בראיון הבא שלך! אם הטיפים שלי עזרו לך, או אם יש לך טריקים שימושיים יותר לשתף, בואו לשוחח!