
Why Doesn't Creativity Matter in Tech Recruiting? - signa11
http://prog21.dadgum.com/208.html
======
FrankenPC
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.

~~~
danieltillett
I am also not a “rock star” developer and I would have no chance of answering
all the language trivia questions in an interview, but despite this I have
managed to solve complex problems that nobody else seemed to be able to.

On the topic of language trivia is there anyone out there that can keep it all
in their head? I only spend about 25% of my time writing code and I need to
work in 5 languages (C, Java, JavaScript, PHP and ObjC) on 5 different
platforms (Linux, Windows, MacOS, iOS and Android). I find it impossible to
keep more than a limited amount of all the detail in my brain at any time. How
do you geniuses do it?

~~~
JamesBarney
I dealt with it by specializing on the C#-Windows platform. Allows me to hold
5x the language trivia I would able to hold if I worked on 5 different
languages and platforms :P.

It's easier in the .NET world because a lot of shops for better or worse go
pure Microsoft so there is a standard set of technologies and accompanying
trivia you can learn. Unfortunately you won't get to work with best of breed
products, but the upside is you'll get to familiarize yourself with enough
technologies that you can get up and running fairly quickly.

    
    
       Language : C#
       Database : Sql Server
       ORM : Entity Framework
       IDE : Visual Studio + Resharper
       Client Side UI : WPF
       Web Server : IIS
       Web : Asp.net MVC/Classic etc...
       Client OS : Windows
       Server OS : Windows
       Development OS : Windows
       Cloud : Azure
       Logging : NLog or Log4Net
       Code Generation : T4   
       Source Control : TFS 
       Build Server : TFS
       Unit Testing : MSTest
       Build language : MSBuild
       Deployment : Wix or ClickOnce
       Mocking Framework : Moq or Fakes
       etc...
       

(This list is ignoring many of the different technologies that have been
discarded by Microsoft such as winforms, COM, VB6, etc..)

~~~
danieltillett
Yes I am sure specialisation helps, but as you have rightly pointed out the
amount of stuff you need to know even with one language/one platform is
enormous.

~~~
FrankenPC
It's insane. At one point I was fully fluent in C#, Silverlight, all the
HTML/CSS/Javascript necessary to successfully embed Silverlight, MVC/MVVM, SQL
implementation and design, etc etc etc etc... Being a full stack .NET
programmer is just as crazy as being a full stack Javascript.

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

~~~
scruple
So, how do we find employers that want to hire the most agile, creative, and
curious engineers? I've long given up on trying to locate those companies,
they are unicorns to me after more than 10 years in this industry.

When I switch jobs (for the record, that is > 10 years in and on my 3rd
employer), I, too, need to reach for my trusty, old algorithms and data
structures books and brush up for whiteboard-style examinations and a few
rounds of framework/language trivia.

~~~
sago
On reflection, I want to say more about this.

The problem with "the most agile, creative, and curious engineers", is it is
like "above average intelligence" or "good sense of humour". Almost everyone
_thinks_ they are agile, creative and curious, because - hey - who doesn't
want to be those things? So trying to interview for that is like inviting
people to show you their bullshit circuits.

People who are genuinely agile, creative and curious are as much unicorns as
the people who want to hire them. People who think they are among the most
agile, creative and curious engineers are more numerous than sparrows.

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

~~~
scruple
> 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.

But don't forget the inverse. We had a candidate come on board recently who
passed the interview with flying colors... Except for 1 person who essentially
said the same thing. "You know, I saw something horrible that none of you did,
and I don't think we should take the chance." And here we are, with a bad hire
in a company where letting people go in general is a non-starter (which is
another problem onto itself).

~~~
vlasev
I think you are assuming the problem is symmetrical but it isn't. The cost of
a bad hire is higher than the cost of missing a good hire.

~~~
sgift
People say this all the time, but I've never seen any explanation for it
besides the quite shallow "bad people make bad code which someone has to fix"
.. well yeah, and good people make good code which offsets bad code, so .. why
should the cost of a bad hire (who you can fire in the first few month without
any problems thanks to probation periods) be higher than the cost of missing a
good hire who can - potentially - work for many years for your company and
produce good solutions for a long time?

~~~
sheepmullet
Spot on. Bad hires fall into basically 3 categories:

1) A bit worse than average, maybe 10-20% worse than their coworkers. They
still add plenty of value and with good management and time can be improved.
Just not quite the "gem" hire.

2) Clearly unqualified/unsuitable for the role. Easy to spot and you can let
them go with a couple of months serverence. Everyone is happy. Total cost
maybe 3-4 months wages.

3) Qualified but toxic. Has negative value and can destroy a team. Problem is
these people can get through tough interviews anyway. Having higher testing
standards does nothing to stop these people.

On the other hand a good software engineer, working within a company and
framework that supports them can easily add $1,000,000/year to the bottom
line.

~~~
andrea_sdl
I think the worse that can happen is the 3rd options, although I agree that we
have no information about "How much bad is hiring a bad engineer"

When I'm asked about how I'd hire I always look for adaptability, creativity,
communication, taste. Unless our goal is to find something really skilled on
alghorithims or a specific language, it's just ok if they are curious,
passionate, and communicate.

