面試準備

When I prepare for interview I'm trying to structure nearly everything I know. All the technologies, methodologies, all my experience and achievements. The good way to do so is to use mind mapping tools.

This technique allows to make an overview of your career and decide what could be important for the job you're trying to apply and what could be not.

Sometimes I ask myself what if I would be an interviewer. What would I ask?

I also look at the vacant position from the point of view of a higher-level management. What would they value in the candidate and why. Usually they look for somethimg more than just meeting the list of formal requirements. This help me to think of potential questions which might be considered out of the scope of the position, but would give you "a plus" if you would be able to demonstrate your awareness or attitude.

Also I recommend to always ask hr people who drive you through the whole process about what do they usually ask in technical and manager interviews. I never faced the cases when such information was a secret. Usually they are interested in your success since they need to close the position in time.

There are many factors that come up when interviewing someone, the main things an interviewer would be looking for would depend on many factors like the role, experience, team size, Job description etc;

Some of the most generic things that an interviewer would be looking for are:

1. How passionate is the candidate about the quality and the overall quality process
2. How eager is he to learn new stuff
3. How well he communicates ( not the accent or skills, but the charisma )
4. How technically sound he is
5. How technically versatile the candidate is
6. How he handles challenges ( How he find solutions for a problem in hand)
7. What are his future goals and how it aligns to organizational interests?

So some of the tips for the interviewees are:

1. Mostly interviews in Europe would be behavioral driven, means they will ask behavioral questions like "What are your weakness", "what are your strengths" etc. So for such questions answer according to the role you are applying. FOr instance, if you are applying for a technical role, don't tell that your strength is to "lift 100 kg". Instead, say like, " you are really good at debugging, and helps colleagues find the code issues pretty fast". Always answer something technical for behavioral questions
2. Always be proud of things you have done, whenever you tell about the products you worked on, tell with a passion and pride.
3. Always look around and find some issues with office, interview room etc. They might ask like " if you get a chance what will you suggest as an improvement for the workplace. And be straight forward to tell faults or if there are no faults, tell that too.
4. Learn the basic OOPs concept
5. Always mention the importance of manual testing even if its a 100% automation role. Because only a good manual tester can identify good test cases and your automation scripts will be only as good as the manual test cases.
6. Ask questions like what is the bug tracking process, daily runs , team size , role expectations etc

First of all, let us assume my skills and experiences more or less match the position I'm applying for. That means that if for example, job postings are looking someone with "skill A" I don't possess and have not even heard of are of the table.

Second, I look through my CV and try to systemize what have I done and what have I learned at previous jobs.

Third, I look at how my past experiences and future ones (the ones posted in the job posting) match.

Other than that, I am not trying to learn "skill A" in a couple of days before the interview. It wouldn't be possible to learn it that fast and just having an appearance of knowing something I don't would not be cool.

US Interviews broadly consist of two approaches:

1) Test the applicant. Test their knowledge. Push them on algorithms. Test CS fundamentals. See if the candidate can defend themselves when pushed. See if a candidate can think clearly during the interview. This is used for over 90% of interviews (even at the manager level). This sort of interview is basically a continuation of the academic approach of test, test, test that folks with less and experience, and more recently graduated from college, gravitate to. There is also a belief in the fairness of the purity of all candidates going through the same process is fair. It is fair if you only intend to hire inexperienced candidates and ignore the benefits that other candidates with experience would bring. They will lots of opinions that comes from their experience that they will want to talk about.

2) See how the applicants experience can be an asset to the company. In these interviews, folks with decades of experience with enjoy a fun and lively conversation with the other party. Both parties will speak (roughly) equally. NOT one drilling and then 'questions at the end'. Both parties ask questions throughout. It is NOT a test. It is a conversation between experienced people - who can tell in about 5 minutes where the other person is it if they have a healthy and direct and open conversation. There is NOT a sense of 'testing' each other, just the desire to know if this person has been there, done that, and has learned that working together beats everything else and open minded people can learn and adapt. These interviews are extremely rare at the moment due to the lack of battle tested experience in our industry and intense "Not Invented Here" syndrome. This is simply due to how new so much technology is, and how past experience is often not relevant when it is simply out-of-date. Most of my peers were unable to adjust to these changes and much of what I now encounter is bias based on the (real) experience that many younger folks have with older, less open-minded folks. Like other biases where there is a fair element of truth for many or even most people, the problem is that the exceptions then get judged harshly and incorrectly.

