Experienced Noobs

I was asked to help conduct a job-interview last week. The candidate claimed to have some direct experience in embedded software programming. Unfortunately, the candidate met me. I only focused on asking the candidate questions about things that the candidate had direct experience working in.

Firstly, the candidate claimed to have written software for a variety of processors – almost a dozen of them. However, what the candidate failed to mention was that they all belonged to the same architecture – ARM. This is a slight-of-hand trick. Unless the interviewer knew his stuff, he would not know the variety in the ARM eco-system. But this stretching of the truth is fine with me – because at least the candidate had some experience writing software for one of the world’s most popular processor.

However, what I could not forgive was that the candidate did not know the thing that sets the ARM7TDMI processor apart from its predecessors – the introduction of the Thumb instruction set. The candidate claimed to have worked closely with the ARM7TDMI. Since the candidate failed to know the architecture, this limits the ability of the candidate to do embedded software programming. In order to do embedded programming well, the programmer needs to know the quirks of the hardware architecture and exploit it to their advantage.

Secondly, the candidate claimed to have helped solve some problem with their current project, dealing with null pointers. So, I asked the candidate how they found out the problem was the problem. Turns out that the candidate used the technique that I dub – random bandaging – trying random things until something works and then claim that the problem is solved, without understanding the under-lying cause. That is a problem that I have with my apprentice as well, but it is fine because we can always ask for proof and train our staff to investigate things.

However, what I couldn’t forgive was that the candidate – when asked what a null pointer was – looked at us incredulously and claimed that a null pointer was a pointer to a random memory location! Sigh. I thought that the name of the pointer should be a dead give-away. If the candidate had mentioned that it was a pointer to the null or zero memory address, I would have given half a mark. If the candidate could tell me that it is architecture specific and is just defined as an invalid memory address location, I would have given full marks. But it most certainly does not point to a random location – and that is a failed understanding of what a pointer is.

Thirdly, I wanted to test that the candidate could actually write code and understand how the code works. So, I got the candidate to write a simple for-loop that counts from 0-99. Thankfully, the candidate got this right. Then, I asked the candidate what would happen if I compiled the code as it is. The candidate didn’t know what would happen – the code block would be optimised away by the compiler because it does not do anything. That was still fine. Then, I asked the candidate to output the numbers on screen. The candidate used printf to do it.

So, I asked the candidate when is printf not supposed to be used. Surprisingly, the candidate said that it should not be used in interrupt routines. I was seriously impressed! Then, I pressed the candidate for why it should not be used and the candidate said that it was slow. Again I was impressed! Finally, I asked the candidate to think of any reason – even one – why it was slow but the candidate could not think of even one. Then, the candidate confessed to have only read the information online and did not actually know the reason why. Fair enough.

To me, at the very least, the candidate had a bit of working knowledge but I would still classify the candidate as quite a noob when it comes to embedded programming. Experienced nonetheless though – but still a noob.

Let me add – knowing the right answers to the questions is easy. Knowing why is the difficult part.