I love that idea. I always try to be cognizant of the stress thing too. I cannot count the number of times I've given the candidate a problem based on some basic EE or CS concept, only to have them over-think the heck out of it because the answer seemed "too easy."
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'.
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'.