Why Doesn't Creativity Matter in Tech Recruiting?

I'm no grade A programmer. Yes, I know all the sorting algorithms and graph theory and all that. I can work effectively in a continuous development scrum based environment. I know .net and all the popular browser stacks. I can engineer dimensional ETL warehouses. Yada yada... Everyone can at this point.

What made me really famous in my little circle was my ability to do really fast problem mitigation. While all the other hardcore devs were freaking out due to all the stress of having to work and communicate directly with management while dealing with rapidfire requirement changes, I took it all in stride and just got it done. My reputation was this: if I was on the case, it got done on time and with a smile... period.

No one in any interview I've ever had was interested in that skill set. They only wanted to know about old school algorithm skills and how fluent I was with popular frameworks. It's as if upper management actually believes that my project management skills are irrelevant because hey! they've got project managers and staff for those. Why would a dev need it!

Oh, and I don't have a college degree. So, good bye... NEXT CANDIDATE!

Sorry...I ranted.

I got asked once "what are the four uses of static in C++". I couldn't recall one (can't remember which one), though I'd shipped a lot of code with all four in more than a decade of C++. He wasn't impressed with my so-called-C++ skills.

I wish I'd asked him what three common words in the english language begin with D and then W, or any three words with just the five vowels in the correct order. I think the chances are good that I could have mocked his so-called-English skills.

These questions, and comp-sci trivia tests, don't test developer ability. I've employed a whole bunch of programmers. The best have been the most agile, creative and curious.

This is something I always liked about the IMVU hiring process. I wish I understood all the ingredients of the recipe, but somehow we managed to hire a diverse engineering team. Creative folks who just got stuff done, people who could find bugs deep in third-party dependencies, people who could design and build high-performance technology at scale.

I no longer work at IMVU, but the lessons I'd take away are:

- Hire based on passion and innate problem solving ability, not which specific technologies they know. (Except when you need to bring in specific expertise.)

- Have a fuzzy hiring process where people don't necessarily need to quantify a candidate.

- Take risks on people. We've had candidates who were a "no" but one person stuck their neck out and said "You know, I saw something special that none of you did, and I'd like to take a chance." Many times the candidates ended up being amazing, and it took that one person to see it.

Interviews which have you rebalancing trees and what not are really just legally safe IQ tests. They purport to be testing skills, but nobody really cares if you can implement a search algorithm - 99.9% of the time you're going to make a library call to do that. They do care to hire the kind of people that are smart enough to do that kind of thing, though.

While the question of creativity vs programming skills is interesting, I think it's not even good to assume that people inverting binary trees on a whiteboard are good at coding.

I know several people that are great at algorithms but write garbage code (unmaintainable, unreadable, untestable, etc). Or they can't take business requirements and turn them into low-level details in a useful way.

The number of times a product manager has gone to an engineering team and said that they need a product that inverts binary trees is about equal to the number of working quantum computers.

Part of the problem is that the bigger the company the less creativity they want out of their programmers. Programmers are supposed to do whatever task they were assigned by their managers. Creativity is reserved for the product team.

Creativity is next to impossible to measure during an interview. So all these proxies for creativity are invented and we use weird memes ('thinking out of the box') to describe some aspects of it without fully nailing it in a way that would make it a measurable quantity.

I think creativity is hard to measure by definition because if you could measure it it would have some other name. It's a bit like 'AI', by the time something gets done it is no longer AI.

Programmers are - by non programmers - in general not considered to be creative people, they are seen along the lines of engineers, whereas architects generally are seen as creative people.

For me good programming is like writing poetry (definitely a creative art), only now all of the poem has to be internally consistent and the computer will mercilessly reject any prose you wrote that isn't.

So it's a very constrained and formalized kind of poetry, an arena where beauty is not only not apparent to non-programmers but largely irrelevant. As if painters produced nothing but white canvases that only they could see with special glasses.

If you want creativity to matter in tech recruiting then stop using proxies for creativity during the recruiting process and throw a new recruit a real life problem and work with them to solve it. That will give you a measure of someone's creativity.

This is a great discussion piece.

My opinion of why creativity doesn't matter in tech recruiting (even in small start ups) is because the person making the decision to hire someone is going to have to defend why they hired that person to someone else (who likely is a business-minded person who does not have a tech background). If the hiring person can't have concrete documentation of why they hired someone, then it is the hiring persons problem.

It is the dehumanizing effect of division of labor in action - programmers are not supposed to have ideas about product features, product people are. Programmers are supposed to execute and this is what is tested in these interviews.

