Status: 30 years experience, BS E&AS/Bi, Top 20 engineering school, worked at Google and JPL
Position: Senior SWE at any of Amazon or 4 local startups
Location: Los Angeles
Date: July 2020

I was laid off from a startup during (and partly because of) the coronavirus slowdown.
After taking a few weeks to relax, and another month or so to contribute to
open source projects, I posted my resume on Linkedin and started looking
at local opportunities. There were two kinds:

1. smaller companies where at least a couple engineers had heard of me (I've been around a bit)
2. big companies who didn't know me from Adam

My experience is mostly in C/linux/unix, with a lot of classic C++ and a few years of Java/python/ruby/shell/windows/mac/gdb/strace/embedded systems/automake/cmake/meson/etc.
My goal was to get a C++ or Golang senior SWE job, ideally doing new
designs at least part of the time rather than maintaining old stuff.

I'd never really embraced STL, so about a month before interviewing I read "Effective STL" and
did 70 or so leetcode problems simply as a way of reviewing STL and the lowest
hanging fruit in C++11/14. This went swimmingly.
Also, one local opportunity mentioned Golang, so I read the first half of
"The Go Programming Language", and did 20 or so leetcode problems in Go
(some I'd already solved in C++). (Golang is a joy so far, it's like C, C++, D, and Java
smashed together with all the ugly and excess bits removed, plus a modern-ish ecosystem.)
I also did a few problems in Java and enjoyed the "new" features like generics,
but decided that refreshing three languages at once was a bridge too far.

My resume was pretty good, and I was able to get an interview at five places without much trouble. My general takeaway was:

• leetcode is in fact a great place to simply brush up on your target language(s)
• it's also a good way to get in the swing of solving programming puzzles on deadline
• the exact problems you choose don't matter that much
• Amazon's initial programming evaluation will ask you about the computational complexity of your solutions, and golly, if you used six things from STL, you probably need to know for each one whether they're linear, log n, or n log n. Guessing a little is ok if you have a good feel.
• The email from Amazon comes with a link to a practice session. Use it, preferably several days before the interview, so you get a chance to get used to the format.
• The online coding environment for Amazon does not show you all the test vectors you failed, so you'd better be sharp... and/or figure out a way to jam your own test vectors in. That's something you can practice at leetcode.
• Interviewing in a language you just learned is a dumb idea :-) unless you're really sure they want it, and you're lucky.
• You'll have lots of conversations with engineers about interesting stuff you've done in the past
• You'll have a few conversations about how you'd design X, and at least at the non-Amazon places, the goal is for you to extract the real requirements and come up with an English description of a couple key parts of the design in a way that shows you can communicate well, and you understand how to do real systems at a high level (including little details like how long you'd keep data, what basic technique you'd use for moving it from point A to point B reliably, how you'd test).
• If you've been reading domain relevant sources ( e.g. lwn.net ) regularly, you may find some tidbits you've gleaned from them handy during those open-ended conversations.

I ended up getting very serious interest from two smaller local companies, one of whom surprised me with an offer before I had even scheduled the Amazon "onsite".

All in all, it was a very pleasant experience. I thank my lucky stars. I just accepted the offer, and am still pinching myself... hopefully I'm not jinxing it by posting before I actuall start :-)