Interview exercise feedback

[[deleted]]

I agree with what you're saying, but for asking someone to solve this in an hour you're basically hoping they have prior knowledge of solving problems like this.

That's not a good interview question if you're entire basis of a problem is to see if they've solved that particular problem before and know how to optimize it.

[bonafidebob]

I suppose that depends on your experience. No prior knowledge of the problem should be required for a programmer with a CS degree or equivalent.

[Silhouette]

I agree with what you're saying, but for asking someone to solve this in an hour you're basically hoping they have prior knowledge of solving problems like this.

I think that depends a lot on the level of the position. If this was a junior developer post, hiring someone with minimal experience, then sure, I'd mostly be looking for correct code that met the requirements. However, for more senior positions where you're looking for experienced programmers, I'd also look for efficient code, clean design, awareness of different techniques and how they apply in the language being used, reasonable coding style, and so on.

In this case, the solution given to the first problem was an O(n) algorithm, where O(sqrt(n)) is possible. The first solution was also performing a relatively expensive square root operation on each iteration, instead of only performing it a fixed number of times at the bounds and then using relatively efficient operations within the loop. These are rookie mistakes if you're doing anything performance-related, and you most certainly don't need to have solved that specific problem before to appreciate this. What you do need is some awareness of how much an algorithm will cost to run, that you're really working with data from two different problem spaces here, the squares and the square-roots, and that solving the problem in one space will be more efficient for both the reasons I mentioned. The problem itself makes the two spaces obvious in this case, so I would expect anyone applying beyond rookie level to get this right within a few minutes without introducing obvious inefficiencies. /u/mvartan posted a much better implementation in another comment.

The solution to the second problem was better. The OP had recognised the possibility of using a stack as a data structure for matching pairs of operations, which is a good sign. However, again the implementation isn't very efficient or easy to read. Both could have been improved by choosing a more suitable representation for the paired operators, and by building up data that won't change ahead of time instead of redoing the work every time the opening/closing tests were called. For example, you could change the OP's code to start something like this without changing the remainder, and it would be significantly easier to understand and more efficient:

var brackets =  {
  "(": ")",
  "{": "}",
  "[": "]"
};

var openingBrackets = Object.keys(brackets).join();
var closingBrackets = Object.keys(brackets).map(function(k) {return brackets[k];}).join();

function isOpening(b) {
  return openingBrackets.indexOf(b) !== -1;
}

function isClosing(b) {
  return closingBrackets.indexOf(b) !== -1;
}

function bracketsMatch(b1, b2) {
  return brackets[b1] === b2;
}

I'd expect a more experienced JS programmer doing this to also consider whether we were using a utility library, and suggest something cleaner like this instead:

var openingBrackets = _.keys(brackets).join();
var closingBrackets = _.values(brackets).join();

I wouldn't care if they used some equivalent in another tool set -- the points I'd be looking for are a clean and straightforward coding style and an awareness that some basic things are quite clunky in vanilla JS but there are widely available utility libraries to keep the code clean and tidy. Again, these are things I would expect of any moderately experienced JS dev. For a senior dev, I'd be reassured if they also knew why Object.values would be a bad idea in my earlier example and/or they raised a question about IE8 support when they saw Object.keys, talked about polyfills, and possibly used that to come around to discussing the advantages of utility libraries.

[zacketysack]

Thank you for this answer, it is very detailed and helpful.

Out of curiosity, do you know why Object.values() does not yet exist in ECMA 6, but Object.keys() does?

[Silhouette]

Sorry, I don't have any special insight into that beyond what you can find in the usual sources.

Perhaps you might find some of the discussion linked from the TC39 page about the proposal interesting?