Hacker News Reader

Comment by nilkn | Hacker News Reader

How do you avoid awarding candidates who violate your request of no more than two hours and spend considerable time coming up with something amazing? They may still produce 100 lines of code — but those 100 lines may end up being unusually elegant, beautiful code that stumps 40 year veterans. How do you avoid punishing someone who took your requested time constraint seriously (or otherwise didn’t have enough free time to violate it anyway)?

That’s not to say I don’t think this process has promise, but I’d need to be convinced that the above two issues can be fairly dealt with first.

View on HN

I'm of the opinion that this is fair enough as long as the pay isn't crazy high. The truth is, no interview is ever truly fair, and all interviews can be gamed. "Grinding leetcode" is much the same problem you are describing wrt spending 40 hours on a 2 hour project. People game non-technical interviews too. And resumes.

It sucks, but you only need to be better perceived than the next best competitor. Most folks don't have 40 hours to spend on a 2 hour max coding challenge. Hopefully the ones that do are already employed and not currently competing with you, or are so inexperienced that 40 hours produces horrific over-engineered abominations instead of clean efficient readable code.

I reject entire the premise of this question. Anyone spending huge amounts of time is either going to produce way too much or they just took too long. There is nothing magical about programming where taking 8 hours to solve a 2 hour problem is going to stump 40 year veterans or be unusually beautiful. That's just unrealistic.

That's not my experience at all. To a limited extent, you can get something more beautiful by just putting more work in it.

You are taking it to the other extreme. Sure, in 8 hours I will not write something "unusually beautiful". But if I spend two hours solving a problem and hacking together a solution, I come to better understand both problem and solution. Hereafter, I then can rewrite my solution in another couple of hours and improve it significantly with respect to maintainability, readability, naming, messy choices, &c.

If I want this job, I would spend this extra time to submit this better solution because obviously that will improve my chances of getting the job. But that means that these take home assignments might not be such a good indicator of efficient proficiency. You might be overvaluing people spending more time on these tasks and undervaluing people spending the allotted time on these tasks. For example, a better developer who did write a solid solution in under 2 hours might get passed over because her solution seems not as good as mine where I did spend another hour to rewrite my initial messy solution.

Actually, if they spend more than two hours, the question is why. We are happy to see them get interested in the task and dive deeper, but we just don't want to ask for more, that would be unreasonable in our view. It's fine if the code is broken, or has a couple of bugs. (It's best if it compiles though!)

The goal is as much to learn how they think, solve problems and communicate as it is whether they know how to write software.

I'll give one example: One task is to figure out how long it takes to grab the current time from the operating system. We use a rather obscure OS. A candidate chose this and solved it simply (though it's got a couple of points to mind), but then he got curious and wanted to know whether a virtual machine had a different timing and then what the performance on a different operating system was. He told us that he spent about 8 hours altogether. I felt a bit bad on one hand, but on the other, it's exactly what we like to see: Solid programmers who love programming technology for its own sake.

Something i've seen a couple of times is giving a take-home exercise, then working on it further in the on-site interview. The first stage filters out people who can't get things done even given as much time and help as they want, the second stage filters out people who can't get things done at a reasonable pace without a helping hand.

I think it's common for an on-site interview to include a reasonable chunk of programming, and using a continuation of the take-home to do that is good because it means the candidate isn't starting from scratch. Coming in warmed up should minimise noise from nerves, unfamiliarity with tools or context, etc.

This. I just can't see this not penalizing conscientious candidates.

Reply on news.ycombinator.com