Click here to Skip to main content
15,666,726 members
Articles / Programming Languages / C#
Posted 11 Jan 2020

Tagged as


2 bookmarked

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

Rate me:
Please Sign up or sign in to vote.
5.00/5 (3 votes)
11 Jan 2020CPOL6 min read
Advice for suitable type of technical question to ask in an interview

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.


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.


  • 12th January, 2020: Initial version


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Software Developer (Senior)
Singapore Singapore
Shao Voon is from Singapore. His interest lies primarily in computer graphics, software optimization, concurrency, security, and Agile methodologies. His hobby is writing a free C++/DirectX photo slideshow application which can be viewed here.

Comments and Discussions

QuestionNever bothered with heavy technical questions... Pin
Steve Naidamast13-Jan-20 7:14
professionalSteve Naidamast13-Jan-20 7:14 
Before I retired from my last position in 2014, I had done quite a bit of interviewing of technical candidates over the years.

My success rate, at least of the results I was aware of since I also performed interviews for managers outside my own department, was 100%.

This was because I never concentrated of technical questions solely as I was more interested in the overall person I was interviewing than just their skill sets.

As a result, I devised a technical examination that was divided into two sections; the first was what I expected any applicant to know for the level of position they were applying for with a second section, devoted to more difficult questions that I was looking for how a person answered and not if they got all of the answers correct. If they attempted to answer a question confidently though admitting to a lack of knowledge, that often counted for more than one who could simply knock out the questions with ease.

The second section told me if the candidate could learn what he or she didn't know if they failed to provide a completely correct answer.

However, after the technical questioning, I got to the meat of the interview where I asked the candidate about their interests in computer technologies and what they had been doing on their own to promote their own skills. This often demonstrated a person's interest in pursuing difficult issues and of developing their own projects on their own. In both cases, the applicant was demonstrating their actual interest in doing the job they were being interviewed for.

The result of all my interviewing experiences have shown me that those who give these heavy duty technical interviews in the business realm of application development have no idea what they are doing. Such interviewers have little grasp of the job at hand and often exist in cultures where a professional is often ripped to pieces from crushing deadlines and other constraints.

Now of course there are situations where such styles of interviewing are warranted such as positions with a hospital IT organization in which the applicant may have to work with systems that monitor life and death processes. However, in such instances, technical interviews are more often than not highly focused as they should be.

However, in the business realm of application development there is very little in the way of actual necessity to get it right every time thus allowing for a flexibility when interviewing applicants. What one should be looking for are good, honorable people who have an interest in performing their jobs well and what they do not know they will be able to learn on their own.
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.