Ironically enough, a lot of the people I've cut in the interview process seemed like working their way through Vivado, Lattice, etc. wizards was the only development they had ever done. They could get an env setup, but would be completely lost outside of a trivial hello world style project.
Yeah, we had several interview questions specifically to weed those out too. A favorite was, "How would you design a multiplier, without a wizard/Coregen?"
They didn't have to hit everything, but a couple of general multiplier design points - throughout and area? A MAC, or a straight multiplier? Shift add? Do they know enough to try to hit a certain primitive (DSP48E, fast carry chains?).
The wizard-only designers frequently couldn't even understand the question, and were incapable of discussing tradeoffs of area/time/resources.
We use an internship program - the best indicators seem to be a lot of undergrad courses in digital design (like 4 or 5 of them), the ability to talk about a project you did that used digital design and what your process was and what you learned, and then some small coding or design problem everyone should have seen. "Build a block that outputs a 1 when it sees the pattern 1100100" - you should know what a finite state machine is, combinatorial logic is, denouncing switches (not because it's hard, but because it means you've been in a lab!), etc, and if you're from a good program you should have at least heard of some of the more fundamental elements behind synthesis, place and route, timing; you should know what a UART or SPI is, and have implemented it at least once.
What I try to do is give candidates a bit of a hand - don't remember UART? What about SPI or I2C? Don't remember either? Ok, how would you design a communication block that looks like this (SPI).
I ask fundamental questions- what's synthesis? What's place and route? Explain timing to me. What underlies the logic minimization at the heart of FPGAs? There are a lot of questions to ask - I try to keep moving if a candidate gets nervous so that I can focus in on something that they can answer. For a lot of young people, especially tech types, if you can get them "on a roll" with something they did or were excited by, their anxiety will drop away and they'll do better. Generally we want to see what you know, but also how you think.
For more senior candidates, I take a similar approach - but I'm trying to identify weaknesses. So instead of a glide path to another problem, I'll use your answer to identify a weakness. Gave a marginal answer about something? Ok, let's see how they handle a hypothetical about pipelining, clock domain crossings, timing violations, block level design, proper reset usage, etc. We have a few questions about math implementations, timing violations, etc that are in our stable as well that have proven to be real destroyers.
There is a fundamental understanding about space, memory, and time that a good candidate will be able to grapple with that a marginal one won't - "Design two versions of this block - a small one, and a higher performance one, in broad strokes. Discuss the difference between them". - Area, throughout, latency.
Also: Show up on time. Do your best. Stay positive. Admit what you don't know. Ask questions when you're stuck. Try to learn something while you're there.
If you can find someone in the industry that is willing to do interview prep with you, do it. When I just got started, somebody sat with me and did mock interviews. It helped me a lot, so I try to pay it forward by doing that for my interns to help them get into the industry.
It's a great time to be in the game. Learn all you can, develop your passion for it, and you'll do great.
