programming in the
twenty-first century

It's not about technology for its own sake. It's about being able to implement your ideas.

Why Doesn't Creativity Matter in Tech Recruiting?

A lot of buzz last week over the author of the excellent Homebrew package manager being asked to invert a binary tree in a Google interview. I've said it before, that organizational skills beat algorithmic wizardy in most cases, probably even at Google. But maybe I'm wrong here. Maybe these jobs really are hardcore and no day goes by without implementing tricky graph searches and finding eigenvectors, and that scares me.

A recruiter from Google called me up a few years ago, and while I wasn't interested at the time, it made me wonder: could I make it through that kind of technical interview, where I'm building heaps and balancing trees on a whiteboard? And I think I could, with one caveat. I'd spend a month or two immersing myself in the technical, in the algorithms, in the memorization, and in the process push aside my creative and experimental tendencies.

I hope that doesn't sound pretentious, because it's a process I've experienced repeatedly. If I focus on the programming and tech, then that snowballs into more interest in technical topics, and then I'm reading programming forums and formulating tech-centric opinions. If I get too much into the creative side and don't program, then everything about coding seems much harder, and I talk myself out of projects. It's difficult to stay in the middle; I usually swing back and forth.

Is that the intent of the hardcore interview process? To find people who are pure programming athletes, who amaze passersby with non-recursive quicksorts written on a subway platform whiteboard, and aren't distracted by non-coding thoughts? It's kinda cool in a way--that level of training is impressive--but I'm unconvinced that such a technically homogeneous team is the way to go.

I've always found myself impressed by a blend between technical ability and creativity. The person who came up with and implemented a clever game design. The person doing eye-opening visualizations with D3.js or Processing. The artist using a custom-made Python tool for animation. It's not creating code so much as coding as a path to creation.

So were I running my ideal interview, I'd want to hear about side projects that aren't pure code. Have you written a tutorial with an unusual approach for an existing project? Is there a pet feature that you dissect and compare in apps you come across (e.g., color pickers)? And yes, Homebrew has a number of interesting usability decisions that are worth asking about.

(If you liked this, you might enjoy Get Good at Idea Generation.)

permalink June 17, 2015

previously

archives

twitter / mail

I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.

Where are the comments?