> Spot the bugs in this printed out code? Find everything wrong with this schematic in 5 minutes.
I don't consider those terribly unfair. Depending upon how the discussion goes, I could see myself doing something like this.
For example, one of my standard questions for firmware people is a state machine in Verilog (for those who claim to know Verilog). What I'm looking for is whether you know the difference between blocking and non-blocking assignment.
> Take home coding challenge -> take home hw design challenge where they expect you to have access to expensive software.
> I have a dozen more questions to get through.
These are not fine, though.
> The interviewer was completely wrong
This, sadly, happens. I have had an interviewer cite incorrect information about semiconductor device physics.
Quite often, though, it happens in more junior interviewers with "standard" questions that are passed around because the interviewer doesn't fully grasp the question. When I was a junior engineer, I was always terrified that I would make that screwup. I used to do review study on my own questions and area before every interview to make sure that didn't happen.
For example, I had an interviewer who gave me a question of "clock a binary number in serially and use a state machine to divide it by 3." It's a really cool question and was passed around between engineers of a certain company. But ...
This is either a really easy question or a really hard question depending upon your choice of direction to clock the number in. If you pick the easy way, it's something like 3 states and it's obvious. If you pick the hard way, it's 6 states and takes a somewhat subtle inductive proof to show that you're right. If the interviewer doesn't know that this can happen, he can't dig the candidate out if they pick the hard direction.
Of course, you know which direction I picked in the interview. LOL.
I have no problem with spotting schematic issues (or spotting code issues) given appropriate time to do it. I actually prefer these to rushed questions where you have to implement the solution because it lets me get into the design considerations without spending time drawing symbols or stumbling through syntax.
Last time I got that question it was a schematic large enough that I would have put it on multiple pages and I only had a few minutes to get through it, which was a problem. Brought it up because it seems to be a touch point for others.
I don't consider those terribly unfair. Depending upon how the discussion goes, I could see myself doing something like this.
For example, one of my standard questions for firmware people is a state machine in Verilog (for those who claim to know Verilog). What I'm looking for is whether you know the difference between blocking and non-blocking assignment.
> Take home coding challenge -> take home hw design challenge where they expect you to have access to expensive software.
> I have a dozen more questions to get through.
These are not fine, though.
> The interviewer was completely wrong
This, sadly, happens. I have had an interviewer cite incorrect information about semiconductor device physics.
Quite often, though, it happens in more junior interviewers with "standard" questions that are passed around because the interviewer doesn't fully grasp the question. When I was a junior engineer, I was always terrified that I would make that screwup. I used to do review study on my own questions and area before every interview to make sure that didn't happen.
For example, I had an interviewer who gave me a question of "clock a binary number in serially and use a state machine to divide it by 3." It's a really cool question and was passed around between engineers of a certain company. But ...
This is either a really easy question or a really hard question depending upon your choice of direction to clock the number in. If you pick the easy way, it's something like 3 states and it's obvious. If you pick the hard way, it's 6 states and takes a somewhat subtle inductive proof to show that you're right. If the interviewer doesn't know that this can happen, he can't dig the candidate out if they pick the hard direction.
Of course, you know which direction I picked in the interview. LOL.