איך לאלף ג'וניור?

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

אני מנסה לאלף את ג'וניור

שלום! שמי פאבל, אני עושה עבודה חזיתית בצוות Wrike. אנו יוצרים מערכת לניהול פרויקטים ושיתוף פעולה. אני עובד באינטרנט משנת 2010, עבדתי 3 שנים בחו"ל, השתתפתי במספר סטארטאפים ולימדתי קורס בנושא טכנולוגיות אינטרנט באוניברסיטה. בחברה אני עוסק בפיתוח קורסים טכניים ותכנית חונכות Wrike לג'וניורים וכן בגיוס ישיר שלהם.

למה בכלל חשבנו להעסיק זוטרים?

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

מי זה זוטר?

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

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

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

1. ג'וניור הוא מישהו שרוצה להתפתח ומוכן לעבוד קשה בשביל זה;
2. הוא לא תמיד יודע לאיזה כיוון הוא רוצה להתפתח;
3. זקוק לייעוץ ומבקש עזרה מבחוץ – מהמנהיג שלו, מהמנטור שלו או בקהילה.

היו לנו גם כמה השערות:

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

וכמובן, הייתה לנו מטרה: 4 צעירים ב-3 שבועות.

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

אנחנו מפרסמים משרה פנויה

בשביל החברה: יהיו מאות תגובות! תחשוב על פילטר.

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

ביום הראשון קיבלנו כ-70 קורות חיים ממועמדים "בעלי ידע ב-JavaScript". ואז שוב. ועוד. פיזית לא יכולנו להזמין את כולם למשרד לראיון ובחרנו מהם את החבר'ה עם הפרויקטים הכי מגניבים לחיות מחמד, Github חי, או לפחות ניסיון.

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

הוא הכיל שאלות סטנדרטיות על JS, פריסה, אינטרנט, מדעי המחשב - כל מי שמדמיין מה הוא שואל בראיון חזיתי מכיר אותם. מה ההבדל בין let/var/const? כיצד אוכל להחיל סגנונות רק על מסכים קטנים מ-600 פיקסלים ברוחב? לא רצינו לשאול את השאלות הללו בראיון טכני - התרגול הוכיח שניתן לענות עליהן לאחר 2-3 ראיונות מבלי להבין כלל את ההתפתחות. אבל הם הצליחו להראות לנו בהתחלה אם המועמד, באופן עקרוני, מבין את ההקשר.

בכל קטגוריה הכנו 3-5 שאלות ויום אחרי יום שינינו את הסט שלהן בטופס התגובה עד שחיסלנו את הסבירה והקשה ביותר. זה איפשר לנו להפחית את הזרימה - תוך 3 שבועות שקיבלנו 122 מועמדים, שאיתו נוכל להמשיך לעבוד. אלה היו תלמידי IT; חבר'ה שרצו לעבור לחזית מהחלק האחורי; עובדים או מהנדסים, בני 25-35, שרצו לשנות את עיסוקם באופן קיצוני והשקיעו מאמצים שונים בחינוך עצמי, קורסים והתמחויות.

להכיר אחד את השני טוב יותר

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

לג'וניור: אל תעתיק-הדבק בדיקות - זה מורגש. ושמור על ה-Github שלך בסדר!

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

מה היה חשוב לנו במבחן:

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

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

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

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

• העתק-הדבק, או פיתוח המבוסס על אותה הדרכה ללא ארכיטקטורה משלך;
• שתי המשימות נמצאות באותו מאגר בתיקיות שונות, כמובן שאין היסטוריית commit;
• קוד מלוכלך, הפרת DRY, חוסר עיצוב;
• תערובת של דגם, תצוגה ובקר למחלקה אחת באורך של מאות שורות קוד;
• חוסר הבנה של בדיקת יחידות;
• פתרון "חזיתי" הוא קוד קשיח של מטריצת 3x3 של שילובים מנצחים, שיהיה די קשה להרחיב ל-10x10, למשל.

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

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

ראיון טכני

בשביל החברה: לא הביניים/קשישים הגיעו אליך! אנחנו צריכים גישה יותר אינדיבידואלית.

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

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

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

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

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

ערכנו 21 ראיונות באמצעות עיצוב זה. הקהל היה מגוון לחלוטין - בואו נסתכל על קומיקס:

1. "רָקֵטָה". הוא אף פעם לא נרגע, מתערב בכל דבר, ובמהלך ראיון הוא יציף אותך בזרם של מחשבות שאפילו לא קשור ישירות לשאלה שנשאלה. אם זה היה באוניברסיטה, זה היה ניסיון מוכר להפגין, ובכן, את כל הידע שלך, כשכל מה שאתה זוכר על הכרטיס שנתקלת בו הוא שאתמול בלילה החלטת לא ללמוד אותו - אתה עדיין לא יכול להשיג זה החוצה.
2. "גרוט". די קשה ליצור איתו קשר כי הוא גרוט. במהלך ראיון, אתה צריך להשקיע זמן רב בניסיון לקבל תשובות מילה במילה. זה טוב אם זה רק חוסר תחושה - אחרת זה יהיה לך מאוד קשה בעבודה היומיומית שלך.
3. "דראקס". עבדתי בעבר בהובלת מטענים, ומבחינת תכנות למדתי JS רק ב-Stackoverflow, אז אני לא תמיד מבין על מה מדברים בראיון. יחד עם זאת, הוא אדם טוב, בעל הכוונות הטובות ביותר ורוצה להפוך למפתח פרונט-אנד גדול.
4. אנחנו כנראה "לורד הכוכבים". בסך הכל, מועמד טוב שאפשר לנהל איתו משא ומתן ולבנות דיאלוג.

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

התאמה תרבותית

בשביל החברה: אתה עובד איתו! האם המועמד מוכן לעבוד קשה ביותר למען התפתחותו? האם הוא באמת ישתלב בקבוצה?

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

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

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

החיים אחרי ההצעה

בשביל החברה: שמור על הזוטרים שלך או שאחרים יעשו זאת!

לג'וניור: אאאאאאאאאאא!!!

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

כשחשבנו על זה, הגענו לרשימה של 26 כישורים שלדעתנו, ג'וניור צריך להיות עם עד סוף תקופת ההצטרפות של שלושה חודשים. זה כלל מיומנויות קשות (בהתאם למחסנית שלנו), ידע בתהליכים שלנו, Scrum, תשתית וארכיטקטורת פרויקטים. שילבנו אותם למפת דרכים, שהתפזרה על פני 3 חודשים.

לדוגמה, הנה מפת הדרכים של הצעיר שלי

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

חלק מהעומס על המנטורים מוריד על ידי קורסים על הערימה שלנו - Dart, Angular. קורסים מתקיימים באופן קבוע לקבוצות קטנות של 4-6 אנשים, בהם לומדים התלמידים ללא הפרעה מהעבודה.

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

מסקנה

בשביל החברה: האם כדאי להשקיע בג'וניורים? כן!

לג'וניור: חפשו חברות שבוחרות בקפידה מועמדים ויודעות כיצד לפתח אותם

במשך 3 חודשים, סקרנו 122 שאלונים, 54 משימות מבחן וביצענו 21 ראיונות טכניים. זה הביא לנו 3 ג'וניורים נהדרים שסיימו כעת מחצית ממפות הדרכים שלהם למטוס ולהאצה. הם כבר משלימים משימות מוצר אמיתיות בפרויקט שלנו, שבו יש יותר מ-2 שורות קוד ויותר מ-000 מאגרים רק בחזית הקצה.

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

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

מקור: www.habr.com