Totally relate to this. As soon as you're put into a programming role, all of a sudden it doesn't matter if you have domain knowledge, lateral thinking that can lead to improved processes, personable skills etc All that matters during the interview process is whether you can remember some obscure construct in a language, or what the Big O notation of Quicksort is - something that you'll very rarely even have to think about while making web pages...

I guess the problem stems from people hiring others who are like themselves ignoring the fact that diversity isn't whether you are black or white, male or female, but actually stems from the experiences you've had, and the ways in which you think.

I challenge ANYBODY to actually define in any sort of concrete terms what a great programmer is.

And without a clear definition, how can any interview process ever work out if someone is a great programmer? It is absolutely not possible and in fact meaningless to try.

Everyone - every company, every interviewer, every recruiter has a different opinion.

Recruiting is, in the end, nothing more than a matter of opinion. Everyone keeps trying to "solve" recruiting. It's not a solvable problem. All recruiting comes down to "Hey what do you think of how this guy interviewed? Yes or No?"

When I do interviews I always have the candidate show me some of their own projects and walk me through the interesting parts. Sometimes I'm curious about a certain feature and will have them explain the code to me. I feel like this is the a great way to know their skill, personality and how they solve problems. It's actually interesting for me as well. Brain teasers are good for seeing whether the candidate can memorize algorithms. Since our work involves very little, if any algorithm writing, that's not something we look for.

We ask an open ended design question. For example (not a real one), when hiring an ME we might ask, "How would you design a new kitchen stove?"

There isn't a right answer. One person might ask more requirements ("electric or gas? Home or professional") while another might state themm up front ("well for this project I'll make it a gas stove since I think that's nicer to cook on in your kitchen"). One might go down more on the design or cosmetics, another safety, another weight and price...

We look at how they look at the problem and take it apart, how they react as they go down a path they later don't like and want to backtrack ("hmm you know I really should have allowed room for an oven because at home most people want both, and if I do this I can save some parts, so let me cross this part out"), how they react to questions (defensively or confidently) etc. One person might say, "I'm sure there's some safety code about XXX but just for design I'd worry about this shutoff" while another might say, "and we put this valve in here for safety code 1234..." Both are fine.

