Can you elaborate on your eighth point?

Yes and sorry for the delay. A common issue/complaint I see with fellow programmers is they feel like they haven't actually made something on their own. Perhaps they've only followed tutorials, implemented random features in their day job, or perhaps they actually have written something kind of cool but it is sitting unused by anyone in a github or hard drive somewhere.

This often translates to anxiety once you get into an interview, because you are trying to answer behavioral/design/career questions based on some heuristic, some proxy, some guess at "what the interviewer wants to hear".

While some interviewers are indeed assholes who play weird games and don't operate anywhere near reality, the truth is, if you've written literally anything that people actually use even weekly to do something (e.g a blender add on that simplifies texture baking, a toy online chat room as a discord alternative, a wrapper for ffmpeg or etc to convert files to different formats, a simple time wasting game in threejs, etc), you will be astonishingly more confident in your answers, even if they don't work every time.

Why is that? Because, by actually writing software without a tutorial that is still good enough for someone to use, it guarantees you have solved some problem, without any help besides reference documentation, and have therefore wrestled with crucial design questions like "should i make this a vector or a scalar? do i need a map here? should i do this by naming convention? should this be done in a loop or should i make it a task for multiple threads?"

It doesn't mean you should like, focus on marketing or chasing hot problems, but definitely do this if you are feeling like you are faking some parts of your interview questions, which are so abstract, they can benefit from delivering a real world answer naturally and confidently.