I have been on the recruiting side a fair number of times and I hope to cover some common pitfalls and advice to help you land a nice job!
Before we start I want to say this is advice from my own jobs and interviews for "normal" developer jobs in Europe, especially Sweden, in techy small- to mid-sized companies with interviewers that are not out to diminish or play tricks on you.
If I could only give one piece of advice, it would be to practice first! I'm not talking about 100s of hours of LeetCode or memorizing the docs for Kubernetes. No, what I mean is "mock interviews" and getting comfortable in an interview setting. Many (most?) developers are simply not very comfortable interviewing, and practice does help. I do try to be sympathetic and accommodating when interviewing, and it is perfectly fine to stumble for words, having shaking hands etc.
However, it can only go so far. You need to be able to tell the interviewer what you know! One case I remember clearly was a candidate that could not explain the difference between client-side and server-side execution in a web app. I suspect he was just too nervous or had a bad day. This candidate had a solid CV, a tech blog and given talks at AWS conferences! But if you cannot explain the basics, it's extremely difficult to recommend you for hiring regardless of your other qualities.
Now, after many years I feel reasonably calm when interviewing, but that was not the case when I started. And of course, since I didn't like it, I naturally also didn't want to practice it. But please, don't you make the same mistake! Practice makes perfect! It helps both you and the interviewer to have a nice and productive interview!
Some candidates have many short jobs (like 3, 4 or 5 jobs lasting a year or less). This is not a critical issue and I believe you will get an interview regardless. However, you do need to have a good reason why your next job will be different. Unless specifically asked for in the job description the company want to have someone for the long term. Think through your reasoning beforehand. And it's probably best you mention it before they have the chance to ask about it, so that you can control the discussion.
If your current role is something different from the job you apply for, then you need to cover this and explain. This is equally important if you "level down" as if you want to "level up". One typical case I have seen is candidates that currently lead a small team but now apply to a developer type role. This type of candidate and experience can be very valuable, especially when hiring for a senior developer role in a smaller company that expects developers to take more responsibilities than just implementing a ready-planned task. At the same time, there are a couple of things you must convince the interviewers of. First, you should show that you still have the technical skills. It's not uncommon for team leads to lose touch with the tech, or maybe they were not that into the tech side to begin with. Secondly, you do need to explain why you want to go back to coding full-time. That you can't find a job as a team lead is unfortunately not a good explanation.
Please do not talk too much! Especially if you are unsure about something it doesn't help to talk about it more. Sounds obvious, right? But apparently difficult to follow in practice! I have interviewed candidates that could give a decent answer to a basic question but then failed in their own follow-up. Like a candidate that was asked about when to use GET and POST. I acknowledged I was happy with the answer and ready to move on, but they continued talking a fair bit more and showed their very shallow understanding on the topic!
A related issue with talking too much is that you paradoxically may not let the interviewer learn enough about you. I've left the interview more than once thinking I didn't learn much of the candidate, but at the same time she/he was talking all the time. Often the best outcome of a technical question is to have a technical discussion as "equals" with the interviewer(s). This is only possible if you let the interviewer back in and don't keep a 10-min monologue about the topic at hand. It is especially important if you are not deeply experienced in the topic (as described above), or a great presenter.
As a senior candidate you need to be very careful when you talk about dated/legacy tech, or experiences that don't match what the interviewer is looking for. The problem is not that you have that experience, it's that the interviewer is afraid you don't know or don't like what the interview is looking for and that you won't be able to adapt to the new company's tech and processes.
For example, your old-school Linux scripting skills are still relevant for a company running on hosted Kubernetes, but you need to explain it to them! Don't focus on how you scripted the installation of 100 physical machines, because that is useless in this context. Instead, you can talk about how your deep Linux skills helps you write optimized and secure docker files, or troubleshoot networking issues when you 'exec' into a pod.
In general, I find that most applicants are very self-aware and know their limits. I also believe that this is in general a good thing. Most of the time it's obvious anyway when someone talks about a topic they are not very familiar with, so you can just as well admit it directly. At the same time, don't be too humble, and no need to point out all your weaknesses!
Whatever the topic, it's always an advantage if you can connect to real experiences you have had. It's great to collect a number of good examples before the interview - you should come prepared!
For example, they ask about your experience of event driven architecture, but you haven't really done much in this area. However, one time you did implement a work queue. Then bring that up and explain what you did, why and the reasoning behind. Another idea is to bring up the time you considered event driven architecture, but opted out because of reasons X, Y and Z. And then finish off by asking how it works for the recruiting company. All tech always comes with downsides, but awareness of this is often lacking, so this is a great way to both show your maturity, and let them talk about their own system. Most interviewers love to talk about how their own unique system works.
But, there is something to watch out for here for the senior candidate! Be very careful to bring up examples from 10+ years back. And be equally careful to take examples using the wrong technology. If I interview a candidate for a microservice type of job, do not speak about Windows app development more than absolutely necessary even if you think it all boils down to the same thing.
This advice you will find in every generic interview guide. But it is actually good advice. Don't forget to bring some questions. In the end you might end up working there, and you do want to try and find any red flags beforehand! Or if you don't then at least take the opportunity to get the interviewers to talk about something they find interesting - almost everyone likes to describe their current architecture, team structure or day-to-day work! Just remember that the questions you ask reflects on you - what are you interested in, what do you care about?
Great, congratulations! Remember: They hired you. That means that they think you can do the job. Things can be very confusing and overwhelming in the beginning, especially if you are not used to the role or type of company from before. It will become better, do your best and hang on, and after a couple of months you will feel more at home.
Whatever the reason, do not feel bad! Sometimes it's best for both parties, maybe you weren't a good fit, or maybe they were not the dream company you thought. It could also be pure (bad) luck. To take an example from myself, I once interviewed with a fintech which gave me a coding task in Golang. At that point I hadn't written Go for 3-4 years. It was not a difficult task, just implement a simple Rest API. However, I made some mistakes, and they rejected me. Looking at the mistakes I made I would also have rejected myself, so no blame on them. However, at the same time I am confident I would have been able to manage the technical challenges on the job based on my prior experience building large parts of Tantan in Golang, or any of my other jobs since. Sometimes the stars are just not aligned.