אחד הנושאים הכי מרתקים בעיני הוא ראיונות טכניים למפתחים. בכל חברות הסטארטאפ שאני מכירה זה אחד הנושאים הדינמיים ביותר. הראיונות הטכניים עוברים אינסוף שינויים על מנת להעריך באופן טוב את ההתאמה האישית/ מקצועית לחברה בפרק זמן מוגבל של כמה שעות. בפוסט זה בחרתי להביא גישות שונות מחברות בעלות צוותי engineering מצויינים ואשר בילו זמן רב ב"אופטימיזציה" של התהליך.
כמה גישות מעניינות שמובאות בפוסט : סימולציה של פיתוח באופן הכי קרוב שניתן לעבודה עצמה, התמקדות רק ביכולות למידה של נושאים חדשים, שאלות להבנה מהירה של המניעים של המועמד ואיזה אזורים הוא הכי אוהב, התעלמות מרושם ראשוני ו – ארוחת צהריים עם המועמד.
התהליך עצמו מבחינת סדר ומספר ראיונות דומה בין החברות השונות –
- לרוב יהיה ראיון טלפוני קצר שיכול לכלול גם שאלות טכניות בסיסיות (דעות בעד ונגד שאלות טכניות בראיון הטלפוני מובאות בפוסט)
- אחרי הראיון הטלפוני יקבעו מספר ראיונות טכניים עם לפחות 2-3 חברי צוות
- השלב המסכם יהיה לרוב ראיון HR. מכיוון שראיון ה HR לא נעשה לרוב ע"י הצוות הטכני בחרתי לא להרחיב עליו בפוסט זה
רן תבורי (co-founder at Yodas, אקס גוגל ואאוטבריין).
איך לא לשפוט מועמדים מהר, למה כדאי לקחת מועמד לארוחת צהריים והשאלה שתעזור לכם להבין איך מועמד חושב
רן הוא אחד האנשים הבולטים בקהילת המפתחים בארץ ומי שנמצא מאחורי רברסים (הפודקאסט והכנס). אחת הסיבות העיקריות שרציתי להביא את הזוית של רן לכתבה זו היא שבשנה האחרונה הוא ייסד סטארטאפ בשם Yodas שמתמקד בתהליכי השמה של מתכנתים ועתיד לשפר אותו ולהקל על ההתאמה למועמדים. רן היה גם מפתח וראש צוות בגוגל ובאאוטבריין ומשתף בפוסט זה גם את תהליכי הגיוס הטכני בגוגל.
מי מראיין? התהליך בגוגל כולל 4-5 ראיונות טכניים נפרדים, כל אחד ע"י חבר צוות אחר ובנושא שונה (למשל : אלגוריתמיקה, קידוד, התמודדות עם למידה של נושא חדש). מה שמעניין בתהליך הוא שעד סוף סבב הראיונות, המראיינים מתבקשים לא להחליף רשמים בינהם. הסיבה שעומדת מאחורי החלטה זו היא לאפשר לכל מראיין לבוא בראש נקי לראיון. אחרי שמסתיים תהליך הראיונות כל המראיינים מזינים את הציון של המועמד למערכת. רק אחרי שלב זה "מותר" לדבר על המועמד. יש צורך בציונים גבוהים מאד ע"י כל המראיינים כדי שמועמד יתקבל. כמו כן, חובה שיהיה ״צ'מפיון״ אחד לפחות – כלומר מישהו שמתעקש על קבלת המועמד. מנגד, אם יש אפילו אחד מחברי הצוות שמתנגד לקבלת המועמד – הוא נפסל, אפילו אם יש לו צ'מפיון. אחד הדברים שהכי אהבתי בתהליך הוא שאחד הראיונות הוא פשוט ארוחת צהריים משותפת של אחד מחברי הצוות עם המרואיין. לא ראיון על ארוחת צהריים, אלא פשוט ארוחת צהריים. זו דרך מצויינת להכיר טוב יותר את המועמד ולתת לו הזדמנות להכיר את הצוות ואת החברה.
ראיון טלפוני – גם בגוגל וגם בחברות אחרות רן התחיל את התהליך בראיון טלפוני קצר עם מספר שאלות אישיות וכמה שאלות טכניות בסיסיות. דוגמאות לשאלות טכניות לראיון טלפוני:
הסבר על סיבוכיות
מתי כדאי להשתמש ב bubble sort
ראיונות טכניים – הראיון הטכני כולל בעיקר שיחה סביב פרוייקט משמעותי שהמועמד פיתח בשנים האחרונות. רן מנסה להבין איך המועמד חושב ובאיזה תחומים הוא חזק יותר ע"י שיחה על כל מרכיבי הפרוייקט, הבנה של בחירות מסויימות, התעכבות על הבעיות ומה גרם להן.
שאלה מעניינת שרן משתף היא לבקש מהמועמד לתאר מה קורה 'מאחורי הקלעים' כאשר יוזר מקליד google.com ב browser שלו. שאלה זו עוזרת להבין את תהליך המחשבה של אותו המועמד – האם ההתמקדות היא ב flow, ב backend, באלגוריתמיקה, אופטימיזציה.
עוד סוג של ראיון טכני שרן ממליץ עליו הוא להכניס את המועמד ישירות אל תוך הקוד של החברה ולתת לו לממש משהו 'אמיתי' – כלומר פתרון באג קטן או תוספת מסויימת ל front-end – בראיון מסוג זה אפשר לראות איך מועמד מתמודד עם למידת כמות מידע גדולה ולראות אותו 'בפעולה'. רן מציע אפילו לאפשר למועמד לעשות deploy לקוד הקיים. ראיון טכני זה מתבצע על גבי מחשב בניגוד לכתיבת קטעי קוד קצרים על נייר/ לוח כמו שנהוג בהרבה ראיונות. שני עקרונות שאני מאד מסכימה איתם פה : 1). מבחן הטכני הוא סביב בעיות "אמיתיות" מאפשר למראיין לבחון את המועמד טוב יותר וגם למועמד לדעת על איזה סוג בעיות הוא יעבוד בעתיד. 2). יש ערך גבוה בלראות מועמד כותב קוד ממשי, פעמים רבות זה משלים את התמונה על הידע המקצועי ומנפה מועמדים שיודעים לדבר טוב. זו גם כמובן דרך טובה 'למכור' את החברה ולאפשר למועמד להתרשם מאופן העבודה והקוד.
רושם ראשוני – אחד הנושאים המעניינים שעלו בשיחה עם רן הוא שברגע שמועמד מגיע לראיון – יש לתת לו את מלוא הקרדיט ולא להגיע עם דעה מוקדמת. דוגמא שרן מציין שקרתה גם לי מספר פעמים היא שמרואיין זומן לראיון איתו אחרי ראיון טלפוני, המראיין הטלפוני אמר "שהמועמד נשמע בעייתי" – מאותו רגע מאתגר מאד לחבב את המועמד או לתת לו צ'אנס אמיתי. רן אומר שידוע שהרושם הראשוני נקבע בחמש הדקות הראשונות – מבחינתו, כמראיין, הפוקוס ב 55 הדקות שנותרו לראיון הוא להפוך את הדעה שלו ולא לתת לרושם הראשוני להטות את ההחלטה. ההמשך של הניסיון להגיע בראש נקי לראיון הוא התהליך בגוגל בו לא משתפים מידע על המועמד עד לסיום הסבב. אני חושבת שהגיוני להעביר מידע פרקטי בין ראיונות (למשל – נראה שהוא קצת יותר חלש באלגוריתמיקה, אם תוכל לתת דעה על הנושא) אבל קביעות שליליות או חיוביות על המועמד גורמות לראיון להיות פחות אפקטיבי עבור החברה.
חיים ידיד – Head of performance and application infrastructure, Outbrain
שאלות לראיונות טלפוניים, התעמקות בפרוייקט קיים והיתרונות והחסרונות במבחן בית.
מי מראיין? חיים מצטרף לדעת הרוב שכדאי שמספר מתכנתים יקחו חלק בתהליך הראיון. בניגוד לגישה של גוגל שרן הציג, חיים מתאר רצף ראיונות שתלוי אחד בשני – כלומר אם המרואיין לא עבר את אחד המראיינים אין סיבה להמשיך לראיון הבא. אני מתחברת לגישה הזו יותר מאשר מספר ראיונות לא תלויים, הזמן של מתכנתים בסטארטאפ הוא סופר יקר, וגם חבל לזלזל בזמן של המועמדים. ברוב המוחלט של המקרים, אם מראיין מסויים נתן 'לא' וודאי כנראה שהמועמד לא יתקבל. באאוטבריין, בחלק מהמקרים, המראיינים יהיו משני צוותים שונים – גם כדי לתת פרספקטיבה רחבה וגם לראות לאיזה צוות המועמד יכול להתאים יותר.
ראיון טלפוני – ראיון של 15-20 דק' להכרה אישית וטכנית בסיסית של המועמד. ברמה האישית השאלה העיקרית היא לא מה המועמד יודע לעשות אלא מה הוא אוהב לעשות. הראיון הטלפוני כולל גם שאלה או שתיים טכניות ברמה די בסיסית. דוגמאות לשאלות בראיונות טלפוניים :
מה המשמעות של volatile ב Java?
מה זה GC ואיך הוא עובד באופן בסיסי?
איך קוד רץ בתוך ה JVM?
ראיונות טכניים – בדומה לגישה שרן הציג, רוב הראיון סובב סביב פרוייקט שהמועמד עבד עליו בעבר. בגלל אופי העבודה בקבוצת תשתיות, חיים שם דגש על התמודדות עם בחירות ארכיטקטוניות, התמודדות עם Multithreading ו – Concurrency וניסיון להבין מה המגבלות של המערכת ואיפה היא נכשלת.
מבחן בית – המטרה של מבחן הבית הוא לראות את הדרך שבה מועמד ניגש לבעיית פיתוח, בחירת הארכיטקטורה, באיזה תחומים המועמד מתמקד, חשיבה על מקרי קצה, יסודיות ואיכות הקוד. במבחן הבית ב Outbrain מבקשים מהמועמד לפתח "מיני מערכת". לרוב יהיה למועמד בערך שבוע להחזיר את מבחן בית שאמור לקחת חצי יום – יום.
מבחן בית נשמע רעיון מצויין לקבלת תמונה רחבה של היכולות של המועמד ובסטארטאפים שלי התלבטתי גם אם כדאי להוסיף מבחן בית לתהליך. הבעיה העיקרית לדעתי היא שמבחן בית מצריך זמן רב מהמתכנת. באקלים היום, שעל כל מתכנת מוכשר מתחרות עשרות חברות, מבחן בית יכול לגרום לחלק מהמועמדים לפרוש מהתהליך. לדעתי עדיף להביא את המועמד למשרד למבחן מעשי של שעתיים- שלוש על פני תרגיל בית. כמובן שככל שהחברה המגייסת 'מפורסמת' יותר, מבחן בית נהיה לגיטימי יותר. מעורבות בפרוייקטים של קוד פתוח יכולה לחסוך את מבחן הבית ולאפשר לחברה לראות כיצד המועמד כותב בלי צורך במבחן נוסף.
עמית כהן ואבישי איש שלום – FewBytes
כישורי למידה של תחומים חדשים במרכז המבחן הטכני והשאלה שתעזור לכם לדעת כמה מועמד passionate לגבי DevOps
FewBytes היא חברת ייעוץ בתחום ה DevOps. יצא לי לפגוש את עמית, אבישי ושאר החברה דרך הרבה סטארטאפים שעבדתי איתם ונעזרו ב FewBytes לבעיות Ops/ Scale מורכבות. FewBytes הסכימו לשתף את המבחן המלא שהם מעבירים – מקור מדהים לכל מי שמראיין לתפקידי DevOps. התהליך המלא וכל השאלות הכלולות בו מצורף בתחתית הפוסט.
בשיחה שלנו, הפרמטר הראשון שעמית מעלה לבחירת מועמד הוא שיהיה עם הרבה תשוקה למקצוע. כבר בתהליך סינון המועמדים עמית נותן עדיפות לאלה אשר הובילו פרוייקטים אישיים המערבים הבנה מעמיקה הן בפיתוח והן בתשתיות. תהליך הראיונות בא לבדוק מעבר לידיעות טכניות האם המועמד אוהב את התחום, מעוניין ללמוד נושאים חדשים ולהתמודד עם בעיות מורכבות.
שאלה לדוגמא שעמית שואל היא : "איזה CPU יש לך במחשב האישי?" נשמע מאד בסיסי אבל מי שבעל תשוקה אמיתית ל Ops ידע בדיוק איזה מחשב הוא קנה.
ראיון טלפוני – ראיון קצר שבא לבדוק בעיקר מה המועמד מחפש ולבחון את מידת ההתאמה שלו לעבודה בחברת ייעוץ. כמו כן, הראיון כולל מספר שאלות טכניות וארגוניות.
שאלות לדוגמא:
הסבר איך DNS עובד?
למה עורכים פגישת post-mortem?
ראיון טכני – ראיון של שעה עם שני אנשים מהצוות. בדומה לגישה שרן וחיים הציגו, עמית גם מתחיל בשיחה על פרוייקטים בהם המועמד היה מעורב בעבר. בניגוד לשיחה כללית, עמית מתמקד בבעיות שהיו בפרוייקט זה וכיצד התמודדו איתן. פרמטר חשוב הוא הבנה שיש בעיות ושניתן לשפר כל פרוייקט. החלק השני בראיון כולל שאלה טכנית, לדוגמא: שרטוט של תרשים של רשת בחברה דמיונית, המועמד מתבקש להסביר מה יכול לגרום לכך שהאתר לא זמין. מטרת תרגיל זה היא בעיקר לראות כיצד המועמד חושב, איזה שאלות הוא שואל והיכן הוא מתעכב. עמית סיפר שבעבר הראיון הטכני נמשך מעל שעתיים, עם הזמן הם גילו שהם מגיעים לאותה הכרות עם המועמד ומספיק מידע כדי לקבל החלטה גם בשעה. עוד פרמטר חשוב עבור עמית הוא לבחון את תגובת המועמד כשהוא נתקל בשאלה בנושא שהוא לא יודע – ההעדפה היא שפשוט יגיד שאינו יודע או ינסה להקיש מנושאים אחרים בהם הוא מתמצא. שתי האפשרויות לגיטימיות, רק שלא ינסה להתחמק בתשובה מופרכת.
מבחן בית – מציגים כאן גישה שונה במבחן הבית – במקום לבחון ניסיון, הדגש הוא על למידה של נושא חדש לגמרי. המבחן בא לבדוק אם המועמד מסוגל להתמודד עם נושא חדש בפרק זמן של כמה שעות. לדוגמא, מועמד שלא מכיר Chef יכול לקבל כמבחן בית הקמת סביבת Chef וכתיבת Cookbook ייעודי. אני צריכה לציין שאישית אני מוצאת את המבחן הזה סופר מעניין – בניגוד לכל סוגי המבחנים האחרים שבוחנים ידע קיים, התפיסה פה היא שחלק גדול מהתפקיד יחייב למידה של נושאים חדשים והאספקט הכי חשוב הוא יכולת למידה ולא ניסיון קיים.
עדי שחם שביט – R&D Manager, AppsFlyer
למה לא כדאי לשאול שאלות טכניות בראיון טלפוני ושלב נוסף של ראיון עם ה co-founders והכרת המערכת אחרי הראיונות הטכניים
AppsFlyer מפתחת מוצר בתחום המעקב וה attribution של אפליקציות מובייל ומאפשרת למפתחי אפליקציות לנתח את מקורות ההגעה אליהם ולהגדיל את מספר ההורדות.
אחת הסיבות שבגללן רציתי לראיין את AppsFlyer היא ששפת התכנות העיקרית שבה הם עובדים, Clojure, די נדירה בארץ (ובכלל) ולכן קשה לבחון מועמדים בתרגילים בשפה עצמה.
ראיון טלפוני – בניגוד לגישות הקודמות שהוצגו, AppsFlyer, לא מאמינים בשאלות טכניות בסיסיות במהלך הראיון הטלפוני. עדי מסבירה שהרבה פעמים קשה למועמד להתבטא כראוי בלחץ של שיחת טלפון קצרה או בלי אפשרות לשרטט דברים. הראיון הטלפוני אינו בא לבחון ידע טכני אלא לבחון התאמה אישית – באיזה תפקיד המועמד מעוניין, האם הוא ראש גדול, האם מרגישים ש AppsFlyer והתפקיד מתאימים למה שהוא מחפש.
ראיונות טכניים – הראיונות הטכניים משלבים מרכיב אישי עם מרכיב מקצועי. הראיון הראשון כולל הסבר על החברה, הצוות והתפקיד. עדי מספרת שמעניין אותם להבין לעומק על המועמד איזה סוג מתכנת הוא, מה הרקע שלו, מה מלהיב אותו והאם יתאים לרוח החברה. לדוגמא, אחד הפרמטרים שחשובים ל AppsFlyer הוא למידה של טכנולוגיות וכלים חדשים, גם לא במסגרת העבודה השוטפת. אחת השאלות תהיה לתת דוגמא למשהו מעניין שלמדת/ קראת לאחרונה. כמו בדוגמאות קודמות שהצגתי – גם כאן נכנסים לעומק פרוייקטים קודמים שהמועמד עבד עליהם. אחד הדברים שנבחנים הוא גמישות ומחשבה על שינוי פרוייקט קיים – למשל – כיצד היית משנה את הפרוייקט שעבדת עליו כדי שיתאים למיליון משתמשים, או כיצד היית מעביר פרוייקט מסויים למודל SAAS. דרך השאלות האלה ניתן גם לראות מהי הנטיה המיידית של המועמד ועל איזה אזורים הוא מתמקד.
מעבר לשאלות על פרוייקטים קיימים, עדי בוחרת גם לשאול שאלות כלליות שמטרתן לבחון אופן מחשבה ולא ידע קונקרטי. כמה דוגמאות :
- למשרת Frontend – משתמשים בסין מדווחים על באג מסויים. איך היית ניגש לבעיה?
- Backend – הצגת קוד קיים/ מערכת קיימת – המועמד מתבקש להציג פתרונות אופטימיזציה
- בניית אלגוריתם לבעיה מסויימת
הראיון הטכני השני הוא השלמה של הראיון הראשון – מוקדש גם לשאלות טכניות ואישיות שלא הספיקו לכסות בראיון הראשון וגם להתמקדות בנושאים שנראו בעייתים או שהיתה לגביהם חוסר וודאות בראיון הראשון.
הכרות למועמד עם החברה – אחד השלבים שמצאתי מרתק בתהליך הראיונות של AppsFlyer הוא השלב הסופי שבו הפוקוס הוא לתת למועמד להכיר טוב את החברה ואת הפן הטכנולוגי שלה. שלב זה כולל ראיון עם שני ה co-founders של החברה. לדעתי זה מאד מרשים שגם שבגודל של 80 עובדים ובצמיחה מהירה עדיין שמים את הדגש שה co-founders יראיינו כל מועמד, זה גם נותן למועמד הבנה טובה יותר של מי מאחורי החברה ומה ה DNA. עוד שלב הוא הצגה לעומק למועמד של המערכת של AppsFlyer – זמן בו מראים למועמד את הארכיטקטורה, החלקים השונים של המערכת ואופן העבודה עליה.
יואב אברהמי – Chief architect, Wix
סימולציה מלאה של סביבת עבודה וכתיבה של פיצ'ר חדש
Wix מגייסת מתכנתים בהיקפים גדולים מאד ותהליכי ראיונות העבודה נמצאים בה בחשיבות עליונה. התהליך שיואב מספר עליו מסכם למעשה כמה שנים של איטרציות על סוגי ראיונות ותהליכים שונים.
ראיון טלפוני – דומה לראיונות שהוצגו כאן ע"י חברות אחרות. הראיון הטלפוני בא לעזור בתיאום ציפיות בסיסי, הכרת הרקע של המועמד וכולל שאלה טכנית קצרה. לדוגמא : איך מוצאים index של איבר במערך.
ראיון טכני – שיחות design והכרות עם פרוייקטים קודמים. הראיון הטכני הראשון מתמקד בפרוייקטים שהמועמד כתב בעבר. יואב מספר שמעניין אותו להכנס כמה שיותר עמוק לפרוייקט ולבחון את ההבנה של המועמד. אחד הפרמטרים הנבחנים הוא הבנה של בחירות מסויימות – למה נבחר database מסויים, למה נבחרה ארכיקטורה מסויימת. יואב רואה חשיבות גם בהבנה של בחירות וקטעי קוד במערכת שלא היו תחת האחריות של המועמד. שאלה מעניינת לגבי המערכת היא איך היית בונה אותה היום מחדש.
לאחר השאלות על הניסיון הקודם של המועמד, עוברים ב Wix לשיחת design כללית יותר עם שאלות לדוגמא כמו :
"איך בונים מערכת צ'ט?" או "איך בונים מנוע חיפוש?" – שאלה מסוג זה מאפשרת לראות מה הנושאים הראשונים בהם המועמד נוגע, ע"פ מה הוא בוחר טכנולוגיות מסויימות ועל איזה מגבלות הוא חושב. יואב מציין שלאורך השיחה הוא משתף מידע ו"טיפים" – למשל, אם המועמד בחר ב database לא מתאים הוא יסביר לו מדוע זו בחירה פחות נכונה – בדרך זו גם ניתן לראות איך מועמד מתמודד עם למידה של נושאים חדשים והאם הוא גמיש מחשבתית. עוד פרמטר חשוב עבור Wix הוא "האם המועמד יכול להתנתק מההיסטוריה שלו" – כלומר האם המועמד יבחר תמיד בטכנולוגיות שעבד איתן בעבר וכמה קשה לו לפתוח דף נקי טכנולוגית.
ראיון טכני מעשי – אחד מסוגי הראיונות שאני מאד מתחברת אליהם ולדעתי יכולים לחזות באופן טוב האם מועמד יתאים לתפקיד. ב Wix פיתחו מערכת מלאה בקנה מידה קטן שמשמשת לראיונות עבודה. מערכת זו בעצם באה לתת סימולציה לכניסה ל code base של Wix אבל באופן שיאפשר השתלטות עליה תוך פרק זמן קצר. המערכת כוללת גם Unitests. המועמד מתבקש להוסיף פיצ'ר או מספר פיצ'רים קטנים בפרק זמן של בערך 3 שעות. פיצ'ר לדוגמא הוא הוספה של השוואה בין שני קבצים או מציאת הרצף שחוזר על עצמו הכי הרבה פעמים במערך. מבחן טכני זה מאפשר לבחון נושאים רבים כמו – מהירות כניסה לקוד קיים, חשיבה על מקרי קצה, איכות קוד, עמידה בבדיקות של המערכת.
יאיר עמית – Co-founder and CTO , Skycure
תרבות ארגונית נכונה כחלק מתהליך הראיונות
הנושא הראשון שיאיר מעלה בהקשר של ראיונות עבודה הוא שמבחינתו תהליך הראיון עצמו הוא חלק מהתרבות הארגונית של החברה. זו נקודת המגע הראשונה של מועמד עם החברה וקריטי מבחינתו לייצג באופן נכון את החברה וליצור תהליך מכובד. ב Skycure מקפידים על מהירות התהליך ועל תקשורת מלאה של הסטטוס עם המועמד לאורך כל הדרך. החל ממענה שלילי על קו"ח לא מתאימים שמתקבלים (אני מכירה מעט מאד חברות שעושות את זה, לדעתי מועמדים תמיד שמחים לקבל פידבק גם אם הוא לא חיובי) ועד עידכון מהיר על הססטוס אחרי כל ראיון. אם מועמד לא עבר את אחד הראיונות משתדלים לתת תשובה כנה ומפורטת לגבי הסיבות שבגללן הוא נכשל.
ב Skycure קיים דגש חזק על על התאמה של המועמד לחברה ולהיפך – האם המועמד יוכל לממש את הפוטניצאל שלו בתפקיד המוצע.
ראיונות טכניים – הראיונות הטכניים כוללים בעיקר שאלות לוגיקה וארכיטקטורה. יאיר מספר שפחות חשוב להם לבחון הבנה בסיסית (לדוגמא, לא ישאלו שאלה על מימוש Hash table) אלא מידול נכון של בעיות וצורת מחשבה. הראיון הראשון יכלול בחינת יכולות לוגיות ומימוש ההחלטות בקוד. השאלות הראשונות יהיו לרוב יותר פשוטות, גם על מנת להתרשם ממימוש קוד פשוט ולא פחות חשוב – להפחית את הלחץ בראיון ולהתחיל אותו ברגל ימין. אח"כ יהיה מעבר לשאלה מורכבת יותר שבאה לבחון איך המועמד חושב. תהליך הפתרון יהיה ביחד עם המראיין ויאיר מספר שהיו מועמדים שנזקקו למספר רמזים לפתרון השאלה ולמרות זאת עברו את המבחן הטכני. הראיון השני יתמקד בנקודות שנראו פחות חזקות בראיון הראשון.
הראיונות כוללים גם דיון בפרוייקט שהמועמד עבד עליו בעבר, קיימת חשיבות להבנה של מיקום הפרוייקט מבחינת החברה והבנת המניעים מאחורי הבחירות שנעשו בתהליך המימוש. חשובה לא פחות היא יכולתו של המועמד לשמור על פתיחות מחשבתית ולענות על שאלות כגון "מה היית מממש בצורה שונה אם היית מתחיל כיום את פיתוח הפרוייקט מאפס?" או "מה היית משנה בתכנון לו הדרישות היו משתנות באופן מסויים?”.
FewBytes technical interview (By Avishai Ish Shalom and Amit Cohen)
What we're looking for when evaluating solutions:
- architecture
- platform and tooling choices
- ecosystem – e.g. tests, deployment scripts (chef, puppet, whatever), readme, comments
- production readiness – e.g. metrics, good logs, debugability, defensive programming
We are looking to see if the candidate can logically justify his/her design choices and how much experience they have with actual software running in production. for example, people with little production experience often write code without thinking about backpressure, metrics, debugability, etc; all of these don't have to actually be implemented, it's sufficient to refer to them in design or TODO – we just want to see the candidate has these in mind
definition of done is working code – both source and a running instance on the cloud. we inspect server configuration as well.
task 1 – Smart LB:
Build an HTTP REST based smart load balancer which send all write methods (POST, PUT, DELETE) to all backends and load balances all read methods (HEAD, GET). the idea is to build a cluster of HTTP REST based databases (e.g. couchdb, elasticsearch)
write loss is allowed, we expect some effort to write and logging of lost updates (within reason of course). Service uptime is more important then consistency.
There is no need to handle bootstrapping of new nodes – it's assumed that all documents have short TTL so empty nodes are allowed to join the cluster.
Failed nodes should not fail the cluster.
There are no restrictions on your choice of technologies, as long as you can reasonably explain the merits of said choice.
task 2 – RSS Ticker (web dev oriented):
A service that monitors RSS feeds and notifies, as close as possible to discovery time, about new items to the user.
Backend:
A daemon that queries a list of RSS feeds and notifies about new items to the user.
The daemon should monitor the RSS feeds in a concurrent manner, can be async or threads – your call.
Backend will notify all subscribers when a new item is found.
Subscribers must be able to connect/disconnect to the backend without backend service interruption.
Frontend:
Enables the user to add/remove RSS feeds to query.
Management page
Management page should display tracked RSS feeds and allow adding and removing feeds.
Once the user adds a feed, the backend should know about it and start monitoring it.
Dashboard page:
The user has a "dashboard" page, showing the items found.
Dashboard is a subscriber to the backend and will render updates on the browser immediately (or as close as possible to that)
No need for fancy display: Title, link, rss publish date and discovery time (when the backend saw the item).
Debug subscriber:
A cli subscriber which will receive updates from the backend and display them on stdout
Database subscriber:
A subscriber daemon which will register discovered items in a database: title, link, rss publish date and discovery time.
Notes:
Single user: no need for user management.There are no restrictions on your choice of technologies, as long as you can reasonably explain the merits of said choice.