That said, I still wonder why we put that much emphasis on the language or the
algorithmic skills when what we really care about is culture, passion, and
helpful communication.

Maybe it's just me but I feel like searching for a more human skillset seems
worthwile in the long term

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

~~~
chrischen
Implement a search algorithm in 30 minutes!

~~~
fho
Define "search algorithm" ... simple breadth- or depth-first set membership
queries are easily doable in under 30 minutes.

Edit: I don't want to defend such questions in interviews ... it's just that
almost everybody has done something like this at some point. It should be
easily doable.

~~~
Corrado
Yes, I've implemented several search algorithms in the past, but that was over
20 years ago, in school. I've used libraries ever since for doing mundane
things like this. While I know the general idea around search algorithms, and
given some Google time I could tell you which one to use in a certain scenerio
and probably even whiteboard one, it's not currently "easily doable" for me to
pop one out on the spot. Does that disqualify me?

What about the fact that I wrote an image processing army to churn through
4.5MM images in a weekend? I didn't write the thumbnailing algorithm (yea,
GraphicsMagick) but I did write a GraphicsMagick Ruby gem to work with data
in-memory instead of writing to disk.

Could I do it again, in an interview, on a whiteboard. Probably not, but I
didn't do like that in my real job either.

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

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

~~~
yelloblac
This comment seems really broad, I've worked in big and small companies and
the size of the company had nothing to do with whether or not I was given the
ownership and freedom to be creative. On what basis are you judging that this
is the case?

~~~
geebee
I agree with you, I've had good and bad experiences at big and small
companies.

One thing - I think that if someone is _hiring_ a programmer, that's already
an indication that they are looking more for someone to execute a vision than
to be "creative". This isn't always the case, but it leans that way. People
have an idea, or a need, and they realize they need a programmer to implement
it, so they set out to hire one.

There are some highly coveted R&Dish programming jobs out there at big
companies (such as the old Sun Labs) - smaller companies may have trouble
supporting something like this. But if you want to really be creative, you may
have to strike out on your own, launch side projects, and so forth. It's
tough, because it's hard to get this and a stable salary at the same time.

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

~~~
mrxd
> Creativity is next to impossible to measure during an interview.

