איך הגעתי ל-ThoughtWorks או ראיון לדוגמה

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

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

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

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

ThoughtWorks

מה הקשר של ThoughtWorks לזה? כאן מצאתי דוגמה לראיון דוגמה לעצמי. מי הם ThoughtWorks? בקיצור, מדובר בחברת ייעוץ High-End עם משרדים בכל העולם, מסין, סינגפור ועד יבשות אמריקה, אשר מייעצת בתחום הפיתוח מזה כ-25 שנה, בעלת חטיבת Science משלה, בראשות מרטין. פאולר. אם אתה מחפש רשימה של 10 ספרי חובה למהנדס תוכנה, אז אולי 2-3 מהם ייכתבו על ידי החבר'ה מ-ThoughtWorks, כמו Refactoring מאת Martin Fowler ו- Building Microservices: Designing Fine-Grained Systems מאת סם ניומן או בניין ארכיטקטורות אבולוציוניות
מאת פטריק קואה, רבקה פרסונס, ניל פורד.

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

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

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

שלב 0. HR

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

שלב 1. כמה טוב אתה ב-OOP, TDD?

1.5 שעות לפני תחילת הראיון, נשלחה אליי משימה להכין סימולטור של Mars Rover.

משימת רובר מאדיםחוליית רוברים רובוטים אמורה להיות נחיתה על ידי נאס"א על ​​רמה על מאדים. הרמה הזו, שהיא מלבנית בצורה מוזרה, חייבת לנווט על ידי הרוברים כדי שהמצלמות המשולבות שלהם יוכלו לקבל תצוגה מלאה של השטח שמסביב כדי לשלוח בחזרה לכדור הארץ. מיקומו ומיקומו של רובר מיוצגים על ידי שילוב של קואורדינטות x ו-y ואות המייצגת אחת מארבע נקודות המצפן הקרדינליות. הרמה מחולקת לרשת כדי לפשט את הניווט. מיקום לדוגמה יכול להיות 0, 0, N, כלומר הרובר נמצא בפינה השמאלית התחתונה ופונה לצפון. על מנת לשלוט על רובר, נאס"א שולחת מחרוזת אותיות פשוטה. האותיות האפשריות הן 'L', 'R' ו-'M'. 'L' ו-'R' גורמים לרובר להסתובב 90 מעלות שמאלה או ימינה בהתאמה, מבלי לזוז מהמקום הנוכחי שלו. 'M' פירושו לנוע קדימה נקודת רשת אחת, ולשמור על אותה כותרת.
נניח שהריבוע ישירות מצפון (x, y) הוא (x, y+1).
קֶלֶט:
קו הקלט הראשון הוא הקואורדינטות הימנית העליונה של הרמה, ההנחה היא שהקואורדינטות השמאלית התחתונה הן 0,0.
שאר הקלט הוא מידע הנוגע לרוברים שנפרסו. לכל רובר יש שני קווי קלט. השורה הראשונה נותנת את מיקומו של הרובר, והשורה השנייה היא סדרה של הוראות המספרות לרובר כיצד לחקור את הרמה. המיקום מורכב משני מספרים שלמים ומאות מופרדים ברווחים, התואמים לקואורדינטות x ו-y ולכיוון הרובר.
כל רובר יסתיים ברצף, מה שאומר שהרובר השני לא יתחיל לנוע עד שהראשון יסיים לנוע.
תפוקה:
הפלט עבור כל רובר צריך להיות הקואורדינטות והכיוון הסופי שלו.
הערות:
כל שעליך לעשות הוא ליישם את הדרישות לעיל ולהוכיח שואב אבק עובד על ידי כתיבת בדיקות יחידה עבורו.
יצירת כל צורה של ממשק משתמש היא מחוץ לתחום.
פתרון הבעיה באמצעות גישת TDD (Test Driven Development) יועדף.
בזמן הקצר העומד לרשותנו, אנו דואגים יותר לאיכות מאשר לשלמות.
*אני לא יכול לפרסם את המטלה שנשלחה אלי, זו מטלה ישנה שניתנה לפני מספר שנים. אבל תאמין לי, ביסודו הכל נשאר אותו דבר.

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

• TDD;
• יכולת להשתמש ב- OOP ולכתוב קוד בר תחזוקה;
• צמד יכולות תכנות

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

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

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

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

שלב 2: ספר לנו

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

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

שלב 3. קוד איכות ייצור

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

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

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

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

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

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

אם תחפשו קצת בגוגל על ​​תרבות Thoughtworks, תמצאו מאמר מאת מרטין פאולר [https://martinfowler.com/bliki/ThreePillars.html] שמתאר את 3 עמודי התווך: עסקים בר קיימא, מצוינות בתוכנה וצדק חברתי.

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

יתר על כן, החלטתי להתמקד באחרון.

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

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

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

בסופו של דבר, 80% מהמצגת שלי הייתה מלאה בחתולים.

מיד לאחר המצגת, HR כתב לי שהוא עדיין לא יודע את תוצאות הראיון, אבל כל המשרד כבר התרשם מהחתולים.

בסופו של דבר, חיכיתי למשוב - סיפקתי את כולם כאדם.

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

סך הכל

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

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

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

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

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

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

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

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

אם אתה מעוניין להצטרף ל-ThoughtWorks, תוכל לצפות במשרות הפתוחות שלנו כאן
אני מציע גם לשים לב למשרות פנויות מעניינות:
מהנדס תוכנה מוביל: גרמניה, לונדון, מדריד, סינגפור
מהנדס תוכנה בכיר: סידני, גרמניה, מנצ'סטר, בנגקוק
מהנדס תוכנה: סידני, ברצלונה, מילאנו
מהנדס נתונים בכיר: מילאנו
אנליסט איכות: גרמניה סין
תַשׁתִית: גרמניה, לונדון, צ'ילה
(אני רוצה להזהיר אותך בכנות שהקישור הוא קישור הפניה, אם תלך ל-TW, אקבל בונוס נחמד). בחר משרד שאתה אוהב, אתה לא צריך להגביל את עצמך לאירופה, אחרי הכל, כל שנתיים TW תשמח להעביר אותך למדינה אחרת, כי... זה חלק ממדיניות ThoughtWorks, כך שהתרבות מופצת והומוגנית.

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

מקור: www.habr.com