Intro

For about an year I've interviewed a lot (and I do mean A LOT of candidates at Chili Piper, before that I've did interviews for my previous employers and I had a period of experimenting with different platforms to find remote work (which led to plenty of interviews). You can read more about it here Finding remote work in 2019. I've also talked a lot with friends, co-workers, etc. on job hunting, recruitment and so on. What is listed below is what I've noticed is a good or bad indicator for both candidates and interviewers.

Pre-interview

The job posting

The way a job posting is written tells you about the company. This can take several posts on its own, but in general if the listing is using every popular framework and language, it was most likely not written by an engineer, but by an HR, so expect that initially you'll have to deal with HR, before actually talking with your future co-workers. If it was written by an engineer, it is highly likely that the company will have issues in the future. For instance I recently had an offer with the following tech stack - FE with experience with WebGL graphic libraries such as Three.js, Babylon.js, Paraview, etc. DevOps stack including Jenkins, JFrog, GitLab, Docker, Kubernetes, Ansible. Understanding of 3D Math, ReactJS/React Native, Angular, NodeJS with Express, Flask, Django, Rails, Spring or PHP. Any SQL or NoSQL (list them here). Languages as JS, Python, .Net core or Java. Since this wasn't written by a recruitment agency or an HR, it makes me wonder how many projects a single dev has to work on, how are they being maintained, how is the tech stack being chosen, how you find new devs, how you onboard them, etc.
After a while you'll get to decipher the usual lingo of competitive salary, growing environment and so on.

Requiring you to write a cover letter

If they (the company) requires for it to not be a stock letter it is a huge Pro. The template cover letters are boring to both write and read.
From a company perspective, this automatically filters most of the candidates that are just applying on every position they see. The cover letter requires the candidate to read and follow your instructions. It is also a great way to evaluate the candidate's writing skills. After all a lot of the communication in a company is in a written form. This is especially true for remote companies.
From a candidate's perspective, this is a great chance to hone your writing skills and dazzle them by telling them a short story about yourself. Cover letters typically come with a set of guidelines or question telling you what to focus one. This can be used as a great indicator on what the company values are and whether or not you really want to work there. Additionally this will give you something to talk about on the interview.

Speed

Speed of replying, setting up meetings, how far the meetings are in the future, how fast they reply if you follow up with questions, etc. As everything else, this is valid for both the employer and the candidate.
As a candidate I typically avoid companies that are taking a couple of weeks to get back to you and are setting up your first interview or even the follow ups several weeks in the future. If they do that you can typically expect a higher amount of bureaucracy involved not just in the hiring process.
If a candidate takes so long to respond and set up an interview, they are most likely not that interested in working for/with you.

Testing (Pre-Interview)

If you are using coderbyte, toggle hire, hacker rank, etc., try to tailor the coding exercises and questions to your actual needs. For instance, asking what the "S" in the SOLID principles stands for or is 0.1 + 0.2 equals 0.3 in JS isn't really an accurate representation on the candidate's knowledge. The coding questions are finite and after a while people start getting use to them.
Alternatively you could set up a barebone repo and give people a task to complete something with it and then run automated tests against it (typical for clevertech) This was you can learn a bit more about the candidate's skills.
It all depends on how much you want to filter developers before talking to them. You'd be surprised how useful a simple writing exercise to write a function that finds if two strings are anagram can show you about a person. People almost always try to overthink and over complicate it.

Interview

Questions

In general open ended questions are better. They require a bit more thought before answering and are closer representation to actual human communication.
Examples for interviewers - tell me a bit about yourself (it is interesting what the candidate will focus on), what would you do in situation X, how would you react to Y, What do you thing about Z, how much supervision do they expect, etc.
Examples for candidate - what is a typical day at Company X looks like, what is your approach on Y, how do you handle Z, how are you financed, client revenue or investors fund, how many people have you highered (to see if they are overreaching, because they have received financing or they actually need people), how many people are working on something, how hands on are they, ask them about their technology stack (even though it is already listed) follow up on why they picked the technologies they did, how did that work out for them, etc.
Asking question as a candidate means that you care about where you are working and is not just about the paycheck.
The questions you ask tell the other as much about you, as you'll learn by the answers.

Do some research

As an interviewer you can check the candidate's previous companies and especially their side projects and ask them about it. People love being asked about their passion projects.
As a candidate, try to learn as much as possible about the company before the interview. You'd be surprised how much a well timed question about the billing system they are using or something else that you noticed on their product will make you stand out of the crowd. If you are applying for a startup, you even have pretty good chances to ask the person that had actually develop the thing you are curious about.
In both cases it shows that you did some preparation before hand and makes (or it seems to make) you more caring and interested.

