איך לעבור את ראיון העבודה שלי How to pass my technical interview

Source: https://res.cloudinary.com/teepublic/image/private/s--nsFTfEGE--/t_Preview/b_rgb:0073ad,f_jpg,q_90/v1446153336/production/designs/25093_1.jpg

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

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

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

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

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

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

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

For quite a while now, we are looking for someone who will join our team, which means we get a whole bunch of CVs, and some of the people I get to interview (alongside my manager). What can I say? It's really frustrating to interview a candidate that fails. We want to find a new team-member, the candidate wants a job offer (hopefully, they want a job offer in our team), but as far as we can determine - there isn't a match in the skill-set the candidate has and that which we need. Of course, an interview is a stressful situation, which can lead to wrong impression. 

The way things are set now, it seems that next week I will do very little other than interviewing candidates. So, as a service to the community (and also in hope that the interviews I have scheduled will go better), I thought to write about how to pass my technical interview.

First of all, before you even get to the interview, do your best to determine that the position matches your skills and desires. It almost doesn't matter how well prepared you will be - if there's a mismatch here you either won't pass the interview, or you'll get a job offer you don't want. If you want to improve your mobile testing skills, a place that builds software for aviation engineers is probably not the right place for you, and if you don't have any performance testing background, no (decent) place will hire you to lead the performance testing efforts of the entire company. Before you get to any interview, sit with yourself and be honest - what do you want to do? what skills do you have? what skills you need to acquire? It's ok to apply for a position if you don't have all of the required skills: It is always assumed that a new employee will have to learn some stuff before actually being productive. However, there are some skills that the workplace will not have the time, ability or will to teach you - and guess what? Those are the very skills you'll be interviewed for. For us, for example, there are three basic things we look for in a candidate: Communication skills, Programming (at least at the level of a university graduate) and the package that is sometimes referred to as "Tester's mindset" (Including stuff like System-view, Question-asking and context awareness). If you'll ask us before the interview - that's probably what we'll tell you. 

You got to an interview with me? congratulations. This means that I think that you have a good chance to pass the interview. Also remember that I want you to pass. So, here are some things you should keep in mind. 

• I asked something you are not familiar with? There isn't much that you can say and will impress me more than "I don't know". If I asked you about how memory is managed in Java and you have never learned it - I am probably trying to map what you know, not to trick you and disqualify you based on an easy to learn subject. I might also be trying to direct the interview to a certain direction, in which case saying "I don't know" will save us both time and I can tell you what I need you to know to continue.  If you'll throw around some half-related terms to try and make me think you know what you are talking about I'll notice and will lose my appreciation for you.
• Even if you do know how to respond - ask a question or two to make sure. Knowing to ask good questions is important for testers (and any other knowledge workers). I've asked you to test a pencil? If you'll start throwing test cases without asking if it's a make-up pencil, it will be disappointing. In a world where the possible test options are infinite, I want to learn about the way you prioritize your tests. I also pose challenges that are meant to make you ask questions so that I'll see how good are they. 
• Also, don't bother practicing testing pencils, I don't ask this sort of things. I interview people for software testing positions, not for industrial designer ones. If I'll ask you to test something, it will resemble more something that you can expect to find in your day to day work. 
• At the beginning, I will ask you to describe your last workplace, or a project or course from your studies - I'm trying to understand how well do you understand technological projects, and how well can you communicate them and separate between what's important and what isn't. I will ask for a high level overview, I might ask to deep dive on a random part of the system. I expect you to know to explain what is the system used for (and by whom), how data is passing through it and what are the main components in it. When I ask about the fine details of your system it is not because I try to uncover trade secrets, but because I want to assess how deep is your understanding of the system you were working on previously. 
  If you want to prepare for this question - make sure you can draw a high-level diagram of the system, and can dive in a level or two on every part chosen at random. Also make sure to notice which level of detail am I asking for. I expect you to be comfortable in  both high-level overview and low-level fine details scope, so don't run to the overview when asked for details, and don't hide behind details when asked for an overview. 
