
I Hate Puzzles: Am I Still a Programmer? (2011) - lordbusiness
http://zef.me/3666/i-hate-puzzles/
======
smacktoward
_> I’ve been programming for 18 years now._

Then congratulations, you are a programmer!

Despite what you'll hear from people peddling various flavors of Kool-Aid,
"programmer" isn't a personality type. It's a job description. If you program,
you are a programmer, end of line, full stop. Don't let anyone convince you
otherwise.

~~~
silverbax88
This. So much this.

I'm a programmer who loves 'building the brain'. I've been coding
professionally for about 16 years.

I've written some code I'm really proud of. A couple of specific pieces of
code are actually used in a LOT of major websites you probably use. Like
almost every health care site or major retailer site. I actually find most
code written by 'whiz' startups - even successful ones - to be incredibly
simplistic. Not a knock on them, just stating this for reference - I have even
written some encryption code that gave me headaches to understand but is still
in use by a few major financial corporations years after I wrote it. I know I
can write some serious code. I studied and work with AI programming in my
spare time.

I don't have a GitHub page, nor do I have an interest in having one. I barely
have a StackOverflow profile. I post on Hacker News now and again but that's
about it.

I don't care about hackathons or solving puzzles.

I hate the term 'nerd' or 'geek'. I am neither and I find the terms insulting.
I'm just smart and I like to code. I am not socially awkward. I'm introverted,
but I'm not shy. I played football and basketball _and_ I played chess. These
concepts are not mutually exclusive.

~~~
computerjunkie
I agree.

 _> >> I don't have a GitHub page, nor do I have an interest in having one._

Glad I'm not the only one.

 _> >> I don't care about hackathons or solving puzzles._

Couldn't have been said any better. I never produce anything good when its
tightly timed, under pressure, when people are watching over you.

 _> >> I hate the term 'nerd' or 'geek'. I am neither and I find the terms
insulting. _

Add "ninja", "guru", "rockstar" and other hipster name floating around these
days to your list. I hate it too.

I've been doing programming for 3 years on and off. I program for fun, as a
hobby and I can't see myself programming to meet unrealistic deadlines year in
year out for someone, that's my personal opinion. I grew up in an athletic
environment so I also play rugby and sprint for fun too. The most I would do
is to program small projects _at my own pace_ and share them to people or keep
it to myself. I hate rushing into things which I feel hackathons encourage.I
like to _think, research, think_ and then create.

I program because I generally like _making things_ , not just programs but
also technical drawing, house designs (architectural and interior) and custom-
modded computer builds , it has no correlation to solving puzzles or cramming
algorithms I probably will never use.

Edit: There is this insanely think barrier filled with confusion in Human
Resources, as a recent Computer Science graduate, some of the job descriptions
have unimaginably high expectations for entry positions I actually think you
have no place here if you don't know 4+ languages, 2+ trendy frameworks, and
1-2 years of experience from a _fresh graduate._

~~~
mavsman
I wish programming culture didn't scare away people who enjoy athletics. I
love playing basketball and sometimes it's hard to find other programmers who
enjoy the same.

When I see "Ninja", "rockstar", etc. I run. Can't stand that.

------
delecti
The problem isn't with him, it's with programmers who have an inflated view of
how smart you have to be to be a programmer.

There are plenty of smart programmers, and there are plenty of problems that
would benefit from smart programmers, but the vast majority of problems just
need a spark of creativity and a lot of hard work from a person with a
reasonable base of knowledge.

~~~
raverbashing
And then people don't know where impostor syndrome come from...

With a lot of BS being spewed on the net like "everybody needs to know how to
unit test", "everybody should learn how to use Vagrant", "everybody should
know Ruby", "knowing the SOLID principles is essential"

And then you ask them how to write a regular expression and they fall flat on
their face. Or the basics of how to do a Fourier transform. Or how to draw
something on a canvas.

~~~
klibertp
You realize that regexes, fft and canvas APIs can be seen as the same kind of
thing - as simply tools - as unit tests, Ruby and SOLID (whatever that is)?

Some tools are usable in more contexts, but you can still lead a perfectly
healthy life if you are in a domain where the ones you don't know are not
needed.

~~~
kazagistar
SOLID is a set of (possibly questionable) religious principles often espoused
by OOP programmers. It tends to boil down to "keep things modular and don't
break abstractions", with specifics guidelines for dealing with objects and
inheritance.

~~~
raverbashing
> SOLID is a set of (possibly questionable) religious principles often
> espoused by OOP programmers

Exactly my opinion

There's a good side to it, but it's mostly used for people to (in a cargo-cult
way) abuse OO and replace simple computations with something spread over 5
levels of inheritance and lots of different types.

------
karl_gluck
Definitively: Yes!

Everyone has their own preferences. Like you, I lose interest in puzzles after
a few minutes. Whatever it is that gives some people great satisfaction out of
finding that one missing piece, I didn't get it.

I can't speak to your experience, but for me, I like architecture. Finding the
right way to glue pieces together is actually very interesting to me. I
basically implemented reflection in C++ before I even knew that's what it's
called because I thought it would be fun. I enjoy debugging and assembly
optimizations.

What I found is that this speaks to the difference between a prototypical
Software Engineer and Computer Scientist.

Engineers are interested in getting stuff done efficiently, and not just in
CPU cycles--time for coding, training new coders, maintenance, extensibility,
and how often the code will ever be run all must be taken into account. In my
experience, grabbing someone else's solution via a package manager or using a
10-minute brute-force solution to a very hard problem can be the most
"efficient". Just throw comments on it and avoid the puzzle so you can get
something working. Of course, be sure to isolate the code so that if it ends
up being a hotspot it's easy to fix later.

Computer Scientists, on the other hand, seek that efficient solution. Many of
the PhD candidates I encountered were optimizing very specific cases of very
hard problems (largely related to distributed computing). They enjoy spending
time picking apart algorithms and understanding the problem so thoroughly that
they can prove, confidently, that they have the most efficient solution to any
given problem.

In the end, each broad category relies on its partner, and all programmers
have to have some of both. Some of us just lean harder to one side than the
other.

~~~
mod
I don't think you can determine what kind of SE/CS you have by whether or not
they enjoy (tabletop) puzzles.

I have always enjoyed puzzles (although I rarely do them)--I think it's a part
of something greater. I like to complete all the achievements in games. I like
checking off tasks in task lists. I like cleaning my plate at dinner.

They all feel the same to me, and have little to do with how I operate as a
computer programmer (speaking as a web application developer).

------
maxlybbert
Dijkstra commented on this multiple times (e.g.,
[https://www.google.com/search?q=dijkstra+puzzle+minded+ewd+s...](https://www.google.com/search?q=dijkstra+puzzle+minded+ewd+site:cs.utexas.edu)
).

"I still often hear that a successful programmer should be 'puzzle-minded'
whereas I have the feeling that a clear and systematic mind is more essential.
A modern, competent programmer should not be puzzle-minded, he should not
revel in tricks, he should be humble and avoid clever solutions like the
plague" (
[https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/E...](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html)
).

~~~
yen223
Having seen people banning list comprehensions from Python because they are
"too clever", I am wary of people who instinctively avoid "clever solutions".

~~~
wes-exp
For me something like list comprehensions is simply a matter of learning and
expertise, not cleverness. Somebody banning them for "cleverness" reasons
should be called out for what they are really doing: setting a (sadly low)
knowledge ceiling.

The real problem of cleverness is when people are bored of being code monkeys
and start inventing things that complexify their project without any
legitimate justification. Like "a cron job and a two line shell script would
do but why don't I design my own multi-tier scheduling cluster"

------
bguthrie
Puzzles are a terrifically poor way of judging whether a candidate will be
good at performing the most common form of programming there is: solving
meaningful problems, often business or interface ones, in a simple and
readable way. Your primary audience for this type of programming is other
humans. I'll take a good writer over a puzzle-solver any day. Don't get
discouraged if they aren't for you.

~~~
am391
> I'll take a good writer over a puzzle-solver any day

Absolutely agree, but I'd extended it to good communicator. Communication
touches on so much of what we do as programmers, be it talking to customers,
sharing ideas amongst a team or writing code in a way that's readable by
others, that it should be a primary concern.

------
Smudge
> Could you please solve this algorithmic puzzle within half an hour? I
> failed. Hiring decision made. End of story.

If that alone was the reason, then your interviewer did a bad job.

The point isn't to trick you. It's to see how you work under pressure when
presented with a tough problem. What is your thought process? Do you dive
right in or do you take time to chew on it? What parts of your background can
you draw on to help you?

It certainly helps your chances if you can solve the problem, all else being
equal, but I'd rather take someone who talks through their work but _doesn 't_
quite solve it over someone who solves it yet has trouble explaining how or
why.

The best interview questions are layered. There should be a relatively easy
solution solvable in multiple ways by anyone with experience programming. It
should almost solve itself if you walk through the specifications. (Think
fizz-buzz-level.)

But underneath that should one or two harder problems with very elegant
solutions. And those are much more about the process -- about weeding out the
people who would dive in without really thinking it through. If you make a
mess of the whiteboard, get frustrated, start desperately erasing and
rewriting the same things without ever stepping back to think through
alternatives... well, that might be what I'd hold against you. It's not that
you didn't solve it. It's that you didn't prove to me you could've given more
time.

