Comment by fragmede | Hacker News Reader

Comment by fragmede | Hacker News Reader

Parent Full thread

HBO's Silicon Valley is dramatized, but I can't be the only one who's coded from the the convention hall floor/hotel, or had to setup servers "live". Every time a site gets unexpectedly popular (/. effect; HN hug of death) and dies, and comes back, there's someone at the other end who's probably close to tears trying to get their site back up ASAP.

That doesn't indict the fact that's the exception and that software programming almost never looks like that.

The real problem is that take home problems are trivially gameable - it's obvious to someone unscrupulous who's not a well-seasoned coder, that it would be well worth paying someone else to do their take-home-interview-homework. (Sure, that would come out eventually, but that's only one of the problems I have with take-home assignments.)

Some places have "open book" interviews, where it's like "here's a laptop, do this thing, and google/stack overflow/devdocs" your way to victory, which is at least better than the older "how much trivia do you remember about this API"-style questions. But I have no idea how to go further and make that unbound by time when an employee is on the other end of the table listening to the interviewee's thought process, if only because it makes it very hard on the interviewer to plan their own time. (Especially considering maker vs manager time.)

Have you ever actually tried a take home exercise? Or is this just based on your perceived concerns?

In the years I have been doing take-home exercises for candidates, I have yet to see a single instance of a great take home leading to a terrible on-site or hire in terms of technical skill. There have definitely been great take-homes for candidates that we later chose not to hire, but usually due to challenges interacting with the product team, or in some cases too much fixation on technical perfection with no focus on business realities, etc. If there are a large number of candidates paying others to do their take homes for them, they should be asking for refunds.

Second, even if this is a problem, there's a very simple solution. For candidates that do well on the take home, either on a call or on the on-site, do a live code review with the candidate and ask them to explain a bit more about why they wrote the code the way that they did. Ask them questions about other approaches, or what they'd do if they have more time. Candidates will be significantly more comfortable talking about their own code they wrote. It'll be quite clear if the candidate didn't write it themselves.

I had a project give me a take home exam with a link to the git repo and basic instructions on implementing a simple algorithm, as well as tests, and FFI bindings. That took a couple hours, then I had two 1-hour remote interviews discussing the code. I thought the process was pretty good: even though I was annoyed at having to do the take-home bit, it served to demonstrate that I could navigate the project source code, build files, learn the FFI interface, etc. The algorithm itself was fairly simple to implement with a little thought, although they probably didn't care if I looked up how to solve the problem on Wikipedia. Personally I think that being able to figure out where the tests were, how to add FFI, etc., was one of their biggest requirements.

Anyway, I thought it was robust but not too time-consuming interview process. I think such an interview could use a reasonably-sized open source project for this, instead of their internal code base.

Reply on news.ycombinator.com