I find it true that most coding challenges are either about math, or simple algorithms, such as path finding, DFS/BFS, tree traversal, etc. I think it's because they're simple to explain in a quick way, and don't involve the person needing to know libraries or frameworks.<p>That being said, most of the coding I've done in my life has been all about integrating different libraries and frameworks together. I don't see a lot of complex algorithms, which is good (because they are complex, and probably someone else already wrote it better, with less bugs and better performance). I'd never want to work with someone who rolls their own red black tree into production code just for the lols.<p>That being said, I don't think it's a great way to evaluate candidates, because it's not what most people do all day. I find problems about integrating systems, and understanding complex topics like networking, databases, testing, protocols, and APIs to be much more useful.<p>To find a good middle ground, I like to ask design questions, and then give people a "library" of functions they can call with prototypes, and tell them what they will do. This focuses on the logic of putting it together rather than off by one errors in loops, which still happens to me all the time. Those kinds of bugs are easy to fix when you can actually run the code, but a right pain on a whiteboard.<p>I'll never forget the look of surprise on the interviewers face when I was doing an intern interview and asked "can I use stdlib calls like memset and memcpy, or do you want me to write loops?" I think just asking the question gave me huge interview points. (and yes, I got the job.)<p>Let me finish by giving an example of what I thought was a good coding assignment: Write a service that listens to rabbitmq and rotates the images 90 degrees and post them back to a different queue. This wasn't about writing code to rotate images either, it was about knowing how things work, and stitching them together correctly (with the right error handling and failure modes).