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.