These are nice because 1> they are open ended and should be fun 2> they don't relate specifically to the company's business (we're not in the stove business) so it's not a trick question to see if the candidate knows some special safety code or something 3> they allow the candidate to show themselves off without needed to be glossy or get everything perfect.

Really good interviewers and really bad interviewers both have idiosyncratic candidate judging methods.

Startups, when they start to hire at scale, try to standardize a methodology to compare apples to apples -- to avoid really bad (arbitrary) interview experiences in favor of predictable experiences even if those experiences are not excellent.

They look for interviewer formulae they can plug a random company developer, who would probably rather be working on something else, into.

The word creativity has many different meanings, depending on who is speaking.

For "packers" it is an umbrella term they use when they are unable to grasp how, say, Rich Hickey came out with Clojure all alone (a few fundamental ideas put together plus ripping out CL) or how Igor Sysoev wrote nginx (after studying Apache's internals and coming up with a better model) or what is so special about Arc language.

For other people it is just the set of habits of thinking which is natural to them, so they literally cannot see what is that people are talking about.

There are the majority, who think that creativity is something which is related to [visual] arts, some kind of mindset. They use this word to justify an inability of a kid to sit down and do the homework as being a creative nature. No wonder packer managers want none of these.)

There is no "creativity" which can be boosted aside from habitual analytical thinking and hard work. Insights could appear only after extensive training of ones mental maps.

Because developing new stuff - although advertisement and PRopangda will tell you the exact oppposite- are bloody dangerous. If you are the first to do a thing, you are the first to craft the tools for it, the first to experiment, the first to find errors in the equations, the first to be delayed and then to be overtaken by a spying competitor learning from your mistakes.

The first to be put out of buisness by somebody who realizes your advances put them into danger- with all the force of a currently working buisness.

Prototypes might make good tv-clips. What they do not show, is how often those endavours end pathetic - Rocket explodes, Cars crash, Robots fall and the guys working on them get laughed at by there collagues who stuck to more incremental research. Getting a steampowered nuclear reactor going- fast- getting a fusion plant going - not so much.

"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."

Memorization is certainly not the way to learn how to solve math/cs/logic problems. There's a lot of thinking and (creative) experimentation involved when trying to solve a problem.

A lot of problems are classic problems in disguise. You'd be amazed to find out how many problems are just sorting + one traversal: reducing the average wait time in a queue, convex hull, counting duplicate elements (no extra space), interval scheduling, maximum number of overlapping intervals and a ton more. Can you memorize all of these problems individually? No, but you can ask yourself "how about if I sort my data first, what then?". If that doesn't work then try another question: "I have this brute force algorithm, if I use some other data structure will it get better?" - that question alone solves half of the problems I've ever seen. Follow up questions would be "does my problem look fractal-y?, maybe I can divide it repeatedly" or "can I incrementally build the solution?"

Even more interesting is that problems usually have more than one optimal solution: Prim's algorithms and Kruskal's solve the same problem in opposite-ish ways and use different data structs. How about substring searching: Boyer- Moore searches backwards, Rabin Karp computes hashes while others simulate automata. With self-adjusting binary trees it's the same story: a lot of very diverse solutions to the same problem.

Solving problems implies doing a lot of permutations and experimenting with data structures and classic approaches if you ask me - it's certainly not about memorising more than "sorting sorts and hash tables have constant-ish access time"

Is this process any different than changing colors, fonts and layout on a website until you get a good-looking enough whole? All you have to know are some principles about contrast, alignment, spacing and what not, and the rest is experimentation.

I think this herd mentality in recruiting is great. The more companies chase the same 0.1% of developers the easier (and cheaper) it becomes for semi-thoughful companies to recruit those developers who don’t fit in the box, but who can get stuff done.

Anytime I'm interviewing, these days for contracts as an independent consultant, I try to mention early on that my B.A. was in Philosophy, with a minor in Music History.

I try to avoid (or spend as little time as possible) with companies who are only looking for pure-bred CS majors. It's refreshing when you encounter a medium to large corporation who tell you that most of their best engineers / programmers were originally art students.

But it's hard to test creativity. We try to test programming skill because it's one of the few things (we think) we can test.

How would you go about testing creativity?

I think in mobile development creativity matters. An app is a program but also (and very important) is the UX. Mobile portfolios with good interface are an advantage.

It's an interesting discussion. Do interviews focus less on side project than pure programming skills on whiteboard?

I'm just trying to give an idiot test at this point. I don't know why people still aren't passing it.

I've been following the latest rounds on technical interviews, and I think this post raises an important question. Based on my interview experiences at Amazon Google, and a few other companies that emulate them, I would tend to agree that the interview process places almost no emphasis on certain types of creativity. They really are data structures and algorithms exams. I'd be careful not to claim there is no creativity tested, as I would argue that there is a kind of creativity in figuring out how to find the square sub matrix with the larges sum in an NxN matrix, especially if you haven't seen the problem before. But it is true, the ability to see the value in software and build something interesting and useful with it isn't tested, at all.

This blog post makes another good observation - if there is a limited amount of time and mental space, the two could even start to negatively correlate.

I've been thinking a lot about this in terms of another hobby of mine, music. Think about the difference between a great session musician and a wonderfully creative songwriter. The first can do amazing things musically, but might draw a complete blank on what he or she has written. The second may only be able play the open chords, but write truly wonderful songs.

Google essentially tests you like a session musician. Can you play a B flat diminished scale? Put together a quick 4 bar run. Oh, the singer needs to do this in E, immediately shift to that scale, and do it again. Here's the song, and lyrics, oh, there's this one tricky part, let's go over that, ok, ready to record? Great session musicians really can do those things.

Aside: Now, some might reasonably object, saying I've given an overly rosy view of what a tech test truly is, because those are all things a session musician does in the day to day job. But what tech interviewers really do is interview a bassoon player, grill her on obscure points in jazz theory on paper, allow her to strum on "air guitar" but never actually letting her pick up an instrument, and in the unlikely event she passes, will later place her as an oboe player in an orchestra, figuring, close enough. Plenty of support for that point of view on tech hiring as well.

And truth is, there are people who are interested in great songwriters, thing is, you don't audition for the role. You need to create great songs and get someone's attention. No creative person can be successful just by being creative.

In this sense, I suppose google (along other large tech companies) does value creativity, it does this by finding and purchasing new technology and startups at 100+ times the rate they would have paid in salary.

Rank and file developers should not be creative. We must follow the rules and do what we're asked to do. Creativity is distractive and destructive. Filtering out too creative candidates is one of the main purposes of an interview in most companies. You can hate this fact, but you won't change it.

So the thing is:

> tricky graph searches

> finding eigenvectors

> building heaps

> balancing trees

> non-recursive quicksorts

All these 'scary' 'hardcore' things are covered in the first year of most good CS programs.