Hacker News Reader

What I've seen done at my last jobs have been the following:

- A pretty simple take-home problem (something that just implements two or three classes) - An exercise to refactor really terrible code (this is offered in alternative to the take-home) - Questions about architecture that they've worked on in the past, the problems they've had to deal with, etc.

Just asking those questions and seeing how they do with the simple challenge is enough to see if they have at least good code instincts. In person, they can justify their decisions (and it's good here to see if they can take feedback, run with it, and come out with a better solution).

Ultimately the interview process should smell out if 1) they're an asshole to work with 2) if they're able to have good code/architecture instincts.

I do think these are reasonable questions, and allowing the candidate to use their own laptop sounds very fair.

One thought though, not necessarily for the poster but for anyone who asks these questions: for the second question, finding common elements of two int arrays, the idiomatic Ruby answer is: x & y

Would you be satisfied with that answer? As a candidate, would I be expected to create a set of tests to ensure that it works, even though this is a standard feature of the language?

If you would not be satisfied with that answer, would you be surprised that a candidate might struggle with an alternative, knowing that they would never use an alternative in their normal coding experience?

YES! for the first 2 questions. My go to question is reverse an array (without using any library functions).

Instead of asking a quirky question, it is better to have them solve a simple problem and judge on logic and structure.

Why can't you use libraries? You're rewarding people for reinventing the wheel.

Because in many languages, this is trivial to the level of calling .reverse() on the array.

Sure, but in some of the popular languages where that is the case, .reverse() is no more (and no less) a “library feature” than creating or indexing an Array.

In which case, the question isn't really relevant to the job. Same goes for stuff like sorting algos. Why not pose problems more representative of the job and business domain?

Because reversing an array is super easy and using a library is one function call

> Because reversing an array is super easy and using a library is one function call

It's not super easy without using library functions when all the operations that work on arrays (including the constructor that makes them) are as much “library functions” as the one that reverses an array. (Conversely, if the mechanism that reverses an array is part of the language core and not a library, the restriction fails to have the expected effect from the other side.)

The restrictions seem to assume that every language has the same division of distinct core “language” features as distinct from what is provided by libraries.

Writing the following does not use any libraries

a = [0, 1, 2]

print a[1]

That's just how arrays work. If your elements are 32 bit integers then you are establishing a pointer to the first element. Accessing an element is multiplying the index by the element size and jumping from the first element pointer to a memory address offset.

> The restrictions seem to assume that every language has the same division of distinct core “language”

Fine, if your language has a library for arrays, then reimplement it on the whiteboard. Everyone is able to do that if they know what arrays are. They are just contiguous memory

At some point, you need to decide what you're going to ask something to build in an interview. It's probably been implemented before.

Yes, reversing an array is arguably lower level than an application engineer needs to go - but not by much (in some languages you will be doing this yourself). And if they can do that, they can do something comparably difficult.

Why not choose a problem more representative of the job and business domain?

One that demonstrates their ability to write clean, testable, readable OO code, with appropriate abstractions, and not overengineered.

I find most candidates, struggle to do this, including algo wizards. Most software engineers aren't good at this either.

> My go to question is reverse an array (without using any library functions).

If you mean “functions provided by a library outside of the core” there are languages where this restriction doesn't prevent the kind of trivial solution you are trying to prevent.

If you mean “any predefined functions/methods” there are languages where this is impossible (e.g., since even literal array syntax is just syntactic sugar for the Array constructor method.)

Note that there are several languages that fall into both categories (e.g., Ruby.)

There are probably a very narrow slice of languages where this restriction, however you define it, really does what you intend.

> They were asked to bring their own laptop, and use their favourite editor, with the language of their own choosing, and setup a test environment.

That's a really nice way to make someone a lot more comfortable. I do have to ask, was any part of your judgement affected by those choices?

What percentage of candidates should you filter out before bringing them on site EG what percentage of these people into that we had about just wondering because it makes a difference in where in the funnel they were

We placed the technical interview as the second interview. So if we thought they were a good match they would go to the technical interview, and if they completed that we would offer them the job.

I am not sure how many we rejected before the technical interview, because I wasn't involved as much in that part.

Kk. I've seen widely varied screen out procedures and that can heavily hit on how many "can't even write a for loop" candidates you get.

I actually disagree with most of the other posters about bringing your own laptop. I only own a desktop and chromebook. I use a macbook that my employer provides, but I wouldn't feel comfortable bringing that to an interview. I think by asking someone to bring their own laptop its creating an unnecessary requirement, but I realize I may be in the minority as far as laptop ownership goes...

If you didn't have a machine, we would of course provide you with one. The feedback we have received is that people felt more at home with their own tools and hardware.

Are these tests actually representative of the kinds of problems you need to solve regularly in the job?

So, in all three cases if you sort the arrays (the last one by price) then the rest is super obvious?

I think the order matters in the 3rd exercise. As in your "buy" index has to come before your "sell" index.