מה אני מחפש אצל מועמדים What do I look for in a candidate

http://yomamultinational.com/blog/wp-content/uploads/2013/12/finding-perfect-candidate.jpg

This post is written after James Thomas, who has a fascinating blog of his own, commented on this post and pointed out that I did not mention what I was looking for when interviewing candidates, and why. And, since to the best of my knowledge, James does not read Hebrew, I'm starting this post with the English version. 

Generally, we are trying to get an understanding about the following points:

• Testing skills
• System-wide view\ understanding
• Technical affinity
• Asking questions and questioning authority. 
• Identifying context and understanding what does it mean for testing. 
• Risk awareness (and tendency to spot risks)
• "Thinking on your feet" 
• familiarity with testing theory & terminology. 
• Programming (roughly at the skill level of a university graduate)
• Interpersonal skills
• Career goals

Each of these points can be broken down to smaller parts, and in some cases, those parts can be broken down again. And breaking those definitions is exactly what I'm about to do.

• Programming - probably the easiest thing on this list to explain. We expect the candidate to be able to write code, we don't care in which language. We look for the ability to come up with algorithms that solve simple problems, some basic understanding of data structures, good coding habits (e.g.: meaningful names, division into functions) and while it's not a must, we sometimes also try to see if the candidate has some idea about what is happening in the memory below the code (not registers and assembly language, just an understanding of the stack, heap and garbage collection).
  Why are we looking for that? In short - because we use programming in our work. No, we are not "automation engineers", but we do write automated checks in a framework that we built and maintain (and I'm even somewhat proud of). Learning to code on the job is possible, but it's way too expensive for us to accommodate that. In addition, formal learning in this case will be more thorough and cover the things you need only once in a blue moon, but we're long past the point where one needs "just enough programming to manage", and a decent theoretical base is always helpful. Sure, one does not need 10 years of programming experience to work with us (in fact, universities graduates might  fit well), but sometimes there are problems that require some investigation and fiddling around. In a team as small as ours, we don't have the luxury of having this task within the skill-set of only part of the team. 
• Interpersonal skills - A bit undefined, and can be roughly translated to "how much we like you". We look for people who are pleasant to talk with, won't cower in a corner in face of a loud voice. Into this category comes also the ability to explain oneself, to accept criticism and just about a million other things I can't exactly name, but can tell when they are missing.
  Why are we looking for that? First of all, because we look for people we would want to work with. I don't want to work with people I feel unpleasant around, so if I can affect that - I will. Secondly, because as testers, our work is all about communicating with others, so a candidate better not be horrible on this account. Third, and most importantly - We are quite of an aggressive team. We have some people in the team who respond fast and think while talking - which might push aside the more timid team members. Like it or not - and until we manage to change that - timid people will be run over, so when we assess the candidate fit for the team, this must be a parameter, even if it's only so that we'll know how much protection the candidate needs. Candidate who can hold the conversation when there is some cooperative overlap (I found this term here) and will not let themselves be pushed aside when the overlap becomes a bit competitive, will have easier lives in our team. One need not posses the glib tongue of a lawyer or a salesperson, but we prefer candidates who can join our team painlessly. By the way, this is more important for female candidates who will face unconscious gender bias on top of the general pushiness. 
• Testing skills is a title for a long list of possible skills, and everyone has a slightly different definition of what it actually is. It's also an umbrella term for stuff we don't have anywhere else to put but deem important for a tester - stuff such as professional pessimism, familiarity with different kinds of testing (there's very little in common between performance testing to localization testing, despite the fact that both are "testing").
  Within this list, we try to focus on the following:
• System-wide view: There are two ways in which systems can be understood: bottom-up, in which one learns all the fine details and slowly constructs the whole, and top-down, in which one learn how things are connected and what is the role of every part, and only later fills this schematic with details. The added value of testers is usually in putting the new feature in context - who will be using it? what other parts are affected? and so on. A person who learns in a top-down manner will probably have it easier to provide this kind of value, but in the end, it's about being able to see the system and zoom in and out as needed: if someone is very comfortable in the high-level descriptions, we'll drive to more technical details. If someone's very keen on the details, we'll push for a higher abstraction level. 
• Technical affinity - Be as it may, we are testing software (or hardware), which is something technical. A tester should not be afraid of it, and should understand how computers work instead of regarding to it as magic. In addition, when something stops working, we dive into it and investigate, and this requires technical skills.
  (Also, if you're using "technical" as a euphemism for "knows to code", please stop. Thank you.)
• Questions in face of authority: I hope I don't have to convince any of the readers that asking questions is one of the most important things testers do. The authority part is no less important. We ask questions that people don't like to hear such as "are you certain you want to release with this unfixed?" and sometimes we just call other people's baby ugly with questions like "will your solution still work when five people click on the button simultaneously? " There's always some sort of pressure against such questions, especially close to a release. A tester should not be too much intimidated by such pressure, and leave a question unasked only when there's a decent professional reason for that. Also, good questions that are based on understanding the system can save a lot of time and effort to everyone. 
• Identifying context: This one's simple. We don't test everything the same way, and we don't test the same thing in the same way on a different project. Being able to justify our testing and prioritize them is important. A tester who can do that with no context is reading from a manual that was never relevant. 
• Risk awareness & tendency to see risk: It's an extension to the previous bullet. Risk is what drives testing. If there is no risk, there's no need for testing. It also provides us with language to communicate with other team members - "I'm going to invest three days on this, since a minor defect will cost a whole lot of money, while no one will really care about the typos and spelling mistakes in the help file, so I'll go over it only if I'm really bored").  
• Thinking on your feet: In many cases, a tester need to provide a quick response. For instance, if someone raises an idea during a design review meeting, the best time for a feedback would be right then, not after a week of analysis. In fact, in most situations I can think of, saying "here's my initial thoughts, and it seems to me that there's a week of analysis that can be done here to find out what I've missed" is by far more useful than "oh, really? Gimme a day to analyze and I'll tell you what I found". 
• Familiarity with testing theory & terminology: Well, that's usually a probe to see if the candidate is familiar with some of the basic terms found in the ISTQB syllabus, maybe the difference between testing & checking or the ability to hold a short conversation about "why test?". Having a common language enables passing information precisely and concisely, but it has another aspect to it - behind each such term there's an idea. Once something has a name it can be easily recalled and used. Boundary values, for instance, is a really simple idea (which doesn't mean it's shallow) - but it's not something one will necessarily think about if they never heard of it before.
  In addition, being familiar with the jargon is a good indicator that the candidate is learning testing in some ways. There isn't anyone who is interested in testing and did not encounter some basic terms such as equivalence partitioning or a test oracle. From the experience I gained thus far, it seems that candidates that are not actively learning are not familiar with such terms. Sadly, it's true also for people who have recently bought their ISTQB CTFL certificate (and I say bought since learning or earning was clearly out of the question in their case. They passed the test, probably without cheating, and they didn't learn a thing).
Why are we looking for that? Because we are hiring testers. Because we don't know how to teach stuff such as "system view" and while we can help people learn to stand their ground, it's not a short process, nor it is perfect (or fun to all involved parties). To put it simply - we are looking for employees, not offering training. We will be happy to hire inexperienced people, but they have to show us that they did the first steps themselves (or have some natural affinity to the testing mindset) to convince us that there will be value in investing in training them. 

Career goals: Here we try to guess whether the candidate is regarding software testing as a profession.  We try to understand what are the short term career goals of the candidate, and ask about the long term ones (we don't usually ask about the short term goals, since it's an invitation for a lie).
Why are we looking for that?
Two reasons: The first and only one that matters is that we have a long ramp-up period. Our product is carrying over fifteen years of history, and is quite complex. Usually we consider the first three months as pure training time, and don't really expect an employee to be highly effective in the first year. If a candidate will ask to switch role after a year (or worse - leave in favor of another place), we invested a lot and got little in return. Additionally, employees that are interested in testing will be more open to acquiring new skills in this domain. Employees that want to use testing as a stepping stone towards a different role will try to acquire skills that are relevant to that role.
We ask for the long term goals for two reasons: One is to gain insight for the short term goals. The other is to see if we can accommodate such goals - Not everyone can be a manager, and if someone is keen on accessibility testing, there are better places for them to be in. A candidate that can only see progress as "becoming a manger" might need some guidance to find other options (unless specifically recruited to become a manager) in comparison to someone who is familiar with the technical career paths that are out there.
The second reason is  a matter of ideology. I see testing as a profession and not as something temporary to do in order to "get into high-tech", or because someone lacks the skills to do what they actually want to do. I prefer to work with people who share this view. 

------------------------------------------------------------------------------------------

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

בגדול, אנחנו מנסים לקבל מושג לגבי הנקודות הבאות (הסדר אינו מעיד על חשיבות):

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

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

• תכנות: ככל הנראה, זה החלק הכי קל. תכנות הוא תחום סגור ומוגדר למדי, ואנחנו לא נכנסים לדקויות של שפה. אנחנו מנסים למצוא את היכולת לאתר אלגוריתמים לפתרון בעיות פשוטות ולהעביר אותם למשהו שנראה כמו קוד. על הדרך אנחנו בוחנים יכולת שימוש במבני נתונים בסיסיים, הרגלי כתיבת קוד טובים - שמות בעלי משמעות, חלוקה הגיונית לפונקציות. לפעמים נגיע ונבדוק שימוש נכון באובייקטים או היכרות עם הדרך בה מנוהל זיכרון.
  
  למה אנחנו מחפשים את זה? בקצרה, כי אנחנו נעזרים בתכנות במהלך העבודה שלנו. לא, אנחנו לא "מפתחי אוטומציה", אבל אנחנו בהחלט כותבים מבדקים אוטומטיים בתוך תשתית בדיקות שכתבנו (ואני אפילו גאה בה באופן יחסי). ללמד תכנות זה אפשרי, אבל זה גוזל הרבה מאוד זמן, וממילא יש לעובדים חדשים הרבה מאוד מה ללמוד ולנו מעט מאוד זמן ללמד אותם את כל מה שצריך. בנוסף, לימודי תכנות במקום העבודה יהיו פחות מעמיקים מאשר לימודים פורמליים, ואת הנקודה בה צריך "לדעת רק מספיק תכנות כדי להסתדר" עברנו מזמן. לא צריך עשר שנות ניסיון כמתכנת כדי להשתלב, אבל מדי פעם יש בעיות שמצריכות קצת חקירה ומשחק, ובצוות קטן אין לנו את היכולת להשאיר את הכל לאחד או שניים מאיתנו.
• כישורים בין-אישיים: כאן ההגדרה קצת יותר אמורפית. אנחנו מחפשים מועמדים שנעים לדבר איתם ולא מתחבאים בפינה לנוכח הרעש הקטן ביותר. לתוך הקטגוריה הזו נכנסת גם היכולת להסביר את עצמך, להתמודד עם ביקורת, ועוד מיליון דברים שאני לא באמת יודע  עדיין להגדיר במדוייק.
  
  למה אנחנו מחפשים את זה? בראש ובראשונה, כי אנחנו מחפשים אנשים שנרצה לעבוד איתם. אני לא רוצה לעבוד עם מישהו שלא נעים לי להיות במחיצתו. שנית, כי העבודה שלנו מבוססת על תקשורת עם אחרים, ומי שנעדר את היכולת לתקשר באופן הולם לא יצליח. שלישית, ואולי הכי חשוב - אנחנו צוות עם התנהלות כוחנית למדי. אנחנו (או לפחות רובנו) נחמדים למדי ורוב העקיצות הקטנות שמתעופפות בחדר נראות הרבה יותר גרועות מאשר הן מרגישות, אבל אנחנו לא מאוד מוצלחים בלהשאיר פתח שיאפשר לחדשים להיכנס לדיון. אם מועמד מסוגל להיכנס באופן טבעי לשיחה ולתפוס את מקומו בה, העבודה שלו תהיה קלה יותר (ובמקרה זה, אפסיק לרגע להשתמש בלשון סתמי ואציין שזה נכון שבעתיים אצל מועמדת). אנחנו לא מצפים לכישורים הרטוריים של עורך דין או לחלקלקות של איש מכירות, אבל אנחנו מעדיפים מועמדים שיוכלו להשתלב בצוות בלי שזה יכאב להם.
• כישורי בדיקות: זו כותרת כללית מאוד להרבה מאוד דברים, וכל אחד מגדיר אותם באופן קצת שונה. זהו מונח מטרייה לכל מיני כישורים שלא נכנסים תחת שום הגדרה אחרת - היכולת להבין מערכת בלי להיכנס לפרטי פרטים, פסימיות מקצועית, היכרות וניסיון עם סוגי בדיקות ספציפיים (כי אין הרבה דמיון בין בדיקות ביצועים לבדיקות לוקליזציה, למרות שלשני הדברים קוראים "בדיקות").
  בתוך כל זה, אנחנו מתמקדים בכמה אזורים. 
• תפיסה מערכתית: יש שתי צורות בהן ניתן להבין מערכת - ללמוד את כל הפרטים לפני ולפנים ומתוך זה ליצור את התמונה השלמה, או ללמוד את התמונה השלמה ורק מתוכה להבין את החלקים הקטנים. הערך המוסף של בודקי תוכנה הוא ביצירת הקשרים בין חלקי המערכת השונים. מי שמבין מערכות מלמעלה למטה יהיה מסוגל ליצור את ההקשרים האלה מהר יותר, וגם במערכות שהוא מכיר פחות טוב. אבל בסופו של יום, זה לא ממש משנה איך לומדים, כי הבנה טובה של המערכת מחייבת כמה רמות - הרמה המופשטת למעלה והרמה הטכנית למטה. בודק תוכנה צריך להיות מסוגל לדלג בין הרמות האלה בהתאם למשימה הנוכחית. לכן, אם מועמד חש בנוח ברמה האבסטרקטית אנחנו נשאל על הפרטים הקטנים ואם מועמד מפגין בקיאות גבוהה בפרטים הקטנים אנחנו נחפש את ההבנה הפשטנית יותר שאפשר לסכם בחמש מילים.  
• הבנה טכנית: איך שלא מסובבים את זה, אנחנו בודקים תוכנה. תוכנה היא משהו טכני - קוד, מחשבים, טלפונים. בודק תוכנה צריך להיות מסוגל להבין איך הדברים האלה עובדים ולא להתייחס אליהם כאל קסם. כשמשהו לא עובד כמו שאנחנו מצפים, צריך לצלול פנימה ולהתחיל להבין קצת יותר לעומק, וזה דורש חוש טכני טוב.
  (ובקשה קטנה - אם אתם משתמשים ב"טכני" כדי לומר "יודע לתכנת", בבקשה הפסיקו. תודה)
• שאלות וסמכות: אני מקווה שאני לא צריך לשכנע אף אחד מהקוראים בחשיבותן של שאלות טובות ומתוזמנות כהלכה. החלק של הסמכות הוא חלק חשוב לא פחות - אנחנו שואלים שאלות שלא תמיד נעים לשמוע, כמו למשל "האם אנחנו רוצים לשחרר את המוצר עכשיו עם הבעיות עליהן אנחנו יודעים?", ולפעמים אנחנו סתם מערערים על סמכותם של אחרים בשאלות כמו "האם הפתרון שהצעת עכשיו יעבוד אם חמישה אנשים ינסו אותו ביחד?". יש לא מעט לחץ נגד השאלות האלה, במיוחד כשרוצים לשחרר משהו לאוויר. בודק תוכנה צריך לדעת לא להתקפל בפני לחץ שכזה ולוותר על שאלות רק כאשר יש סיבה מקצועית לעשות את זה. כמובן, סוג השאלות ששואלים חשוב גם הוא - שאלות טובות שמבוססות על הבנה של המערכת יכולות לחסוך לכולם הרבה מאוד זמן ומאמץ. 
• זיהוי הקשר: דברים שונים דורשים בדיקות שונות. לא נשקיע את אותו מאמץ בכל דבר, ולא ניגש לבדוק כל דבר באותו האופן. בודק תוכנה טוב ידע לזהות את הנקודות בהן צריך להשקיע יותר ואת אלה בהן צריך להשקיע פחות. 
• מודעות לסיכון ונטייה לראות סיכונים: זה הבסיס לנקודה הקודמת. זה גם נותן שפה לתקשר בעזרתה עם חברי צוות אחרים - אני הולך להשקיע יותר בבדיקה הזו, כי אם נפספס פה משהו זה יעלה המון כסף, ואם נפספס במקום אחר זה סתם יהיה קצת מכוער. 
• חשיבה על הרגליים: במקרים רבים, צריך לתת תגובה ראשונית מהירה (זה מה שאתה רוצה לעשות? האם חשבת על... ועל... ?). התשובה "תן לי חצי יום לנתח את זה" תהיה במקרים רבים אפקטיבית הרבה פחות מאשר "במבט ראשון נראה לי ש..., אבל בוא ניקח קצת זמן כדי להבין את זה כמו שצריך". לפעמים התשובה ששלפנו מהר מספיקה. 
• היכרות עם עולם המושגים התיאורטי של בדיקות תוכנה: זה אומר להכיר טיפה את עולם המונחים שאפשר למצוא בסילבוס של ISTQB, לדעת דבר או שניים על ההבדל בין בדיקה לווידוא (testing & checking) והיכולת לנהל שיחה על למה צריך לבדוק תוכנה. שפה משותפת מאפשרת העברה יעילה יותר של מידע וחוסכת זמן, אבל יש לזה אספקט נוסף: מאחורי כל מונח יש רעיון. ברגע בו למשהו יש שם, קל יותר לחשוב עליו ולראות אם הוא רלוונטי או לא. מחלקות שקילות, למשל, הן רעיון פשוט מאוד (שאפשר להעמיק בו) - אבל מי שלא שמע עליו מעולם לא בהכרח ידע לחשוב עליו.  בנוסף, היכרות עם עולם המונחים מעידה על עוד משהו קטן - שהמועמד טורח ללמוד קצת - אין מישהו שמתעניין במקצוע ולא נתקל במונחים השונים מדי פעם. על בסיס המועמדים שראיינתי עד כה, נראה שרוב מי שלא לומד קצת בעצמו, לא מכיר את המונחים הבסיסיים, או משתמש בהם באופן שגוי - וזה כולל מועמדים שקנו את תעודת CTFL לאחרונה (אני אומר "קנו" כי בבירור לא היה שם תהליך של לימוד. הם עברו את הבחינה, כנראה ביושר. הם פשוט לא למדו כלום).
למה אנחנו מחפשים את זה? כי אנחנו מחפשים בודקי תוכנה. כי אנחנו לא יודעים ללמד דברים כמו "ראייה מערכתית", וכי למרות שאנחנו יכולים לעזור קצת למי שמפחד לשאול שאלות ולעמוד על שלו, זה לא תהליך קל, קצר או מושלם. בסופו של יום, אנחנו מחפשים עובדים, לא מציעים קורסי הכשרה. אנחנו נשמח לקבל אנשים חסרי ניסיון - אבל הם צריכים להראות שאת הצעדים הראשונים הם כבר עשו (או שיש להם נטייה טבעית לדפוסי המחשבה הרלוונטיים). 

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