כיצד להתקדם תוך כדי לימודים לראיונות קידוד

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

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

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

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

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

1. לפתח בסיס חזק

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

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

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

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

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

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

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

2. קבל יותר חווית קידוד

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

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

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

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

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

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

3. גש אסטרטגית לכל שאלה בראיון

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

התוכנית הנפוצה ביותר שאני רואה לפתור בעיות ראיונות נראית כמו הבאה:

  1. תסתכל על הבעיה
  2. תחשוב על הבעיה
  3. לבוא עם פיתרון
  4. כתוב את הפיתרון
  5. הַצלָחָה

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

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

זה מסוכן במקרה הטוב.

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

[0: 00–05: 05] הסתדר וודא שאתה מבין היטב את הבעיה שהם שואלים. עבוד על כל קלט לדוגמא שסופק.

[0: 05–010: 10] בדוק פיתרון כוח אכזרי לבעיה. אין קידוד בשלב זה, פשוט דבר דרכו וצייר תמונות אם אתה מועיל. אם אתה תקוע עם פיתרון כוח אכזרי, נסה לעבוד על הבעיה ביד ולתרגם את התהליך שלך לפתרון לאלגוריתם.

[ 0: 10–0: 15] בצע אופטימיזציה לפתרון שלך. קח את חמש הדקות האלה כדי להבין את הפתרון המוחלט הטוב ביותר שאתה יכול בפרק זמן זה. כאשר משווים פתרונות, שקול את מורכבות הזמן.

[0: 15–0: 35] קידם את הפתרון שלך. גם אם זה לא אופטימלי, עדיף שיהיה פיתרון מלא ולא אופטימלי מאשר פתרון לא שלם ואופטימלי.

[0: 35–0: 50] בדוק את הקוד שלך ותקן את הבעיות. זה חשוב להפליא. לא משנה אם הקוד שלך אינו מושלם בפעם הראשונה, אך מוטב שתצליח לזהות את השגיאות.

[0: 50–1: 00] שאלות למראיין שלך.

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

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

4. שקול פתרונות אפשריים שונים

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

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

לדוגמה, שקול בעיה זו:

  • לפיתרון אחד יש O(n)מורכבות זמן ומורכבות O(1)חלל
  • לפיתרון אחר יש O(log n)מורכבות זמן ומורכבות O(log n)חלל

איזה מהפתרונות האלה עדיף?

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

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

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

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

5. התחל עם תמיסת כוח הברוט

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

אבל תן לי לשאול אותך את זה: מה עדיף, פתרון כוח אכזרי או אין פתרון?

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

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

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

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

החל בפתרון כוח אכזרי נותן לך בהירות ונקודת התחלה כדי להקל על כל השאר.

6. תכנן את הפתרון המלא לפני שתקודד

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

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

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

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

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

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

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

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

7. זכור את התמונה הגדולה

אחת הבעיות הגדולות ביותר שאני רואה אצל מפתחים מנוסים יותר היא שהם נתקעים לגמרי בעשבים שוטים עם בעיה. הם מתחילים לאובססיבי אם לולאה צריכה להיות <; N or &lt; = N ולא מצליח להבין איזו גישה נכונה.

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

דוגמה מושלמת לכך היא בעיה בה אתה מנסה להשתמש במבנה הנתונים הלא נכון. בואו נגיד שאתה שומר את הערכים שאינדקסים מהם 1-Nואתה מחליט שאתה רוצה להשתמש ב- HashMap. אתה יכול להוסיף 1 -> value 1, 2 ->value2 וכן הלאה.

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

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

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

8. השתמש בהפשטה לטובתך

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

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

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

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

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

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

יש לכך מספר יתרונות:

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

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

9. בדוק את הקוד שלך

כשאנחנו עושים משהו חדש, אנחנו נוטים לשכוח הרבה מהדברים שאנחנו כבר יודעים. אנו מניחים שהדברים שאנו כבר יודעים אינם חלים.

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

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

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

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

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

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

10. קבל משוב טוב

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

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

"אז," אתה יכול לומר, "למי אכפת? אני יכול פשוט לשפוט את ההופעה שלי ".

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

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

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

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

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