My advice is to NOT go to technical interviews until you have determined these factors. Nothing is more soul-destroying than going into an interview with a recent comp-sci graduate who just can't wait to challenge you on sorting, heaps, BigO, etc. In other words comp-sci theory, data structures and algorithms 101 and NOT programming or high quality software development. These folks have not learned the first rule of computing - avoid premature optimization whenever possible. Instead they drill on doing the exact opposite, making the code unreadable for the sake of efficiency. Ignoring that we solved a lot of that in the 1990's. To them, the algorithm is EVERYTHING and if they do not see their reflection they will reject you. Avoid these by tough questioning yourself up-front and before the interview. Never believe that 'you'll have plenty of chances to ask that in the interview'. In my experience you won't. That is recruiter BS to move you along the process. You won't get the chance to ask questions that you hoped for because you'll be exhausted by theory questions for the first half hour to 'see how smart you are and how you think" and partly because the interviewer is likely to expect you to follow their pattern. My main skill now is asking questions, so when I am asked one I usually have about 10 follow-ups immediately along the lines of 'why, how does this relate, what do you actually want to know? how is this relevant to quality code, what about customers? etc. Unfortunately answering a question with 10 other question rarely goes well in the moment and the rejection process starts.

How can I be so confident of my opinions? Decades of programming in different companies and industries and markets has taught me the lessons over and over again. 30 years ago I went to 'how to write an efficient sort routine' interviews. Those are still being done. The rest of the world has moved on to tackle more modern problems. I learned the various sort techniques BUT in 30 years of programming I never got to wrote those sort routines. If I wrote my code now the way I wrote it to solve them before I would fire myself for premature optimization.

One other suggestion - send a link to this answer in your initial correspondence.

Based from my experience as testmanager and now as tech-recruiter (but still with passion for SW-testing) I can tell you how it is working in Germany.

Regarding:

Studying more testing related stuff before interview: For me as tech-recruiter this doesn't make sense just to mention some good sounding buzzwords. For us it is important to get an authentic person, who has a passionate in what he is doing. I got a colleague from a testing department he just wanted to to automated testing e.g. with Java, Python, Selenium...So it makes no sense for him e.g. to know the testing gurus in exploratory testing just to mention them and and make a good impression just to get the job. Because this way implicates that the business departments thinks this guy wants to do manual testing instead of automated testing. And after getting the job, you won't get lucky (and believe me, a good recruiter finds it out whether you fit the job position or not :-) ) Furthermore it also doesn't make sense to mention all the great projects as a test manager when the job is related to a manual testing position. Hence I would focus more on the second part - and that is YOU and it is important to fill these testing knowledge with related stuff which of course can be proved and explanined by your side (of course job related).

Regarding:

Should you go only my past work experience by looking at your CV YES! This is the right way for me as tech-recruiter. Why? Because I want to know this guy which I want to hire and also whether he or she fits in our team (and also the business department). Please always be authentic! This is important it makes no sense to exaggerate your job. Just reflect your position with all your strengths (and with project examples) and also your weakness.

So from German point of view I would say that you can prepare via your CV like questions related to:

• Questions related to your strengthens: Mention your strenghtens related to testing projects that you can metion easily. Just mention 2-3 of them is good. For example: Don't just say "I am good teamplayer" say like this " In my last project we had to set up a testing framework with different teams in Germany and in India. I liked this way to test with different teams and in different time zones" (>>> Teamplayer, Communicative, International Experience)
• Questions related to your weakness: Once asking about weakness, we do not want to know about his weakness (e.g. impatience in getting testing results). We just want to know what he did against imaptience. I would always mention examples from your CV regarding your testing career and make it positive at the end! For example, "My weakness actually was the cultural misunderstanding between testing team from India. I shifted the tasks (e.g. creating test cases with requirements) to our testing team in India. But I never received an answer about the progress and our project manager was complaining about that. So after three weeks I introduced a daily call where we also used Skype to demonstrate the test cases (progress of test creation or whatever else), and this is what I learned from improving communication and I am still learning
• Behavioural questions see above and is mainly done via recruitment

And questions which are typically done by business department are these:

• How do you test software which has been developed from your team?
• What was your badest software project?
• Imagine you have a Softwareproject finished and there are some critical bugs, but we have to deliver within the next week, what would you say?
• Did you have struggle with your Product Owner when delivering the test results too late and how did you manage that?

These are typical questions from the business department, we want just to know how these guys are reacting in a typical testing situation. Once when reflecting your CV I am sure that you know those situations from your real life as testmanager/tester.

Furthermore we as recruiters are also looking for candidates like:

• How passionate is the candidate with his job what he is doing? We want someone who loves his job and can help us in solving testing issues!
• Does he know the newest trends (and uses them? - depends on the business department we got a business department where exploratory testing was important, and e.g. this guy knew all exploratory testing methods and also went to different conferences e.g. "ministry of testing" Great!)

Regarding the challenges in facing testing interviews. Well, we don't ask the applicant or candidate about some algorithms or deep dive testing procedures !!!(e.g. something from ISTBQ). That makes no sense, this stuff can be learned. The person is more important (can he fix in the team, is he willing to learn? can he ideally share his knowledge with team? and so on).

Hope this helped from a view of a (german) it-recruiter :-)