Given a non-empty zero-indexed array A of N integers, return ...

There are mixed opinions to the benefits of asking questions like this to prospective candidates, especially in a software development role where there could be a large emphasis on UI work or there is a standard/non-standard library that can do the processing work for you. Oftentimes you should use a defacto, well reviewed library; for example encryption, image processing or compression.

However, sometimes including a large library for a single and simple function is not a good option. Perhaps the language of choice is Javascript, so the whole library needs to be downloaded to the client before it can be ran. Or it is part of a licensed dynamic .NET library so can not be legally extracted.

More importantly it gives vital clues to the innate logic of a candidate, their code style, attention to detail, and care. Regardless of whether a candidate provides an optimal answer, these are the main things I look for:

  • Is the entire solution contained inside one single function?
    Depending on the challenge or the answer, this can be fine. But is it DRY? Would splitting it out into a few smaller algorithms improve the readability?
  • Is the solution self documenting?
    There is nothing worse than seeing poorly or simply unnamed variables and functions. Equally bad is comments on every other line. Both of these scenarios spell out trouble for code reviews down the line.
  • Is the complexity satisfactory?
    I find complexity is often overlooked, and especially important for mobile developers as battery life remains a coveted resource. An array manipulation or comparison test can quickly see if a candidate is concerned about complexity. This kind of test naively solved can quickly give rise to loops inside loops, calculating the same thing over and over again, making redundant calculations... before you know it the complexity for a best case scenario constant or linear time challenge is O(n2) or worse: O(n!).

Now of course under pressure of a test, even an experienced candidate may slip up on this last one, and chances are you aren't hiring for Google, or Uber so don't have a plethora of engineers with 6 sorting algorithms memorised waiting on the other side of the interview room door to show off, with strategies for concurrent calculations..

This is the opportunity to see how they respond to iteration. If you ask them how they can improve it, do they start looking in the right place? If you hint to them where to look are they able to take it and run with it or are they waiting for your next hint until you spell it out? Do they insist it's perfect?

How they act here, is how they'll act in the future.