You're going to get a lot of advice, but some general comments for your consideration. As always, your mileage may vary.
> failed a number of technical interviews because I can't make architecture diagrams
I would caution against correlating interview failure to a lack of diagramming skill. Diagramming is a teachable skill; how to formulate architecture is much more complicated. If I am considering hiring someone who I see can design strong architectures but couldn't represent that in a diagram, I'm probably not dismissing them because of their drawing skills. But that's only when I believe they can design an intended architecture.
> I can't for the life of me draw the architecture of anything
I had an engineer on one of my teams who had the same problem. With him, he understood some things but in other aspects he was more murky. So, I asked him to start by writing down the architecture. Literally, write words and sentences that describe the collective of systems, i.e. Service "A" is a REST API, and it connects to Database "B"; a client connects to Service "A" over HTTPS, etc. etc. I don't know if this would help, but if you can do that, you can start to translate the words to pictures.
> I don't know how people learn to do that
By doing. I don't know anyone who has ever been trained to create an architecture diagram that knew what they were talking about. Just start small, and then ask someone to describe it back to you. When you begin to hear what you consider to be correct, you'll know you're making progress.
> I've never used diagrams in my day-to-day work
This tells me a couple of potential things: you're possibly not working in complex or large systems, or maybe are not responsible for communicating those systems to others. "Complex" is a relative term, so interpret that as you may. Ultimately, arch diagrams serve as a way to visualize complexity with the goal of letting others understand.
> failed a number of technical interviews because I can't make architecture diagrams
I would caution against correlating interview failure to a lack of diagramming skill. Diagramming is a teachable skill; how to formulate architecture is much more complicated. If I am considering hiring someone who I see can design strong architectures but couldn't represent that in a diagram, I'm probably not dismissing them because of their drawing skills. But that's only when I believe they can design an intended architecture.
> I can't for the life of me draw the architecture of anything
I had an engineer on one of my teams who had the same problem. With him, he understood some things but in other aspects he was more murky. So, I asked him to start by writing down the architecture. Literally, write words and sentences that describe the collective of systems, i.e. Service "A" is a REST API, and it connects to Database "B"; a client connects to Service "A" over HTTPS, etc. etc. I don't know if this would help, but if you can do that, you can start to translate the words to pictures.
> I don't know how people learn to do that
By doing. I don't know anyone who has ever been trained to create an architecture diagram that knew what they were talking about. Just start small, and then ask someone to describe it back to you. When you begin to hear what you consider to be correct, you'll know you're making progress.
> I've never used diagrams in my day-to-day work
This tells me a couple of potential things: you're possibly not working in complex or large systems, or maybe are not responsible for communicating those systems to others. "Complex" is a relative term, so interpret that as you may. Ultimately, arch diagrams serve as a way to visualize complexity with the goal of letting others understand.