Reviewing Bad Schematics as EE Interview Tactic

It was code deliberately filled with various errors, from JavaDoc with @param names not matching argument names, to generic issues, to more subtle issues. One of the last ones involved threading and concurrent access. It also had a test suite to help candidates gauge their progress for programmatic issues, not so helpful for code style issues (that JavaDoc comment).

Basically, we wanted to see the dev a) look at the reds and yellows in their IDE, b) run the tests, and then c) prioritise the issues. And d) say "these tests are wrong"

It was a highly effective filter for people with "qualifications" from dubious private training institutes (one candidate fixated on the red Javadoc for a mismatched parameter name, we hinted that he check the arguments in the method, he muttered "method, method, method..." to himself while scrolling down the code looking for the actual word 'method' - spoiler, he didn't find it, and he didn't get the job), but we left it behind when we found it was causing candidates genuine anxiety when they couldn't get all the tests to pass - which was intentional - anyone who figured out that the tests were deliberately wrong was an instant hire.

But we felt it was unfair, it's very very hard in a job interview to say "hey, I think your tests are wrong" so we dropped it.

These days, we use a simple filter - write code in your preferred language to find the element in the list that only has one occurrence. It's surprisingly effective as a first pass. People with years of Scala on their resume from writing Spark jobs, who choose Scala, but who can't quite get the hang of how you define an array of X in Scala... when you find yourself telling them to use square brackets for generics instead of angle brackets, you learn a lot about their actual capabilities vs. their projected.

While its interesting to see what vector their over-thinking takes, it doesn't help move the interview along.

Doing similar examples with code is also good, as debugging is probably a big chunk of the time people will spend on things. And there are various shades of bug from "in your face" like you have an if statement in C or C++ that uses only one = sign, to "subtle" where a local definition masks a global variable, to just plain ridiculous like structure packing alignment issues based on compiler options.

All good ways to see how much of the 'craft' the candidate knows versus the 'facts'.

However, you’re often working in groups, so it’s not uncommon for one person to really “get it” while the other members of the group nod along but don’t fully understand the choices being made. In addition, TAs in the lab probably don’t have industry experience, so there are basic practical circuit design practices that aren’t taught or enforced.

Labs are a good way to get initial experience, but I think there’s a lot that you inevitably have to learn on the job. There’s a reason you can’t earn a license as a Professional Engineer until you have 4 years of work experience.