Ask HN: Code tests from potential employers

like every other developer ever, i have often been asked to do coding tests for a job interview. personally, i think ten to twenty hours of work is reasonable, if it's a place i really want to work.

what i have a problem with is companies that want you to do the coding test before they've even talked to you. i may rule them out as a potential employer as part of that process, in which case it would be a waste of time.

If you're really new to the field, there are a lot of really horrible developers, a bunch of developers interview well but are horrible on teams, and a whole bunch that are just not people persons at all. 10 hours of work really isn't a lot to ask, IMHO. The best tests though are like short contractual work to test a dev out, because then everything is tested (culture, intelligence, people skills).

2 hours is maybe on the far end of what I would consider reasonable. I might complete a slightly larger project for a more appetizing position.

10 hours is outright. That company is unlikely to value your time when you work for them.

I think 10 hours is a lot, but I would consider it if the position was really intriguing.

Calibrating tests like this is pretty difficult though, anecdotally. We give out a work sample test that we think should take 2-3 hours maximum and try to frame it that way in the problem description. Nonetheless, we have gotten a few in the past where it was clear that way more time was spent, and I feel bad when they don't make the cut.

Tip - if you are giving out tests like this, ask for feedback from hires on how long they spent and then adjust accordingly. Anything you give out is probably way easier for you than the candidate.

You've stated it perfectly. Either you're totally misjudging the amount of work involved (in which case, you're probably not what they're looking for), or they are asking far too much for a coding interview.

The longest off-site coding test I've ever been involved with took 1.5 hours, split into two parts of 45 minutes. If they can't gauge your chops in an hour and a half of technical questions and real-time problem solving, they're not doing it right.

That strikes me as absolutely insane, to be frank. I work in a different segment of the industry now (SET) but to my knowledge I've never been at a reputable company that gave a coding assignment that extensive, especially if they haven't talked to you yet.

So here's the question: is the code being asked to be production-ready, or otherwise real-world useful?

Because one possible thing that's happening is that they're mechanical-turking their codebase by doling out assignments to hopeful applicants.

I think <30min is reasonable. I send candidates a test that should take about 5-10min. My primary goal is to filter out candidates that can't complete tasks on the level of fizzbuzz.

Most of those code tests are scam. It's a psychological tool used by companies to improve their bargaining position vis a vis employees. It's called the IKEA-effect -- people like IKEA furniture more because they had to assemble it themselves. Programmers become more attracted to job opportunities if they have to work for it.

I've been asked to write constraint solvers for hexagonal Graeco-Latin squares which I did complete. It took me days, I got an optimal solution and was the only candidate able to do so. Still didn't get the job.

My current strategy is to only agree to solve puzzles if the recruiter can tell me how many of my potential coworkers solved what puzzles when they were hired. If it turns out most of them solved very challenging ai or dynamic programming problems, then I could jump through almost any hoops to get the job. Because working with people smarter then you is just invaluable.

If they aren't able to divulge such information, or most of the employees didn't solve any puzzles at all, I would be weary.

I disagree with anyone who says that code tests are scam. I work at Thoughtworks and we follow extreme programming practices. The most basic of which includes pairing. Pairing is a super strenuous activity which brings in productivity as well. However it is not everyone. Doing a code pairing round validates a lot of softer aspects.

I personally believe in show and don't tell. So if I am interviewing with someone or vice versa I would rather appreciate that I get to see some code that an individual has written or have someone assess me on that rather than how I well I can articulate myself or conjure up jargons and buzz words.

I am comfortable taking on large problems as long as there is flexibility in time. I spend about 15 hours over three days solving a problem that intrigued me when I interviewed 5 years back. I learned a lot about company, programming and myself int those three days.

Years later as I am trying to make that experience smoother for others, I have done a 5 series blog on what we look into coding solutions. Hopefully, that solidified them a little bit and doesn't make them look like "vague" and "just a whim and fancy" coding round.

Find my detailed take on coding problems given out by Thoughtworks recruiting here.

http://priyaaank.tumblr.com/post/95095165285/decoding-though...