Programming interview : quick ways to ensure that program is correct

Question

Hi,

I faced a telephonic interview recently and I was asked to write a program. The program is non-trivial to understand, but I am asked to write the program. I wrote the program and interviewer showed me bugs on some corner cases. I wish, I could have found the corner cases earlier. what does everyone do in this case.

Thanks
Bala

Answer 1

A simple suggestion is to think of "corner cases" as soon as you have written any code. This is helpful in everyday coding as well.

Edge cases (corner cases) vary from application to application, but in general ask yourself 'what happens'

• if there is no input?
• if the input is null or empty?
• if the String, List, Set is empty?
• if a Set, List etc is never initialized?
• if the int used to traverse the list/array is 0, or exceed the size of the array/list?
• if the arguments provided to the function / constructor are null?

As with any problem, first make sure you understand it thoroughly. In this case, that would mean asking a lot of questions to the interviewer. In this way you are demonstrating that you want to exhaust all aspects of the problem. At the same time this could also help you in locating "corner cases" on an early stage.

Answer 2

Keep in mind that since the interviewer asked you to write the program, they have probably had plenty of time to think of the solution themselves before the interview (they may even have asked multiple interviewees the same question before, as well) so they'd be much more familiar with the problem than you are. So I would not sweat not picking up every corner case right off the bat (unless they're really obvious, I guess).

As long as you can demonstrate to the interviewer that once the corner-case is pointed out, you can understand the problem and suggest solutions, then you're already well on your way to making a good impression.

A lot of this stuff simply comes with experience, however.

Answer 3

You can come up with a list of test cases even before you start writing the code. This step could even expose some bugs in the approach that you are going to implement in the program.

The interviewer will really appreciate if you tell them that you'll design the test cases before you go ahead and finalize on the approach/algorithm.

Edge cases are really important because many bugs in the software come because of failure to find/handle the edge cases. Usually the interviewer gives time to the candidate if one/more edge case(s) has not been taken care of; if the candidate does not identify them in that time its not a good sign.

Never make the common mistake of checking your program for a few trivial test cases which work fine and announce you're done. The way interviewer looks at this is: you did not care to find/handle edge case today, you'll do the same tomorrow when hired and you'll write buggy code.

Answer 4

I've conducted my fair share of interviews, so I can tell you this isn't uncommon.

When the interviewer gives you a problem:

• First, make sure you understand the problem.
• Second, make sure you understand your solution.
• Third, start coding.

Too many candidates get these steps out of order - that leads to corner cases and bugs. Believe me - interviewers notice candidates who do those steps in the right order.

While you're solving the problem:

• Talk through your solution. Keep talking.
• Tell the interview that at your job you'd use libXYZ.
• Tell her you'd profile performance and see if you should use a different approach.
• Mention if there are inputs that would cause your function trouble.
• Are you nervous? Tell them you're nervous... they won't fail you for that.

An interview isn't about "gotcha! found an off-by-one error! you fail!" or "you forgot to check for socio-pathic user input, you fail!" (Some probably are, and those are bad interviewers... let it slide).

It is about evaluating your solution. It is about evaluating your problem solving process. It is about how you handle it when the interviewer says "are you handling an empty list properly?". There's a lot of important information that comes from an interview (face-to-face or phonescreen), so learn from this experience.

Remember that the interviewer has seen this question before, they know the corner cases. They're pointing them out to move you closer to the solution or see if you understand them, not rub your face in failure.

Jeff Atwood recently blogged about coding during phonescreens [again]. He (like many others excluding Tom Cabansky :P) concluded that it was an incredibly useful tool to pare down the applicant list. Like it or not, it's here to stay.

To the interviewers, use a collaborative tool like Google Docs or I.See[Mike]Code. That's much better than "solve a problem"... "now read it back to me"... don't be a lame interviewer.