• Defend your opinions. sometimes, during the interview I will ask you "why?" I might have noticed something I think is a mistake, or I might want to make sure you know why you are doing something. I might even check how do you respond when an authority figure (me, in this case) is putting pressure on you. 
• Your CV sets expectations. If you write "ISTQB certified" and you don't know what boundary values are, I will hold it against you. If you did not write such thing, I will just assume that you have not heard of the term and explain it quickly. 
• There's no such thing such as "failing a question". First of all - if you're here and I'm investing my time in you, I won't let a single question to be a single point of failure. Second - a question is giving me information. You might have a knowledge gap that I have to consider, and I will ask some follow-up questions to better understand that gap and see if I can live with it or easily fix it. 
• Tell me what are you looking for - if you do not do so, and I will get the impression that you are looking for something different than what I have to offer, I will not pass you to the next phase. If you don't tell me and I will pass you through - I will be wasting your time on something you don't want. 
• Now, some stuff about coding questions: 
• I ask you to solve a programming problem without giving you a computer. This means that I don't care about the code compiling and couldn't care less about syntax issues. Had I cared, I would have provided you with an IDE. I won't care if you miss out a semi-colon, or have a typo in your function name. In fact, if you're not sure if there's a function that does what you want, just pretend to invoke a function with a clear name and say that you're not sure that there is a function by that name. 
• If it's critical for you - you can write down your answer on a piece of paper. In any other case, it's better to answer on the whiteboard, so that I could see what you are writing and how does your thought process goes. I learn from the code you erase as much as from the code you don't. When you are writing on paper I can learn mostly by looking at your expressions, and usually this doesn't work in your favor. 
• Don't be silent. Tell me what you are about to do. Tell me about the problem that is preventing you from progressing. If you need to think quietly for a couple of minutes, tell me that you are taking a pause to think - I might even get out of the room for five minutes to provide you with some comfort. 
• Work with examples, and make sure that your algorithm works for the examples you chose. 
• I can see the code you're writing. Either as you write it or shortly after. Use meaningful names. On top of demonstrating good coding habits, it helps me understand faster where are you going and what are you trying to do. If you write a function named "flipNextBit" I can tell what it should do even if I don't see the implementation (or if it has a bug).
• You cannot google during the interview, but you can ask me. 
• Before the interview, google some coding interview questions and practice answering them on a whiteboard. Most will be much harder than what I usually ask. There are two types of difficulties in the coding question - not being able to find an algorithm that will solve the problem, and finding an algorithm but failing to transfer it to "code". Practicing will help you with both types. Just getting accustomed to this type of question will increase the chance of you finding an algorithm quickly, and practicing on a whiteboard will free you from depending too much on an IDE. 
• Most probably, you'll have some mistake in your code on the first attempt. maybe an edge case you didn't deal with, or something you overlooked. Don't freak out once I lead you to such a failpoint. I don't care if your code is working, I want to see how do you deal with your own mistakes. Do you freeze? Do you try to minimize the importance of the mistake (I had once heard a candidate refer to an off-by-one-bug that was applicable to every input as an "edge case" - don't do that)? do you shrug your shoulders and fix it?
• Yes, it's a testing job. Yes, we use selenium sometimes. Don't bother memorizing the selenium API - I don't ask questions if the correct answer for them is "Google it". 
• If all of your programming education is some "automation course" you took, do yourself a favor and learn how to code properly. You don't have to get a fancy diploma to prove that you can code, but you should have a solid understanding of data structures, polymorphism and recursion. Not all of those will come up during an interview, but all are fair game. 
• Finally - ask for feedback. It's still something I need to learn how to do, but I asked you to invest your time in coming to an interview with me - I will be happy to help you gain some benefit from it by pointing out what flaws I saw, so even if you don't pass my interview, at least you can get a pointer or two and improve. 

* Also - if you happen to be looking for a new job (and are located in Israel) and want to hear some details, drop me a note.