Companies already look at resumes, and the interview is a good way to double check things in a pass/fail manner. It's not like the SAT where you take a single test that sorta determines where you go, but even that is useful as a broad measure. Like if I'm in a top school's admissions and see 1800/2400 (idk the new scoring), there'd better be an explanation. If Amazon saw my resume and I couldn't explain to them generally how I'd architect the backend for their lockers, something would be wrong. And sometimes something is wrong; I interview someone who clearly doesn't know how to code and must've lied on the resume. I don't know how else you're supposed to do it.
At the higher levels, they're also testing for humility.
These interviews are not gutchecks. They are shibboleth checks.
I can design you a nice document, do the research, put the pieces together, etc with the big picture. I may not know a ton about AWS or another cloud provider but I can put the document together that describes how it will be looking when it's done. That is architecture. Somewhere between UML and word documents.
What these interviews are checking, and the one you are describing, is whether or not I can parrot the correct code-words. Lambda, elastic cache, all this other nonsense. That's the purpose of the bloodsuckers I mentioned above. If you can train someone with little architecture experience to pass a senior level interview by just saying the right things and knowing the right hype tech then you're not hiring architects you're hiring grifters.
It's a problem that is endemic in this industry. You can't "gut check" 30 years of architectural experience unless you're legitimately asking the core questions of architecture. Every interview I've been in has had me studying stupid buzzwords from cloud technology and every interview I am asked how to use these technologies. As an example, I was once turned down because I didn't use Kafka. I knew what the underlying technology was and suggested using it but the fact I didn't say kafka eliminated me. The reason? I can only guess, but it's likely because the interviewer doesnt know much and was looking for a way to get into a debate over kafka vs protobuf vs whatever instead of discussing actual planning of a system. These debates are resolved after I take the problem back to my desk and think about it for a week. Not in an hour. In an hour the best I can give you is a block diagram with maybe some very rough fleshed out detail.
The humility check should be bi-directional. It has been my experience that interviewers tend to be the least humble people at a company. The power dynamic is obvious and it's not in the character at most startups where a "senior" engineer high on hopium can settle themselves into their rightful place.
> I may not know a ton about AWS or another cloud provider but I can put the document together that describes how it will be looking when it's done. That is architecture. Somewhere between UML and word documents.
> What these interviews are checking, and the one you are describing, is whether or not I can parrot the correct code-words. Lambda, elastic cache, all this other nonsense.
Maybe we've just had very different architecture interviews. All the ones I've given or received were the way you'd want. I've never specified a cloud product in these. At most might say "let's use something like Postgres." Amazon for instance didn't care that I couldn't name any of their products.
Kafka example sounds awful. I'm sorry, but on the other hand, sounds like you dodged a bullet.
At the higher levels, they're also testing for humility.