Hypothetical interview question: push bytes at a LCD

Hypothetical interview question: push bytes at a LCD

I like the notion of coming up with interview questions based on real problems which have happened recently. One time when I was asked to write a fresh set of questions (and answers, unfortunately) for other people to use, they all came from recent support tickets. A lot of those questions were random trivia, but there are other things which can be genuinely interesting.

This one is based on a question someone asked me a couple of years ago. He was trying to get a LCD going on an embedded device. It had its own little C environment and a couple of custom functions to push data out to the display. That inspired a question I might use some day.

We have a LCD connected to a serial port. We have a helper function called printchar() which will shift characters onto the right side and which scrolls everything else to the left. The leftmost character disappears. It takes an unsigned char as an argument.

It uses ordinary ASCII for its character set, so if you pass it an argument which is equal to 65 (decimal), it'll add an A to the display.

Given this, write a function which will print your name on the display. Assume the display is 16 characters wide. Feel free to use something else if your name won't fit.

Now write a function which will generate a (hopefully) random number between 0 and 4294967295 and then print that number on the display.

The idea is to have something which sounds relatively simple but will ramp up in complexity as the candidate works through it. Right away, it should detect whether a function call is a foreign concept. This might be the case if someone is just trying to bluff their way through a programming interview.

Next, there's the notion of ASCII, and the general concept of numbers mapping to a single character and vice-versa. This is something you probably take for granted if you're a technical type. While I don't expect most people to remember the starting positions of a few meaningful groups (48, 65, 97), finding out that someone knows them would also be a useful signal.

With this in place as a foundation, now it's time to think about multiple calls to that function. Do they just line up a bunch of printchar() calls with one for each letter in their name, or do they write a for loop? Do they keep it all in one function or do they write a printline() and then call that with their name?

I would hope that more experienced candidates would raise a flag about how not all names can be expressed in ordinary ASCII. That would open the door to a lovely conversation about alternate character sets and methods of encoding, plus how you might deal with the limitations of the hardware display.

After that, it would be great if the candidate said something about the nature of pseudorandom number generation and what could be done to make it better. For that matter, it might also be nice if they asked whether I really cared about "good" random numbers or whether a rough approximation would work. Sometimes, that's all you really need.

Once they have a number, then they have to figure out how to get it to the display. With the name situation, it was just a matter of sending the characters in the same order that an incrementing for loop would encounter them. With a pure number, you can't do that. One approach would be to build a string with that value and then use the earlier printline() technique.

I'd accept that as a first cut and then would ask if there was a way to do it without turning the numeric value into a string first. It might take a while but I'd hope they'd come up with something. Even if it doesn't hit them during the interview, it might be one of those things which pops loose in the middle of the night or many days later. Then they'd think "aha! modulo!" or "recursion!" or something like that.

An interview is a test, but if it's done properly it can also be a learning experience for both parties.