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:
So some of the tips for the interviewees are:
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.
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).
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:
And questions which are typically done by business department are these:
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:
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 :-)