I want to give back to the community. I cannot share details of my questions due to an NDA, but here are some of my thoughts and general tips for those interviewing. All of these apply to both companies, with a small section at the bottom that's Amazon specific:

Process

• Recruiter Contact
• Recruiter Phone Screen
• Technical Phone Interview (OA for Amazon)
• OnSite Interview
• Team Matching

General Thoughts

• Make sure you're well rested, and bring a sleeping aid if you can stand them. Doesn't matter how much you prep, a bad night of sleep can ruin it.
• Take advantage of the "off-record" lunch to ask the touchy questions like work/life balance, support responsibilities, stress levels, etc.
• Make sure to smile and be friendly. Soft skills are underrated. Try to be confident, even though inside you're probably a mess of nerves.
• Be prepared with intelligent questions for them! Don't be the person at the end who's like "nah, no questions for you, bye!"

Technical Thoughts

• Talk out loud. This is at the top of the list for a reason. You've heard it already I'm sure, but seriously. Explain your thought process out loud.
• You need to know big O complexity, no way around it.
• Important concepts: dynamic programming, graph traversal, BSTs, and of course basic data structures.
• Know your language, and common APIs. If you forget during an interview, just be honest. There was one point I couldn't remember the API for StringBuilder and just said so. Mentioned I couldn't remember if there was a delete function and the contract, but just pretended there was and the interviewer was OK with that.
• Abstract simple functions and implement them later. For instance, if you need to do something like lookup a value from a hashset, do some math on it and then do something with the value, just on-the-fly stub out a method like retrieveValueAndCalculate(key). You can continue with the core algorithm and actually write out that implementation later. Or buy yourself more time and ask the interviewer "so this method is pretty simple, we just get the key and do X to it. Do you think it's worth writing the code for it?"

Tips for Coding

• Ask lots of questions, and present multiple solutions. My general flow was to first ask as many questions about size limits, overflow, input validation, etc. that I could think of. Next, start spitballing as many possible solutions as you can think of and their big O complexity and trade-offs. Don't spend more than 5 minutes on this, before settling on whatever you think is best. Favor better runtime over space. It doesn't hurt to ask the interviewer "hey, this one seems like a pretty decent solution, and I'd like to move forward with that unless you think there's something better I'm missing?"
• Next thing is just walk through the algorithm, writing steps down in short-form. For instance: step one, check if null and in right range. Step two, iterate through until N. Step three.....etc. I got direct, positive feedback for doing this, and it helps solidify the algorithm when it comes time to write the code.
• Next, write compilable code! Write small, and be thoughtful about your variable names. There won't be enough board space, and you will eat into your time if you name a variable "countOfTotalValues" or something and have to rewrite it multiple times.
• Once done, walk through some quick input if you have time and self-reflect. "So, given the input X, Y, Z, we'd do this and that and...yep, looks like the correct output. If this was production code, I'd want to write some tests for input A, B, C. I'd also probably extract this portion to a helper function to make it more readable, and this section might need a comment explaining it, since it's not really intuitive."
• If you have time, the interviewer will likely ask follow up questions and throw a few wrenches. In my experience, I didn't often have time to write code for these but just discuss the approach and how it might change.

Behavioral Tips

• Before coming in, self-reflect on some valuable experiences you've had for common questions. In my experience, this part was more relaxed and the interviewer was just curious about my experiences. Whatever you do, don't BS this part because they will dig in and ask specifics about your story. I was fortunate to be able to have stories for the questions asked, but I've heard a good tactic is "I can't think of a specific example, but if I was in that situation, I'd handle it like so...."

Amazon Specific Thoughts

• They really care about the leadership principles. I brought in an example or two for each principle, and even then I didn't feel prepared. While Google was 80% coding, 20% behavioral, Amazon was the opposite. Dan Croiter on YouTube was a good resource.
• The coding questions were a different beast. Google had more "we want to see your logic and thought process" type questions, Amazon had more "do you know this data structure" type questions. Trees and graphs were the main ones they asked.
• Amazon felt less "we want to see how you think" and more "we are looking for a specific solution" to me, as well. There was one case I had a solution that I thought would work, but the interviewer wasn't having it. They instead nudged me to a different solution, which had the same runtime complexity but I guess was just the specific one they wanted to hear.
• Amazon interviews were typically one or two behavioral questions, then the coding question. That meant there wasn't as much time for solutions. Be quick, come up with a solution and solve it. Still followed the process I outlined above, but streamlined it and hurried through it as best I could.
• Behavioral questions are in the same vein as the last point - try your best to read in between the lines because it felt less like they wanted to hear my experience and stories and more like they had some checklist of things they wanted me to say. Be honest with your replies, but also word them in a way that matches what you discern they're looking for.

Hope that helps someone, and good luck!