Maybe the difference is that I do a lot of hiring of junior frontend devs. I interview people that never developed before and now took a 3 month bootcamp for example.
The things they can tell me is basically their curriculum. What I found was working the best was showing them code and they they explain to me what's happening, and I ask some practical questions on that code ("what would happen if I change this?", etc)
I moved from your kind of inteview to a more technical "explain this piece of code to me, what would it do?".
But it's possible the kind of developers I see have different experience level than the ones you see.
I also still interview seniors (maybe 1 out of 10). Maybe I have to think about changing their interview a bit.
The thing is with frontend, you can get a senior that basically did mostly html and never serious programming. And so if you build a complex web app, you really need to see how far they can go with their development skills.
I can't address most of your reply without sounding like an evil gatekeeper, but yes - it's safe to say that when I'm hiring, I'm interviewing the people our team needs to rely on today, not someone who might grow into the role after the company fails.
To be honest, it's super frustrating that we can't have that conversation without an army of bootcamp grads accusing us of elitism. Only a decade ago, it wasn't controversial to expect that people applying for highly demanding technical positions were ready to start on Monday.
I digress.
As to the senior HTML artist... I feel like that's on you to suss out in the conversation. Another one of my elitist views is that someone who can only do HTML - literally, text markup - is not a senior talent.
If you want to make sure that a candidate understands how an MVC framework works, ask them to talk about their thoughts on service objects, or when they use Redis vs Postgres, or whether they have used Sidekiq jobs to do cool things. You can interrogate them to a wild degree and check off all of your boxes while making it feel like you're just shooting the shit.
It's almost impossible to bullshit your way through explaining how you implemented a key-based authentication mechanism over websockets. Writing out the code on a board accomplishes nothing. I know how it's done, and I'll know in 15 seconds if a person shuts down, terrified, when talking about it.
The things they can tell me is basically their curriculum. What I found was working the best was showing them code and they they explain to me what's happening, and I ask some practical questions on that code ("what would happen if I change this?", etc)
I moved from your kind of inteview to a more technical "explain this piece of code to me, what would it do?".
But it's possible the kind of developers I see have different experience level than the ones you see.
I also still interview seniors (maybe 1 out of 10). Maybe I have to think about changing their interview a bit.
The thing is with frontend, you can get a senior that basically did mostly html and never serious programming. And so if you build a complex web app, you really need to see how far they can go with their development skills.