Software Engineering Interview Questions that Make an Impact

Published on: September 26, 2013

Compared to others, I haven’t had that many interviews: one for my freshman year internship, three sophomore year, and none in the foreseeable future, as I’ve accepted an offer to go back as an intern to Citadel, which I’ve written about a couple of times before. Despite the small number, I routinely find people entertained when I retell my interviews, so I decided to document them here, so that I don’t forget.

Before I go into my spiel, do a quick read of The Most Revealing Job Interview Question. I found it quite ingenious.

Questions

I have a program that crashes, what is wrong with it?

At first glance this program may seem nonsensical, but after an answer is given, the interviewer knows what the candidate has gone through and gets a more well rounded look at the candidate. Obviously, there isn’t a right or wrong answer. The goal of the question is for the candidate to list possibilities and then come up with solutions. Answers had to include actual experiences, one couldn’t rattle off bugs they’ve only heard about.

I scoffed at the question upon hearing it, but after realizing the interviewer was serious, my mind started racing through all C# exceptions. Odd because I was interviewing at Citadel, which is a C++ firm. Here are the things that I mentioned:

• Index out of range and buffer overflow when attempting to access elements outside of a range. I’ve written graphical libraries before and this is a major issue. Sometimes I don’t get the stride correct.
• Dereferencing a null pointer. Nothing needs to be said here.
• Out of memory error. Yup, while testing my graphical library I tried loading a decent sized image 10,000 times. Somebody (me) wasn’t deallocating memory properly.
• Stack overflow. Occurs when a stack allocated buffer exceeds the stack limit or when a function is called recursively but isn’t tail called optimized. When asked, I explained the optimization strategy and that gcc doesn’t do the optimization unless -O3 is supplied based on past experiences of toying with replacing all loops with recursion. He segued and asked what typically has a short stack. I guessed LISP. It was Linux. I blushed.
• Leap second bug. This piqued the interview’s curiosity and I had to explain how a bug would come up due to a leap second. It must have been obvious I didn’t know what I was talking about because then I was questioned about when this happened to me. I was caught in a lie. I recovered by saying it was an interesting topic. I blame Hacker News for posting an article that day on Leap seconds.

Does the stack grow up or down? Prove it.

This question demonstrates knowledge on the machine level, which leans more into the domain of the computer engineer; however, if a programmer doesn’t know how the underlying machine is structured, how can they write efficient code that takes advantage of the machine? Since the University of Michigan is a more infrastructure based programming college, I luckily knew the answer to the first part : down. Proving it is a bit harder, and I needed a hint from the interviewer.

The answer is simple. Create a function with a local variable. Print out the local variable’s address. Call the function recursively. With each call the local variable should have lower memory address than the one before it. This is most straightforward in C/C++. In some languages it might not even be possible to retrieve the address of a variable.

Have you contributed to open source?

Not at the time I hadn’t. I said I had released software as free, but none of it was open source nor had I contributed code to other projects. I then received a short lecture about contributing to open source demonstrates that one can read someone else’s code and add to it. Many times when handed a project that has seen its fair share of time (I’m refraining from calling it a legacy project as that has negative connotations), people want to start from scratch. My own opinion here, but I feel like that could stem from laziness. I know I reboot projects of mine all the time and whether the reboot can be considered a success is sometimes up for debate.

This question really led me to reevaluate my opinion of open source and want to contribute more. Since then, I’ve helped out more than a few projects on Github.

You have 25 horses and want to find the fastest three. You have no stopwatch but from a race you know the rankings. A race can have up to five horses.

Probably one of the only questions that I know the process to solve, but haven’t actually gone through to get an answer. During the interview, I gave a sub-optimal answer, and after a hint I was on the right track but the interviewer moved on to another question. The trick is after the initial five races, race each of the top horses and those that got 4th and 5th, their entire bracket can be discarded. The reason I include this question with the others, is that no one who I have asked has gotten the correct process let alone come to an answer. The question, I believe, is too hard and not on topic when it comes to being a software engineer. And let’s be realistic, who doesn’t have a stopwatch?

Tips

• Never be silent, always be voicing your thoughts
• If unsure, write test cases. This makes you more sure and impresses the interviewer. When asked how swap two int values without a temporary, I knew it used XOR but I was unsure. Demonstrating the XORs usefulness in the test cases the interviewer seemed satisfied enough to go on to the next question.
• Never give up. If an answer isn’t obvious, stall for time by complimenting the interviewer with asking such a difficult question. After complimenting, if nothing is coming to mind, state what you think and ask for a hint.
• Give an answer even if you know it isn’t the most optimal one. Be sure to also say that it isn’t optimal and ask for a hint if it is needed.