How to Improve code quality

  Many candidates are confused and ask themselves, “Why wasn’t I hired even though the interview questions seemed simple to me?” There are many reasons why people fail, and the most common one is that there are some problems remaining in their solutions or written code. That is to say, they have to improve their code quality.

The first standard of code quality is readability. If candidates are asked to write code on paper or white boards, they must write neatly and cleanly. Additionally, readability is improved if code is written with reasonable variable names and logical indentation.
The second standard is completeness. Many interviewers examine quality through boundary checking and special inputs (such as NULL pointers and empty strings). There are lots of candidates who fail their interviews because their code only fulfills the basic functional requirement.
Let’s take one of the most popular interview questions in Microsoft as an example: How would you convert a string into an integer? (See Listing 1-1.) This question seems very simple, and some candidates can finish writing code within three minutes.
Listing 1-1. C Code to Convert a String to an Integer

int StrToInt(char* string) {
    int number = 0;

    while(*string != 0) {
        number = number * 10 + *string - '0';
        ++string;

}

    return number;
}

Do you also think this problem is quite easy after reading the code above? If you think so, it is highly possible that you will be rejected by Microsoft.
The simpler the question is, the higher expectations an interviewer has. The problem above is simple, so interviewers expect candidates to solve it completely. Besides basic functional requests, boundary conditions and error handling should be considered. Converting a string into an integer is the basic functional request to be fulfilled. Additionally, candidates should pay attention to more cases, including the negative and positive symbols, the minimal and maximal integers, and overflow. The code is also expected to handle cases when the input string is not numeric, with non-digit characters. When we take all of these cases into consideration, it is not a simple problem anymore.
Besides incomplete solution and code, another intolerable mistake from an interviewer's perspective is that code is not robust enough. If we scrutinize the code above carefully, we notice that it crashes when the input string is a NULL pointer. It would be a disaster if such code were integrated into a real software system.
Not all issues related to robustness are so obvious. Let’s take another popular problem as an example: how to get the kth node from the tail of a list. Many candidates read its solution with two pointers on the Internet. The first pointer moves k-1 steps, and then two pointers move together. When the first pointer reaches the tail node of the list, the second one reaches the kth node from the tail. They feel lucky and write the code in Listing 1-2 with much confidence.

Listing 1-2. C++ Code to Get the kth Node from Tail

ListNode* FindKthToTail(ListNode* pListHead, unsigned int k) {
    if(pListHead == NULL)

return NULL;

    ListNode *pAhead = pListHead;
    ListNode *pBehind = NULL;
    for(unsigned int i = 0; i < k - 1; ++ i) {

        pAhead = pAhead->m_pNext;
  }

    pBehind = pListHead;
    while(pAhead->m_pNext != NULL) {

        pAhead = pAhead->m_pNext;

        pBehind = pBehind->m_pNext;
  }

    return pBehind;
}

The candidate who writes the previous code feels more confident when he or she finds that the NULL pointer is handled and, consequently, believes he or she will definitely be hired. Unfortunately, a rejection letter might be received a few days later because there are still two serious issues left: (1) When the number of nodes in a list is less than k, it crashes; (2) When the input k is zero, it crashes.
The best approach to solving this kind of problems is to figure out some test cases before coding. Candidates may write complete code only if all possible inputs have been considered. It is not a good strategy to ask interviewers to check their code immediately after they finish writing the code. They should execute their code in their minds first and only hand the code to interviewers after they are sure it gets expected results for all test cases. 

Besides basic functional requirements, interviewers expect candidates to handle boundary conditions, special inputs (such as NULL pointers and empty strings), and errors.

www.cinterviews.com appreciates your contribution please mail us the questions you have to cinterviews.blogspot.com@gmail.com so that it will be useful to our job search community