I gave the TripleByte application a try very recently, but this step wasn't a part of it: > 1. A fizzbuzz-like programming assignment. Applicants completed two

I gave the TripleByte application a try very recently, but this step wasn't a part of it: > 1. A fizzbuzz-like programming assignment. Applicants completed two simple problems. We tracked the time to complete each, and manually graded each on correctness and code quality. Instead, I was presented with a single, rather convoluted, 1-hour long programming problem that was most definitely not anywhere close to the difficulty level of a FizzBuzz test (the solution they're looking for probably involved dynamic programming, which I honestly haven't had much practice with). This was before I even spoke to any humans on the phone screen or interview steps of the process. I couldn't finish it in 1 hour (I kept going at it on my own time for another 2-3 hours before I finally arrived at a sub-optimal solution, at which point I had enough). I'm sure there are plenty of people who are much better at this than I am who can finish it in an hour. But I do want to question the wisdom of using something of this level of difficulty as a screening test. Your clients seem to value the "Product Programmer" very highly. Using a question like that as a screener will weed out a significant portion of these "Product Programmers" before they ever get a chance to showcase their product skills. Most "Product Programmers" I know (myself included) don't do enough convoluted dynamic programming problems in their spare time to be able to solve a dynamic programming problem like that within an hour with any level of certainty (and yes, solving problems like that quickly involves either extraordinary talent or lots and lots of practice). Instead, in their spare time, these "Product Programmers" like to build things, and learn new technologies and techniques to help them build things in a simpler, more maintainable, and more productive way.