Bad phrases

As a candidate be wary of interviewers (especially on a higher level) that use "I" too much. For example - I pay well, I pay on time, I've highered X amount of people, I've interviewed. It speaks volumes for that person ego. Some adjustments for non-native English speakers are needed of course, but you can understand if it is a mistake or intentional based on the tone of voice, speaking patterns and general context.
As a candidate you can do that as well. Some applicants love to use "I". Usually, no matter how much of a superstar someone is, they didn't work completely alone. Using a dash of modesty when giving the overview of what you've done, by using "WE" or something similar and then filling up your specific role by another means, either in the follow up questions or something similar can do wonders.
In general "WE" as a company, or a team, etc. are great or terrible. Individualism, especially in the leadership positions isn't good.

Live Coding (optional)

Not every company has it.
If you have it, as a company, try to use tasks that have more than one right solution and that are not usually used in online tests, articles, etc. This will help you reduce the chance that the person would have already done something similar. After a while (20-50-100 interviews) you'll start associating the chosen direction of the solution with other personality aspects. Additionally, try to keep it short and sweet. If you plan to interview someone and set up 1-1.5 hours of live coding and this is after work hours, that person can perform a bit worse on the questions after, simply because they are exhausted.
If you do it, as a candidate, try to explain what you are doing it to some extent. It will speak to your thought process. Especially if you hit a snag at some point of doing it. Don't worry, live coding reduces everybody's skills. Even if they are not being interviews, but are just working with a colleague.

Subsequent interviews

Take home coding task (optional)

Not every company has it.
If you have it as a company try to incorporate some open ended questions in it. If you want to be sneaky you could always try to make it a bit vague and see how many people will ask you questions and try to clarify it and/or how they'll interpret it. After all, this will happen sooner or later during the time they work with you. Either way, try to keep it short and sweet here as well. Chances are your candidates are working somewhere at the time and everything longer than one or two hours would make it difficult for them to find time for.
As a candidate - try to do it in a repository, even if it is not required, try to make some github issues for it (if you are using github), do make multiple commits (it will help show your work process) and definitely do it as soon as possible after the interview that "assigned" it to you. This way your next interviewer will have plenty of time to go through it and you'll have a linchpin for the next interview.

Avoid repetition

As a company - try to streamline your interview process. Let the people that interview candidates sync between them what each of them will tell and ask them. When you get the same story told two or three times by an engineer, CTO and the CEO or get asked the same few questions by all of them, it makes you question the planning abilities of those people. It is super a super easy pitfall to avoid, by sending an email with your feedback to everyone else in the process for that candidate with your feedback and then just replying to it. This way you have all of your information in the same place. As a candidate - try not to say the same thing that is on your CV. They have already read it. If you do talk about the same things, tell them in a different light. Depending on the questions they have asked you, try to talk about the things that the company will need. They have problems with X and Y? Great! Talk about how you solved something similar before, and of course, try not to make it too obvious what you are doing.

The payment expectation question

I've been working remotely for ~3 years now. I hate that question! Most of the time I am based in Sofia, Bulgaria. You'd be surprised how much the IT sector is driving the average salary for the country upwards. I get that companies are trying to save as much as possible and are trying to pay the salary of a region + X, but often times, devs don't know the average salary for their own region. This calculation becomes even messier, when you take into account that when you are working remotely, usually you'll have to pay your own taxes, social security, etc.
My typical dodge of this is to find out if they have other people at the same position. Be it FE, BE, leads, product owners, doesn't really matter. Then explain that it depends on the workload, the company, etc, and you'd prefer for the company to make you an offer. Many companies would be OK with that. If they are not, you could ask them to just average out the salary for your position and make you an offer. Most of the companies would be OK with that. If they are not, don't give them your direct expectation, but a ballpark. Otherwise if you ask too much, they can just stop the interview process and if you ask too little, you may be unhappy.
Most decent companies will raise your salary to the average level if you ask for too little anyway, so there isn't anything to be afraid of.
Keep in mind that this will usually take some back and forth for all sides to agree. Even if it is several sentences in the span of 5-10 minutes. Don't be afraid to discuss it and to hear "no". Things are rarely given when you don't ask for them.

These are just my two cents on the topic. Take them with a grain of salt. I would love to hear what you have come across and what good or bad sings you have noticed in your career.