~~~
computerjunkie
_> >>If that alone was the reason, then your interviewer did a bad job._

Then most, if not all these of recruiters are bad. I like to think through
things and take time solving problems. If I see myself doing something and
struggling to complete it, I haven't thought it out properly or I have rushed
into the problem.

Some people will call you "slow" which I find insulting. For example, When I
read a book I like to read the actual sentences rather than skimming over
them. I like perfecting details and that sometimes takes time.

~~~
Smudge
I like taking my time too. The best solutions come to me after days or weeks
of chewing on the problem in the back of my head.

Experienced interviewers know that this is how people solve problems. They
know that time-boxing the problem is artificial, so they're not exactly
evaluating you on how fast or slow you are within that time. The problems
should be constructed in a way that lets them evaluate you based on your
_approach_ instead of on your _solution_.

Sometimes it's just a bad interview question, or not the right question for
you, the interviewee. Which is why interviewing takes practice, time, and
patience, from both sides of the hiring market. It's far from perfect, but
more "puzzle"-like questions aren't entirely useless as long as the
interviewer really knows what they're doing and how to guide the interviewee.

------
ChuckMcM
Silly question of course, anyone who has programmed for 18 years is a
programmer. But the missed question is "Am I a hacker[1]?" And it is _that_
which puzzles attempt to ferret out. Let's take the example of the 1000 piece
Escher puzzle that the author uses as an excellent example. They are correct
that most of the pieces are just 'shades of grey'. Impossible right? If you're
a hacker you say "Challenge accepted!" if you're not you say "This is way more
work than its worth." Because what the hacker mentality gets reinforcement
from, is overcoming the 'impossible' (or simply the 'you can't do this') not
the actual puzzle assembly.

So in the Escher puzzle a hacker says, "Hmm the picture isn't much help, its
not on most of the pieces. What else can I use? Shape!" and so first will
attempt to identify every piece that has a shape suggesting it is on the edge
of the puzzle. Next puzzle pieces themselves have a certain symmetry, with
some 'coves' and some 'penisulas' (or convex and concave curves, or 'innies'
and 'outies') so unknown pieces are often sorted into the number of those
features they have. Basically the hacker is looking for any piece of
information that can inform on a possible way to get to the end, generally
that information is non-obvious at first, more obvious once you find it.
Particularly delicious puzzles will have several layers of information.

So if you don't care to figure out ways to solve a problem that is, at first
glance, either really hard or nominally impossible to solve, you can still
program just fine but you need a set of rules for putting together your code.
And you won't find yourself asking if they are the best set of rules for the
particular problem you are coding, you just make sure the problem is solved.
That is a perfectly valid programming model, it gets things done.

[1] And I'm using the puzzle solving / bounds testing skill here not the
application which can be applied to good or evil.

~~~
chavesn
> if you're not you say "This is way more work than its worth." Because what
> the hacker mentality gets reinforcement from, is overcoming the 'impossible'
> (or simply the 'you can't do this') not the actual puzzle assembly.

Hmm, up until this, I thought I was a hacker. When I see a problem worth
solving, I'll dig in and try different tools that I've never tried before and
figure out a way to make it happen. I really resonate with what you said about
not being deterred by the problem seeming extremely difficult or having no
obvious solutions.

But I actively try _not_ to work on things that are "more work than they are
worth". Seeming "impossible" is not enough to me to make it worth. It has to
actually provide some benefit.

This is not to say I don't still get carried away and attempt something which
really ends up not being worth the time...

~~~
ChuckMcM
Fair enough, I see it as something of a spectrum. From full on OCD[1] on one
end where once engaged a puzzle must be finished, drifting off toward zero
(not sure how to compute the shape of that curve though). For the OCD person
it is a compulsion, for someone just to the right of that, it is
entertainment, further right its part of the job, and furthest right it is 'a
waste of time and I won't do it.'

I completely agree with your point _" When I see a problem worth solving,..."_
the only debate is computing the value. My original point is that as it takes
less and less external motivation to engage someone on solving a
puzzle/problem they exhibit more and more tendencies of what I associate with
the moniker 'hacker.'

[1] Obsessive Compulsive Disorder

------
darkFunction
I dislike puzzles too. I guess because you're just finding the creator's
predefined path, and it often feels like a pointless task. Programming is
coming up with original solutions of your own, so I don't see the two as
wholly related.

~~~
dntrkv
That is exactly how I feel about puzzles. They just feel like such a waste of
time, especially jigsaw puzzles. What do you even do with them once you're
done?

------
nemo1618
Anyone have a not-dead link to the comic he's referencing?

(looking forward to a future where an image's URI is its hash and this problem
evaporates)

~~~
fredsted
Here you go: [http://mu.ms/f/pxYcdb.png](http://mu.ms/f/pxYcdb.png)

~~~
userbinator
People who feel that way in their day job should really try participating in
the demoscene.

------
nathanb
The most challenging aspect of programming, for me, is the ability to turn
something over in my head to look at it mentally. To be honest, I can only do
that for any length of time on a good day. Writing stuff down is laggy and
sometimes lossy, so I am only at my most productive when I can take a complex
problem with a lot of little fiddly bits, ingest it mentally, and keep a
holistic model in my head.

Puzzles provide a good first-order estimation of this ability. Not solving
puzzles, per se, but at least analyzing them. A good puzzle requires you to
use a part of your brain as "scratch space" to hold hypotheses which are
applied to other parts of the puzzle. Can I solve it this way? What if I tweak
this part over here? Does this assumption simplify the path to a solution, or
miss out on an important subtlety? I think the thing I tried previously was
more correct; can I remember how to get back to it?

I'm actually not that great at this. Many of my peers are better. Fortunately,
I can compensate in other areas (I'm glad to see writing skills called out in
the comments, as I like to think I'm a good communicator). I have developed
some coping mechanisms (the ability to identify which details in a problem can
be succinctly written down and which subset can be stored in my head -- I
refer to my notebook as swap space), but I do see the value of puzzle-type
questions for evaluating a candidate's ability to do this sort of thing.

Does this mean that if you can't do it, you aren't a programmer? Of course
not. I happen to be a kernel developer, so I write a lot of code that
communicates with other modules, doesn't have much of a UI, and has a multi-
dimensional rather than flat structure. Different types of programming need
different sets of skills. Find your niche, and don't fret about how you don't
fit into other niches as well as you fit into yours.

(I interviewed at Google seven years ago and was rejected for being weak at
algorithm design. A few years ago I had an aha! moment where I found a simple,
elegant, and easy solution to the problem I completely bombed in the
interview. Apparently my subconscious had been chewing away at it for
literally years. I think solving a question in four years or so is sub-optimal
from Google's perspective so I'm sure they were right to reject me, and my
inability to do it faster speaks to the deficiencies I mention above. But in
the ensuing years I have become reasonably successful in my current line of
work, which I enjoy completely. My failure at Google does not keep me up at
night.)

TL;DR: Puzzles only measure a single axis, so find which axis your greatness
lies on and optimize for that.

------
lukaslalinsky
I don't hate puzzles, but my brain just refuses to work on something that is
not important to me. That's why I can't play go/chess well, I can't do sudoku
and I can't solve algorithmic puzzles. Even when working on a real algorithmic
problem, my brain just refuses to analyze whether something should be x or
x+1. Those are things I can easily try and see.

I had a number of technical interviews last month and the conclusion was that
because of this, I'll never work for a company that uses this kind of
interview process. I just can't take the puzzle questions seriously enough to
be good at them. But the experience also made me question whether I am still a
programmer. Fortunately, I have written some algorithmically complex software
to convince myself that I am.

~~~
computerjunkie
_> >> I don't hate puzzles, but my brain just refuses to work on something
that is not important to me._

Another Human Resources blunder. I really would like to ask them, where and
when am I going to use this in one of your ongoing project? If the answer is
not related to the project, there is something wrong.

------
valas
Google and Facebook long ago stopped asking (or at least now they discourage
their interviewers from asking) puzzle-like questions in their SWE interviews.

~~~
foobarqux
They stopped asking brainteasers, they didn't stop asking algorithmic puzzles
(some of which are arguably brainteasers)

~~~
SomeCallMeTim
...and which seem to largely be collected in the book Cracking the Coding
Interview [1]. If you can answer all of their sample questions, you should do
fine at a Google interview -- once your brain is used to the task of solving
small algorithmic problems, it should get easier, even if the precise question
they ask isn't in that book.

Easy for me to say, since I find problems like those easy; I cranked through a
few dozen of them with only having to really think about a couple.

If you can't answer them all yet...well, now you have something specific to
study.

[1] [http://www.amazon.com/Cracking-Coding-Interview-
Programming-...](http://www.amazon.com/Cracking-Coding-Interview-Programming-
Questions/dp/098478280X)

------
skybrian
This discussion is going to be mostly meaningless because everyone has a
different idea of what a puzzle is. Whether or not something is a puzzle
depends on what you know. To a beginner, writing fizzbuzz is a puzzle. To
someone with ordinary programming skill, it's not.

The question I usually ask in a job interview is an adapted version of
something I actually had to solve, and if you don't know how to either use
pointers or how to build and print a tree then you might think it's a puzzle.
If you do then it's just applying your skills to the task at hand.

Maybe there are other questions I could ask, but it's a job interview; how
else are you going to find actual programmers?

------
austinz
I hate "puzzle" questions where there's a single insight with which the
problem becomes trivial, without which the problem is unsolvable, and it's a
tossup whether or not you'll come across it in the 30-60 minutes you spend in
a room with the interviewer.

I do enjoy questions where there the path to the goal isn't immediately
obvious, but there are immediately a couple of approaches to consider, and
even though the problem itself might be novel, the steps to get there are each
something a competent person can reason about.

------
emotionalcode
I don't know. I like getting close to code, because I like thinking about the
people that make each symbol, establish a meaning, weave that into a language,
where it is either contextually derived or explicated clearly. I like watching
those things change and I like figuring out why some things stay the same. I
like selecting words for new concepts, which I am never really sure of whether
these things are arbitrary. When I zoom out and generalize enough, everything
shares the same fuzziness, these symbols are all puzzle pieces. But when I
zoom in, each puzzle piece is the puzzle itself.

I grew up enjoying puzzles, logic puzzles, logic books, math books, piece
puzzles, riddles, and all the supposedly clever things to that affect. The
more involved I become in the world of programming though, I can't really say.

I have the time to study the complex math and computer science theory
sometimes, on the weekend, for fun, and then the code I read through ranges
from deeply personalized learning to clear, uniform specifications developed
over time periods I have no actual experience understanding what goes on
during those time periods. I know the importance behind many theories, and I
understand how to apply these things. But I don't know why or how it grew.

If you want to see a puzzle pattern in code, you will see puzzles everywhere.
You can see anything you want to in code, just like every other human
creation. Make your own meaning and what not. Code is more art to me than
'Art' is.

------
iceberg
Does a lack of interest in solving (mechanical) puzzles imply you're a weak
programmer?

I really don't think so: I think it all comes down to how you think -
intuition versus logic. And I think people don't fall neatly into either
category - it's a spectrum. Too much emphasis is placed in interviews on
solving mechnicaly problems and less on problems that can be solved more
suitably by itutition: design, feature improvements, re-factoring and some
people (including me) I've found have to internalise the problem and can't
just simply solve a problem as qucikly as those who are very mechanically
minded.

And besides technically ability is part of being a professional(!) programmer
working with others. The following should also carry significant weight: an
ability to work with others, take criticism, lead others, be resourceful, get
stuff done on time, write clean and readable code (not just solve the problem
technically) and so on are from _my(!!)_ experience not given enough weight!

Just me two cents.

------
MCRed
This is a feature not a bug-- let me explain:

Recruiting is not necessarily easy. But you can judge a company by how they
recruit people. Their hiring process-- given that talent is so critical--
tells you a great deal about the company.

If they do a terrible job, if they are arbitrary or capricious, or if they
have discrimination as a policy (e.g.: I was in the room at Startup School
when Zuckerberg said "don't hire anyone over 30, they just don't get it"
(paraphrased).... then you know it's not a good place to waste your time
interviewing.

I'd argue that the company with the puzzle saved you a lot of hassle-- you
know they are arbitrary and did not put the effort into producing a competent
hiring process, and this likely tells you that they won't respect you once
you're on board as an employee either.

There are a great many of these "smells".

As I've gotten more experienced, and more in a position to be picky, here's my
current gauntlet:

\-- If they locate themselves in a place that guarantees a 2 hour commute for
most employees, but don't allow working from home 3 days a week, or remote
employees, that's a bad sign. Why pay for downtown office space-- as a
startup, no less! -- when there's a lot of cheap offices out in the periphery
where most people live? (That's the case in this town, maybe not in others.)

\-- Asking for references. First off this is a legal minefield. A reference
that isn't glowing is going to open themselves up to liability. Any well run
business is only going to say you worked there for some period of time. And
who is going to give people they think will give a bad reference? This one
shows naivety.

\-- Having a preference for ivy league. Google impeaches itself with this one
in my mind.

~~~
vonmoltke
> Asking for references. First off this is a legal minefield. A reference that
> isn't glowing is going to open themselves up to liability. Any well run
> business is only going to say you worked there for some period of time. And
> who is going to give people they think will give a bad reference? This one
> shows naivety.

I recently stumbled across two research-oriented companies that demanded
references _as a condition of reviewing your resume_. I can't believe they get
very many good candidates with a borderline offensive requirement like that.

~~~
MCRed
Just imagine if every company did that-- your references would be overwhelmed
with phone calls.

My policy, in the past, was that I'd give references after getting an offer,
so that the references would only have to spend their time on a job I wanted
to take.

------
hangonhn
I think some of it comes from our notion of human intelligence being
universally applicable to all problems. Puzzles and chess are often used as a
proxy for that. The thinking goes is that if you're smart then you'll be good
at puzzle solving. If you're smart then you'll be a good programmer. It's not
really something that has a lot of evidence for. One of the best career advice
I've received is to interview with lots of companies but do it in the order of
least wanted job first so by the time you're interviewing for the job you
really want, you have had lots of practice. It works pretty well. Puzzle
solving and programming are both skills that you get good at with practice.

Someone else already commented that if you program then you're a programmer. I
think that's really the only definition you should use. Everything else are
just proxies, mostly bad ones, for if you're a good programmer or not.

~~~
titanomachy
> ... if you're smart you'll be good at puzzle solving

There is some evidence in psychology that many seemingly unrelated types of
intelligence are correlated with each other. For example there is correlation
between verbal and spatial reasoning ability. Sure, there might be people who
can solve differential geometry problems in their head but have terrible
language skills, but those people are outliers.

Whether this has relevance to hiring programmers is debatable, but preferring
intelligent candidates isn't an unusual idea. Law, medical, and dental schools
base their selection on what is essentially a verbal reasoning test (LSAT,
MCAT, DAT) though it's hard to imagine that verbal reasoning is the most
important part of being a dentist. They follow the same thinking.

------
nemo
I really like certain types of puzzles - figuring out the causes of bugs,
figuring out how to implement something in code cleanly and elegantly,
figuring out how to make sure something is designed maintainably and
intelligibly to spare future grief, figuring out the mysterious ways of
programmers who wrote code I now maintain.

I also like figuring out and implementing the right algorithms for a problem,
but it's a pretty small part of what I do at work, and if it's complex, it's
something I like to take some time to think through and sometimes read up on
to make sure I really understand what I'm getting into, so I really don't like
playing the logic puzzle games they use in interviews at some places. Being
quick with an algorithmic answer is a nice skill, but being a good programmer
is a craft that involves more than cleverness with algorithms.

------
jbaskette
It is well known that the ability to solve mathematical puzzles was used as a
screening tool at places like Google to screen new hires. It seems to me that
this practice was based on the belief that there was an affinity or
correlation between the interest and ability to solve mathematical puzzles and
programming. I suspect there is such a correlation, but it is a weak one and
is not useful as a screen tool for hiring which is why the practice has been
dropped. But, jigsaw puzzles are not mathematical puzzles, so there may be no
correlation at all there. I love mathematical puzzles, but I am bored with
jigsaw puzzles.

So, since it is not the case that loving jigsaw puzzles implies "ability and
desire to be a programmer", then the fact that you hate jigsaw puzzles implies
nothing with respect to your status as a programmer.

------
chavesn
Ok, but a _jigsaw puzzle_ is sooo not the kind of _puzzle_ that programming is
at all about, even the explicit "puzzle" questions that companies like
Facebook dish out.

I can't even think of one similarity between the two activities.

~~~
bentcorner
As far as jigsaw puzzles go, it would be interesting to see if there are
unique ways to optimize your piece search.

There's the edge pieces and sorting by color. I've found that sub-sorting by
pegs/holes can dramatically help - I had a "picture made up of pictures"
puzzle which allowed me to correctly orient the pieces. Knowing even just two
of the required slots, combined with the color, reduced the search to a
reasonable brute-force search. Plus, by sorting the pieces you could actually
do a brute-force without feeling like you might have missed a piece.

------
Blahah
I personally dislike puzzles (of the toy/jigsaw variety), riddles, and so on.
But I love solving problems when programming. A programming problem abstracted
to a word problem is no longer fun - you've taken away half the toolset I have
for tackling the problem. It's the synergy between mind and machine that gives
me deep joy when programming - the fact that the tedious repetitive parts of
mental gymnastics are turned into creative problem solving, which in turn
leaves me more time for creative solutions to the problems that weren't
repetitive.

------
Xyik
People forget there's a distinction between Computer Scientist / Data
Scientist / Software Engineer. They are not one and the same, and depending on
your job you may only need to be one of those three categories. You don't need
to know how quick-sort works create a CRUD web application, but you sure need
to know how to write clear, maintainable code in all areas from the stack. But
if that's all you know you can't expect to excel at a job like generating the
Facebook news feed which actually involves theoretical knowledge.

------
throwmeout
I couldn't agree more with this article.

I pursued Computer Science in the hope of being recognized for the ability to
create something NOT in the ability to regurgitate the most arcane algorithm
in 45 minutes. Most interviewers KNOW they would NEVER like NEVER use it in
production.

Yet, I'm not happy at my current job. What option do I have but to remember
the 5th variant of the problem I saw in Cracking the coding interview? None.

Back to chugging. </rant>

EDIT: Thank you for writing this article! Till today I thought I was an idiot
for not being able to solve 'that' problem.

------
lostcolony
Interview questions you don't like/fail shouldn't be viewed as reflective of
you, but reflective of your fit at that company.

They asked a puzzle-y question you couldn't solve? Either their problems are
puzzle-y, or they have terrible criteria for evaluating people; either way, do
you really want to work there?

They asked a hard algorithmic problem, the kind that was someone's PhD thesis
30 years ago, and which you'd only get the optimal result to if you'd seen it
before? Either they really do expect you to know stuff like that off the top
of your head, or they expect you to behave a certain way when confronted with
stuff you don't know; either way, do you really want to work in an environment
with those kinds of expectations?

They asked you to code something hard withing a short time limit, and while
you can code it, you failed the time limit; do you really want to work
somewhere where speed is -the- criteria to optimize, rather than
quality/maintainability/whatever (or at least where they're selecting for that
rather than those other attributes)?

Etc.

In general, as others have said, if you program, you're a programmer. What
specific roles you're a fit for is largely orthogonal to that.

If you don't pass a company's test, view it as having dodged a bullet, not
having 'failed'; either they expect you to have something from day one that
you don't have, or they are terrible at testing for what they really want, and
so their culture, codebase, etc, is likely miserable. In neither case do you
want to work for them.

You want to work for a place whose expectations for what you have on day one
fits what you actually have (whatever they may be), -and- whose interview
process tests for that (even if it's a little flaky), so both you and they can
expect, going into the job, that you can handle it.

Remember, too, that there are false positives and false negatives even when
they're testing specifically for what they want. Failure to figure out a
puzzle doesn't even mean the person isn't good at figuring out puzzles; just
that in this case, in this contrived, high stress set of circumstances (an
interview), they were unable to come up with an answer in the time limit.

~~~
rdtsc
Agreed on all points.

But how would you interview a candidate? I see what not to do.

Here is what I do:

* Ask about their previous work. Dig into something they are excited or proud of.

* Try to solve a problem together. Usually a simplified version problem I am actually solving at the moment at work.

* If it is a new grad. I will ask them some simple questions about data structures, school projects.

* If there is any sample code, anywhere, I like to see it and it is a big + sometimes.

* See if and what kind of questions they ask.

Does that work? What would you add/remove?

I try not be a "dick" and take the approach of "ok, let's work on this
together" approach because that is how things work here.

Another approach (which I don't like as much) is to go by the "we want to hire
smart people" mantra. "smart" here is is nebulous of course. So how do you do
it? IQ tests. Oh but those are illegal, so just write a tests that looks like
one without calling it an "IQ test". That involves puzzles usually too. So I
think that is how puzzles became popular.

~~~
lostcolony
Depends what you're looking for. None of the prior methods are -bad- if
they're what you're looking for. I don't even object to IQ tests masquerading
as not-IQ tests; it serves as a warning to me I don't want to work for you.

Depending how many applicants you get, I'd start with a screener, a basic,
customized problem that they get an hour to solve, that doesn't have a hard
pass/fail, but is just a "Hey, let's see how they code when given a problem".
If you have constraints you want to filter for, now is the time (you want
speed, see above. You want production quality, give them more time than you
think a basic implementation would take, and indicate you want the thing to be
production quality; see what they do, what they ask, etc).

If they pass that, yes, what you describe sounds fine, if it's what you're
looking for in a hire.

If you want to favor false positives, ask a variety of fairly trivial
questions; you're trying to make sure you ask questions they may not have
solved before, but which any reasonably competent dev can solve. Bonus points
if the person scopes them beforehand.

If you want to favor false negatives, ask harder questions, but make sure they
actually are ones you deal with. If you're writing basic business CRUD apps,
and your challenges are really in deployment, reliability, gathering and
responding to user needs, etc, asking them to implement something from
Cracking the Coding Interview is counter to your purposes. Ask them instead
what it takes to build a reliable system. Are they familiar with doing that?
What are some of the considerations? If they suggest distribution, are they
familiar with CAP? Etc.

Really, it all depends what you're looking for. If you want someone who is
keen to learn about the domain you work in, ask them if they know about things
they have no reason to know about, and indicating that "it's okay if you
don't"; see if they admit it. See if they respond with enthusiasm when you
start to explain it, "Oh, that's cool!" when confronted with a new idea is
probably someone you want, "Huh, okay", maybe not. Etc.

I readily admit, hiring is hard, extremely hit or miss, but a lot of companies
seem confused about how it's supposed to work; don't borrow the interview
practices of another company in a completely different industry. Google asks
those questions? Google -can- ask those questions; they're trying to filter
out people. You don't get 1000 applications for every job opening, you can't
afford that. You also aren't dealing with the same problems; someone who fails
those questions may still be a great hire for you.

------
dlwj
"The Tao that can be spoken is not the eternal Tao The name that can be named
is not the eternal name"

Once "art" becomes defined, it ceases to become art. The barista ceases to
become important once a machine can replicate the exact results. The artist
becomes useless once his or her method can be codified and repeated.

The method of choosing good engineers also becomes useless once it is defined
because then that standard can be copied without regards to the traits it
originally was trying to gauge. Pure arbitrary processes aren't great because
of the lack of transparency that encourages nepotism, but neither is a purely
mechanical approach that opens itself to becoming gamed.

A heuristic exchanges information for faster processing. When heuristics are
passed around, the original information is lost. Almost everything we do is a
heuristic though. 3 meals a day, brushing teeth everyday, etc... Is it better
than nothing? Probably. Is it great? No. But everyone offering a "solution"
isn't really offering a solution. They're just telling personal stories about
what heuristic worked best for them.

The job interview process is quite similar to the friend making process. Not
everyone is going to be your friend, and following scripts like saying hello
every morning isn't going to do it either. It's just one of those things that
are part of life.

------
floating-points
This. A thousand times this. After going through the rounds of interviews at
various companies as someone who's not particularly strong in the algorithm
department, I've often felt frustrated. I think my strengths are in making
good sensible design decisions for a given problem, and being able to manage
the complexity of a system; but I've never been able to really show that in an
interview. I've seen work from colleagues that solves a simple problem, but
makes extensive use of obscure C++ template features. Maybe they were great at
algorithms, maybe they weren't, but they certainly weren't capable of coming
up with the simplest solution.

I've dedicated lots of time learning graph algorithms in order to get better
at interviews: I've only had a graph problem come up once in the last 5 years
of programming, and it wasn't particularly tricky (it came up at a time I knew
nothing of graph problems, and kind of figured out a graph structure by
myself).

When I'm at work, I find I have a knack for keeping things simple, and get a
feeling for when certain solutions are a bad idea. For me, software
engineering is really about the engineering (make things that meet
requirements with the given resources), and from my experience is not so much
about being able to implement and provide the time/space complexity of 10
different sorting algorithms (although knowing the basics is important).

It's genuinely a relief to see many other people relating to this kind of
experience, sometimes it can feel like you're the only one!

------
brandonmenc
Yes. I hate puzzles too, and so do most of the other programmers I actually
like hanging out with.

I know this is a "me too" post, but that's kind of what you're looking for.

~~~
daddykotex
Same thing for me, I could recognize me while reading your post...

The definition of a "programmer" is very subjective.

------
MrQuincle
I definitely agree with this sentiment. Recently someone dropped by for a job
interview and revealed how much he loved to solve puzzles. Not that this
influenced my decision in any way, but it made me reflect how different I felt
w.r.t. this.

For me, it is not design either, it is something different.

I hate puzzles that are created by other people, where you have to follow the
"hidden variable" which is in that case the brain of the maker of the puzzle.
They already know the solution! I feel utterly useless solving a puzzle that
has been already solved thousands of times by others. What's the point!? After
3 sudoku games I'm done with them. The same with IQ tests on national
television. Why would I feel any reward in being able to crawl into the brain
of a television writer concocting questions for a general audience? I think
there are many much more interesting people in the world, than these guys.
Their "puzzles" suck.

I also have never enjoyed solving mathematical problems in text books. I love
math, and I read a lot of text books, although university is years ago. I
think for people like me there should be different ways to teach them.

What makes me going is to find new things that haven't been known before.
After I get some understanding of a field, I love to make up my own problems
and solve these. The boundaries of such a problem are vague, it is not even
known if it can be solved, but I am happy. Even if it turns out that I solve
something that has been solved in the 13th century, I can't care less.

This is just a personal story, but perhaps someone can relate.

------
kstenerud
Evaluating a programmer by how well he solves a logic puzzle makes about as
much sense as evaluating a race car driver by how well he rides a horse.

~~~
gaylemcd
Then it's good that Google doesn't really ask logic puzzles. (That link to
Google questions is full of fake questions. Just link bait.)

------
sriku
Yup. The way I like to express this is as follows -

It took Einstein about 10 years to formulate the general theory of relativity,
needing no further experimental input into the work during this period. A few
other scientists such as Wheeler, Schwarzschild and others, not to mention
mathematicians like Riemann, put in at least as many "top scientist years" of
time - about 20 TSYs in all, conservatively. The core content of this is
taught in grad school these days over one semester and could be considered
about 1/2 grad student years worth of intellectual effort.

So what did these people do for the remaining 19.5/20 of the time? They got
hold of a problem that wouldnt let go of them, that they poorly understood,
but nevertheless persevered through false starts, uglifications, and what not
to arrive finally at the beautiful theory that it is.

i.e. Problem finding and perseverence through foggy days with all but a candle
that seems to threaten to blow out any minute is at least 40x harder and that
much more valuable than problem solving.

I believe your phd would've served you well on that front.

~~~
titanomachy
> needing no further experimental work

General relativity is an incredibly impressive theory, even more so when you
take into account how few experimental observations were required to formulate
it. Basically "the speed of light is the same in any frame of reference" and
"being in a gravitational field is (locally) indistinguishable from being in
an accelerated reference frame". (For the second one, think about being in a
rocket ship accelerating at a constant rate... you feel a force pushing you
into the floor, just like you would if you were standing on the Earth's
surface.)

If those two things are true, then GR is the only logical conclusion... but we
might have gone another 100 years without reaching that conclusion if it
hadn't been for Einstein.

------
phazmatis
It's really sad how amateur most interviewers are. I learn a lot more from
them than they do from me. I actually take advantage of the few minutes they
set aside for me to ask questions to poke a bit and try to get them to go off-
script. Companies: For god's sake, choose interviewers that don't need a
teleprompter to conduct an interview. It's making you look bad.

------
R_Edward
>Four people need to cross a rickety bridge at night. Unfortunately, they have
only one torch and the bridge is too dangerous to cross without one. The
bridge is only strong enough to support two people at a time. Not all people
take the same time to cross the bridge. Times for each person: 1 min, 2 mins,
7 mins and 10 mins. What is the shortest time needed for all four of them to
cross the bridge?<

17 minutes, if you can stipulate that at the beginning of the problem, the 10
minute and 7 minute people are on opposite sides of the bridge, each paired
with one of the other two guys.

18 minutes, if they must all start on the same side of the bridge, but there
is no requirement for all of them to end up on the opposite side.

This also assumes that person who can cross the bridge in as little as one
minute has no problem slowing down to accommodate someone else's slower pace;
otherwise there's no real point to trying to share the torch.

~~~
zeidrich
I think the purpose of the puzzle is one of resource management.

It's not a hard puzzle, and I think that it's too easy to try to overthink it
to sound smart, like you've done.

The reasonable assumption is that the four people are on one side of the
bridge, and you want to have them all on the other side of the bridge.

The simple answer is that the person that takes 1 minute to cross goes with
all of the other people, and then brings the torch back for the rest.

So 10 minutes, 1 back, 7 minutes, 1 back, 2 minutes. Total of 20 minutes.

There isn't anything technically specifying that they have to end up on the
opposite side of the bridge at the end, but you wouldn't have a situation
where someone really wanted to cross the bridge and end up where they started
without a torch, and it indicates that the four people have one torch, which
implies that they're a party of 4, not 2 groups on opposite sides of the
bridge.

I think it's a good question, because it judges the state of the person being
interviewed. Are they just scared away by a simple puzzle? Do they come up
with some contrivance to try and show off how smart they are? Do they just
come up with a practical solution?

Personally, I'd give the practical answer and say 20 minutes, give or take a
bit for transferring the torch and turning around. I'd make the assumption
that they were all on one side of the bridge and want to go to the other.

When you're given a request to send a request across a network and send a
confirmation across the network, you're not going to go and send the some of
the requests to the server, and some of the requests to the client, and some
of the responses to the server, and some to the client, just because, despite
the implied context, you decided that you could make it a bit faster by doing
something that didn't make sense because it technically followed the rules.

You probably think your answer is still better, and that's why it's a decent
question.

~~~
jghn
"The reasonable assumption is that ..."

Sometimes these questions are explicitly asked to see if the candidate will
check the assumptions when there can be more than one, even if one is fairly
obvious.

------
stinos
I love puzzles - especially ones that are unicolor or close to it but do have
weird shapes - but never related it to programmings as a whole. That just
seems wrong to me so I'd say your question should be phrased otherwise as it's
far from a simple yes/no question. Just depends too much on what you thing
'programmer' means.

Programming itself is such a vague and general term me and my friends tend to
split it in smaller, somewhat better defined aspects when discussing about it.
I'd say aspects related to creating new code/design/refactoring don't have a
whole lot to do with puzzles. Lowlevel debugging of nasty problems on the
other hand does have quite a lot in common with puzzles. I should check some
research on this, but wouldn't be surpised if one effectively uses different
areas of the brain for these aspects as well.

------
area51org
People tend to presume that everyone thinks the way do. In this case, everyone
solves problems and thinks about programming the same way, right?

I've always had a more narrative approach to coding. Until I read some of the
stuff Larry Wall (Perl) has written about how he thinks, I'd assumed I was a
giant freak. Not at all.

~~~
Kluny
Has he got a blog?

------
Rooster61
I can't help but think this is a perfect example of the contrast between a
programmer and a hacker. When I think of those who enjoy puzzles, or more
accurately the mental process to solve said puzzles, I think of hackers. A
programmer is simply someone who programs.

That's not to say that you can't be a perfectly competent programmer without
being a hacker. On the contrary, sometimes, though rarely, hacker traits can
be detrimental to programming as a profession. A programmer bitten hard by the
hacker bug may become a bit too enamored with a puzzle when going about their
work on a given project, and as a result come up with a solution that
effectively solves a difficult problem but is a nightmare to effectively
maintain, especially when others are doing the maintenance.

------
flawlessvoid
I like puzzles (jigsaw or otherwise), just not as an essential criteria for
getting a job. "Wow, you solved the knapsack problem using dynamic
programming! Great. Now here's 2 million lines of 30-year old code, much of it
crufty. You'll be a natural!"

------
ThomaszKrueger
Yes, you are. Don't be fooled by companies with hiring processes that
basically say "dance for me, monkey". They have their own agenda; just because
you don't look like the programmers they would hire it doesn't mean you are
any less a programmer.

------
treehau5
This isn't the only industry this happens.

In restaurants you have line cooks, prep cooks, and then occasionally if you
are a "fancy" enough of a place you have a sous chef and an executive chef.

The one common thread here is, they are all cooks.

Now most line cooks will have never have actually "created" a dish, just like
most of us have never "created" an algorithm, (having the vision for something
new, knowing which ingredients sourced from what region will work the best,
knowing how the various intricacies of spices, how they interact with each
other, what temperature is optimal for meats, ect), but I am sure they know
how to put something new together.

------
yawn
A programmer is one who programs. You are a programmer.

There are many reasons people program. For me personally, it's to make stuff
and put it out there. Companies have to have methods of weeding people out,
and some of them pick those puzzles.

------
nraynaud
I tend to agree, I hate riddles and puzzles, I don't like trying to debug
something in an embedded system with no screen, GDB (which is a riddle in
itself), and a temporal component that prevent me from using some technique
(like breakpoint scripts that continue).

I just put up with them in the hope that I get stuff done past them.

Today I tried an online Mensa test (the quick stuff), I didn't recognize any
patterns in the domino section (I tried 5 before giving up, vertically,
diagonally, like text, nothing), I guess, some people are not made for that. I
know people who love them and are good at it, I just hope to still get some
respect from them.

------
bithush
Depends on the kind of puzzle to be honest. I enjoy puzzles (as in a physical
puzzle like the author is talking about) but only ones that are not stupidly
hard like his Escher puzzle. Sod that!

Programming puzzles are very different though. Do I hate programming puzzles?
Sometimes. Again it depends on the puzzle at hand.

As for is he still a programmer? Well if he codes and produces something that
works how he wanted it too then sure. He might be one of those programmers
that hate debugging though so ends up writing more and more code to 'fix' a
problem rather than actually find the real problem instead of coding around
it.

------
thewarrior
Ha ! And I was feeling stupid for not being able to make headway on the puzzle
on the front page that was shared from Terry Tao's page :P

On a more serious note ..

I'd like to think that raw cognitive ability would be a nice thing to have in
a programmer. In a field where things change so fast we definitely need people
are who are good at figuring things out and making things work.

Ofcourse its obvious that the best way to hire someone is to have them build
something substantial and or go over their previous open source work. When
that is always not possible then some test of cognitive ability will have to
come into the picture as a proxy.

------
bane
I look at puzzles as a problem-class that need to be solved, not the
individual puzzles need to be solved, but the fact that there _is_ a puzzle at
all should be the thing that's being solved.

95% of software development is not solving complex algorithmic problems, it's
plumbing. If the plumbing is so complex that it creates puzzles that need to
be solved, then something probably went wrong somewhere along the line.

Preventing the 95% of software development that _shouldn 't_ be a puzzle from
becoming one is something I'm very passionate about.

------
CapitalistCartr
I could have written this; It's me to a T. I build things. I like building
things. It's fine with me if it's not completely original. I can ride around
my city and point to the parts I helped build. I like that.

When I program I bring order from chaos. I can do that best by using the
discoveries of others, and building them up. I'm glad there are creative
people who love mathematics enough to figure out original algorithms; I
appreciate their work. I'm not one of them. It doesn't change the quality of
what I build.

------
mncolinlee
Jigsaw puzzles are repetitive and inefficient. They may be the antithesis of
good programming. While they might be fun as a distraction, they are hardly a
marker of programming ability. I don't like the idea that people have to have
"smart person hobbies" to be coders. Playing music, poker, shooting pool, or
racing could be equally as relevant.

The best programmers typically choose not to reimplement a solution when an
existing one works just as well. Why should we love solving the same old
puzzle from scratch over and over again?

------
DigitalSea
This is what really irks me about the industry as a whole. Large companies
like Facebook and Google have hiring processes in place that aim to weed out
the strong from the weak by making them solve complex algorithmic puzzles and
solve them on a whiteboard, and for larger companies like Facebook or Google
who have massive troves of data, this kind of makes sense to me, but only if
you're hiring a programmer to work with your data, not make things pretty or
interface with existing services.

However, what does not make sense to me is the asinine requirement that a web
developer needs to know or understand algorithms. A front-end developer
working with HTML, CSS and Javascript will never EVER need to know how to
write an algorithm. In my 12 years as a developer thus far I have never needed
to solve a complex math problem or write an algorithm to markup some HTML, the
closest I get to math problems is simplistic operations in Javascript like
calculating the scroll distance from the top of a page or mathematically
moving an element around the page in a particular way and I generally use a
calculator for these problems.

The problem is many startups try and replicate the likes of Google and have
the attitude of, "Well, if Google require you to solve complex math puzzles on
a whiteboard in 30 minutes, then that is what we will do too" \- reality
check: A developer working with HTML, CSS and Javascript does not need to know
algorithms whatsoever. Only a developer working with data or writing an
algorithm to sort it should need to know that stuff. You are not Google, so
stop pretending you only hire smart developers who know how to solve
unrealistic math problems that they will never encounter.

I have heard from friends and experience a couple of times myself, broken
recruiting processes that ask you to solve non-realistic problems and complex
math puzzles (which I always fail myself). My policy is unless I am going for
a job working and sorting through data, I should not need to know how to write
an algorithm on a whiteboard.

The only skill I think all developers should know regardless of whether you
are a front-end developer or writing complex algorithms to sort through
billions of rows of privately collected American data through a secret
Government program is regular expressions. I do not know regular expressions
extremely well, but I know them enough to be useful with them and I think this
is one area where most developers fail. You might know the latest tools, heck,
you might even know how to write an algorithm to sort through a large set of
data, but if you can not write a regular expression (even for the most basic
of tasks), then I think we have a problem.

The interview process for most developers should be simple like this: Can you
write regular expressions? (yes) or (no) - if (yes) then write me a regular
expression to get the value between two curly braces in my Node.js application
and you have got the job.

There are always going to be companies out there with this unrealistic
inflated image of how smart a developer should be. To be quite honest, I would
not call myself an overly smart person. A lot of the problems I solve on a
daily basis are merely following simplistic troubleshooting steps with a
combination of Google and reading the documentation. Most of my day job is
simply just common sense. Web developers in particular are over-glorified
Googler's with an eye for detail and a large bottle of strong adhesive used
for gluing different pieces together. And you know what? There is nothing
wrong with that, it is the truth, because I am one of those people.

~~~
Ntrails
RegEx is just ludicrous a general requirement to "program" as anything else.
I've never particularly wanted it to write the mathematical models I work
with. I can think of just a single instance where I've used one in the last
year and that was to display integers as ordinal numbers (hardly a sizeable
task).

Every job needs a spec. Every spec should inform the interviewer and the
interviewee of the skills and competencies expected by the role, and therefore
what will be brought up in the interview. Adding "everyone should be able to
_criteria unrelated to role_ " is madness

~~~
lostcolony
Agreed. I can write a regex the (very) few times I need one, but it generally
entails me looking up a cheat sheet to get the appropriate character classes.
If you were to put me in front of a whiteboard I would flub the most simple of
tasks (from the original post, "{(.*)}", I think? Did we mean to include
whitespace, and does . translate properly? Because that's partly language
dependent when it comes to white space, newlines, etc, and how the regex
parser works. Did we mean to capture empty cases? Did we intend for it to be
greedy?).

Does that mean I can't program? Ha ha ha, no. Does that mean I can't
manipulate strings like a boss? Ha ha ha, no. I first reach for the language's
tools, before I reach for regular expressions (the OP, I would first reach for
doing a string search for {, and then one for }, from the rear if you want it
greedy, and substringing what is in the middle; it's far less ambiguous, and
any dev will know exactly what it does). Even when something ~technically~
takes a regex, if what I'm looking for is just a literal (as it often is; does
this string contain X or not?), I don't need to 'know' regexes. So there's a
LOT I can do without knowing regular expressions.

Meanwhile, I -have- needed to be able to recognize that something was running
in O(n^2) time, and what I could do to optimize it to O(n). I -have- needed to
implement my own search and bucket sort routines.

EDIT: Oh, wait, no, for the regex I'd need to escape the brackets, too. Etc.
See? Now I have two problems.

~~~
moron4hire
Start using regex in your text searches while programming. It will make you
more productive (especially when you start using it with search-and-replace)
and you'll learn regex properly. Please don't parrot that Jeff-Atwood-
nonsense.

EDIT: I don't care if you ever actually use regex in a program. You should
learn regex just as a part of using a text editor.

For example, suppose I want to write a bit of repetitive code like this:

    
    
        x = x + vx * t + ax * t * t / 2;
        y = y + vy * t + ay * t * t / 2;
        z = z + vz * t + az * t * t / 2;
    

If you just copy-paste the first line and change all of the x's to y's and
z's, you're _extremely_ likely to make a mistake. There has been study in this
and it's one of the most common classes of logic error.

However, with regex search and replace, I first type

    
    
        x
        y
        z
    

Search with the pattern: (\w)

And replace with the pattern: $1 = v$1 * t + a$1 * t * t / 2;

And now that I've been doing it for a little while, it's second nature. It's
how I write lots of code.

~~~
lostcolony
I do, if it will actually save me something. Usually, I don't need anything
that actually requires me looking up or constructing a super complicated
regular expression.

Per your example, I code in a functional language. I'm even less likely to
make a mistake if I just reuse the function, than I am to apply a regex.

~~~
moron4hire
You don't have to look up how to use regex if you know how to use regex. If
you just learn how to use the tool already--which isn't very hard, the syntax
is quite limited and the salient points are nearly universal between all regex
engines--then the stuff isn't "complex". It's as complex as C or Javascript or
Scheme was on your first day of learning it. Less so, because there is less to
learn.

The example is arbitrary. The point is, sometimes you end up writing
repetitive code. Yes, even in functional languages.

~~~
lostcolony
Clarification: I know how they work. What I -don't- bother keep in my head, is
every metacharacter, character class (POSIX especially), assertions, string
replacement options, etc, because I can just look those up. The example
mentioned above is actually a really good case of why I don't worry about
remembering all the specifics; because it's really easy to screw it up. Oh, I
forgot {} were special characters, because I have -never- used them (any time
I needed repetition it was always so few times, and for a single character
class, I just repeated the character in the pattern), so I forgot to escape
them.

And let's not forget the implementation different specifics (the need to
specify multiline matching as a separate parameter into the parser, \ vs $ for
string replacement, etc)

In general, if I'm writing a regex more complicated then "Hey, does this
string match this literal?" I'm going to pull up a cheat sheet, because it
avoids issues like that. But the number of times it makes sense to do that is
really, really low.

It makes as much sense to me to say you should remember all ASCII character
codes. Why? If you know how they work, and you're not using them enough to
remember all of them automatically, it's not really a problem to just look
them up if/when you need them.

------
chasing
I like making things. If I want to make something and I don't know how, I'll
figure it out. Call that "solving a puzzle," but it's a very different
activity than solving a literal jigsaw puzzle or answering some arbitrary
question about rickety bridges.

If you enjoy making things with software, you'll be a decent programmer. If
you enjoy puzzles for their own sake, go check out some Martin Gardner books.
Those two enjoyments can overlap, but they're not necessarily dependent upon
one another.

------
clomond
Puzzles: One clear solution Algorithms: "Better" solutions. "Best" solution
may exist but hard to definitively prove. Often, things like cost and time are
real constraints in the solution to the problem. Real world
"problems"/"design": solutions are optimized for a certain set of outcomes.

I don't like puzzles either, but I think it's due to their restrictive nature
and generally non-creative solution finding process. I prefer making puzzles
over solving them.

------
ryanchamp_ICE
I'm not going to get into the fake programmer vs real programmer thing, but I
will mention the thing that most excites me about programming. For the the
author it was "design," and for me it's similar: communication.

I love being able to take a fuzzy idea, decompose it into discrete (and
concrete parts) and then transposing that idea into programming language in
such a way that not only solves the problem, but also communicates clearly
what the original intent/idea/solution is.

------
gaylemcd
If you program, you are a programmer. By definition.

I suspect what you're really asking is: why do so many companies thinking
programming == solving puzzles?

The answer is that: (1) Based on what you're defining as a puzzle, they don't.
(2) It is valuable skill (but it's also not the only skill).

\-- (1) --

While there are stupid companies that ask "puzzles", this is not the norm at
Google, Facebook, and similar companies. The "puzzles" listed at that Google
link are basically fake. Link bait. While it's possible that each of those was
asked at Google, I doubt that's where the author of that blog post got them
from. They are certainly not representative of Google questions.

The "puzzle" questions you're referring to are really more like: \- Design an
algorithm to return a random node from a binary tree \- Design an algorithm to
find the nth number divisible by only 9, 13, and 15

You can define "puzzle" however you'd like, and I'm not going to engage in
some debate over whose definition is "right." Doesn't matter (and there
probably isn't a "right") here.

In the real questions asked at companies like Google, there's typically no
sudden insight you need or trick in the wording. Rather, these questions are
about working through a different problem and creating optimal solution (and
recognizing tradeoffs along the way).

\-- (2) --

That _is_ an important skill for a developer. It _is_ valuable for a developer
to be good at that, and even enjoy it.

Maybe you don't care about making your solution better. Get it done. Get it
out the door. Even if it's not perfect.

That probably makes you a less awesome developer, but it doesn't mean that you
are necessarily a bad developer. There are lots of parts of being a "perfect"
developer. \- Enjoying testing. \- Understanding what users want. \-
Architecting a system. \- Understanding the lower level computer architecture.
\- Being a perfectionist. \- Not being a perfectionist and knowing when you
just need to get something done. \- Knowing how to scale a large system. \-
and so on.

There are a TON of things here. No one has all of them.

You _might_ be missing one of them, and it's a fairly important one. But it's
not the only one.

I once worked [worked = prepping the startup for acquisition interviews] with
a developer who was, honestly, quite stupid. He was exceptionally poor at
developing good algorithms. His code however was correct.

He would be terrible at a company like Google. But at this company, he was
very good. You see, he was very detail-oriented and thorough. If you want
someone to write a correct bit of code for a very tedious and boring problem,
he's your guy.

Is he a good developer? In the right role, yes.

This doesn't mean that Google is flawed for doing interviews this way - not at
all. Their goal is not to hire all good developers. Their goal is to hire
enough good people and to not hire bad people.

Problem solving/algorithmic skills and coding skills is a decent filter for
_that_ purpose.

~~~
throwmeout
First off, I've read most of your books. Great job with them! Now, your
response seems fair enough and I completely understand what your trying to
say.

However, without going into specifics. How does an interviewee handle/convince
an interviewer with a preconceived solution?

For example, Interviewer A has an interview tomorrow and plans on asking this
really slick problem that has one way of being solved well. A looks this way
up and knows the ins and out of it. Now as an interviewee,if B were to come up
with a 100 ways of handling the problem (starting from brute force) but fails
to reach the "cool" solution because he has only 45 minutes of time . Do you
think the interviewee would be considered a good candidate?

I'd say that the interviewer has hardly learnt anything about the candidate by
asking such a problem. But then again, I could be wrong.

~~~
gaylemcd
Eh... it depends.

You could have a question that can really only be solved optimally one way but
that still provides adequate room to demonstrate problem-solving skills (even
without knowing the "slick trick"). Such a question could still be a
reasonable question.

Of course, many questions with slick tricks aren't like that. The interviewers
who ask these questions also tend to be worse, which exasperates the problem.

In the situation you described - the candidate might still be considered a
good candidate. It depends what the interviewer is looking for.

------
kazagistar
I love puzzles. I love to ask people who were just interviewed to tell me all
about any puzzles they got, and try to see how long it takes me to work them
out. I feel fairly confident that I have a knack for them.

But it isn't actually a good interview strategy. I don't think any company
should hire me over someone else due to puzzle solving. If I were to do an
interview, I would probably leave out puzzles entirely.

------
dead10ck
As many others have already said, if you've been programming for 18 years,
then yes, you are a programmer. I wouldn't say you're crazy for not liking
puzzles, but I would say you're crazy for not liking puzzles _and_ pursuing a
Ph.D in (what I assume is) Computer Science, since that is invariably what
most research involves, and what most Ph.D level jobs are going to involve.

------
timsco
Never let an HR manager or recruiter's decision or feedback be a reflection of
your self worth. They rarely know much about our jobs.

------
logfromblammo
I have lost count of the number of job interviews where I have been asked to
solve a puzzle or brainteaser. I very much enjoy it when I can tell them "I've
heard that one before: the answer is X," until they run out of alternate
challenges. But I also enjoy it when I actually get to solve a new one. It's
like my payment for doing the interview, even if there's no offer.

This isn't really a strike against the company. This is just an indicator that
they haven't had much experience at hiring people. They clearly are all
copying from the same source, who was in turn copying from the books and
magazines filled with puzzles and crosswords that I have been reading since I
was old enough to do so.

I know from firsthand experience that the puzzles they are using are not the
ones that I feel best correlate with coding ability. They are instead the ones
that can be asked and solved quickly, with a single correct answer. They are
generic filler, like "what's your greatest strength?" and "what's your worst
weakness?" Those questions just show you that your interviewer does not know
how to evaluate your fit for their job.

Programmers translate human problems into procedure-based solutions. They do
not need to solve puzzles, except insofar as it can be puzzling to get stupid
agents to perform complex tasks without step-by-step supervision from the
principal.

Hacking is an essential part of the wider culture that formed around early
programmers, but this culture is somewhat more inclusive than most. Certain
activities draw forth the archetype. Safecracking, lockpicking,
geocaching/orienteering, scavenger hunts, reverse engineering, deckbuilding
strategy games, Rube Goldberg machines, drone photography, robotics, etc. That
type of person is drawn to programming, not necessarily the other way around!

We don't need a cultural battle. I don't particularly care for "brogrammers"
or "rockstars" or Nerf battles and foosball at the workplace, but I don't
begrudge those types the right to call themselves programmers and to claim to
work for technology companies.

But just as they should not be expected to solve brainteasers during their
interviews, so too should I not be expected to play Ping Pong against a
company founder during mine. I think monoculture is dangerous and foolhardy.
Please, lets just judge our worth as programmers by how well we can write
programs.

------
kjjw
I don't know but where can I get that jigsaw?

~~~
jerf
~5 seconds: [http://www.amazon.com/Buffalo-Games-M-C-Escher-
Portrait/dp/B...](http://www.amazon.com/Buffalo-Games-M-C-Escher-
Portrait/dp/B00BNUPTDY/ref=sr_1_2?ie=UTF8&qid=1413908497&sr=8-2&keywords=escher+puzzle)

~~~
willis77
Apparently a web search is not the kind of puzzle he wanted to solve.

~~~
eric_h
He's better at jigsaws.

------
incanus77
Love this. I like puzzles (and scifi) and definitely fit the more traditional
model of a programmer, though I'm entirely self-taught and didn't take CS in
school. I really don't like algorithms that much. What I do enjoy is API
design, writing elegant code that is maintainable, and solving the macro,
human-scale problems.

------
calvinbhai
I hate puzzles. I hate puzzle/trick questions. I have been programming for
more than 10 years.

Usually when I interview with a company, I am upfront with them when they
present me with a puzzle as part of the interview process, and tell them that
I don't do puzzles. If that pisses them off and thats the end of the
interview, fine.

At least, I'm not wasting time acting like I love solving the puzzle, which
the interviewer got to know online and wants to show off who's the boss.

On the flip side, if someone gave me a really tough coding assignment, and I
failed to even get the basics right, I'll accept it gracefully, go back home
and figure out what I need to improve at solving that problem.

 __Often __, I have noticed that these tough interview questions are a way to
satisfy the interviewer 's ego, more than finding the right candidate for the
position needed.

Those who ask puzzles for s/w engineering jobs don't really know how to
interview a prospective candidate or what exactly to look for.

Unless you are interviewing for job which involves you being a Sherlock
Holmes, there's no way your ability of solving puzzles indicates how capable
you are with programming.

Really glad this is getting more visibility. Thanks Google for starting the
Puzzle craze. (glad that they are trying to put an end to it)

------
baddox
The author should probably at least take a stab at defining his usage of
"puzzle." There's a big difference between a jigsaw puzzle and, say, the
Portal games. In fact, jigsaw puzzles are a _very_ different endeavor than
logic/programming puzzles and many puzzle video games.

------
WalterBright
I don't write programs because I like solving puzzles. I write them because I
like creating things, and it's a lot easier to create things with programs
than with a machine shop.

I also enjoy the competition with other compiler/language vendors to produce a
better product.

~~~
zura
> I write them because I like creating things, and it's a >lot easier to
> create things with programs than with a machine shop.

Exactly. This is one of the main reasons for me as well - creating things
without buying or manufacturing physical materials.

~~~
WalterBright
I designed and built a steam engine in high school in metal shop. It took
forever and was beyond my machining skills. It didn't work, due to being so
poorly made.

I tried again in college, with a much better design. The guy who ran the
college machine shop (he built custom lab equipment for researchers) helped me
a lot. It still took months. This time, it did run, but it took so much time
it didn't satisfy my urge to create things - my designs ran far, far out ahead
of any possibility of making them.

Not so with software!

------
FrankenPC
Programming is a pyramid. Each strata building on the other. Anyone can join
in on any level to contribute. I enjoy living on the framework and data
levels. I really don't like front end or bare iron work. That certainly kills
some job opportunities, but I'd rather be happy.

------
ww520
When you are young and have nothing to show, puzzle solving, like a school
degree, is a way for other people to judge you. When you have experience and
track record, puzzle is like meh. People still using puzzle to judge an
experienced developer are not very good in evaluating others.

------
LukaD
I love programming, but I hate puzzles.

Solving puzzles is nothing like programming to me. Programming to me means
crafting your own pieces of the puzzle and being able to create something
unique and beautiful.

Of course programming has some bad and boring sides. I would compare those to
solving a jigsaw puzzle.

------
geekam
Oh lord, I could not have read this ata more apt time. I am going through such
a crisis right now, professionally. I keep interviewing at these places where
they just want to know if I can solve 9 ball problems or not. I almost feel
like an impostor. Glad I read this.

------
chrisdone
I feel the same way about games that he feels about jigsaws. They're fun
enough but they're inherently contrived and produce no real value. I read
books and watch movies for narrative experiences. While there's a growing
minority of games that have real emotional, sophisticated and even literature-
level narratives, at the end of the day, most games require you to solve
contrived puzzles to advance the narrative.

On the other end, there are games like that one where you build pieces from
blocks and it's a little world, people have expressed their artistic side with
whole castles with automations and calculators. These are more like LEGO,
Meccano or other tool; they're a substrate, like a programming language,
something you build on. I wouldn't call them games.

Although I will grant that games that pit you against or collaborate with
other human beings is worth it to some degree, because you're spending time
with people (which is why Chess is bloody boring and pointless to play against
the computer), it's all noughts-and-crosses with bells and whistles.

Coming back to his point about jigsaws, while it is satisfying to complete
one, personally, any time spent putting in active effort (as opposed to
passive effort, like in the case of a novel or movie or theatre), I'd prefer
to be doing something actually constructive; to produce something real, either
artistically (I paint canvases), or technologically (I'm a programmer). Rather
than maintaining these “farms” and cyberpet-style games, or the games where
you're digging for gold and collecting resources, I'd rather maintain my bike,
go grab some materials from the store and do some DIY in my apartment, plant
some things in my garden, etc. Whenever one of my gamer friends explains a
game to me, I'm thinking more about how I'd make that than how I'd play it.
I'm not saying people who like to spend time doing these things are wasting
their time, just that I don't share that desire at all.

Puzzles in a job interview are a poor idea. People don't solve puzzles on
their job, with their manager watching them do it. They don't get sacked for
failing to solve the puzzle (which failing a job interview is tantamount to;
your career depends on it). And if they can't solve a puzzle in 15 minutes,
they spend all day on it. Or all week. They ask their colleagues for help. If
it's too hard, the product manager considers breaking the problem down. Asking
contrived puzzles is such a silly idea that I'm biased against companies that
try to ask them for job interviews.

------
iconjack
When Google and Facebook ask if you enjoy puzzles, I'm pretty sure they're not
talking about jigsaw puzzles! They mean stuff like this:
[http://realmode.com/punch22.html](http://realmode.com/punch22.html)

------
j_baker
I'd like to point out that the Google quote is not from Google's webpage and
is in fact likely a banned interview question. The facebook quote on the other
hand is from their webpage on a tool that _is_ used for recruiting.

------
amitlan
Found this related article by an author I've come to respect recently

"Organizational Skills Beat Algorithmic Wizardry"
[http://prog21.dadgum.com/177.html](http://prog21.dadgum.com/177.html)

------
crimsonalucard
Sure you are still a developer if you don't know algorithms or programming
puzzles. You can hold a job and be competent and churn out quality code.
However, you are a BETTER programmer if you do know these things.

------
sp332
[https://news.ycombinator.com/item?id=6583580](https://news.ycombinator.com/item?id=6583580)
Dear startups: stop asking me math puzzles to figure out if I can code

------
yarrel
Optimizing out inefficiency and waste is part of good programming. So yes.

------
buckbova
Only puzzles I enjoy are researching a bug and reading through code to find
the bug and propose a fix. I enjoy this more than writing new code, even if
the codebase is completely foreign to me.

------
alecbenzer
> Coming up with algorithms is the programmer’s version of puzzle solving.

I'm not really seeing the connection. Are they both just things you don't
like?

------
mediumdivision
_> What I like about programming is not problem solving — it’s design_

Apparently in some alternate universe where design is not considered problem
solving.

------
cevaris
> Maybe I should refer to myself as software designer rather than programmer.

I think you should refer to yourself as an Software developer, not a Software
Engineer. You can be good by referencing your previous experiences. But
knowing how to solve and loving puzzles is a nice sign that this individual
can solve problems quick and efficiently. This latter case is less common
though. Most programmers are Software Developers, just referencing sdk's and
frameworks and minor "new" development.

------
slapresta
Turns out 500-pieces puzzles are more like an exercise in banality and less
like actual puzzles.

------
the_cat_kittles
there are a number of ways to be a good programmer: being a skilled puzzle
solver / algorithmist is one of them, being good at designing apis is another,
deciding what even needs to be built is another.

------
interdrift
I don't really want to sound off-topic but did you guys get the answer?

~~~
interdrift
I thought about it like that : since the one whos cost is 1 is a good roamer
he should get each of the other ones? This looks too damn easy?

~~~
FlyingLawnmower
That's a good solution to start off with, but given the current costs, it's
not the most optimal one. A lot of time is wasted by sending C and D to cross
independently. If you manage to get them to cross together at one point, you
will ultimately save some time.

~~~
interdrift
Okay, so my best bet is that the optimal solution is 17 minutes.

------
chuck8088
I like puzzles a little bit, but I kinda suck at them.

I am an antiprogrammer though.

------
beyondcompute
Thank you for sharing! So good to know that I'm not alone. :)

------
LeicaLatte
Weird interview puzzles are out. If you or your community continues to lazily
fallback on "puzzles", you must quit your job now.

It is worth solving the problems we solve, however boring and straightforward
the solutions can sometime be.

------
jjzieve
As someone who doesn't play video games. I can relate.

------
kakakiki
My life story! Relieved to see similar people :)

------
mrcactu5
you're a programmer, but you're certainly not a computer scientist.

you like design! design a puzzle where the game is to optimize features for
your end users.

how many wonderful algorithms have shitty interfaces? i know because I have
written them - and nobody uses them because the interfaces suck.

i promise to keep an open mind to design, if you try a jigsaw once in a while

------
pmelendez
Correlation is not causation :)

------
lancejpollard
i hate puzzles too

------
vacri
The discussion here is far more interesting than the article. "I don't like
jigsaw puzzles, therefore I'm not supposed to be good as a programmer"?
"Facebook and Google aren't looking for people like me, therefore I'm not
supposed to be good as a programmer"? It seems to be intentionally narrowing
the definition in order to make a somewhat whiny point.

 _What I like about programming is not problem solving — it’s design. How do I
design an application in such a way that people will understand it?_

Or, to put it another way, 'what I like about programming is not problem
solving, it's problem solving'. The author somehow distorted the term 'problem
solving' into 'puzzle solving'. Improving the usability of something _is_
solving a problem. The author is tilting at windmills.

------
Fando
No you're not, abandon ship.

------
danschumann
Best stick to the shallow end of the pool if you can't swim.

Do you program? Then you are a programmer. However, in some circles, where
extremely complex problems need to be solved, they would say, " No ", because
you can't do any of the programming required, and you'd be as useful to them
as a rock, only less useful because you take air and food.

I play volleyball occasionally, but if I went to the olympic men's team, they
would tell me I don't really play volleyball, I've not yet earned the right to
say that I have.

It's a matter of skills and standards. In the right context I can call myself
a car mechanic.. like if my car needs air the tires, but beyond that I'm not.

If you can program simple things on the web you can get away with calling
yourself a programmer until you run into problems that make you realize you're
not, like complex graphics algorithms.

I can cook food at home, but if I walk into a 3 michelin star restaurant and
try to get a job, it's not like I'm going to write an article if they don't
like my food. Boo hoo, they made me cook for them, how dare they? Whatever
they're doing, it's working, so why knock the process that produces success
when you can mimic it?

~~~
general_failure
I have to admit, I don't understand what you are trying to say.

Are you saying puzzles are somehow the higher level of programming? You are
completely wrong.

~~~
danschumann
Lol.. How can you say I am wrong when you don't understand what I am saying?

~~~
general_failure
Mm, I asked a question before that sentence. I guess I should have preceded it
with "if you are, then". Sorry about that.

