I interview a lot of software engineers, and people (especially college seniors) frequently tell me that they want to work on “hard problems.” When I ask them what they mean, they generally talk vaguely about doing something algorithmically challenging on the back-end, maybe related to machine learning, natural language processing, or big data. They don’t typically have anything more specific, which is fine – the specificity of a candidate’s interest is usually inversely proportional to the likelihood of an appropriate position existing – but it got me thinking, both about what they’re asking for, and what’s “hard.”

Don’t get me wrong – wanting to work on hard problems is a Good Thing™, and I appreciate it when a candidate is intellectually ambitious. I appreciate it a little less when it seems like a candidate is really saying that he – and yes, it’s always a he – wants to be treated specially, and only work on the cool projects (even stars have to take out the trash now and again – the difference is that stars try to automate the process so that that particular type of trash is never a problem again). But in general, we should all be striving to work on the most intellectually demanding projects possible. The question is, what qualifies?

School vs. Real Life

In school, you have easy classes and hard classes. You have easy assignments and hard assignments. You know which problem domain is being tested in your homework, and what technology you’re expected to use to solve it. Assignments have solutions, and are usually designed to teach or test one thing at a time. Problems have clean solutions. Your problem sets aren’t going to be tested against real-world traffic or bizarre user behavior. Your primary concern is correctness, not delighting end-users.

In real-life, nothing comes with a label. Hard problems are messy, and finding an optimal solution is usually a trip down an asymptotic curve with misleading local maxima and frustrating unavoidable tradeoffs. Sometimes, a problem that’s hard when looked at one way may be easy when approached from another angle. Your beautiful solution may blow up when exposed to the harsh light of real world conditions.

In school, “hard-ness” is usually measured in terms of algorithmic difficulty – each problem is a beautiful logic puzzle that requires an incisive mind’s careful dissection. In real life, these are the easiest challenges to tackle, since they have verifiably correct answers. Most real problems don’t, though, and require a balancing of implementation time, flexibility, robustness, scalability, and proximity to the desired end result.

Furthermore, the more experienced you get, the easier programming becomes, and the more you’re gated by factors external to code. Engineers are famously bad at design and usability. “Programmer art” is synonymous with “terrible graphics only to be used as a placeholder.” Self-styled “hard-core coders” are frequently disdainful of usability and front-end technologies (HTML, CSS), and only want to work on the back-end. Most developers prefer to work on problems holistically, rather than break them down into short- and medium-term deliverables to demonstrate progress. They’ll tell you that these are jobs for web-devs, graphic artists, designers, usability specialists, and project managers. This is junior thinking, though – whether they admit it to themselves or not, they’re using perceived difficulty as an excuse to stay firmly within their comfort zones.

What’s Hard

There are hard problems everywhere. Architecting a codebase so that it’s easy to do the right thing, and hard to do the wrong thing is a major challenge, whether in back-end or front-end code (go ahead, just try to control the size of CSS files being touched by 150+ engineers). Organizing larger projects for maximum efficiency is no small feat. Usability is an art form all its own. And yes, there are pure coding exercises so hard they’ll make you cry.

With this in mind, I’ve come up with a laundry list of different kinds of hard problems. So with tongue firmly planted in cheek, and apologies to Matt Groening, I humbly present the following:

This image is released under the Creative Commons Attribution-ShareAlike license.

Join the discussion at HackerNews.

In all seriousness, we’re hiring! If you’re interested in working on some hard but fun problems, please contact me at dblumenthal at my company.