Torrance Tests of Creative Thinking:
[https://en.wikipedia.org/wiki/Torrance_Tests_of_Creative_Thi...](https://en.wikipedia.org/wiki/Torrance_Tests_of_Creative_Thinking)

These tests measure how many different ideas you can come up with and how
detailed and original they are. These seem quite easy to measure during an
interview. It doesn't really have anything to do with the formal or aesthetic
qualities of what is being created.

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

~~~
ScottWhigham
And, like it or not, this is one of the main reasons that certifications
matter at some job positions. If I have two candidates that are equal in every
way except candidate A is more creative but candidate B has the XYZ
certification, which one am I going to be better prepared to defend when
pushed?

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

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

------
andrewstuart
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?"

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

Definition:

A great programmer is one who can define/identify the problem which needs to
be solved as put forth by people who have a vested interest (stakeholders),
contributes to or delivers a software solution to said problem definition,
within time constraints allowed for by their stakeholders, and does so to the
acceptance of the same stakeholders.

Q.E.D.

~~~
andrewstuart
That's your opinion. Others will think differently - recruiting is purely a
matter of opinion.

I tried to define it here: 50 characteristics of a great software developer
[http://www.supercoders.com.au/blog/50characteristicsofagreat...](http://www.supercoders.com.au/blog/50characteristicsofagreatsoftwaredeveloper.shtml)

In software engineering terms, specify the requirements that make a great
programmer and if there is science to it then you should also be able to
define concrete test cases that tell you if someone meets each requirement.

It can't be done, doesn't work in real life.

~~~
AdieuToLogic
You originally asked:

> ... actually define in any sort of concrete terms what a great programmer
> is.

And I did. The concrete terms are in measurable aspects of a person who is (or
is expected to be) performing the role of programmer. These characteristics
are congruent with both tangible metrics (such as time) as well as empirically
observable metrics (such as solving the problem at hand and doing so to the
satisfaction of other people involved).

Using software engineering terms to identify a person's ability is invalid.
Attempting to do so restricts the ability to define, measure, and verify with
minimal subjectivity whether or not a person meets the expectations of
whatever subjective classification ("great", "bad", "OK", "senior", "rookie")
being considered.

~~~
andrewstuart
Then you have solved recruiting and everyone agrees with you.

~~~
AdieuToLogic
Sighs.

You presented a challenge for providing a definition for the subjective
categorization of a "great programmer." It was my assumption that you did not
have a satisfactory one, based on how you presented this challenge.

Perhaps the problem domain which you presented is not immediately
recognizable. In defining a concept relating to people, a plausible one will
include terms/metrics/observations relevant to people. This implies a
continuous domain (as opposed to a discrete one) much like what exists in
analog systems.

Attempting to apply binary "yes/no" requirements and/or tests when faced with
a partially observable universe doesn't work. Which is why AI agents use
heuristics such as "confidence factors." And a person with which an
organization has little to no history with presents a partially observable
universe often limited to their CV. Now, a computer program has to do
approximations such as confidence factors because _it_ is a digital entity
(assuming a Von Neumann machine[1]).

But we, as human beings, are not Von Neumann machines. We are analog. Which
implies continuous domain metrics (IOW: a "spectrum"). Hence the fruitless
effort of attempting to apply software engineering best practices onto people.

However, addressing the problem defined as being "evaluate whether or not this
multi-dimensional analog system can be of value to a collaborating set of
multi-dimensional analog systems, for some equally nebulous definition of
value" may reveal that collecting measurements within the observable outputs
of said analog systems has a higher probability of success than one which
attempts to apply measurements/practices for an entirely different problem
domain.

YMMV.

1-
[https://en.wikipedia.org/wiki/Von_Neumann_architecture](https://en.wikipedia.org/wiki/Von_Neumann_architecture)

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

~~~
jacquesm
I do something similar during DD, I usually ask the technical people to show
me the parts of their code that they are most proud of and the parts that
horrify them and/or that are least maintainable.

This gives great insight in their ability to deal with extraordinary needs and
the teams potential to hack their way out of a problem and is a good predictor
for their long term survival.

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

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

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

~~~
sklogic
> set of habits of thinking

This is called engineering

While "creativity" is, most often, an "over-engineering"

~~~
dschiptsov
Or merely sticking an eagle's head and wings to a lion's body.)

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

~~~
spacecowboy_lon
You do know that fusion plant will have a lot of steam turbines :-)

I suspect that mech engineers don't have to memorize steam tables for
interviews.

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

~~~
RogerL
The author's point was that memorization is how you pass these silly
interviews.

There's a wonderful paragraph in Skienna's algorithm book, where he states
that if you can reduce your problem to a graph problem you should do so, and
that you should never invent your own graph algorithm - the standard ones will
solve whatever problem you have. Perhaps a bit overstated, but by and large
true. There is definitely value in having all of that information at hand so
you can fairly quickly perform the mental gymnastics to find a good solution.

I think most people complaining about interviews would agree with that. The
thing is that so many people _don 't_ work in areas where they need at at the
front of their brains, but they do work in areas where similar levels of
ability are needed. Product design, finding difficult bugs, working with
customers, leading teams, and so on. Bad interviews test memorization.

I'm doing almost all linear algebra these days. I can talk to you about matrix
computations, round off errors of various implementations, and so on. You
probably can't. But only because you are not doing it, and I am. I TA'ed a
graduate level Algorithms class. At the time I could do whatever graph
algorithm you wanted, now I can't because it is not what I work on now and
most of the details have fled my brain. Doesn't mean I can't do it, just like
you not being able to implement a Cholesky decomposition on a whiteboard means
that you couldn't do linear algebra programming if it became your job.

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

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

------
fragsworth
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?

~~~
jacquesm
> How would you go about testing creativity?

Solve actual problems to which you currently do not have a solution and
observe the _process_ , not the solution.

~~~
chetanahuja
That road leads to "how many golfballs in a minibus" type of puzzlers and we
already have data now that shows that those things don't work.

[http://www.deathandtaxesmag.com/200732/google-admits-its-
fam...](http://www.deathandtaxesmag.com/200732/google-admits-its-famous-job-
interview-questions-were-a-complete-waste-of-time/)

~~~
jacquesm
That's not an 'actual' problem, that's a fake problem.

I mean actual as in 'problem that you actually have and that needs solving'.

~~~
vlasev
I have to humbly disagree with you here. Estimation problems are quite
important in science. When dealing with computers and algorithms, a quick
back-of-the-envelope calculation can illuminate a lot of things. Maybe your
algorithm is running slowly but a quick calculation shows it needs to be
orders of magnitude faster. Etc.

It's by no means a super necessary skill to have though. And certainly it
makes for a rather silly interview question. I would guess it takes no more
than half an hour to an hour to train yourself to do estimation problems.

~~~
jacquesm
Of course they are important in science. But that's not the kind of problem
that you're likely to be hiring this particular (presumably a programmer) for.
And if it is then estimation problems are exactly what you should be doing but
if they are not then it would be a lot better to pick something related to the
work at hand.

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

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

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

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

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

~~~
MichaelGG
If that's true, then the people creating the orders for these programmers
should simply write code and automate the whole process. We can't do that in
other jobs, like coffee servers, because vision and speech recognition, along
with robotics, are too weak.

But for writing code, we've got all the tools. If "rank and file" just need to
follow rules and do as asked, the asker is far better off asking a computer.

But they don't. Why?

~~~
sklogic
Because our tools suck, and when they don't we are still cheaper than such
tools.

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

~~~
MichaelGG
And yet I've had people literally laugh on interviews when asked to merely
_describe_ binary search (if 10 yr olds can figure it out, it seems fair to
ask a pro). Even if they have a masters in CS.

~~~
zo1
Laugh because it's too-easy, or as some sort of "I should know this, and it's
ironic you ask me, because I can't remember" type of laugh?

~~~
MichaelGG
Laugh because they think I'm joking, cause how could that possibly be
relevant.

