morfizm (morfizm) wrote,
morfizm
morfizm

Interview Club

Today I was playing interviewer role, and picked a new task which, I think, from now on will become my favorite. It is an algorithmically easy task, it will not let you show how your deal with ambiguity (the task is straightforward), but it is great for demonstration of ability to do low-level coding and design. I was surprised by how much one can make his solution complex, and how many bugs can be introduced. In fact, I even overlooked one subtle bug which he noticed after the interview was done.

The task:
You are given two sorted single-linked lists. Merge them into one sorted list.

A couple of common mistakes to be aware of:

1. Strive for simplicity, make it easier to understand.
If you try to make it too concise, you may end up making it complex (and conciseness will also be under question). If you have to spend twenty minutes tracing your code, before you're sure it's right, imagine how much time another person will spend to debug your code.

2. Avoid mistakes and fix them quickly.
Doing a lot of mistakes and then fixing them after tracing overall leaves good impression, but it's better to be more attentive and not do a lot of mistakes, or fix them shortly after you make them.

3. Avoid syntax errors.
Going after syntax errors is nitpicking, but making syntax errors leaves impression of inattentiveness to detail and lack of experience (if you are experienced and you look at a syntax error, the compiler in your mind will instantly raise red flag).

4. Choose minimal test cases.
Unnecessarily long test cases may take significant time to trace, and also leave impression that you aren't a good tester, or you don't understand your own solution very well (after all, you generally need to cover all of your execution paths only once).

5. Isolate subtasks.
If you're writing a function, don't make it applicable only in the context of another function from which you're calling it. Try to generalize. A function should be easily testable with abstract test data (hand-crafted just for this function), and after you've done testing you shouldn't look in the implementation to trace it (you shouldn't step into it when tracing the outer function). You also shouldn't have to look in the implementation to find out "what function does". If you do, it's an indication of poor design.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 15 comments