Shh...Your Interviewer Didn't Have the Answers to his Technical Questions!

Write Code to Sum Up From 1 to 100

One has to be especially careful when the question is deceptively simple, for instance, sum up all the numbers from 1 to 100. A simple summing loop wouldn't suffice to satisfy your interviewer. He is looking for you to give answer of O(1) time complexity. Of course, I gave the same answer as then eight year old Carl Friedrich Gauss, the math child prodigy.

The story has it that Carl Gauss's teacher is trying to take a rest from teaching, so he gave his class a problem of adding all the integers from 1 to 100. But Gauss spotted a pattern of adding the beginning and ending numbers giving an average of 50 that enables him to come up with a formula to calculate it.

  1 + 99 = 100, avg = 100/2 = 50
  2 + 98 = 100, avg = 100/2 = 50
  3 + 97 = 100, avg = 100/2 = 50
  .
  .
  .
 47 + 53 = 100, avg = 100/2 = 50
 48 + 52 = 100, avg = 100/2 = 50
 49 + 51 = 100, avg = 100/2 = 50

As it turns out, Singapore education system teaches elementary school pupils this Gauss trick.

I want to ask readers a question: Does it mean every Singaporean, including me, who's been through the Singapore education, is as talented as Gauss? The bigger question is whether the interviewer came up with the answer independently or he has read it somewhere on the web? It wouldn't be fair to ask a question that you yourself are not capable of answering.

Surely, knowing the answer because you just learnt of it from another person does not legitimately make you an expert. However, in fact, not a small number of interviewers actually believe if you give the Gauss answer or make use of exclusive OR to swap two integers, your programming skills must be at an amazing level. This is absolutely absurd at an extraordinary level!

Swap 2 Integers Without a Temporary Variable

A common interview question is where job candidates are asked to swap 2 integers without third variable.

X := X XOR Y
Y := Y XOR X
X := X XOR Y

If you do swapping via a temporary variable and examine the assembly instructions at Godbolt Compiler Explorer, you notice that the compiler does not optimize the code to XOR swapping because for XOR swapping to work, there has to be a check that ensures the 2 variables are not the same and that check makes the execution slower than the third variable swapping method. And XOR swapping is strictly for integers and nothing else: it cannot be used to swap pointers. It is not unreasonable to expect the questioner to well-research the usefulness of question/answer beforehand.

Write Code to Perform Addition Without Using the Plus Operator

Even an electronics graduate like me would be hard-pressed to recall the full-adder circuit and convert that circuit into code on the spot to answer this question. This question and the Lee algorithm are Google interview questions from the electronics domain.

Only those micromouse team members are well-acquainted with Lee algorithm because micromouse used it for maze-solving. Lee algorithm is a very simple algorithm where the robot travels from a higher value cell to a lower value cell. Each cell value is determined from the minimum value of the 4 neighboring cells and increment that value by one. Lee algorithm is the most simple algorithm I have known in my life but even that has its own intricacies only an implementer would know. In my honest opinion, narrow electronics-related questions should be avoided unless the organisation is within that industry.

To digress a little bit, for those readers who are interested in Lee algorithm, read my article!

Embedded System Interview Question: Bubble Sort

If a job candidate is applying for an embedded system position in Singapore, more likely than not, he is asked to write a bubble sort function without pseudo code or instructions! I was admittedly stumped by this question. Why bubble sort, the slowest type? Why not insertion sort or other efficient sort algorithm like merge sort? Sometimes, this is the only interview question on the test. I asked my tester how many people managed to answer that correctly. He said almost all, matter-of-factly. Obviously, every job applicant in the embedded sector, memorises bubble sort by heart. Just like some programmers memorise XOR swap for interviews.

Admittedly, I was not familiar with what embedded system programming job and responsibility entails, this could be the only feasible sort algorithm on bare metal system where every piece of memory has to be pre-allocated and the number of stored items to be sorted remains small. So it could be a legitimate question for an embedded programmer.

Many hiring managers graduated school decades ago and have not keep abreast with the latest developments in software development. In my opinion, coding test should be restricted to test the problem solving skills, not involving rote memorization of information that can be easily Googled or syntax errors that can be caught by compilers.

What Is a Good Example of a Short Question to Ask?

After giving so many bad examples of questions to ask, then what about an example of a good one? My opinion is to ask a question with a short answer to test the problem solving skills on the spot. Avoid the questions found in the interview books as the candidate could have read the answers in the book unless he gave a different but correct answer.

This is my example of a good question. Write a custom add function to detect an overflow and throws OverflowException upon detecting it, without using the checked keyword.

uint add(uint a, uint b)
{
	const uint max_uint = 0xFFFFFFFF;
	if(b > (max_uint - a))
	    throw new OverflowException();
	return a + b;
}

This detection can be achieved in assembly code by doing the add operation and then checking the Carry Flag for unsigned arithmetic or Overflow Flag for signed arithmetic in the FLAGS register afterwards.

Another approach is to ask the candidate if he know the concept and tell him to explain the concept. Don't be surprised: many programmers with years of experience under their belt didn't understand deadlock or know protected accessibility.

Recap

Before the end of the article, let us do a recap of the dos and don'ts in the interview advice mentioned above.

• Avoid asking very difficult questions that the technical interviewer is incapable of deriving an answer by himself and the possibility of candidate knowing the answer like the interviewer beforehand is high.
• Research the question/answer deeply before the interview.
• Avoid narrow electronics-related question unless the organisation is within that industry.
• The question should test problem solving skills of the candidate.
• Answer to question should not involve rote memorization of easily Googled information or syntax errors that can be caught by compilers.
• Avoid the questions found in the interview books as the candidate could have read the answers in the book.
• Ask candidate if he know the concept and explain the concept to see how well he understands it.

History

• 12^th January, 2020: Initial version