[indigochill]

Our take-home obviously isn't a trade secret, so we have three trivial problems in ours:

1. Write code that takes in a rectangle, coordinate, and distance, and tells if that coordinate is within the distance of the rectangle.

2. Determine whether a string has permutations which are palindromes. (I'm of the opinion this one is too simple, but it's been fascinating seeing what mental gymnastics some developers will go through to solve this problem)

3. Write a CLI dice game (we provide the rules) in which the computer player wins 70% of the time. Make the method by which the computer cheats undetectable (of course this is impossible, but candidates just give it a best shot and we talk about their approach in the interview).

Assuming the test passes muster, we have three interviews right now, I think. One with managers to talk about the role, one with senior devs outside the team to perform the technical interview, and one with the devs in the team to talk shop.

In the technical interview, we primarily go through their test solutions (we do no whiteboard coding aside from reviewing the test and even that's very loose - not actual code). We have hired candidates before who have failed some of these tasks (mainly our candidates have trouble with #1) but who showed a capacity for being able to think on their feet and correct their mistakes during the interview. Of course a candidate who aces the test is going to have an advantage, but absent having the right answers, quick thinking/adaptability is probably the #2 trait we look for that seems to be a good predictor for developer success.

Every candidate we've hired through our process has been a success (which could be dumb luck, since none of us are super experienced/knowledgeable interviewers either, but we wing it best we can) and the take-home (and, equally importantly, the technical interview) has absolutely helped us weed out candidates with impressive CVs whose test results did not measure up.

[orangecat]

2. Determine whether a string has permutations which are palindromes.

If I understand this correctly, it's the sort of problem that's simple if you see the trick and hard if you don't. I'd expect many candidates to think that you actually want them to generate all the permutations and then get bogged down in recursion.

#1 is good, and #3 sounds interesting.

[concreteblock]

> I'd expect many candidates to think that you actually want them to generate all the permutations and then get bogged down in recursion.

Ideally the candidate should realize that this is computationally infeasible and quickly come up with a much more efficient solution, right? Perhaps they believe that this question filters out people who 1) don't have a feel for what is computationally feasible 2) will just dive into coding without spending 10 seconds to see if there's a significant optimization.

[datavirtue]

Closes IDE and feels relieved to have dodged that bullet.

[hibbelig]

> 1. Write code that takes in a rectangle, coordinate, and distance, and tells if that coordinate is within the distance of the rectangle.

Distance from the center of the rectangle? Easy. From the closest corner? Easy. From the closest point on the rectangle? I'm not clear how to do this.

And will the sides of the rectangle be parallel to the x and y axes?

[twic]

Break it down into cases. Is the coordinate closest to a corner, or to some point on an edge? You can determine that without actually working out any distance - play around with pen and paper and hopefully that will become clear. Then calculate the distance to either the relevant corner, or the relevant edge.

It's easiest to think about an axis-aligned rectangle, and you can convert any problem to have an axis-aligned rectangle by rotating everything.

[hibbelig]

I see. Thanks!

Quite a few pitfalls there, though. If I was doing computer graphics often, the geometry wouldn't be a problem I guess. But I've not done any such thing in decades.

If the job needs the geometry, then it might be a useful question to ask.